← Back to Blog
Technical14 min read

Threat Modelling Guide: Methods, Frameworks, and Best Practices

Most security vulnerabilities are cheaper to fix in design than in production. Threat modelling is the discipline of systematically identifying what can go wrong, how likely it is, and what to do about it, before writing a single line of code. This guide covers the major threat modelling methodologies, walks through the process step by step, and shows how to integrate threat modelling into your development and security workflows. Whether you run a penetration testing programme or build software, threat modelling will sharpen your security posture.

What Is Threat Modelling?

Threat modelling is a structured approach to identifying security threats, quantifying their risk, and determining countermeasures. It answers four fundamental questions:

  1. What are we building? Decompose the system into components, data flows, and trust boundaries
  2. What can go wrong? Identify threats to each component using structured frameworks
  3. What are we going to do about it? Prioritise threats and define countermeasures
  4. Did we do a good enough job? Validate that countermeasures are effective and the model is complete

Unlike reactive security measures that find bugs after they are built, threat modelling is proactive. It identifies risks during design when changes are inexpensive and options are wide open. A threat model produced during architecture review can prevent entire categories of vulnerabilities from ever reaching code.

The Threat Modelling Process

Regardless of which framework you use, the threat modelling process follows a consistent structure. Here is a practical walkthrough of each stage.

Step 1: Define the Scope and System Model

Start by defining what you are threat modelling. For a new feature, this might be a single API endpoint and its data flows. For an entire application, it covers every component, data store, external dependency, and user interaction. Create a Data Flow Diagram (DFD) that shows:

  • External entities: users, third-party services, APIs that interact with your system
  • Processes: application components that process data (web servers, APIs, background workers)
  • Data stores: databases, file systems, caches, message queues
  • Data flows: how data moves between entities, processes, and stores
  • Trust boundaries: where the level of trust changes (internet to DMZ, DMZ to internal network, application to database)

Step 2: Identify Threats

Walk through each element of the DFD and systematically identify what could go wrong. Use a structured framework like STRIDE (covered below) to ensure comprehensive coverage. For each data flow that crosses a trust boundary, ask: who could intercept this? Who could modify it? What happens if this component is compromised?

Step 3: Assess and Prioritise Threats

Not all threats are equal. Assess each threat using a risk rating that considers both likelihood and impact. Common approaches include DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) and CVSS scoring. Use the CVSS calculator to score identified threats consistently. Prioritise threats that combine high likelihood with high impact.

Step 4: Define Countermeasures

For each prioritised threat, decide on a response: mitigate (implement a control), transfer (insure or outsource), accept (document the residual risk), or eliminate (remove the feature or component). Document the specific countermeasure and who is responsible for implementing it. Countermeasures should be concrete and testable: "implement input validation on the search endpoint using parameterised queries" rather than "fix SQL injection."

Step 5: Validate and Iterate

Review the threat model with the team to ensure completeness. Cross-reference against known vulnerability categories like the OWASP Top 10 to check for blind spots. After implementation, use penetration testing to verify that countermeasures work as designed. Update the threat model whenever the architecture changes.

STRIDE: The Most Widely Used Threat Framework

STRIDE was developed at Microsoft and remains the most popular threat classification framework for software development teams. Each letter represents a category of threat:

S - Spoofing Identity

Can an attacker pretend to be someone or something else? This covers authentication bypass, credential theft, token forgery, and session hijacking. Countermeasures include strong authentication, MFA, certificate pinning, and cryptographic token validation. Inspect token integrity with our JWT decoder.

T - Tampering with Data

Can an attacker modify data in transit or at rest? This includes SQL injection, parameter manipulation, man-in-the-middle attacks, and unauthorised database modification. Countermeasures include input validation, parameterised queries, TLS for data in transit, integrity checks, and access controls on data stores.

R - Repudiation

Can a user deny performing an action? This covers insufficient logging, missing audit trails, and the ability to delete or modify logs. Countermeasures include comprehensive audit logging, tamper-evident log storage, digital signatures on transactions, and centralised log management.

