How complete must a recovered data-flow diagram be before you start enumerating threats on it?

## Why this is a judgment call and not a checklist Recovering an undocumented system is an unbounded activity. There is always one more configuration file, one more log query, one more person who might remember. Meanwhile the system is running, unmodeled, and the reason you were asked to model it has not gone away. The principal-level skill is defining "good enough" in terms of the decision the model has to support, then defending that line. ## A concrete forcing case On day one of an acquisition you inherit the acquired company's marketing-automation stack. There is no documentation of any kind. What you have is its identity role bindings, its network flow logs and its request telemetry. The data at stake is customer personal data and consent records. The most immediate adversary is not anonymous: it is the acquired firm's contract operators, who still hold working credentials and whose contracts nobody has reviewed. Integration decisions — what to connect, what to isolate, what to cut off today — are being made this week. Spending six weeks producing a beautiful diagram would be a failure, because the decisions would be made without it. ## The bar I hold A recovered model is ready for threat enumeration when four things are true: 1. **Every trust-boundary crossing is drawn.** Every point where data moves between parties with different control — your estate to theirs, tenant to platform, operator to production — is on the paper. Threats concentrate at those crossings, so a missing one removes a whole class of findings. 2. **Every data store has a named class.** Not the schema, just the class: consent records, personal data, credentials, financial records, audit truth. Threat severity is a function of what is in the box. 3. **Every identity that can reach a sensitive store is enumerated.** In the acquisition case this is the decisive one. If you cannot list who holds credentials into the consent database, you cannot reason about the adversary you actually have. 4. **Unverified edges are labelled, not omitted.** Each edge carries its evidence — config, telemetry, code, operator statement, inference — and a date. A diagram that displays its own confidence is used correctly by the next reader; one that projects uniform certainty is not. Below that bar, enumeration produces threats against a fiction. Above it, you are usually adding detail that will not change any mitigation you would choose. ## Time-box, then let the threats rank the unknowns Set the recovery budget before you start and hold it. Then use the first enumeration pass as a prioritiser: it tells you which of your open questions actually matter. An unresolved edge that might carry consent records out to a third party changes what you do next week; an unresolved edge that ships build metrics to a dashboard does not. Go back and verify the first kind. Leave the second labelled and move on. This is the same instinct as precision on demand — you resolve an unknown when, and only when, resolving it would change a decision. ## Where I refuse to accept a gap There are unknowns I will not ship the model with, because they hide the threats rather than merely blur them: - A flow that leaves the organisation whose far end I cannot name. - A data store whose class nobody can state. - A path to a sensitive store whose set of authorised identities I cannot enumerate. Each of those is not a missing detail; it is a hole exactly where the adversary would stand. In the acquisition case, an un-enumerable credential list into the consent store is the whole problem, and no amount of pretty drawing elsewhere compensates. ## Guarding against how the artifact gets read A time-boxed recovered diagram has a specific social risk: six months later somebody treats it as the architecture document. Two habits prevent that. First, per-edge evidence and dates, so its provenance is visible on its face. Second, an explicit statement of what was *not* covered — the subsystems you did not reach, the sources you could not obtain. Naming the boundary of the work is what makes it honest, and it is also what makes the next person's job cheaper. ## The answer an interviewer is listening for They want to hear that you will not be paralysed by incompleteness and that you will not pretend it away either. Ship the model at a defined bar, label the gaps in the artifact itself, let the threats you find direct the next round of verification, and name up front the small set of unknowns you refuse to proceed without.