You can threat model with four questions and a whiteboard: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? These are the key questions in the Threat Modeling Manifesto, and they scale from one feature to a whole system.
1. What are we working on?
Draw it. Boxes for components, arrows for data flows, and lines where trust changes, such as the internet boundary or a third party API. OWASP's process starts the same way, with data flow diagrams, entry points, assets and trust levels. A messy diagram agreed by the team beats a perfect one nobody made.
2. What can go wrong?
Walk each arrow and box and list threats. A prompt like STRIDE helps you cover spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. See STRIDE explained. Include non-technical threats, such as a departing employee with access.
3. What are we going to do about it?
For each threat choose a response. OWASP lists the options as accept, eliminate, mitigate or transfer. Prioritize by likelihood, impact and cost. Turn the chosen mitigations into tickets with owners.
4. Did we do a good enough job?
Check that you have a diagram, a threat list and a list of controls, as OWASP's process says. Then ask whether the mitigations are implemented and tested. Revisit when the design changes.
What the Manifesto values
Among its values, the Manifesto says that finding and fixing design issues matters more than box-ticking compliance, and that doing threat modeling matters more than discussing it. It also asks for small iterations that track design changes.
Anti-patterns to avoid
The Manifesto names a few:
- Hero threat modeler: relying on one talented person rather than the whole team.
- Admiration for the problem: listing risks without pursuing practical fixes.
- Overfocus: losing the big picture by fixating on one adversary or asset.
- Perfect representation: assuming one ideal model, when several views reveal different problems.
A one hour session
- Spend 15 minutes drawing.
- Spend 25 minutes listing threats.
- Spend 15 minutes choosing responses.
- Spend 5 minutes assigning tickets and a review date.
Run it at design time, before the code exists, when changes are cheapest.
Quick check
Who should be in the room?
Engineers who built the system, someone who knows the data and its owner, and a security person if you have one. Varied viewpoints find more.
How often should we repeat it?
Whenever the design changes in a way that moves data or trust boundaries.
Sources
Last reviewed: 19 October 2026.
