PASTA

PASTA (Process for Attack Simulation and Threat Analysis) is a heavyweight risk-centric threat modeling methodology developed by Tony UcedaVélez and Marco M. Morana, formalized in their 2015 book “Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis.” The methodology consists of seven stages that take an analysis from business objective definition through technical scope, application decomposition, threat analysis, vulnerability analysis, attack modeling, and risk impact analysis. The output is threat modeling that is explicitly aligned with business risk priorities and that produces outputs defensible to non-technical stakeholders — which is the methodology’s central strength and the reason it has been adopted in regulated industries and enterprise risk programs.

PASTA is also heavyweight in a way that matters operationally. The seven-stage process is substantial; a complete PASTA analysis can take weeks or months for a single system. For organizations with the maturity, personnel, and time investment to support it, the methodology produces outputs that justify the cost. For organizations without that maturity, PASTA adoption produces threat modeling documentation that satisfies the methodology’s form without delivering proportional value. The honest assessment of PASTA requires being explicit about which organizations it serves well and which it doesn’t.

This page is the deep-dive companion to the Threat Modeling Frameworks umbrella. The scope here is what PASTA actually is, how the seven stages work, where the methodology earns its weight, and how to evaluate whether PASTA is the right choice for a given organization’s threat modeling program.

What PASTA actually is

PASTA is a risk-centric threat modeling methodology that explicitly connects technical threats to business impact through a structured seven-stage process. The “risk-centric” framing is the defining characteristic — PASTA is designed to produce threat modeling outputs that drive risk-prioritized security investment decisions, with the business context defined upfront and carried through to the risk-and-impact analysis at the end.

The methodology differs from other threat modeling frameworks in three structural ways:

The process starts from business objectives, not technical scope. STRIDE starts from a data flow diagram and works through technical threat categories. PASTA starts from “what does this system do for the business, what would it cost the business if it failed, what are the regulatory and compliance requirements that apply” and uses those business framings to drive the rest of the analysis.

Threat intelligence is integrated into the methodology. Stages 4 (threat analysis) and 6 (attack modeling) explicitly use external threat intelligence about realistic adversaries, current attack patterns, and operational reality. STRIDE is intelligence-agnostic — the framework asks “what could go wrong with this design” without reference to who would actually attack it. PASTA asks “what would specific adversaries with documented capabilities do against this design.”

The output is risk-prioritized rather than threat-categorized. STRIDE produces a list of threats by category. PASTA produces a risk-prioritized assessment that connects each threat to business impact, with explicit prioritization for security investment. The end-state artifact is more easily consumed by risk committees, audit functions, and executive stakeholders than category-list outputs typically are.

The methodology was developed by Tony UcedaVélez, founder and CEO of VerSprite, a consulting firm specializing in threat modeling and security risk analysis. The methodology emerged from VerSprite’s consulting practice and was formalized in the 2015 book co-authored with Marco M. Morana. PASTA has been refined through the consulting work and through community feedback in the years since, but the core seven-stage structure has remained stable.

The seven stages

PASTA’s seven stages are the structural backbone of the methodology. Each stage has specific inputs, outputs, and analytical activities. The stages are sequential but iterative — outputs from later stages can feed back into earlier ones, particularly when threat analysis reveals scope considerations that weren’t apparent at the technical-definition phase.

Stage 1 — Definition of Objectives (DO)

The first stage establishes the business context for the threat modeling exercise. The activities at this stage include:

• Business objectives identification — what is the system supposed to accomplish for the business?
• Security and compliance requirements — what regulations, contracts, or policies apply?
• Risk profile identification — what is the organization’s risk tolerance for this system?
• Asset identification — what data, capabilities, and resources does the system handle that have business value?
• Business impact analysis preliminary work — what would the cost be if the system failed in various ways?

The output of stage 1 is a business context document that frames the rest of the analysis. This stage is what distinguishes PASTA most clearly from technically-focused frameworks — STRIDE skips directly to the DFD; PASTA establishes business framing first.

The stage 1 work is typically done by business analysts, compliance staff, and risk management personnel rather than security engineers. The cross-functional nature is intentional and is one of the reasons PASTA requires more organizational investment than lighter-weight frameworks.