I - Information Disclosure

Can an attacker access data they should not see? This covers data leaks in API responses, verbose error messages, directory traversal, and unauthorised access to databases or files. Countermeasures include proper access controls, data classification, encryption, and minimising data exposure in responses.

D - Denial of Service

Can an attacker make the system unavailable? This covers resource exhaustion, algorithmic complexity attacks, and distributed denial of service. Countermeasures include rate limiting, input size limits, load balancing, auto-scaling, and CDN-based DDoS protection.

E - Elevation of Privilege

Can an attacker gain higher access than intended? This covers broken access control, privilege escalation, IDOR, and insecure direct object references. Countermeasures include RBAC, least privilege, server-side authorisation checks on every request, and proper separation of admin and user functionality.

PASTA: Risk-Centric Threat Modelling

Process for Attack Simulation and Threat Analysis (PASTA) is a seven-stage methodology that aligns threat modelling with business objectives and risk management. Where STRIDE focuses on technical threat classification, PASTA starts from the business context and works down to technical analysis.

  1. Define objectives: establish the business context, compliance requirements, and risk appetite
  2. Define technical scope: identify the technology stack, infrastructure, and dependencies
  3. Application decomposition: create data flow diagrams, identify trust boundaries and entry points
  4. Threat analysis: research relevant threat intelligence, attack patterns, and adversary capabilities
  5. Vulnerability analysis: map known vulnerabilities to the application components identified in stage 3
  6. Attack modelling: build attack trees that show how an attacker could chain vulnerabilities to achieve their objectives
  7. Risk and impact analysis: calculate residual risk after existing controls and prioritise remediation based on business impact

PASTA is more thorough than STRIDE but requires more effort and cross-functional input. It works well for critical systems, regulatory-driven assessments, and risk assessments where business alignment is essential.

Other Threat Modelling Approaches

Attack Trees

Graphical representations of how an attacker could achieve a specific goal. The root node is the attacker's objective (e.g., "steal customer data"), and branches represent different paths to achieve it. Each leaf node is a specific attack step. Attack trees are excellent for visualising complex, multi-step attack scenarios and identifying which defensive controls would block the most attack paths.

LINDDUN

A privacy-focused threat modelling framework that systematically identifies privacy threats: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance. Particularly valuable for systems subject to GDPR or other privacy regulations.

VAST (Visual, Agile, and Simple Threat modelling)

Designed for agile development environments, VAST creates two parallel threat models: an application threat model (for development teams) and an operational threat model (for infrastructure teams). It integrates into agile workflows by producing threat models as part of sprint planning.

Threat Modelling by Context

The threat modelling approach should adapt to the system being analysed. Here is how to focus your modelling for common contexts.

Web Applications

Focus on the OWASP Top 10 vulnerability categories. Map data flows from the browser through the application to the database. Identify trust boundaries at the CDN, load balancer, application layer, and database layer. Pay particular attention to authentication flows, session management, API endpoints, and data validation. Follow this with web application penetration testing to validate the model.

Cloud Infrastructure

Focus on IAM policies, network segmentation, data encryption, and the shared responsibility model. Map trust boundaries between cloud accounts, VPCs, subnets, and services. Identify threats from overprivileged identities, misconfigured storage, and exposed management interfaces. Our cloud security assessment guide provides a structured approach.

APIs

Map every API endpoint, its authentication requirements, input parameters, and response data. Identify threats from broken authentication, broken object-level authorisation (BOLA/IDOR), mass assignment, injection, and excessive data exposure. APIs are increasingly the primary attack surface for modern applications.

Microservices

Model the communication between services, authentication between services (mTLS, service mesh), shared data stores, and the blast radius of a single compromised service. Microservice architectures increase the attack surface because each service is a potential entry point and the inter-service communication creates additional trust boundaries.

Integrating Threat Modelling into Development

