Threat modelling means working out how a system could be attacked before you build or test it. Done well, you design out the weaknesses instead of discovering them later. The National Cyber Security Centre defines it as techniques used “to model and analyse technology systems and services to better understand how that system or service might be attacked or otherwise fail.” Done properly, threat modelling turns a vague sense of risk into a concrete list. You end up with things to fix, not just a feeling of unease.
Threat modelling is worth understanding even if you never run a session yourself. That applies if your business builds software or runs a website handling customer data. It applies just as much if you are about to commission a penetration test. It shapes what a good test actually covers.
Table of Contents
How does threat modelling actually work?
OWASP frames the process around four simple questions: what are we building, and what can go wrong? What are we doing about it, and did we do a good enough job? Answering them properly usually means:
- Sketching the system: the components, data flows and trust boundaries, often as a simple diagram.
- Thinking like an attacker. For each component, ask how someone could spoof an identity, tamper with data, deny a service, or escalate their access.
- Ranking the threats found by how likely and how damaging they would be.
- Deciding what to do: redesign, add a control, accept the risk, or test it properly to find out.
The NCSC is clear that this should not be a one-off exercise. It recommends threat modelling be “incorporated, as business as usual, into your risk management process, development, or continuous integration and deployment processes.” Review it again whenever the system, or the threats facing it, change.
The main methodologies, in plain terms
| Methodology | What it focuses on | Best suited to |
|---|---|---|
| STRIDE | Six threat categories: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege | Development teams reviewing a specific system or component |
| PASTA | A seven-stage, risk-centric process linking technical threats to business impact | Organisations that need to justify security spend to the business |
| Attack trees | Mapping the steps an attacker would need to take to reach a goal | Understanding a specific, high-value target such as a payment system |
Microsoft built STRIDE in the 1990s. It still documents STRIDE as the backbone of its own Security Development Lifecycle. STRIDE remains the most widely taught starting point, mainly because the six categories are easy to remember and apply to almost any component. PASTA takes longer, but it produces a report a board can actually use, since it ties each threat back to what it would cost the business.
Threat modelling vs penetration testing: what’s the difference?
Threat modelling happens mostly on paper, ideally before a line of code is written or a system goes live. It asks what could go wrong. A penetration test happens against a real, running system. It answers a narrower but more concrete question: can someone actually exploit this. One maps the theoretical attack surface. The other proves which parts of it are genuinely exploitable.
The two work best together. A threat model built at the design stage tells a tester where to focus. The engagement then spends its time on the components that matter most, rather than testing everything to an equally shallow depth. Our guide to judging a provider’s penetration testing methodology covers what a scope built on solid threat analysis should look like in practice.
When should a business do this?
The NCSC recommends applying threat modelling at the design and development phases of a system. It can also be used at any point to better understand how something might be attacked. In practice that means:
- Before building a new application or major feature, especially one handling payment or personal data.
- Before a significant architecture change, such as moving a system to the cloud.
- Ahead of commissioning a penetration test, so the scope reflects real risk rather than guesswork.
- After a serious incident, to work out what the model missed and update it.
Do small and mid-sized businesses need to bother with this?
Yes, though the process should scale to match the risk. A small business does not need a week-long workshop with formal diagramming software. A whiteboard session already delivers most of the value. Cover what data the system holds, who can reach it, and the three or four ways it could realistically be attacked. What matters is doing it deliberately and writing the findings down. Revisit them when the system changes, rather than skipping the exercise because it sounds like something only large enterprises do.
Common mistakes businesses make with threat modelling
The most common mistake is treating it as a one-off document. A threat model produced once, filed away, and never revisited stops reflecting reality the moment the system changes. A new integration, a new third-party API, a migration to a new cloud provider: any of these can make it stale. The NCSC’s own guidance stresses that the exercise should be cyclical, not a box ticked at the start of a project.
The second mistake is skipping straight to tooling. Diagramming software and automated platforms are useful later, once a team has done the exercise by hand a few times. By then they understand what a genuinely useful threat looks like, rather than a generic entry copied from a checklist. Used too early, these tools tend to produce long lists that nobody prioritises properly.
The third mistake is treating threat modelling as a substitute for testing. A model built entirely on assumptions about how the system behaves is only as good as those assumptions. A real penetration test validates the biggest ones. That is what turns a theoretical model into a confirmed picture of risk.
Frequently asked questions
Is threat modelling the same as a risk assessment?
They overlap but are not identical. A general risk assessment tends to be broader and less technical. Threat modelling specifically maps how a system’s design could be attacked, component by component, which makes it more useful for informing development and testing decisions.
Who should be in the room for a threat modelling session?
Ideally the people who understand the system best: a developer or architect, plus someone from operations. Add someone with an attacker’s mindset where possible, whether that is an in-house security lead or an external tester brought in for the session.
Does threat modelling replace the need for a penetration test?
No. It reduces design flaws and focuses testing effort. But it cannot confirm whether a vulnerability is genuinely exploitable in the running system. That confirmation still requires hands-on testing.
How long does a first threat modelling session take?
For a single application or service, two to four hours is a realistic starting point. That covers the system diagram and a first pass at STRIDE-style questions. Larger or more complex systems need longer. Treat the model as something to revisit, not something finished.
What tools are used to record a threat model?
Many teams start with a whiteboard and a simple diagram. They move to a dedicated tool, such as OWASP’s free Threat Dragon or Microsoft’s Threat Modeling Tool, once the practice becomes routine.
Aardwolf Security can help build that picture before testing begins, if you want a penetration test scope that reflects real risk. Get in touch to talk through your system, or see our full penetration testing services.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