Stage 2 — Definition of Technical Scope (DTS)

The second stage establishes the technical scope for the analysis. The activities include:

• Technology stack documentation — what technologies, platforms, and services compose the system?
• Application boundary identification — where does this system end and other systems begin?
• Third-party dependencies — what vendors, libraries, and external services does the system depend on?
• Infrastructure mapping — what underlying infrastructure (cloud services, network components, identity systems) does the system rely on?
• Data flow identification — what data flows in and out of the system?

The output of stage 2 is a technical scope document that catalogs the system’s technical composition. This stage produces inputs that are similar to what STRIDE would require but at greater depth and with explicit attention to the boundary questions that determine where the threat model applies.

Stage 3 — Application Decomposition (AD)

The third stage decomposes the system into its components and produces the modeling artifacts that subsequent stages will analyze. The activities include:

• Use case identification — what are the system’s primary use cases from the business perspective?
• Data flow diagrams — the same DFD artifact STRIDE uses, but typically more detailed.
• Trust boundaries — same trust boundary concept as STRIDE.
• Component decomposition — breaking the system down into its functional components.
• Asset identification at component level — what each component holds, processes, or operates on.

The output of stage 3 is the system decomposition — DFDs, trust boundary maps, component descriptions, use case catalogs. This stage produces what STRIDE would produce in its decomposition phase but typically at greater detail and with explicit attention to the use case and asset framings that connect back to stage 1.

Stage 4 — Threat Analysis (TA)

The fourth stage identifies the threats relevant to the system, drawing on threat intelligence about realistic adversaries and current attack patterns. The activities include:

• Threat actor profiling — who would attack this system, with what capabilities, and for what objectives? PASTA explicitly uses threat intelligence here, including ATT&CK technique tagging for adversary capabilities.
• Threat library application — applying catalogs of known threats (PASTA’s own threat library, CAPEC, ATT&CK, vendor-specific threat catalogs) to the system in scope.
• Threat scenario development — specific scenarios that combine threat actors, capabilities, and targets.
• Threat probability assessment — initial assessment of which threats are realistic given the system’s exposure.

The output of stage 4 is a threat catalog specific to the system, with each threat tied to a threat actor, a capability, and a realistic scenario. This stage is where PASTA most strongly differs from intelligence-agnostic frameworks — the threat catalog is grounded in real adversary behavior rather than in abstract threat categories.

The integration with MITRE ATT&CK and other threat intelligence frameworks is explicit. Mature PASTA programs use ATT&CK as the technique vocabulary for the capabilities side of the threat actor profiles, and use the Diamond Model or equivalent for the analytical structure of the threat scenarios.

Stage 5 — Vulnerability and Weakness Analysis (VA)

The fifth stage identifies the vulnerabilities and weaknesses in the system that the identified threats could exploit. The activities include:

• Existing vulnerability assessment — what vulnerabilities does the system have based on vulnerability scanning, code review, penetration testing, and similar empirical methods?
• Design weakness identification — what design choices create risk regardless of specific vulnerabilities?
• Configuration assessment — what configuration weaknesses exist?
• Vulnerability-to-threat mapping — which vulnerabilities are exploitable by the threats identified in stage 4?

The output of stage 5 is a vulnerability and weakness catalog that connects to the threat catalog from stage 4. The connection is what makes the subsequent attack modeling possible — knowing which vulnerabilities exist and which threats could exploit them produces the input to attack scenario development.

Stage 6 — Attack Modeling (AM)

The sixth stage develops attack scenarios that combine the threats from stage 4 with the vulnerabilities from stage 5 into specific attack paths. The activities include:

• Attack tree development — formal attack trees for the most significant threats, decomposing each attack into the specific steps required.
• Attack pattern application — using CAPEC and other attack pattern libraries to identify how attacks would actually proceed.
• Attack simulation — where appropriate, actually attempting the identified attacks (typically through red team or pen test exercises). This is the “Attack Simulation” part of PASTA’s name.
• Likelihood assessment — based on the attack analysis, how likely is each attack scenario?

