The Threat Modeling Process: A Step-by-Step Guide

What the threat modeling process is

The threat modeling process is a structured way to answer one question about a system: what threats could realistically affect it, and which of them matter most to the business? Everything else in a threat model, from data flow diagrams to vulnerability lists, exists to answer that question with evidence.

That sounds obvious. In practice, a surprising number of threat models contain no threats at all. Teams draw architecture diagrams, tag components with generic categories, and generate long lists of possible weaknesses. What they skip is the step that gives the exercise its name: modeling the adversaries, motives, and attack patterns that are actually in play against this application, in this industry, right now. The result looks thorough and prioritizes nothing.

This guide walks through a risk-centric threat modeling process built on the seven stages of PASTA (Process for Attack Simulation and Threat Analysis). For each stage it covers the goal, who should be involved, the inputs you need, what to do, and what you should have when the stage is finished. The stages are linear on paper. In real engagements you will loop back, and the guide flags where that tends to happen.

Two principles run through every stage:

• Threats anchor the model. Vulnerabilities, controls, and test cases are prioritized by whether they help a credible threat succeed, not by raw count or severity score.
• Builders and breakers work together. Architects and developers know how the system really works. Offensive testers know how systems really fail. A threat model built by only one group misses half the picture.

---

Before you start: scope, team, and inputs

Most threat models that stall do so before Stage 1, because nobody agreed on what was being modeled or who owned the outcome. Settle three things first.

Pick one target. Model a single application, service, or business capability, not “the platform.” A payments API or a patient portal is a workable scope. An entire cloud estate is not, at least not in one pass.

Assemble the room. Threat modeling is not a solo activity. The roles below do not need to be separate people, but each perspective needs to be present.

Role	What they contribute	Most active in
Business or product owner	Business objectives, impact tolerance, compliance obligations	Stages 1 and 7
Architect or lead engineer	Components, dependencies, trust boundaries, data flows	Stages 2 and 3
Developers and security champions	How the code actually behaves, including undocumented paths	Stages 3 and 5
Threat intelligence or SOC analyst	Industry threat patterns and alert data from the live environment	Stage 4
Vulnerability management team	Qualified scan, SCA, and configuration findings	Stage 5
Penetration tester or red teamer	Attack trees, abuse cases, proof-of-concept exploits	Stage 6
Risk or GRC lead	Translating results into risk ratings and treatment decisions	Stage 7

Gather the inputs you already have. Architecture diagrams, recent pen test reports, scanner output, SIEM alert summaries, the data classification policy, and the applicable regulatory requirements. None of them need to be current or complete. The process will expose the gaps, and that is part of its value. For a deeper look at assigning ownership, see A RACI Guide to Threat Modeling.

---

The threat modeling process, step by step

Each stage produces an artifact the next stage depends on. If you skip one, the later stages still run, but they run on assumptions instead of evidence.

Stage 1: Define business objectives

Goal: Tie the application to the business outcomes it supports, so risk can later be expressed as business impact rather than technical severity.

Inputs: Product requirements, business process documentation, data classification, regulatory obligations (PCI DSS, HIPAA, GDPR, and so on).

What to do:

1. Document what the application does for the business, both front-end (customer-facing) and back-end (operational) processes.
2. Identify the data it creates, stores, or moves, and classify it.
3. Record impact tolerances for confidentiality, integrity, and availability, plus any compliance consequences.
4. Agree on what “acceptable risk” means. Almost no organization can reach zero risk, so the model should focus on threats that most affect business risk through this application.

Output: A short business impact statement and risk profile that Stage 7 will score against.

Stage 2: Define the technical scope

Goal: Know exactly what could be attacked. You cannot defend what you have not inventoried.

Inputs: Architecture diagrams, infrastructure-as-code, cloud account inventories, dependency manifests, third-party integrations.

What to do:

1. List every component: front-end clients, APIs, services, data stores, queues, identity providers, CI/CD pipelines, and third-party services.
2. Record frameworks, versions, hosting environment, and network exposure for each.
3. Pull in front-end, back-end, and infrastructure owners. Decoupled and microservice architectures make it easy for any one person to miss components.

