In a threat model, what does a recorded assumption need to contain to be useful?
answer
- the model's unproven load-bearing beliefs
- invisible in the finished threat list
- someone must be able to argue with it
- who guarantees it, and when rechecked
- falsifiable claim, owner, consequence, trigger
basics
~20 sA usable assumption states the claim in a form that could be proved false, names the team that owns it, says which threats come back if it is wrong, and gives an event or date that forces a recheck.
solid answer
~50 sAn assumption is something the model treats as true without proving it, usually a control another team provides or a property of the environment. To be useful it needs four things: the claim phrased so someone could falsify it; the owner who actually guarantees it; the consequence, meaning which threats re-enter the model if it is false; and a revalidation trigger. For example, a nightly reconciliation job's model might record "the upstream extract is schema-validated by the ingest team before it lands", with the note that if it is false a compromised upstream system can push rows that reconcile cleanly and corrupt the ledger and its audit trail. Written that way, the owning team can dispute it — and a dispute is a threat found at design time. Unwritten assumptions are the classic missed-threat cause: a reader cannot tell "no threat here" from "we never looked here".
go deeper
Be ready to say what an assumption is and give one concrete example from a system you worked on. Knowing that assumptions belong in the written model, not just in someone's head, is enough at this level.
You are expected to phrase an assumption so it could be shown false, attach an owner, and explain why an unrecorded assumption is a missed-threat cause rather than a documentation nit.
Show that you actually route assumptions to the teams that own them and treat a rejected assumption as a finding. Be ready to describe an assumption you wrote that turned out to be wrong, and what it cost.
Own the argument that the assumptions register is the model's honest record of its blind spots, and that its fields should be designed for later triage — consequence and trigger, not just the claim.
## What an assumption is in a threat model A threat model is a set of claims about what could go wrong in a design. Under every one of those claims sits something the model treats as true without proving it: that a dependency behaves a certain way, that a control someone else operates is switched on, that some property of the environment holds. Those are **assumptions**. Keep the vocabulary straight. A **threat** is what could go wrong. A **vulnerability** is the flaw that lets it happen. A **risk** is the rated consequence. A **control** is what you do about it. An **assumption** is none of these — it is a load-bearing belief that decides which threats you bothered to write down at all. That is what makes an assumption dangerous: it is invisible in the output. The moment you decide "the upstream extract is already schema-validated", you stop enumerating tampering threats against malformed rows on that flow. The finished model looks complete. Nothing in it says *we chose not to look here*. ## The four things a usable assumption records **1. The claim, phrased so it could be shown false.** "The ingest team schema-validates every record in the nightly extract before it is written to the reconciliation staging table" can be checked by someone. "The pipeline is secure" cannot. If nobody could design a test that fails, you have written a mood, not an assumption. **2. The owner.** Name the team or component that actually guarantees the claim — the ingest team, the platform team, the gateway configuration. An assumption with no owner is a belief nobody can confirm or dispute, and it will never be verified. **3. The consequence — which threats it suppresses.** Write down what re-enters the model if the assumption turns out to be false. This is the field people skip, and it is the one that gives the assumption its priority later: an assumption whose failure reopens one low-impact threat is not the same object as one whose failure reopens ledger tampering. **4. The revalidation trigger.** An event or a date that forces a recheck: "any change to how the extract is produced", "reviewed at each quarterly design review". Without it, the assumption is true on the day it is written and unexamined forever after. A compact register does the job: ``` Claim | Owner | If false | Recheck on Extract is schema-validated on write | ingest team | tampered rows reconcile as clean | any extract format change Reconciliation output is append-only | our service | audit trail can be rewritten | storage change; 6 months ``` ## Why it is an artifact rather than a footnote Writing the assumption down changes who can argue with it. A belief in the modeller's head is unfalsifiable by definition; the same belief in the model, addressed to a named team, is a claim that team can **dispute**. Half the value of the assumptions list is the conversation where the owning team reads "you validate this extract" and answers "we validate the streaming path, not the nightly one." That correction is a threat you just found — at design time, for the price of a sentence. It also survives people. The engineer who knew why a flow was left unmodelled changes team; the register is what tells their successor that the gap was a decision rather than an oversight. ## Worked example A nightly reconciliation job compares a ledger against an extract from an upstream internal system. The modelling session records: *"The upstream extract is already schema-validated"* — owner: the platform data team; if false: a compromised upstream system can inject rows that reconcile cleanly, corrupting both money movement and the audit record; recheck on: any change to the extract producer. That single line does three things a diagram cannot. It tells a reader why no input-tampering threats were enumerated on that edge. It hands the platform data team something they can accept or reject. And it puts a named consequence — corrupted ledger and a false audit trail, from a compromised internal system rather than an anonymous internet attacker — against a claim that otherwise reads as harmless housekeeping. ## Common failures - **Untestable phrasing.** "The infrastructure is hardened", "the internal network is trusted." Nobody can confirm these, so nobody does. - **Assumption laundered into mitigation.** The model shows a threat as *mitigated* because someone else's control handles it. It is not mitigated by you; it is assumed away, and the model should say so. - **No owner.** The claim sits in the document unaddressed, and the team that could have disputed it never sees it. - **Recorded once, never revisited.** The assumption was true when written and quietly stopped being true later. - **Left implicit entirely.** The most common one. The reader of the model cannot distinguish "no threat here" from "we didn't look here". ## What an interviewer is listening for That you treat assumptions as first-class output of the modelling session, equal in standing to the threat list; that you can phrase one so it is falsifiable and owned; and that you can say what the model loses if it is wrong. A candidate who describes the assumptions list as "context we put at the top of the doc" has missed that it is the record of the model's blind spots.
- How would you rephrase "the internal network is trusted" into a usable assumption?Name the actual claim, its owner and its scope: "only workloads in the payments VPC can open a connection to the reconciliation service, enforced by the platform network team's policy". That can be checked, disputed and rechecked. The original phrasing is a mood — nobody can test it, so nobody ever does.
- What is the difference between recording something as an assumption and recording it as a mitigation?A mitigation is a control present in the design you own and can test, so the threat is genuinely addressed. An assumption is a claim about something outside your control, so the threat stays open with residual risk noted. Marking an assumption as a mitigation closes a threat that nobody has actually verified, and closed threats stop being read.
- Why does the consequence field matter more than it looks?It is what makes the register triageable later. If each assumption records which threats re-enter the model when it is false, you can rank revalidation by blast radius rather than by gut feel, and a reviewer can see instantly whether an unverified claim is trivia or the thing the whole model rests on.
It is the difference between a survey that says "no faults found" and one that says "we did not open the floor; if the joists are not as drawn, everything above is unsupported". The second tells you where to look next.
saying these in an interview costs you the question
- Calls assumptions background context rather than model output
- Writes untestable claims like the platform is secure
- Records an assumption with no owning team named
- Marks an assumed control as a completed mitigation
- Leaves assumptions implicit and expects the diagram to imply them
- Never states what threats return if the assumption is false