The output of stage 6 is a detailed attack model that describes how identified threats would actually be executed against the system. This stage is where PASTA’s depth substantially exceeds lighter frameworks — most threat modeling stops at “this threat applies”; PASTA explicitly works through “this is how the threat would actually be carried out, with these specific steps and these specific prerequisites.”

Stage 7 — Risk and Impact Analysis (RA)

The seventh and final stage produces the risk-prioritized output that connects all the preceding work to business impact and security investment decisions. The activities include:

• Risk calculation — combining likelihood (from stage 6) with impact (refined from stage 1) for each threat.
• Residual risk analysis — what risk remains after existing controls?
• Mitigation prioritization — which mitigations would most effectively reduce risk?
• Investment recommendation — what security investments does the analysis support?
• Reporting to stakeholders — presenting the analysis to risk committees, executive stakeholders, and audit functions.

The output of stage 7 is the risk assessment and mitigation plan that the whole methodology was building toward. This is the artifact that justifies the methodology’s weight — a risk-prioritized assessment that connects technical threats to business impact in a defensible way.

The risk-centric framing in detail

PASTA’s risk-centric framing is the operational distinction from other threat modeling frameworks. The framing has several specific implications:

Threats are analyzed in business context, not in isolation. A “spoofing threat” against a service does not stand alone in PASTA analysis; it is connected to which business processes the service supports, what the business impact would be if the spoofing succeeded, and how the impact compares to other threats against the same or other systems.

Risk is quantified where possible. PASTA encourages quantitative risk analysis — likelihood and impact as numeric values that combine into risk scores — rather than purely qualitative categorization. Quantification has its own challenges (estimates can mask uncertainty, business impact is often genuinely hard to quantify), but the discipline of attempting quantification produces more defensible outputs than purely qualitative analysis.

Prioritization is built into the methodology. PASTA produces ranked outputs, not unranked threat lists. The ranking reflects the business-context-aware risk analysis and is what makes the methodology’s output actionable for executive decision-making.

Compliance is integrated, not bolted on. Regulatory requirements appear in stage 1 (definition of objectives) and influence stages 4-7. Other frameworks tend to treat compliance as a separate exercise that maps onto threat modeling outputs after the fact. PASTA folds compliance into the methodology from the start.

Outputs are designed for non-technical stakeholders. The methodology’s structured progression from business objectives through technical analysis to risk recommendations produces outputs that risk committees, executives, and auditors can engage with. The stages explicitly include reporting and stakeholder communication.

The risk-centric framing is what makes PASTA appropriate for enterprise risk programs. Organizations that need threat modeling outputs to drive investment committee decisions, board-level risk reporting, or formal risk management programs benefit from the framework’s structural alignment with risk management practices.

Where PASTA excels

The methodology earns its weight in several specific contexts:

Enterprise risk programs that need business-aligned threat analysis. PASTA outputs map directly onto enterprise risk management vocabulary and structure. Organizations with mature ERM programs benefit from PASTA’s compatibility with their existing risk management infrastructure.

Regulated industries with formal risk assessment requirements. Financial services, healthcare, government contracting, and other regulated sectors often have specific risk assessment requirements that PASTA’s structured methodology and documented outputs support. The methodology’s heavyweight character is justified when the regulatory requirements require comparable analytical depth.

High-value systems where threat modeling investment is warranted. A system that processes financial transactions, handles sensitive personal data, or supports critical business operations may justify weeks or months of threat modeling investment. PASTA’s depth produces analysis that lighter frameworks cannot match.

Multi-stakeholder threat modeling involving business and technical staff. PASTA’s cross-functional structure (business stakeholders for stage 1, technical staff for stages 2-6, risk management for stage 7) supports threat modeling work that requires input from multiple organizational functions. The methodology provides the structure for productive cross-functional collaboration.

Threat intelligence integration into design-time analysis. Organizations with mature CTI programs benefit from PASTA’s explicit threat intelligence integration. The stage 4 work uses CTI as input to the threat catalog, producing analysis grounded in real adversary behavior rather than abstract threat categories.

Outputs defensible to external stakeholders. Auditors, regulators, insurance providers, and customers may need to see threat modeling outputs. PASTA’s structured, business-aligned, risk-prioritized outputs are typically more defensible to external review than category-list outputs from lighter frameworks.

