The threat modelling process is a structured, repeatable way to examine a system through an attacker's eyes: you map what you are building, identify what can go wrong, decide how to address each risk, and validate that the fixes hold. Run it at the design stage and you remove security flaws while they cost pennies to fix, rather than the $4.44 million average global cost of remediating a breach after launch.
That timing is the entire point. Attackers now use generative AI to automate vulnerability discovery and write convincing phishing at scale — AI already powers 16% of breaches, which means organisations of every size are targeted, not just large enterprises. Waiting for a penetration test or an audit to surface your weaknesses is a reactive posture, and a reactive posture is the expensive one. Threat modelling moves the work earlier, where it is cheaper and more effective.
In short:
- Threat modelling answers four questions: what are we building, what can go wrong, what will we do about it, and did it work.
- Eight methodologies cover most real-world use cases, but STRIDE (technical, component-level) and PASTA (risk-centric, business-aligned) are the two you will reach for most.
- It is a practical way to generate the risk-assessment and control evidence that SOC 2 and ISO 27001 auditors expect.
What is the threat modelling process?
Threat modelling is a foundational element of any cybersecurity risk assessment. Rather than scanning finished software for known bugs, it asks how a system could be abused before that system exists, then designs the abuse out. You look at data flows, trust boundaries, and entry points the way an attacker would, and you record the threats you find so they can be tracked and fixed.
It complements a formal threat assessment and sits comfortably inside an established risk framework such as ISO 31000. The difference from a one-off security review is repeatability: a threat model is a living artefact you revisit as the system changes, not a report that ages on a shelf.
The four stages of threat modelling
Most methodologies, whatever their branding, follow the same four stages. Microsoft frames them as four plain questions, and that framing is the easiest to teach across technical and non-technical teams alike.
What are we working on? (Decomposition)
Decomposition means mapping the application, system, or business process you are working on before you look for a single threat.
- Define scope. Establish the boundaries of what you are evaluating so the exercise does not sprawl into the whole company.
- Identify assets. Locate the critical data, hardware, and software components that need protection.
- Diagram the system. Build data flow diagrams (DFDs) showing how data moves between processes, data stores, and external entities.
- Mark trust boundaries. Note every point where data crosses from one level of trust to another, such as user input or a third-party API.
What can go wrong? (Threat identification)
Threat identification means walking each component and boundary and asking what could go wrong: how an attacker could manipulate it, read data they should not, or take the service down. This is where a methodology like STRIDE earns its keep, giving you categories to brainstorm against rather than a blank page.
- Spoofing — impersonating a valid user or system.
- Tampering — modifying data or code in transit or at rest.
- Repudiation — denying an action occurred, with no proof to counter it.
- Information disclosure — exposing sensitive data to unauthorized users.
- Denial of service — making a resource unavailable to legitimate users.
- Elevation of privilege — gaining access rights beyond what was granted.
What are we going to do about it? (Mitigation)
Mitigation is deciding what you are going to do about each threat: rank its likelihood and business impact, then decide whether to eliminate it, reduce it with a control, transfer it, or knowingly accept it.
- Rank risks. Use a scoring system like CVSS or DREAD to prioritize what gets fixed first.
- Design countermeasures. Apply controls such as encryption, multi-factor authentication, or input validation.
- Record every decision — including the ones where you accept the risk rather than fix it. Auditors and future you will both want the reasoning on file.
Did we do a good job? (Validation)
Validation answers whether you did a good job: confirm the mitigations were actually built and tested, and that no threat was quietly dropped.
- Challenge assumptions. Through code review, testing, or a penetration test.
- Check completeness. Cross-reference the mitigation list against the original threat list — a model that ends in a list of fears nobody acted on is wasted effort.
- Iterate. Update the model whenever the architecture changes: a new integration, a new data flow, a new trust boundary.
Threat modelling methodologies
STRIDE and PASTA are the two threat modelling methodologies that get the most attention, but they are not the only frameworks in circulation. Knowing where each one fits helps you pick the right tool instead of defaulting to whichever one you learned first.
| Methodology | Type | Best for | Output |
|---|---|---|---|
| STRIDE | Technical, component-level | Engineers hunting specific flaws in software during development | Six threat categories: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege |
| PASTA | Risk-centric, business-aligned | Aligning technical threats with business impact for leadership | Seven-stage report tying threats to business risk |
| DREAD | Scoring model | Ranking threats STRIDE (or any method) surfaces | A numeric score per threat, based on damage, reproducibility, exploitability, affected users, and discoverability |
| Trike | Requirements-driven | Teams where different stakeholders have different risk tolerances | Acceptable-risk levels mapped per stakeholder |
| VAST | Visual, Agile, Scalable | Large orgs running this inside DevOps pipelines | Threat models integrated into sprint workflows |
| Attack Tree | Visual, hierarchical | Modelling one high-value asset in depth | A tree showing every path an attacker could take to reach a specific goal |
| CVSS | Scoring standard | Prioritising vulnerabilities once found | An industry-standard severity score (0–10) |
| T-MAP | Quantitative | Justifying remediation spend with a defensible number | A score combining exploitability and impact |
Mature teams often run STRIDE inside a sprint, score the results with DREAD or CVSS, and roll the findings up through a PASTA-style business lens for leadership. Choosing a methodology is less about which one is "better" and more about who needs to act on the output.
Tools for threat modelling
A methodology tells you what to look for. A tool makes the exercise repeatable across teams instead of living in one architect's head.
| Tool | Cost | Best for |
|---|---|---|
| Microsoft Threat Modeling Tool | Free | Teams new to the practice — generates DFDs and a starter STRIDE-based threat list |
| OWASP Threat Dragon | Free, open source | Teams that want the process documented in a shareable diagram, browser or desktop |
| IriusRisk | Commercial | Teams running this at scale — automates threat ID from architecture diagrams and links findings to remediation tickets |
None of these tools replace the thinking. They speed up the diagramming and keep the output consistent so a threat model built by one team looks like one built by another.
See how Konfirmity turns threat models into audit evidence
Book a demo and see how the platform tracks every threat, mitigation, and sign-off your SOC 2 or ISO 27001 auditor will ask for.
Book a demo
Threat modelling for SOC 2 and ISO 27001 compliance
Auditors do not award credit for good intentions; they ask for evidence that you identify risk deliberately and treat it consistently. A documented threat modelling process is one of the cleanest ways to produce that evidence, because its output maps directly onto the risk-assessment and control-design requirements both frameworks already demand.
SOC 2: where threat modelling fits
SOC 2's Trust Services Criteria expect a risk-assessment process (the CC3 criteria) and controls that respond to identified risks (CC6 through CC8). Threat modelling feeds both: the threats you enumerate become entries in your risk register, and the mitigations become the controls you later evidence. If you are formalising that register, our SOC 2 risk assessment guide covers the scoring and documentation auditors look for, and threat modelling of your vendors strengthens the vendor risk mapping that CC9 expects — the same exercise also gives your next SOC 2 penetration test a sharper, evidence-backed scope to start from.
ISO 27001: where threat modelling fits
ISO 27001 builds the entire management system on Clause 6.1.2 risk assessment and treatment, and Annex A controls are selected to address the risks you identify. Threat modelling is a structured input to that assessment. The threats it surfaces often point straight at technical Annex A controls — access control, logging, and the ongoing work in our ISO 27001 vulnerability management guide. It also sharpens scope before an ISO 27001 penetration test, so the test validates your model rather than starting from scratch.
Threat modelling finds the risks. The audit asks you to prove you addressed them.
Drop your work email and turn your threat-modelling output into audit-ready evidence for SOC 2 and ISO 27001.
The business case: risk reduction and ROI
Executives often read security as a cost centre, but a threat model is one of the few security activities with a defensible return. Fixing a design flaw on a whiteboard is close to free; fixing the same flaw after it ships, or after it is exploited, pulls in regulatory fines, lost revenue, legal fees, and remediation. Identifying the flaw early is the cheaper end of that range by orders of magnitude, and you can use a compliance ROI calculator to put numbers against your own environment.
The value extends past the balance sheet. Regulators have less patience for negligent security every year, and frameworks from GDPR to HIPAA to the EU's Digital Operational Resilience Act increasingly expect a documented, proactive approach to risk. Extending the model to the software, APIs, and services your partners provide also contains supply-chain exposure, so a vendor's weakness does not quietly become yours. Used well, threat modelling is how cyber risk gets measured and tracked alongside financial and operational risk, rather than sitting in a silo.
How to start a threat modelling program
Knowing you need a process is easy; standing one up without overwhelming the team is the hard part. A few moves keep the first few months realistic.
- Start small and scale. Pick one critical application or a feature currently in design. Run it as a pilot, learn what your team finds awkward, and fix the process before you widen it.
- Establish baseline training. Developers, architects, and product owners do not need to become penetration testers, but they do need the shared vocabulary of risk so the conversation is productive.
- Integrate into existing workflows. Embed the exercise in your Agile or DevOps rhythm — a step in design review or sprint planning — rather than bolting on a separate, heavyweight process that teams route around.
- Create reusable templates. Standard data-flow diagrams and a question checklist lower the barrier to entry and keep results consistent across teams.
- Tie threats to action. A model that ends in a list of fears is wasted effort. Every identified threat should become a ticket, a backlog item, or a named control with an owner.
One cultural point is worth stating plainly: threat modelling is not the exclusive domain of senior security architects. Product managers and business analysts understand their own workflows better than anyone, and they routinely spot logic flaws — a step that exposes customer data, say — long before code is written. Widening the room makes the model better, not slower.
Common questions about the threat modelling process
Decomposition (what are we working on), threat identification (what can go wrong), mitigation (what we will do about it), and validation (did it work). Every mainstream methodology is a variation on these four.
As early as the design phase, and again whenever the system changes materially — a new integration, a new data flow, a new trust boundary. Threat modelling early is far cheaper than retrofitting fixes, but a model that is never revisited goes stale.
At minimum the engineers and architect who own the system, plus a security practitioner to guide the threat brainstorming. Including a product owner or business analyst adds the business-logic perspective that catches workflow-level flaws purely technical reviewers miss.
Neither framework names "threat modelling" as a mandatory control, but both require a documented risk-assessment process — SOC 2 under the CC3 criteria, ISO 27001 under Clause 6.1.2. Threat modelling is a well-recognised way to satisfy that requirement and to generate the evidence auditors ask for.
"What are we working on?" The decomposition step always comes first. You cannot identify threats to a system you have not mapped yet, so skipping straight to brainstorming attack scenarios produces a shallower, less structured model.
Use STRIDE when the goal is finding concrete technical flaws inside software during development. Use PASTA when you need to align threats with business impact for leadership. Many teams run STRIDE at the engineering level and summarise the results through a PASTA-style business lens.
The bottom line
Attackers are using better tools to exploit smaller gaps, and waiting for an audit or a penetration test to find those gaps is a gamble most organisations cannot afford. Building a structured threat modelling process into how you design and ship systems turns security from a late-stage bottleneck into an early-stage decision — one that produces resilient software and the audit evidence your SOC 2 or ISO 27001 programme already needs.
Turn your threat models into audit-ready evidence
Book a demo and we will walk through how Konfirmity tracks every threat, mitigation, and sign-off for your SOC 2 or ISO 27001 stack.
Book a demo
