How do you decide how deep to decompose a data-flow diagram for a threat model?

## The wrong question and the right one The wrong question is *what level should our threat models be drawn at?* — it invites an org-wide answer like *everything to level 2*, which produces diagrams nobody reviews and which are wrong within a quarter. The right question is *what decision is this model supposed to inform, and what depth is needed to inform it?* Decomposition is selective by design. A model can be level 0 in most places, level 1 across the middle and level 2 in exactly one branch. That is not sloppiness; it is the point of having levels at all. ## Worked example: the settlement redesign A retail bank's estate model has, at level 1, about a dozen boxes: channels, customer identity, fraud scoring, ledger, reporting, and one large box labelled *core banking*. That box has stayed closed for years, and closed was the right call — nothing was being changed inside it, and every threat that reached it did so through the same two interfaces. Then a settlement redesign lands. The new question is specific: can an authenticated corporate customer, using entirely legitimate credentials, get a payment instruction applied twice, or applied to a beneficiary other than the one they authorised? The asset at risk is money, and the adversary is a customer with valid access rather than an outsider. That question is unanswerable at level 1, because it depends on where the instruction is validated, where it is queued, what re-signs it after enrichment and which store is authoritative for its status. So *core banking* opens to level 2 and the other eleven boxes stay exactly as they were. The output is a model that is deep in one branch and coarse everywhere else — and that asymmetry is legible to a reviewer, because the depth marks where the decision was. ## Three tests for going one level deeper **1. Would another level change a control decision?** If every sub-element you would draw ends up with the same mitigation — the same authentication, the same encrypted channel, the same audit record — then the extra level adds elements and no decisions. Stop. If instead the sub-elements diverge (one sub-process handles authorised instructions and another handles enrichment under a service identity), the level is buying you something. **2. Does a trust boundary run inside the box?** This is the strongest signal. A box that looks like one component but partly executes under different credentials, in a different account, on a different operator's infrastructure, or under a different team's deployment control, is hiding a boundary. Boundaries are where threats concentrate, so a hidden one is the single best reason to decompose. Conversely, a box that is genuinely one trust context rarely repays opening. **3. Who owns the box?** If another team owns it and models it themselves, do not decompose it here. Model the *interface*: what crosses, under what identity, with what assumptions on each side. Record those assumptions explicitly so the two models compose. Decomposing someone else's component from the outside produces a diagram that is wrong and unmaintained. ## Signals that you have gone too deep - Elements that map one-to-one onto functions or classes. A DFD is not a call graph, and threats do not attach usefully to that granularity. - A page that takes longer to explain than the threats it produced are worth. - Sub-elements whose threat list is identical to their siblings', copy-pasted. - A diagram that was accurate at the time of drawing and is now unmaintainable, because it encodes internals that change weekly. Depth costs review time and rots fastest. A shallow diagram that is true beats a deep one that was true. ## Depth versus a different notation Sometimes the pull to decompose is really a pull toward the wrong tool. If the pending question is about ordering, retries or error handling, more DFD levels will not answer it, because the notation does not carry sequence at any depth. Recognising that is part of choosing depth well: you go deeper for *structure and boundaries*, and you change notation for *behaviour over time*. ## Handling the stakeholder who wants everything at level 3 Ask the question that ends the argument: *which control decision would change if we drew it?* If nobody can name one, the level is documentation, not analysis, and it will be stale before it is read. If somebody names one, you have just found the branch worth decomposing — and only that branch. ## Iterating when the decision is not clear yet Early in a design you may not know where the interesting part is. The workable pattern is to start at context and level 1, enumerate threats there, and let the results point downward: the box that accumulates the most unresolved or highest-consequence threats is the one that earns level 2. Depth is then an outcome of the analysis rather than an input to it, and you can defend every deep branch by pointing at the threats that drove it.