Output: A scoped asset inventory. It doubles as an initial test scope and a checklist for hardening measures.

Stage 3: Decompose the application

Goal: Map how components interact, where data moves, and where trust changes hands.

Inputs: The Stage 2 inventory, plus engineers who know the actual call paths.

What to do:

1. Build data flow diagrams (DFDs) showing data flows and call flows between the components from Stage 2.
2. Mark trust boundaries: browser to API, API to database, internal service to third party, user role to admin role.
3. Identify entry points, actors, and use cases. Then write abuse cases for each: how could this flow be misused?
4. Call out implicit trust, such as services that accept internal traffic without authentication.

Output: DFDs with trust boundaries, an entry point list, and use and abuse cases. Testers use these to target cross-boundary abuse during a pen test. Architects use them to see where design-level controls belong.

Stage 4: Analyze threats

Goal: Identify the threats that are credible for this application. This is the stage threat-free threat models skip.

Inputs: Two sources, used together:

• External threat intelligence on attack patterns targeting your industry and your application type (web, mobile, cloud, API). See open source intelligence for one input.
• Internal threat data from the hosted environment, typically SIEM and WAF alerts showing patterns like denial of service attempts, authentication bypass, data exfiltration, or malicious file uploads.

What to do:

1. Build or update a threat library of actors, motives, and attack patterns relevant to the target.
2. Map each threat to the entry points and data flows from Stage 3 that it could use.
3. Discard threats with no plausible path. Keep the ones you can substantiate with intelligence or observed activity.

Output: A prioritized threat list mapped to the application. It defines which exploitation activities are worth attempting in Stage 6.

Stage 5: Analyze vulnerabilities and weaknesses

Goal: Find the weaknesses that would let the Stage 4 threats succeed.

Inputs: SAST, DAST, and SCA output, cloud and configuration scans, previous pen test findings, and design flaws surfaced in Stage 3.

What to do:

1. Collect vulnerability data across architecture, frameworks, systems, configuration, and code.
2. Have the threat and vulnerability management team qualify it, removing false positives and duplicates.
3. Correlate each remaining finding to the threats it could enable. A medium-severity flaw on a path a known threat uses outranks a critical flaw nobody can reach.

Output: A short list of threat-relevant vulnerabilities instead of a sea of scanner results.

Stage 6: Model and simulate attacks

Goal: Prove which threat and vulnerability combinations are actually exploitable.

Inputs: The Stage 4 threat list, the Stage 5 correlated vulnerabilities, and the Stage 3 DFDs.

What to do:

1. Build attack trees that start from a threat objective and branch through the weaknesses that could achieve it.
2. Prioritize branches that emulate criminally motivated, intelligence-supported attack patterns over generic capture-the-flag techniques.
3. Have penetration testers attempt the highest-priority paths and document proof-of-concept (PoC) results.

This is where the builder and breaker split matters most. Testers without threat context tend to chase whatever is technically interesting. The threat model hands them a scope tied to likely adversary behavior.

Output: Attack trees and PoC evidence showing which paths work, which fail, and which controls stopped them.

Stage 7: Analyze risk and impact

Goal: Rank residual risk and decide what to fix first.

Inputs: The Stage 1 business impact statement and the Stage 6 attack results.

What to do:

1. Score each successful or plausible attack path by likelihood (supported by threat evidence and PoC feasibility) and impact (from Stage 1).
2. Map existing preventive, detective, and responsive controls against each path to find gaps.
3. Decide treatment for each risk: remediate, mitigate, transfer, or formally accept.
4. Assign owners and deadlines across development, IT, and security.

Output: A residual risk register with prioritized remediation, which serves as a shared plan for security, development, and IT teams.

---

What you should have at the end

A finished pass produces seven linked artifacts. Each one is traceable to the stage before it, which is what lets a reviewer ask “why is this risk ranked first?” and get an evidence-based answer.