Where PASTA has limits

Several structural limits warrant honest treatment:

The methodology is genuinely heavyweight. A complete PASTA analysis can take weeks or months for a single system. Multiple systems analyzed in parallel multiply the resource requirements. Organizations without the staff capacity to support the methodology will not complete PASTA analyses at the pace their portfolio requires.

PASTA does not scale to large portfolios. Enterprise architectures with hundreds of systems do not benefit from PASTA applied uniformly across all systems. The methodology was designed for high-value systems where the depth is warranted, not for broad coverage of large portfolios. Lighter-weight frameworks (STRIDE for design-time, ATT&CK-based detection coverage for operations) are appropriate for the bulk of an enterprise’s systems.

The methodology requires substantial methodology expertise. PASTA is more complex than STRIDE and requires personnel who understand the methodology well enough to apply it consistently. Organizations new to threat modeling cannot pick up PASTA without substantial investment in training or consulting. STRIDE has a much lower learning curve.

Quantitative risk analysis is genuinely hard. PASTA encourages quantitative risk calculation, but the inputs to quantification (likelihood estimates, impact estimates) are often based on judgment rather than measurement. Quantitative outputs can mask the uncertainty in their inputs, producing risk scores that look more authoritative than they are.

The methodology assumes business impact can be characterized. For some systems and some kinds of threats, business impact is genuinely difficult to characterize. Privacy harms to individuals, reputational harms, long-term competitive effects of intellectual property loss, and similar non-financial impacts often resist quantification. PASTA can adapt to these cases but does not solve the underlying impact-characterization problem.

Stage iteration can produce scope creep. PASTA stages are sequential but iterative — later stages can feed back into earlier ones. Without disciplined scope management, the iteration can extend the analysis indefinitely. Programs need explicit governance to know when a PASTA analysis is complete.

Tooling support is narrower than for STRIDE. STRIDE has multiple mature tools (Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk, ThreatModeler). PASTA-specific tooling is thinner. IriusRisk and ThreatModeler support PASTA workflows but with less polish than their STRIDE support. Most PASTA work happens in custom internal tooling or in heavyweight spreadsheet-based templates.

Adoption is narrower than for lighter frameworks. PASTA has a substantial user community but is less broadly adopted than STRIDE. Organizations adopting PASTA may struggle to find personnel with PASTA experience and may need to develop their own internal expertise.

These limits are not arguments against PASTA — the framework provides real value in its appropriate context — but they are arguments for matching the framework to the organization’s actual needs rather than adopting it because it signals analytical seriousness.

The relationship to other frameworks

PASTA coexists with several other threat modeling frameworks in mature programs:

PASTA and STRIDE. PASTA can be understood as STRIDE with substantial additional structure. Stage 4 (threat analysis) and the threat identification activities use STRIDE-like category thinking, but within the broader business-aligned framework. Organizations using both typically apply STRIDE for lighter-weight per-feature analysis and PASTA for high-value systems where the deeper methodology is warranted.

PASTA and ATT&CK. Stage 4 (threat analysis) explicitly uses ATT&CK as the vocabulary for capabilities side of threat actor profiles. PASTA’s threat actor profiles include ATT&CK technique tags; the threat scenarios reference specific ATT&CK techniques. The integration is by design.

PASTA and the Diamond Model. The Diamond Model provides the analytical structure for stage 4 threat scenarios in mature PASTA implementations. The four-node structure (adversary, capability, infrastructure, victim) maps onto PASTA’s threat actor + capability + scenario + asset framing.

PASTA and the Cyber Kill Chain. Stage 6 (attack modeling) uses Kill Chain lifecycle structure for organizing attack scenarios. The phases of an attack — reconnaissance through actions on objectives — provide the structure for the attack tree development.

PASTA and OCTAVE. OCTAVE operates at the enterprise asset level, working from organizational risk priorities to identify which systems warrant deeper analysis. PASTA operates at the per-system level, providing the deeper analysis for systems OCTAVE identifies as high-risk. The two frameworks are complementary at different scales.

