Trust Boundary Diagram
A diagram marking where data crosses between zones of differing trust, which is the structure a threat model is built on and the form security findings are best communicated in.
Threat modelling produces findings that are difficult to communicate because they are conditional and technical. The trust boundary diagram is the artefact that makes them legible to people who will fund or accept the risk.
The construction: draw the data flow, then mark every point where data crosses from one trust level to another — internet to edge, edge to application, application to data store, first party to third party, production to analytics. Threats concentrate at those crossings, which is why the boundaries rather than the components are the organising structure.
What to annotate at each boundary: what data crosses, in which direction, what authenticates the caller, what authorises the action, and what validates the content.
Communicating the findings from it: express each as a scenario with a consequence — "an attacker with a stolen API key can read all tenants' data because authorisation is checked at the gateway but not in the service" — rather than as a category name. A named vulnerability class invites debate about severity; a concrete scenario with business consequence produces a decision.
And record accepted risks explicitly, with an owner and a review date. A threat model whose findings are neither fixed nor formally accepted has documented a problem and changed nothing.