What is Threat Modelling? A Complete Guide for Organisations
Published by Aaryanova | Cybersecurity Consulting
Threat modelling is one of the most valuable — and most misunderstood — practices in cybersecurity. Done well, it helps organisations identify their real risks before attackers do, at the point in a project when fixes are cheapest and most effective. Done poorly, it becomes a box-ticking exercise that generates paperwork but changes nothing.
This guide explains what threat modelling is, how it works, which methodologies are most widely used, and how to know whether your organisation needs it.
What is Threat Modelling?
Threat modelling is a structured process for identifying, categorising, and prioritising the threats that could affect a system, application, or organisation — and then determining what controls should be in place to mitigate them.
Think of it as a disciplined way of asking: what could go wrong, who would cause it, how would they do it, and what would the impact be?
It is not a penetration test. It is not a risk register. It is not a compliance checklist. It is a thinking process — typically carried out by security professionals working alongside architects, developers, and business stakeholders — that produces a shared understanding of where the real risks are.
The output of a threat model is usually a prioritised list of threats, a set of recommended mitigations, and a record of the decisions made along the way. It is a living document, not a one-time deliverable.
Why Does Threat Modelling Matter?
The traditional approach to security is reactive: build the system, then test it, then fix what the testers find. This approach is expensive, slow, and incomplete. By the time a penetration tester finds a structural design flaw, the cost of fixing it may be ten or twenty times higher than if it had been caught at the design stage.
Threat modelling shifts security left — into the design and architecture phase, where changes are cheap. A threat modelling session that catches a fundamental authentication weakness before a line of code is written can save tens of thousands of pounds in rework, avoid reputational damage, and potentially prevent a serious breach.
Beyond cost, there is a regulatory dimension. Frameworks including ISO 27001, NIST CSF, SOC 2, and the UK NCSC Cyber Essentials Plus all either require or strongly recommend threat modelling as part of a mature security programme. GDPR’s requirement for privacy by design is also most effectively implemented through threat modelling at the product design stage.
—
Who Should Do Threat Modelling?
The honest answer is: anyone building or operating a system that handles sensitive data, processes transactions, or provides services that people depend on.
In practice, threat modelling is most commonly carried out by:
Software development teams building new applications or features
Cloud architects designing infrastructure on AWS, Azure, or GCP
Security teams assessing new vendors, integrations, or third-party systems
Product managers evaluating the risk implications of new product decisions
Compliance teams preparing for audits or regulatory assessments
Threat modelling scales from a small startup building its first application to a global bank assessing a complex microservices architecture. The depth and formality of the process scales accordingly, but the underlying logic is the same.
Common Threat Modelling Methodologies
Several structured methodologies exist for threat modelling. The most widely used are:
STRIDE
STRIDE is a Microsoft-developed framework that categorises threats into six types:
Spoofing — impersonating a user, system, or service
Tampering — modifying data in transit or at rest
Repudiation — denying an action without sufficient audit trail
Information Disclosure — exposing data to unauthorised parties
Denial of Service — disrupting availability of a system or service
Elevation of Privilege — gaining more access than authorised
STRIDE is applied to each component in a system — typically using data flow diagrams — by asking which STRIDE categories apply at each point. It is particularly well suited to application security and cloud architecture reviews, and is the most commonly used methodology in practice.
PASTA (Process for Attack Simulation and Threat Analysis)
PASTA is a risk-centric framework that aligns threats to business objectives. It operates across seven stages, from defining business objectives through to vulnerability analysis and attack simulation. PASTA is particularly appropriate for organisations that want to connect security risks directly to business impact, rather than treating them as purely technical concerns.
Attack Trees
Attack trees provide a visual representation of how an attacker could achieve a particular goal, modelling the various paths available to them. They are particularly useful for analysing specific high-value threats — such as how an attacker might exfiltrate customer data — in depth.
MITRE ATT&CK
While not a threat modelling framework in the traditional sense, MITRE ATT&CK is an invaluable resource that catalogues real-world adversary tactics and techniques. It is increasingly used alongside STRIDE and other frameworks to ground threat models in observed attacker behaviour rather than theoretical risks.
LINDDUN
LINDDUN is a privacy-focused framework specifically designed for identifying privacy threats — Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance. It is particularly relevant for organisations subject to GDPR or handling sensitive personal data.
The Threat Modelling Process: Step by Step
Regardless of which methodology you use, a typical threat modelling engagement follows a similar pattern.
Step 1 — Define the scope
Agree on what is being modelled. This might be a single application, a specific feature, an integration between systems, or a broader infrastructure design. Define the boundaries clearly: what is in scope, what is out of scope, and what assumptions are being made.
Step 2 — Decompose the system
Create a detailed picture of how the system works — what data it handles, how that data flows between components, where it is stored, who has access to it, and what trust boundaries exist. This is often captured as a data flow diagram (DFD), which becomes the primary working document for the rest of the process.
Step 3 — Identify threats
Apply your chosen methodology to each component and data flow in the diagram. For each element, ask which threat categories apply and generate a list of specific, concrete threats. The goal is to be comprehensive at this stage — you can prioritise later.
Step 4 — Analyse and prioritise
For each identified threat, assess the likelihood and potential impact. Common scoring approaches include DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) and CVSS. The output is a prioritised list of threats, with the highest-risk items at the top.
Step 5 — Identify mitigations
For each high-priority threat, identify what controls are already in place and whether they are sufficient. Where gaps exist, recommend specific, costed mitigations that can be incorporated into the engineering roadmap.
Step 6 — Validate and maintain
Threat models should be reviewed whenever the system changes significantly — a new feature, a new integration, a change in data handling, or a new deployment environment. A threat model is only useful if it reflects the current state of the system.
Common Mistakes in Threat Modelling
Treating it as a compliance exercise. A threat model produced to satisfy an auditor, without genuine engagement from the engineering team, is largely worthless. The value comes from the conversation and the decisions made, not the document produced.
Doing it too late. Threat modelling carried out after a system is built can identify risks, but the cost of addressing structural issues at that point is much higher. The ideal time is during design, before significant engineering investment has been made.
Being too theoretical. Threats that are not grounded in realistic attack scenarios are difficult to prioritise and often don’t get addressed. Anchoring threats to real-world attacker behaviour — using MITRE ATT&CK or recent incident reports — helps keep the process practical.
Not involving the right people. A threat model produced by security consultants in isolation, without input from the people who built and operate the system, will miss important context. The best threat models are collaborative.
Treating it as a one-time exercise. Systems evolve. New features are added, integrations change, and the threat landscape shifts. A threat model from two years ago is likely out of date.
Threat Modelling and AI Systems
As organisations increasingly build and deploy AI systems — large language models, recommendation engines, automated decision-making tools — threat modelling becomes even more important and more complex.
AI systems introduce threat categories that traditional frameworks do not fully address: prompt injection, adversarial inputs, model inversion, data poisoning, and supply chain risks in training data and model weights. The OWASP LLM Top 10 provides a useful starting point for organisations building on large language models, and threat modelling should be applied to AI systems at the same stage — and with the same rigour — as traditional software.
—
How Aaryanova Approaches Threat Modelling
At Aaryanova, we treat threat modelling as a core capability, not an add-on service. We work alongside your architects and engineers at design time, using a structured methodology tailored to your system and context — drawing on STRIDE, PASTA, attack trees, and MITRE ATT&CK as appropriate.
Our deliverables are practical: a prioritised threat register, specific mitigation recommendations aligned to your engineering roadmap, and a threat model document your team can maintain and update as your system evolves.
We also offer threat modelling for AI systems, applying frameworks including the OWASP LLM Top 10 and emerging AI risk guidance to help organisations understand the specific risks of their AI deployments.
If you are building a new system, integrating a new vendor, or simply want to understand where your real risks are, get in touch with our team.
—
Aaryanova is a cybersecurity consulting firm specialising in threat modelling, secure by design, cloud security, AI security, and GRC. We work with organisations across financial services, healthcare, technology, and the public sector.