PASTA and LINDDUN. Privacy-specific threat modeling can use LINDDUN within a PASTA structure. Stage 4 threat analysis can incorporate privacy threats alongside security threats; stage 5 vulnerability analysis can address privacy weaknesses; stage 7 risk analysis can include privacy harm impact.

The general pattern: PASTA is the framework that integrates other frameworks. Mature PASTA programs use ATT&CK for adversary capability vocabulary, the Diamond Model for threat scenario structure, the Kill Chain for attack lifecycle phasing, STRIDE for technical threat category prompts, and LINDDUN for privacy-specific analysis — all within the seven-stage business-aligned PASTA workflow.

Operational use

A few places PASTA shows up in practical work in 2026:

During major system risk assessments. Significant new systems, major architectural changes, or systems undergoing regulatory review often get PASTA-level analysis. The investment is justified by the system’s importance.

During risk committee reporting cycles. Enterprise risk programs that report to risk committees on a regular cadence use PASTA outputs to populate the security risk portion of the reports. The methodology’s risk-prioritized outputs map cleanly onto the risk committee’s vocabulary.

During regulatory and audit engagements. When regulators or auditors request threat modeling documentation, PASTA outputs are typically more defensible than lighter-framework outputs. The methodology’s structured documentation supports external review well.

During mergers, acquisitions, and major business transactions. PASTA-style risk analysis often supports due diligence for business transactions where threat modeling is a required input.

During strategic security planning. Multi-year security investment planning uses PASTA-style risk assessment for the systems that justify the depth. Investment cases for major security spending often benefit from PASTA-level analytical support.

During third-party assessment work. Consulting engagements that produce comprehensive threat modeling deliverables often use PASTA or PASTA-like methodologies. The methodology produces outputs that consulting clients find valuable for the price they paid.

Tooling

The PASTA tooling ecosystem is real but smaller than STRIDE’s:

IriusRisk supports PASTA workflows alongside STRIDE in its commercial threat modeling platform. PASTA-specific templates and stage-by-stage workflow support exist but are less polished than STRIDE support.

ThreatModeler supports PASTA in its commercial platform, with similar positioning to IriusRisk.

Custom internal tooling is common in organizations running PASTA at scale. Spreadsheet templates, internal threat library databases, and custom risk calculation tools support PASTA work in many enterprise programs.

VerSprite’s own consulting tooling is used in PASTA-based consulting engagements. The tooling is proprietary but reflects the methodology’s authoritative source.

Generic threat modeling tools (OWASP Threat Dragon, Microsoft Threat Modeling Tool) can be adapted for PASTA work but are designed for lighter frameworks. The fit is imperfect.

The tooling situation reflects PASTA’s narrower adoption. Organizations committing to PASTA typically need to invest in custom workflow tooling or commercial threat modeling platforms; the lighter tooling ecosystem available for STRIDE does not exist for PASTA.

Persistent pitfalls

Several recurring failure patterns in PASTA adoption:

Adopting PASTA without the organizational maturity to support it. Organizations that adopt PASTA because the methodology signals analytical seriousness, without the personnel, time investment, and cross-functional capability the methodology requires, produce incomplete PASTA analyses that document the methodology’s form without delivering its value. PASTA without the supporting organizational capability is worse than STRIDE done well.

Treating PASTA as a checkbox methodology. The seven stages can be filled in superficially, with stage outputs that satisfy the methodology’s documentation requirements without genuinely doing the analytical work. The failure mode is similar to STRIDE applied as a matrix-filling exercise, but at greater scale because PASTA’s documentation requirements are larger.

Stage 1 work done by security staff instead of business staff. The Definition of Objectives stage is supposed to establish business context, which requires business stakeholders. When security staff produce stage 1 outputs by themselves, the business framing is inferred rather than informed, and the rest of the analysis builds on an imperfect foundation.

Quantitative risk theater. PASTA’s quantitative orientation can produce risk scores that look authoritative without being grounded in defensible input data. The scores feed into executive reporting and budget decisions, with the uncertainty in the underlying inputs hidden by the precision of the outputs. The honest treatment of quantitative risk requires explicit uncertainty ranges and confidence levels, which PASTA accommodates but does not require.

