Both frames work. The four questions ask what you are working on, what can go wrong, what you will do about it and whether you did enough. The Microsoft five steps add an explicit security requirements step at the start. Pick whichever your team will actually run, and keep it the same for six months.
The four questions
The OWASP Threat Modeling Cheat Sheet, citing the Manifesto, lists:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
The cheat sheet maps them to four steps: system modeling, threat identification and ranking, mitigations and responses, and review and validation.
The five steps
Microsoft describes the process in its security development lifecycle as:
- Define security requirements.
- Create an application diagram.
- Identify threats.
- Mitigate threats.
- Validate that threats have been mitigated.
Microsoft also says threat modeling should be part of the routine development lifecycle, so teams keep refining the model.
Where they line up
| Four questions | Five steps |
|---|---|
| What are we working on? | Create an application diagram |
| What can go wrong? | Identify threats |
| What will we do about it? | Mitigate threats |
| Did we do a good job? | Validate mitigations |
| (implicit) | Define security requirements |
The only real difference is the up front requirements step. In the four questions frame, requirements come out of question one, since understanding what you are building includes understanding what it must protect.
When to pick which
Pick the four questions when you are starting out or running sessions with developers who have never done this. They fit on a sticky note and are easy to remember.
Pick the five steps when your organization already writes security requirements, or when auditors and customers ask to see them. The extra step gives you a place to record things like data classification and regulatory needs before diagramming.
What matters more than the frame
- Doing it often, on small changes, rather than rarely on large ones.
- Having the people who built the system in the room.
- Ending with owned, tracked responses.
- Storing the model where the team can update it.
The Manifesto says it directly: continuous refinement beats a one off deliverable. A team that runs short sessions every sprint will outperform one that runs a long session once a year with a perfect framework.
For a hands-on walkthrough, see threat modeling for small teams.
A hybrid that works
Many teams use the four questions as the spoken agenda and keep a short requirements list on the side, which gives them the benefit of both. Start the meeting by reading the questions. Before diagramming, spend two minutes listing what the feature must protect, such as account data or payment integrity. At the end, check the list against the responses. That small addition covers the one gap between the frames without adding process.
Quick check
Do I need special software?
No. A whiteboard works. Microsoft offers a threat modeling tool with standard notation for diagrams and integration with issue trackers, but it is optional.
Sources
Last reviewed: 19 October 2026.
