Threat modeling has dozens of named methods, and newcomers often stall trying to pick one. The Four Question Framework sidesteps the choice. It describes what every method is trying to do, in plain language, so you can start with nothing more than a whiteboard and add structure only where you need it.
The four questions
1. What are we working on?
Build a shared picture of the system: its components, the data that flows between them, where the trust boundaries are, and which assets matter. The usual artefact is a data flow diagram, but a sketch, a sequence diagram or a list of user stories can work for small changes.
This question often produces findings on its own. Teams regularly discover, while drawing, that two components share credentials or that a flow they thought was internal crosses the internet.
2. What can go wrong?
Find threats. This is where named techniques help: STRIDE gives six prompts to ask of every element, STRIDE per element tells you which prompts apply to which kind of element, attack trees break an attacker goal into steps, abuse cases work at the user-story level, and LINDDUN covers privacy. Write each finding as a threat statement with an actor, a weakness and an impact.
3. What are we going to do about it?
Decide a treatment for each threat. The options are to mitigate, avoid, transfer or accept the risk, and prioritising requires a score, usually likelihood × impact. The output is a risk register: each threat with a score, a decision, an owner and, for mitigations, a ticket.
4. Did we do a good enough job?
Review the work. Did the diagram match the real system? Did the threats cover each trust boundary? Did the mitigations get built, and did they work? This question is the one teams skip, and it's what makes the next threat model better than this one.
How common methods map onto the questions
| Question | Typical technique | Artefact |
|---|---|---|
| What are we working on? | Data flow diagram, asset list, scope statement | DFD with trust boundaries |
| What can go wrong? | STRIDE, attack trees, LINDDUN, abuse cases, ATT&CK, CAPEC | Threat list, attack trees |
| What are we going to do about it? | Risk scoring (risk matrix, CVSS, DREAD), treatment decisions | Risk register, tickets |
| Did we do a good enough job? | Review, validation testing, retrospective | Review notes, updated model |
PASTA is a good example of a heavyweight method that still fits: its seven stages spend more time on business objectives and attack simulation, but they answer the same four questions.
Worked example: Invoicely
The Invoicely threat model took about two hours with three people. Mapped to the framework:
- What are we working on? Scope (production service, including the admin console), five assets, and a DFD with three trust boundaries. Drawing it surfaced the shared database role.
- What can go wrong? A STRIDE sweep produced ten threats; an attack tree decomposed the most serious goal, "read another customer's invoices".
- What are we going to do about it? Each threat was scored on likelihood × impact and entered in the risk register with a treatment and an owner.
- Did we do a good enough job? A review was booked for the next significant change, with a check that the IDOR fix had a regression test.
Running a session with the four questions
- Timebox each question. For a one-hour feature review: 15 minutes drawing, 25 finding threats, 15 deciding, 5 reviewing. Finishing all four roughly is better than perfecting the first two.
- Bring the builders. The people who wrote the code answer question one far more accurately than any architecture document.
- Write threats down as you go. A threat discussed but not recorded is a threat nobody will fix.
- End with owners. Question three isn't answered until each decision has a name next to it.
Our guide to running your first threat modeling workshop covers the logistics in more detail.
Common mistakes
- Spending the whole session on question one. A diagram is a means, not the result.
- Stopping after question two. A list of threats with no decisions is the most common failed threat model.
- Treating question four as a sign-off. "Did we do a good enough job" is a genuine check, ideally by someone who wasn't in the session.
Key takeaways
- Every threat model answers four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job.
- The questions are method-neutral: a DFD answers the first, STRIDE or attack trees the second, a risk register the third.
- The fourth question is the one teams skip, and it's what turns a one-off workshop into a practice that improves.
- If a session runs out of time, a rough answer to all four beats a perfect answer to the first two.
Frequently asked questions
What are the four questions of threat modeling?
What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? They come from Adam Shostack's work on threat modeling and are the core of the Threat Modeling Manifesto published in 2020.
Is the four question framework a methodology?
Not exactly. It's a structure that any methodology fits into. STRIDE, PASTA, LINDDUN and attack trees are different ways of answering the second and third questions in more depth.
How long does a four question threat model take?
For a single feature, 30 to 90 minutes with the people who build it. For a whole system, a first pass usually takes two to four hours, split across sessions.
What is the Threat Modeling Manifesto?
A short document published in 2020 by a group of threat modeling practitioners. It sets out values and principles for threat modeling and uses the four questions as its definition of the activity.