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 millions to remediate after a breach.
That timing is the entire point. Attackers are now using generative AI to automate vulnerability discovery and write convincing phishing at scale, 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.
- The two most common methodologies are STRIDE (technical, component-level) and PASTA (risk-centric, business-aligned).
- 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.) Map the application, system, or business process. Draw the architecture, define the data flows, and mark the trust boundaries where data crosses from one level of trust to another.
- What can go wrong? (Threat identification.) Walk each component and boundary and ask 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.
- What are we going to do about it? (Mitigation.) For each threat, decide whether to eliminate it, reduce it with a control, transfer it, or knowingly accept it. Every decision is recorded, including the ones to accept risk.
- Did we do a good job? (Validation.) Confirm the mitigations were actually built and tested, and that no threat was quietly dropped. Validation is what separates a threat model from a wish list.
STRIDE vs PASTA: choosing a methodology
There is no single correct methodology. The two you will compare most often serve different audiences.
- STRIDE — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Developed by Microsoft, it is technical and component-level, and it suits engineers hunting for specific flaws inside software. The OWASP Threat Modeling guidance and Microsoft's own Security Development Lifecycle both lean on it.
- PASTA — the Process for Attack Simulation and Threat Analysis, a seven-stage, risk-centric method. It deliberately ties technical threats back to business impact, which makes it readable for management and useful for prioritising spend.
STRIDE is strong for securing the software development lifecycle at the engineering level; PASTA is strong for the strategic, board-facing view of risk. Mature teams often use STRIDE inside a sprint and roll the findings up through a PASTA-style business lens. Choosing between them is less about which is "better" and more about who needs to act on the output.
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.
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 — you can calculate your compliance ROI 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
What are the four stages of threat modelling?
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.
When should you run threat modelling?
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.
Who should be involved in threat modelling?
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.
Is threat modelling required for SOC 2 or ISO 27001?
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.
STRIDE or PASTA — which should you use?
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. If you want to see how that evidence comes together, book a Konfirmity demo and we will walk through it with your stack.
