In a threat modeling session, what is the system boundary and how do you decide what falls inside it?
answer
- a decision about the exercise, not a drawing
- include what you can actually act on
- three axes, not just your components
- system, dependencies, operators
- exclusions written with reasons and re-entry conditions
basics
~20 sThe system boundary is the explicit line naming which components, dependencies and people a threat model reasons about. Draw it around what your team can act on, and record everything else on a written out-of-scope list.
solid answer
~50 sThe system boundary is the written statement of what a given threat model covers: which components, which dependencies, and which people. The practical rule for placing it is to include what you can act on - your own services and data stores, the interfaces you expose, the behaviour you can specify or negotiate with a dependency - because threats found there turn into work. Scope has three axes and teams usually only remember one: the system itself, its dependencies (libraries, platform, another team's service), and its operators (your admins, another team's on-call, a provider's staff). Whatever you exclude goes on an out-of-scope list with a one-line reason and what would pull it back in, so a later reader can tell the difference between `we looked and found nothing` and `we never looked`. A boundary that is not written down is not a boundary, it is a memory that expires when the session ends.
go deeper
Be ready to say in one sentence that a threat model covers a stated set of things and explicitly excludes others, and that the exclusions are written down rather than assumed.
Explain the three scope axes - the system, its dependencies, its operators - and the include-what-you-can-act-on rule. An interviewer expects you to distinguish the scope of the exercise from a privilege boundary inside the design.
Show judgment on the hard cuts: the dependency where you scope the interface but not the internals, the operator you decide not to model and say so out loud, and an exclusion entry written well enough to be useful next year.
Own the organisational consequence: seams between two teams' models, exclusions used to dodge findings, and the norm that a model without a written boundary does not count as a model in your review process.
### The boundary is a decision, not a drawing Before a threat model can enumerate anything, somebody has to say what the model is about. That statement is the system boundary: the explicit description of what this analysis covers and, just as importantly, what it does not. It is a scoping decision made by people and written as a couple of sentences plus a table. It is not the same thing as a trust boundary drawn inside a data-flow diagram - that one marks a change of privilege between two elements of the design, while the system boundary marks the edge of the exercise itself. The reason to write it down is that a threat model is read later by people who were not in the room. A reviewer holding a finished model cannot tell the difference between `we examined the shared identity service and found nothing worth listing` and `we never looked at the identity service` unless the boundary says which happened. Absence of threats and absence of looking are the same shape on paper. ### Three axes: system, dependencies, operators Teams that scope badly scope on one axis - the components they own - and forget two more. **The system.** The services, data stores, scheduled jobs, queues and interfaces the team builds or configures. This is the easy part and is what most people mean when they say scope. **The dependencies.** The libraries, the platform, the managed services and the other teams' systems this one calls or is called by. Each is either in scope (you will reason about what happens when it misbehaves) or out of scope (you will not), and the choice is rarely all-or-nothing. A common and defensible split is `the interface is in scope, the internals are not`: you will model what a hostile, broken or unexpectedly slow response from that dependency does to you, but you will not model how it is built inside. **The operators.** The humans and automation holding legitimate privileged access - your own administrators, another team's on-call engineer, a support tool, a managed provider's staff. Whether a malicious or compromised operator is a modeled actor is a scope decision, and it is the axis most often left silent. It matters because it decides which threats are even sayable: if operators are out of scope, abuse of a support console cannot appear in the output at all, and nobody reading the model will know why it is missing. ### Where to put the line The workable heuristic is *include what you can act on*. If you could change a design, add a control, negotiate a contract term, or raise a ticket somebody would pick up, that thing belongs inside the line, because threats found there become work. If the only possible outcome of analysing something is a shrug, it belongs on the out-of-scope list where someone who can act may pick it up later. Two secondary rules keep this honest. First, scope to the decision the model serves - a model that exists to approve a design has a different edge from one that exists to prioritise a hardening budget. Second, never move the line to dodge an uncomfortable finding. A boundary drawn so that a dependency's known weakness stays out of the report is the most common dishonest use of scoping, and it is usually visible: the excluded thing is the one everybody in the room was arguing about. ### The exclusion list is part of the artifact An out-of-scope entry is worth almost nothing as a bare component name. A useful entry carries four things: what is excluded, one line of why, who owns it if anyone does, and what would pull it back in. Consider a marketing-site rebuild that authenticates staff through a shared internal identity service. Cutting that service out of scope is the right call - the rebuild consumes tokens and cannot change how they are issued, so re-modeling it would double the session for no actionable output. But cutting it *silently* leaves the next reader unable to tell whether token handling was ever considered, and hides the one condition that makes the cut wrong. Written properly the entry reads: *shared internal identity service - out of scope, owned by the platform team and modeled by them; this rebuild only consumes tokens; back in scope if we ever issue or refresh session tokens ourselves.* That sentence survives a year. `Identity: out of scope` does not. ### Failure modes worth naming A boundary that includes everything is the same as no boundary: the session never converges and the output is a shallow list nobody prioritises. A boundary that is remembered rather than written evaporates when the facilitator changes teams. A boundary that ignores the operator axis produces a model that looks complete while being structurally incapable of describing insider abuse. And an exclusion read as a safety claim - `out of scope` taken to mean `safe` - is exactly how a gap ends up sitting between two teams who each assumed the other had it covered.
- Are a managed database provider's operators inside or outside your boundary?It is a deliberate call, not a default. Put them in scope only if you will act on the answer: for a securities order-matching engine you might, and then you owe real design output such as client-held encryption keys, dual control on privileged actions, and independent audit capture. If you have no intention of changing anything, saying they are in scope is scope theatre - exclude them explicitly instead and name who carries that risk.
- What should an out-of-scope entry contain beyond the component name?Four things: what is excluded, one line of why, who owns it if anyone does, and the condition that would pull it back into scope. The re-entry condition is the part with the longest shelf life, because it tells a future reader when the cut stopped being valid - for example, when the consuming system starts issuing its own tokens rather than only validating someone else's.
- What goes wrong when a team never writes an out-of-scope list?Two teams each assume the other covered the seam, so nobody does. A reviewer cannot distinguish a component that was examined and cleared from one that was never opened, so the model reads as more complete than it is. And the exclusions get re-litigated in every session, because the reasoning behind last quarter's cut was never captured.
It is the difference between a survey and a fence. The survey says which land this report describes and which land it deliberately leaves to the neighbours - and it names the neighbours so someone can go and ask them.
saying these in an interview costs you the question
- Says the boundary is just the network perimeter
- Treats scope as whatever the diagram happens to show
- Leaves exclusions unwritten and relies on shared memory
- Reads out of scope as a claim that it is safe
- Moves the line to keep an awkward dependency out of the report
- Never considers whether operators are modeled actors