What Is Threat Modelling?

Threat modelling is a structured process for identifying and addressing security risks before they become breaches. Instead of waiting for attackers to expose weaknesses, you systematically ask: What could go wrong? How bad would it be? What should we do about it?

Why Bother?

Security bugs found in design cost orders of magnitude less to fix than those found in production. A one-hour threat modelling session before a sprint can prevent weeks of incident response later.

Threat modelling helps you:

• Find security issues early — when they’re cheap to fix
• Prioritise security work — based on actual risk, not gut feeling
• Build shared understanding — engineers, architects, and product managers align on what you’re protecting and why
• Meet compliance requirements — ISO 27001, SOC 2, GDPR, PCI-DSS, and most security frameworks expect threat analysis as part of the SDLC
• Create a security artefact — a living document that auditors, new team members, and incident responders can rely on

The Core Questions

Every threat model answers four questions:

When to Threat Model

Threat modelling isn’t a one-time activity. The best teams do it:

• At design time — before writing a single line of code, for new systems or major features
• At review time — when a significant architectural change is proposed
• Periodically — annual or bi-annual review of existing systems, especially after incidents
• After incidents — to identify what the model missed and update it

Tip: A rough threat model done early is far more valuable than a perfect one done never. Start simple and iterate.

Who Should Be Involved?

The most useful threat models are produced collaboratively. Bring together:

• Engineers who understand the implementation details
• Architects who understand the broader system design
• Security champions or analysts who know attack patterns
• Product managers who understand what data is most sensitive and most valuable to protect

A group of 3–5 people working for 1–2 hours typically produces an excellent model for a bounded system.

Scope Your Model

Before you start, agree on what’s in scope and what’s out of scope. A model that tries to cover everything covers nothing well.

Good scope boundaries follow:

• A single service or application (e.g., the customer-facing API, not the entire platform)
• A specific user journey (e.g., user registration and login)
• A specific data type (e.g., how payment card data moves through the system)

OWASP Threat Modeling Process

This tool implements the OWASP Threat Modeling Process — the industry-standard methodology published by the Open Web Application Security Project. The four OWASP steps are:

1. Decompose the Application — identify trust levels, entry/exit points, assets, and data flows
2. Determine and Rank Threats — apply STRIDE to identify threats; rank by likelihood × impact
3. Determine Countermeasures and Mitigations — map controls to each identified threat
4. Assess Your Work — validate coverage; update the model as the system evolves

Threat Modelling Frameworks

There are several frameworks for identifying threats. This tool uses STRIDE, the most widely-adopted methodology in industry:

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

See the STRIDE Framework guide for a full explanation of each category.

Next Steps

Ready to start? Head to the threat modelling tool to begin your first model, or continue reading about STRIDE and risk scoring.