A data-flow diagram predates a move to three cloud regions and a mobile client — what can you still conclude?

## An undated diagram is an unsourced claim A threat model's diagram is used as evidence: a reviewer reasons from it to conclusions about what an adversary can reach. Evidence has a provenance, and a diagram's provenance is its as-of date and the topology it was drawn against. A page carrying neither is the equivalent of a quoted figure with no source — it may be right, but nothing may be concluded from it. The first question about any diagram handed to you in a review is therefore *when was this true*, and the depressingly common answer is that nobody knows. ## What survives a re-platform, and what does not Suppose the diagram was drawn when the product ran in one datacenter with a web client, and since then the company has moved to three cloud regions and shipped a mobile app. **Usually still roughly valid.** The *classes of data* the system handles, the *business flows* (what a user does end to end), the *assets* worth protecting, and many *internal privilege transitions* that were not touched by the move. These are properties of the product, and re-platforming rarely changes them. **Now unsupported.** Every structural security statement: | Property | Why the old page cannot speak to it | |---|---| | Trust boundaries | Regions introduce new principals: cloud operators, per-region credentials, cross-region roles | | Data flows | Replication and failover traffic between regions exists and is drawn nowhere | | External entities | A mobile client is a widely-distributed, tamper-exposed entity the page never had | | Attack surface | A mobile app implies a public API contract the web-only design may not have exposed | | Availability model | Failure domains changed shape entirely; one datacenter and three regions fail differently | | Data residency | Which region holds which records is a new question the page cannot answer | Notice that the *adversary set* changed underneath the drawing without any line on it moving. That is the characteristic danger of a stale model: the page looks unchanged, so it reads as unchanged. ## The failure that matters: absence taken as evidence A fresh diagram supports a limited negative claim — if a careful author drew every flow last week and there is no path from the public API to the ledger, that is meaningful. A stale diagram supports no negative claim at all. Yet reviewers routinely reason from it exactly that way: *there is no cross-region flow on the page, so nothing crosses regions*; *the mobile client is not shown, so it must go through the same gateway as the web client*. This is why a stale model can be worse than none. With no diagram, a reviewer knows they are ignorant and asks. With a confident-looking obsolete one, they get false assurance, and the review produces a signed-off document asserting coverage that was never performed. The artifact's authority outlives its accuracy. ## How to run the review anyway You will rarely get to refuse and go home, so the useful skill is proceeding honestly. **State the provenance out loud, and write it on the page.** 'This was drawn against a single-datacenter topology; the system now runs in three regions and has a mobile client.' Everyone in the room now knows the standing of what they are looking at. **Demote it from evidence to hypothesis.** The old page becomes a prompt: for each element, ask *is this still here, and is it still reached the same way*. That is a far faster conversation than starting from blank paper, which is the real value the stale page retains. **Spend the budget on the delta, not the whole.** The changed surface — regional topology, the replication flows, the mobile entity and the API it implies — is where every unexamined threat lives, by definition. Re-enumerating the unchanged core is the comfortable option and the wrong one. **Do not sign off the old page.** Whatever the schedule pressure, a review verdict must be attached to an artifact that describes the deployed system. Reporting 'reviewed against a topology two platforms old' is an honest and survivable outcome; a clean sign-off against fiction is not. ## The judgment call to own There is a genuine tradeoff, and it is what a principal is being asked about. Redrawing takes most of the session and produces no threat list that day, which feels like a wasted review to the delivery team. Enumerating against the old page produces a satisfying list of threats, most of which concern a system that no longer exists, and misses the ones the change introduced. My default is to redraw the changed area only, accept a shorter threat list, and be explicit in the report about which parts of the system were examined and which were not — coverage you can describe honestly is worth more than a longer list you cannot stand behind. One cheap habit prevents the whole problem from recurring: every diagram carries a date and a named owner in a corner, so the next reader can make this judgment in five seconds instead of discovering it halfway through the meeting.