Communicating Threat Models
Making risk legible to people who will fund or accept it.
5 to work through
-
intermediate
A security review produces findings that engineering teams dispute or ignore. How should the findings be communicated to be acted on?
2 min answer -
intermediate
A threat model is technically thorough and the engineering team does not act on it. What is wrong with how it is communicated?
2 min answer -
advanced
A security review hands engineering 47 findings on a five-by-five likelihood-impact matrix: 9 high, 12 medium, 26 low, each with a numeric score and a risk-accepted column that three rows already use. Nine weeks later two findings are fixed. Review this pack. What would you remove, what would you change, and what would you keep even though it looks odd?
3 min answer -
advanced
A security team stops scoring findings on a five-by-five likelihood-impact matrix and instead writes each one as a reachable attack path with the single change that closes it. Remediation throughput triples in a quarter. What has the organisation given up, and when does that bill arrive?
2 min answer -
advanced
How do you run a threat model that results in code changes rather than a report?
2 min answer
4 terms in this topic
Abuse Case
A use case written from the attacker's side - a hostile actor plus the interaction that achieves their goal - which engineers can refute or fix, unli…
practiceAttack-Path Framing
Writing each security finding as a reachable path from entry point to impact with the one change that removes it and the cost of that change, replaci…
practiceCommunicating a Threat Model
Producing a threat model that engineers act on — structured by data flow, prioritised by risk, and expressed as work rather than as a report.
practiceTrust 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 findin…
Neighbouring topics
Architecture Communication
General material on communicating architecture.
Architecture Diagrams
Choosing an audience and refusing to mix levels of abstraction.
C4 Model
Context, container, component and code as four separate diagrams.
Context Diagrams
The system as one box, with its users and external systems.
Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
Deployment Diagrams
What runs where, in which zone, behind which boundary.
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Technical Proposals
A written argument circulated before the decision feels made.
Architecture Reviews
Reviewing early enough to influence rather than to veto.
Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
Presenting to Engineers
Mechanism, alternatives rejected, and what you are unsure about.
Explaining Trade-offs
Naming what was given up, and the condition that would change it.
Handling Disagreement
Arguing from consequences, and escalating in the room.
Negotiation
Trading on interests rather than positions, with priced options.
Documentation Practice
Keeping documents close to the code and honest about staleness.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Written Communication
Writing that survives being read without you in the room.
Facilitation
Running a design session that reaches a decision.