What does mandating a data-flow diagram for every design review cost you?

## The real argument for standardising Mandating one notation across an organisation is not bureaucratic instinct; it buys concrete things. Reviews become **comparable**: you can look at forty models and see which systems were examined at what depth. The practice becomes **teachable**, because a new engineer learns one grammar rather than choosing among five. Reviews become **runnable without a specialist**, since an element walk over a data-flow diagram is mechanical enough for a team to do unaided. And a consistent artifact is something a programme can measure, sample and audit. For an organisation trying to get from no threat modelling to some threat modelling, that floor matters more than the ceiling. ## The cost, stated precisely The notation becomes the definition of the threat surface. Three effects compound. **Whole threat families go unreported.** A data-flow view cannot express message ordering, delivery semantics, retry behaviour, failure branches, or the physical placement of components. So replay, check-then-use races, double-processing on retry, spills into undrawn failure sinks, and co-location of components that the design claims are separate simply do not come up. Not because anyone decided they were out of scope, but because there was no box to write them in. **Absence looks like assurance.** A completed template with no ordering findings is indistinguishable from a system with no ordering threats. The artifact says the review happened, and everyone downstream reads that as coverage. **Teams satisfy the template rather than think.** This is the deepest cost. Shostack's four questions are: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job? A mandated template answers the first question well and turns the second into a form-filling exercise. The fourth question, which is the one that keeps a practice honest, gets answered by the existence of the completed form. ## The design I would actually run - **Keep the DFD as the default and mandatory entry point.** It is the right first instrument: it inventories data stores, external entities and boundary crossings better than anything else, and it is the cheapest thing to teach. - **Attach an explicit trigger list.** Name the conditions that require a second view, in the team's own language: there is a handshake or multi-step protocol; a flow is retried or delivered at least once; there is a fallback or degraded path; two components share a host, a process or an identity; a failure branch writes data anywhere. Any trigger means a second, throwaway view of that one interaction, not a second full model. - **Ask the unhappy-path questions per flow.** What happens on failure, on repeat, out of order. Three questions per flow catches most of what the notation hides and costs minutes. - **Measure findings by category, not by count.** A programme reporting hundreds of findings, none of which is ever an ordering, retry or placement threat, has found its blind spot. Category distribution is the metric that detects a notation ceiling; raw counts hide it. - **Let the second view be disposable.** The reason teams resist extra diagrams is maintenance. A message-ordering sketch drawn on a whiteboard during the review, photographed, and attached to the model, is not an artifact anyone has to keep current. Only the DFD earns ongoing maintenance, because only it describes the whole system. ## The judgment being tested An interviewer asking this wants to see that you can hold two things at once: that consistency is what makes a practice scale, and that consistency is also what makes it stop learning. The weak answers sit at either pole, either defending the template because it is the standard, or arguing that every team should pick its own notation, which produces models nobody can compare and reviewers nobody can train. The strong answer keeps a mandatory floor and makes exceeding it cheap, explicit and triggered by conditions the team can recognise without a security specialist telling them. The same reasoning generalises past diagrams. Any standardised security artifact, a checklist, a control set, a question list, caps the findings at what it has room to express, and the job of whoever owns the programme is to watch for the categories that never appear.