Stage	Deliverable	Primary consumer
1. Business objectives	Business impact statement and risk profile	Product owner, GRC
2. Technical scope	Asset and dependency inventory	Architects, IT
3. Decomposition	DFDs, trust boundaries, use and abuse cases	Developers, testers
4. Threat analysis	Threat list mapped to entry points	Testers, SOC
5. Vulnerability analysis	Threat-correlated vulnerability list	Developers, TVM
6. Attack modeling	Attack trees and PoC results	Developers, security leadership
7. Risk analysis	Residual risk register and remediation plan	Leadership, all owners

When to run the process again

A threat model is a snapshot. Re-run it, or at least the affected stages, when:

• A major feature, integration, or architectural change ships (Stages 2 and 3 first).
• Threat intelligence shows a new campaign against your industry or tech stack (Stage 4 forward).
• A pen test, incident, or bug bounty report reveals a path the model missed (Stages 3 to 7).
• Compliance scope or business priorities change (Stages 1 and 7).

Teams that release frequently often move toward continuous threat modeling, where Stages 2 through 5 are refreshed automatically from pipeline and telemetry data.

---

Where the process breaks down in practice

The stages are straightforward to describe. Running them well is harder, and the failures tend to repeat.

The threat-free threat model. Teams jump from a diagram (Stage 3) to a scanner export (Stage 5) and call it a threat model. Without Stage 4, there is no way to tell which findings matter, so everything gets ranked by CVSS and the backlog never shrinks.

Diagrams that describe the intended system. DFDs drawn from design documents miss the debug endpoint, the legacy batch job, and the service account with broad permissions. Have engineers who maintain the code validate every diagram.

Breakers with no threat context. Pen testers given only a URL and a time box will find real issues, but not necessarily the ones a motivated adversary targeting your business would pursue. Stage 6 works best when testers receive the Stage 4 threat list as their brief.

Builders left out of the room. The reverse problem is just as common. Security teams model a system they only partly understand, and developers receive findings without the reasoning behind them. Collaboration is what turns a threat model into remediation people actually do.

Stopping at the PoC. A working exploit is evidence, not a decision. If Stage 7 never happens, the business never learns which risks it is carrying, and nobody owns the fix.

Treating the model as a one-time deliverable. A threat model that is not revisited after the next major release quietly becomes fiction. Tie re-runs to change events rather than calendar dates.

None of these are reasons to avoid the process. They are reasons to staff it with the right people and to keep threats at the center of every stage. For the full methodology, see Risk-Based Threat Modeling with PASTA.

---

Frequently asked questions

What are the steps in the threat modeling process?

A risk-centric threat modeling process using PASTA has seven stages: define business objectives, define the technical scope, decompose the application, analyze threats, analyze vulnerabilities, model and simulate attacks, and analyze risk and impact.

Who should be involved in threat modeling?

Both builders and breakers. That typically means a business or product owner, architects, developers or security champions, threat intelligence or SOC analysts, vulnerability management, penetration testers, and a risk or GRC lead.

What is a threat-free threat model?

It is a threat model that maps architecture and lists vulnerabilities but never analyzes which adversaries and attack patterns are credible for the application. Without that analysis there is no reliable way to prioritize findings.

What is the output of the threat modeling process?

The final output is a residual risk register with prioritized remediation. Along the way the process also produces an asset inventory, data flow diagrams, a threat list, correlated vulnerabilities, and attack trees with proof-of-concept results.

How long does the threat modeling process take?

It depends on scope and on how much input material already exists. A single well-documented service can move through all seven stages much faster than a large, poorly documented platform, which is why scoping one target at a time matters.

How often should a threat model be updated?

Update it when the application changes significantly, when new threat intelligence affects your industry or stack, when testing or an incident reveals a missed attack path, or when business priorities or compliance scope shift.

How is PASTA different from STRIDE?

STRIDE is a threat categorization model often used to brainstorm threat types against design elements. PASTA is a full seven-stage process that ties threats, vulnerabilities, and attack simulation to business impact, and it can use STRIDE-style categories within its threat analysis stage.