Threat modelling delivers the most value when it is embedded in the development process rather than treated as a separate security activity. Here is how to make it practical for development teams.

  • Design review trigger: require a threat model for any feature that introduces new data flows, trust boundaries, authentication mechanisms, or external integrations
  • Sprint integration: allocate time for threat modelling in sprint planning. A 60-minute session at the start of a feature sprint prevents weeks of security rework later
  • Developer training: train developers in basic threat modelling using STRIDE. Developers who can identify threats in their own designs produce more secure code without waiting for a security team review
  • Lightweight for small changes: not every change needs a full threat model. For minor features, a quick STRIDE checklist in the pull request description is sufficient
  • Living documents: store threat models alongside the code they describe. Update them when the architecture changes. Stale threat models give false confidence

For DevSecOps teams, threat modelling is the design-time counterpart to automated security testing in CI/CD. Together, they provide security coverage across the entire development lifecycle.

Threat Modelling as a Consultancy Service

Threat modelling is a high-value service offering for security consultancies. It complements penetration testing by addressing risks at the design stage, and clients increasingly request it as part of comprehensive security assessments.

  • Engagement structure: a threat modelling engagement typically includes stakeholder interviews, architecture review, DFD creation, threat identification workshops, and a deliverable documenting threats, risks, and recommended countermeasures
  • Pairing with penetration testing: use threat models to scope penetration tests. The threat model identifies the highest-risk areas, and the penetration test verifies whether those risks are exploitable. This delivers better value than untargeted testing. Manage both within a single engagement workflow
  • Reporting: document findings using structured findings management and generate professional deliverables with AI-powered report generation. Score each finding using CVSS scoring for consistent, defensible risk ratings
  • Client delivery: share the threat model and tracked findings through a client portal so clients can view progress and remediation status in real time

For guidance on building and pricing this service, see our guides on pricing security services and scaling your consultancy with automation.

Threat Modelling and Compliance

Several compliance frameworks require or recommend threat modelling as part of a secure development lifecycle.

  • ISO 27001: clause 6.1.2 requires organisations to identify information security risks, which threat modelling directly addresses. See our ISO 27001 audit checklist
  • NIST CSF: the Identify function requires understanding the business context, assets, threats, and vulnerabilities. Threat modelling provides the structured analysis that satisfies these requirements
  • PCI DSS: requirement 6 requires secure development practices including threat analysis for payment applications. See our PCI DSS assessment guide
  • SOC 2: the risk assessment criteria require identifying threats and evaluating their potential impact, which threat modelling formalises. See our SOC 2 compliance guide
  • OWASP SAMM: the Design security practice explicitly requires threat modelling at higher maturity levels

Document your threat models as compliance evidence. Platforms that connect threat analysis findings with compliance tracking make audit preparation significantly more efficient.

Common Threat Modelling Mistakes

  • Boiling the ocean: trying to threat model everything at once instead of focusing on the highest-risk components. Start with internet-facing systems and sensitive data flows
  • Skipping the data flow diagram: jumping straight to identifying threats without understanding the system. The DFD is the foundation and skipping it leads to incomplete and disorganised threat identification
  • Generic threats: listing vague threats like "hacking" instead of specific, actionable threats like "SQL injection on the user search endpoint through the name parameter"
  • Not involving developers: threat models created solely by security teams miss implementation details. Developers know where the shortcuts and assumptions are
  • Treating it as a one-time activity: a threat model is only accurate at the time it was created. Systems change continuously, and the threat model must be updated to remain useful
  • Ignoring the human element: focusing entirely on technical threats while ignoring social engineering, insider threats, and physical security. See our insider threat detection guide for the human dimension

Frequently Asked Questions About Threat Modelling

Turn threat model findings into tracked, scored, and reported results

SecPortal gives security teams a single platform for findings management, CVSS scoring, compliance tracking, and AI-powered report generation. Move from threat identification to client deliverable without switching tools. See pricing or start free.

Get Started Free