Insufficient threat intelligence inputs. Stage 4 depends on quality threat intelligence about the adversaries relevant to the organization. Programs that use generic threat lists rather than organization-specific threat intelligence produce stage 4 outputs that don’t reflect the organization’s actual threat landscape.

Scope creep through iteration. The methodology’s iterative nature can extend analyses indefinitely. Programs need governance to know when a PASTA analysis is complete and ready for stakeholder reporting.

Forcing PASTA onto inappropriate systems. Not every system justifies PASTA-level analysis. Small features, internal tools, and lower-risk systems can be threat-modeled with lighter frameworks. Forcing PASTA onto inappropriate systems produces analysis bloat without proportional value.

Treating PASTA outputs as static. PASTA analyses are expensive to produce and tempting to treat as one-time artifacts. Systems evolve, threat landscapes change, and business contexts shift. Periodic PASTA refresh is necessary for systems where the original analysis remains operationally important.

Standards and references

• Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis by Tony UcedaVélez and Marco M. Morana (2015) — the canonical reference on PASTA methodology.
• VerSprite — UcedaVélez’s consulting firm, which provides PASTA-based threat modeling services and supplementary materials.
• OWASP Threat Modeling resources — community documentation that references PASTA alongside other frameworks.
• NIST SP 800-30 — Guide for Conducting Risk Assessments, which provides risk management context that pairs with PASTA-style analysis.
• NIST SP 800-53 — the federal control catalog that mitigation recommendations from PASTA analysis can map onto.
• ISO 31000 — risk management principles and guidelines that align with PASTA’s risk-centric framing.

How to actually decide whether PASTA is right for you

PASTA is the right choice when:

• The organization has an enterprise risk management program that needs threat modeling inputs.
• High-value systems exist where the investment in deep threat modeling is justified.
• Cross-functional collaboration between business, security, and risk staff is operationally possible.
• Threat modeling outputs need to be defensible to external stakeholders (auditors, regulators, customers).
• The organization has the personnel and time capacity to support the methodology.
• Threat intelligence integration into design-time analysis is desired.

PASTA is the wrong choice when:

• The organization is doing threat modeling for the first time. STRIDE is the better starting point; PASTA can come later.
• The system being analyzed is small or low-risk. PASTA’s depth is wasted on systems that don’t warrant it.
• The organization lacks the cross-functional capability to support business, technical, and risk inputs to the same exercise.
• The threat modeling needs to fit into agile development sprint cycles. PASTA is structurally incompatible with sprint-level cadence.
• The threat modeling work is being done by a small team without methodology expertise. PASTA requires substantial methodology investment.
• The organization needs broad coverage across many systems rather than deep coverage of high-value systems. Lighter frameworks scale better.

The general guidance: PASTA is the right framework when both the system and the organization justify the investment, and the wrong framework when either does not. Adopting PASTA for the wrong reasons produces analytical theater; matching the framework to the actual context produces threat modeling that is among the strongest available.

Where to go next on this site

Adjacent material on this site:

• Threat Modeling Frameworks — the umbrella overview.
• STRIDE — the lightweight design-time framework that PASTA extends with business risk analysis. Most organizations should start with STRIDE.
• LINDDUN — the privacy-focused parallel framework that integrates into PASTA workflows for privacy-relevant systems.
• MITRE ATT&CK — the technique vocabulary that PASTA’s stage 4 threat analysis explicitly uses.
• MITRE D3FEND — the defensive countermeasure catalog.
• The Cyber Kill Chain — the lifecycle model that informs PASTA’s stage 6 attack modeling.
• The Diamond Model — the CTI analytical structure that supports PASTA’s stage 4 threat scenarios.
• OCTAVE — the asset-driven enterprise risk methodology that operates at a different scale than PASTA.

PASTA is the threat modeling framework that takes the analytical discipline most seriously and demands the most organizational investment as a result. Used well, it produces threat modeling outputs that integrate with enterprise risk management and stand up to external review. Used poorly, it produces heavyweight documentation that satisfies the methodology’s form without delivering its substance. The difference is the organization’s maturity and the system’s value — both determine whether PASTA’s weight is justified.