A threat model's boxes are 'Team Alpha', 'Team Bravo' and 'Platform' — what is wrong with it?

## The wrong axis of decomposition Every diagram decomposes something along some axis. A data-flow diagram decomposes a **system by where data goes**: which outside party supplies it (external entity), which code transforms it (process), where it comes to rest (data store), and which named payload travels each arrow (data flow). An org chart decomposes a **company by who reports to whom**. Both are legitimate drawings; only one supports threat analysis, and swapping them is one of the most common failures in a first threat-modeling session — partly because the org chart is the diagram the team already has on a wall. ## What breaks, concretely Take an insurance claims platform whose model shows three boxes — 'Team Alpha', 'Team Bravo', 'Platform' — with arrows between them. The asset at stake is claim money: an approved claim moves real funds to a claimant's account. **The boxes have no cardinality.** 'Team Alpha' might be four services, a scheduled job and a spreadsheet. You cannot say what runs there, which means you cannot say what an adversary who compromised one of those things would reach. **The arrows have no payload.** An arrow from 'Team Bravo' to 'Platform' might be a claim submission, an approval decision, a payout instruction to a payment rail, or a design conversation. Threats differ wildly between those. Tampering with a payout instruction is a money-loss threat; tampering with a design conversation is not a threat at all. **There is nowhere to stand.** Adversary positions are defined relative to system elements: a caller of an endpoint, a holder of a database credential, a party on a network path, an operator of a service. A team is not a position an attacker can occupy. So the enumeration silently loses the very thing it exists to find — for the claims platform, the adjuster who can approve their own claim, or the operator who can replay a payout instruction, simply have no coordinates on the page. **No boundary can be drawn.** A trust boundary is a line between two identified principals whose privilege differs. Between 'Team Alpha' and 'Team Bravo' there is a reporting relationship, not a privilege change. If a reviewer draws a line there anyway, it means nothing: the code from both teams may well execute in the same process with the same credentials. ## What the reviewer should conclude — and say The conclusion is blunt and worth saying plainly: nobody has modeled the system. This is different from the diagram being wrong or incomplete. A too-coarse or out-of-date DFD is still a description of the system that can be corrected. An org chart is a description of the company; there is nothing in it to correct, and no amount of adding boxes will turn it into an analysable artifact. The rescue is a single question asked in the room: *walk me through what happens, step by step, when a claim is submitted and later paid.* The answer names the real elements almost automatically — the claimant's browser, the intake service, the claims database, the adjuster's console, the approval process, the payment instruction, the ledger. Draw those, and the boundaries appear where the narration changes principal: claimant to intake, adjuster to approval, approval to payment rail. ## Where team structure is legitimately useful Ownership is not worthless information; it is just not the decomposition axis. Once real elements are on the page, annotating them with the owning team is genuinely useful — it tells you who must be in the room to answer a question about an element, and who accepts a threat that is left open. The defect is using ownership *instead of* structure, not alongside it. A related and subtler version of the same mistake is a diagram whose boxes are project or product names ('Marketplace', 'Insights', 'Core') rather than teams. It looks more technical, but it fails identically: a product name has no cardinality, its arrows have no payload, and no adversary can stand on it. The test is the same in both cases — can I point at a box and say what code runs there and what credential it holds? If not, the box is a label, not an element. ## The one-line test For each box: what code runs here, what data does it hold, and whose credential does it use? For each arrow: what exactly travels along it, and who is at each end? A diagram whose boxes cannot answer those questions has not modeled a system, whatever the boxes are named.