Chapter 1 · Practice 1 of 4
Structure every session around the four questions
Why it matters
The Threat Modeling Manifesto and the OWASP Threat Modeling Cheat Sheet both organize the work around four questions:
| Question | What you produce |
|---|---|
| 1. What are we working on? | a model of the system: usually a data flow diagram with trust boundaries |
| 2. What can go wrong? | a list of threats, found with a structured method such as STRIDE |
| 3. What are we going to do about it? | a response for each threat: mitigate, eliminate, transfer or accept |
| 4. Did we do a good enough job? | a check that the model matches reality and every threat has an owner |
The questions keep a session from drifting. A meeting that spends an hour debating which attacker is most likely is stuck on question 2 without having answered question 1. A long list of threats with no decisions has skipped question 3.
Shostack's guidance is that getting started can be as simple as asking those four questions, and that a quick pass is far better than none. Use the same headings in your threat model document, so anyone reading it later can see what was considered and what was decided.
Example
# Threat model: <feature name>
Date: 2026-10-13 | People: <names> | Design doc: <link>
## 1. What are we working on?
<diagram link, scope, assets, trust boundaries>
## 2. What can go wrong?
| ID | Element | STRIDE | Threat |
## 3. What are we going to do about it?
| ID | Response | Ticket | Test |
## 4. Did we do a good enough job?
<review notes, open questions, next review trigger>