PASTA Threat Modeling for NIS2: What the 7 Stages Cover and the Article 21(2)(a) Gap They Leave

PASTA gives you the strongest evidence most organisations will ever hold for one sub-requirement of a NIS2 risk analysis, and none at all for seven others. Two counts you can reproduce in an afternoon show why.

ENISA’s Technical Implementation Guidance on cybersecurity risk management measures runs to 170 pages of requirement-by-requirement advice. It mentions PASTA zero times [3]. ENISA’s Compendium of Risk Management Frameworks — the document that guidance points to when it tells you to “select a risk management methodology” — profiles 29 methodologies across 37 pages. PASTA is not one of them [4].

That is not a judgement on PASTA’s quality. It is a signal about where PASTA sits in the EU’s compliance architecture: it is an attack-analysis engine, not a risk-management framework. Run it as the first and it strengthens your Article 21(2)(a) file considerably. Present it as the second and you will be asked for seven documents it was never designed to produce.

What Article 21(2)(a) Actually Requires

In plain terms: the directive gives you eight words. The regulation that interprets them gives you a ten-item checklist. Most of the argument about whether any methodology “satisfies” NIS2 happens because people read the first and not the second.

Article 21(2)(a) of Directive (EU) 2022/2555 requires “policies on risk analysis and information system security” — that is the complete text of the obligation [1], confirmed against a second independent reading of the article [8]. Article 21(2) also states that all the measures it lists “shall be based on an all-hazards approach”, a phrase that turns out to matter more than the eight words themselves.

The operational detail lives in Commission Implementing Regulation (EU) 2024/2690. Its Annex point 2 is headed “Risk management policy (Article 21(2), point (a) of Directive (EU) 2022/2555)”, and point 2.1.2 sets out ten things your cybersecurity risk management process must do, lettered (a) to (j). Point 2.1.1 adds that risk assessment results and residual risks “shall be accepted by management bodies”, and point 2.1.4 requires review “at planned intervals and at least annually” [2]. That is the closest thing to an official specification for a NIS2 risk analysis that exists.

Whether it binds you depends on what you are:

Your entity type	Is CIR 2024/2690 Annex point 2 legally binding?	How to use the ten-item list
DNS service provider, TLD name registry, cloud provider, data centre provider, CDN provider, managed service provider, managed security service provider, online marketplace, online search engine, social networking platform, trust service provider	Yes. Article 1 of the Regulation names exactly these eleven categories as “the relevant entities” [2]	Treat (a)–(j) as mandatory. Where you judge a requirement not appropriate, applicable or feasible, Article 2(2) obliges you to document your reasoning comprehensibly [2]
Every other essential or important entity — energy, health, transport, banking, water, waste, food, manufacturing, public administration, space	No. The Regulation does not extend to you	Article 21(2)(a) still binds you in full. The ten-item list is the best available reading of what the Commission thinks “risk analysis” means. Use it as a benchmark, and check your national transposition, which may impose its own detail

Where PASTA Sits in the EU’s Own Paperwork

In plain terms: ENISA does mention threat modelling in its NIS2 guidance — once, under a different article, and naming different methods.

Search the 170-page Technical Implementation Guidance for threat modelling and you get two hits, both inside the guidance for Annex point 6.2, the secure development life cycle. Annex point 6 is headed “Security in network and information systems acquisition, development and maintenance (Article 21(2), point (e))”. The tip reads: “Consider threat modelling as part of the security requirements analysis.” The evidence example reads: “documentation of the process used for example STRIDE or DREAD, data flow diagrams, and meeting minutes.” [3]

So ENISA’s only reference to threat modelling files it under Article 21(2)(e) — secure development — not under 21(2)(a). And it names STRIDE and DREAD, not PASTA.

Under 21(2)(a), the same document says something quite different. Its first instruction for point 2.1.2 is “Select a risk management methodology”, footnoted with ISO/IEC 27005:2022 as the worked example and a pointer to the Compendium [3]. The Compendium profiles ISO/IEC 27005, four NIST publications, BSI Standard 200-2, three OCTAVE variants, ISACA Risk IT, IRAM2, ETSI TVRA, MONARC, EBIOS Risk Manager, MAGERIT, MEHARI, FAIR, CORAS, HITRUST and a dozen more. Not one is a threat-modelling method, and the words PASTA, STRIDE and DREAD do not appear anywhere in it [4].

Read that carefully, because it is easy to over-read. Both documents are advisory rather than binding, and ENISA explicitly labels its evidence examples “indicative, non-exhaustive” [3]. Nothing forbids you from using PASTA, and an assessor who understands it will recognise good work. But when your regulator’s own technical guidance never places threat modelling under risk analysis, “we run PASTA” is a weak opening answer to “show me your risk analysis methodology”.

It also puts a common vendor claim in perspective. IriusRisk’s PASTA page states that “with the PASTA methodology both compliance and regulatory needs are met” — without naming a single regulation anywhere in the article [7]. Drata’s tutorial is more careful, describing PASTA as a methodology “for application security” [6]. The second description is the one that survives contact with the CIR Annex.

The Seven Stages Against the Twelve Mandated Steps

In plain terms: PASTA covers two requirements outright, contributes to three, and is silent on seven. Every one of the seven is a record, not an analysis.

PASTA’s seven stages, as published by VerSprite — the firm of co-creator Tony UcedaVélez, who wrote the methodology with Marco M. Morana in Risk Centric Threat Modeling (Wiley, 2015) — are: define objectives; define technical scope; application decomposition; threat analysis; vulnerability and weakness analysis; attack modelling; risk and impact analysis [5]. Mapped against the Annex [2]:

CIR 2024/2690 Annex requirement	PASTA stage	Verdict	What you still have to produce
2.1.2(a) follow a risk management methodology	The seven-stage process itself	Partly	Name a risk-management methodology as your frame; cite PASTA as the analysis method used inside it
2.1.2(b) establish risk tolerance in line with risk appetite	—	Doesn’t	An approved appetite statement and quantified tolerance levels
2.1.2(c) establish and maintain risk criteria	— (Stage 1 sets business objectives, not scoring criteria)	Doesn’t	Likelihood and impact scales, and the rule that converts them into a risk level
2.1.2(d) identify and document risks on an all-hazards basis, including third parties and single points of failure	Stages 2–3 map the stack, data flows, trust boundaries and access controls	Partly	Physical, environmental, personnel and supplier risk, plus an explicit single-point-of-failure list
2.1.2(e) analyse risks including threat, likelihood, impact and risk level, using threat intelligence and vulnerabilities	Stages 4–7	Covers	Nothing. Retain the threat library, attack trees and validation results as evidence
2.1.2(f) evaluate risks against the risk criteria	Stage 7 ranks by business impact	Partly	The evaluation is only valid once the criteria in (c) exist
2.1.2(g) identify and prioritise treatment options and measures	Stage 7 countermeasure modelling	Covers	Widen the option set beyond technical countermeasures to transfer, avoid and accept
2.1.2(h) continuously monitor implementation of treatment measures	— PASTA ends at the recommendation	Doesn’t	A tracked treatment plan with live status
2.1.2(i) identify who implements each measure and when	—	Doesn’t	Named owners and target dates per measure
2.1.2(j) document treatment in a risk treatment plan and justify residual-risk acceptance	—	Doesn’t	The plan, plus written reasoning for every residual risk accepted
2.1.1 management bodies accept assessment results and residual risks	—	Doesn’t	A dated acceptance record
2.1.4 review at planned intervals and at least annually	PASTA triggers on a project or a sprint	Doesn’t	A calendar-driven review cycle alongside the event-driven one

The pattern is consistent enough to be useful: PASTA is excellent at working out what could happen to a system, and produces almost none of the governance record the Regulation asks you to keep about it.

The two it does cover, it covers better than the alternatives. That deserves saying plainly, because the mapping above reads as a list of failures and it is not one. Annex 2.1.2(e) asks you to analyse threat, likelihood, impact and risk level “taking into account cyber threat intelligence and vulnerabilities” [2] — four inputs and two sources, in one sentence. A conventional asset-based assessment usually meets this with a workshop: a room full of people estimating likelihood from experience, with threat intelligence entering as background knowledge rather than as a traceable input.

PASTA meets it with an audit trail. Stage 4 builds the threat list from environmental data and industry threat intelligence, so the intelligence input is a named artefact rather than an assumption. Stage 5 correlates those threats to actual weaknesses in the design and code, which is the vulnerability input. Stage 6 tests viability through attack modelling, so a likelihood estimate carries reasoning behind it instead of a number someone volunteered [5]. If an assessor ever asks how you arrived at a likelihood rating — and that is a fair question that most risk registers answer badly — a PASTA engagement can show its working.

The Three Gaps That Actually Fail an Audit

In plain terms: the seven blanks are not seven separate problems. They are three.

1. The scope gap — applications versus the entity

PASTA’s unit of analysis is an application. Drata’s description is typical — a methodology “for application security” — [6] and VerSprite’s own stage definitions refer to “the application” throughout [5]. Article 21(2) requires an all-hazards approach across the network and information systems the entity uses, and Annex 2.1.2(d) names third parties and single points of failure explicitly [2].

The mechanism behind the mismatch is worth understanding, because it tells you what to run instead. PASTA reasons forward: here is a technical scope, here is an adversary, here is what they could achieve. All-hazards risk analysis reasons outward from consequence: here is a service we must keep running, here is everything that could stop it. Most of what the second approach finds has no adversary at all — a power failure, a flood, a departing engineer who was the only person with the OT credentials, a supplier outage. A flawless PASTA model of your customer portal will not mention any of them, and it is not a defect of the method that it doesn’t.

2. The governance gap — no scale, no owner, no signature

Five of the seven blanks — (b), (c), (i), (j) and point 2.1.1 — are governance artefacts. PASTA computes a risk level per validated threat from the evidence it gathered, which is internally consistent and locally sensible. What it cannot do is make two assessments comparable, because that requires organisation-wide criteria that exist before any model is built.

This is why the missing criteria matter more than they look. A management body cannot accept a risk level whose scale is undefined; it would be signing off on a number with no stated meaning. ENISA’s evidence list for point 2.1.1 is specific about what an assessor expects to see: a documented risk management framework, documented results from previous risk assessments, a documented risk treatment plan, a record of management-body approval of the assessment results, and a separate record of approval of the residual risks [3]. A threat model report satisfies part of the second item and none of the rest.

3. The lifecycle gap — sprint cadence versus the annual clock

PASTA fires when you build or change something; VerSprite places Stage 1 “early in the SDLC or for a given sprint” [5]. Annex point 2.1.4 requires review at planned intervals and at least annually, and again when significant changes or significant incidents occur [2].

Event-driven and calendar-driven triggers catch different failure modes, which is why the Regulation asks for both. A system nobody has touched for eighteen months never re-enters a sprint-triggered model — and a stable system is precisely where risk drifts quietly, as dependencies age, the threat landscape moves and a control that was proportionate last year stops being so.

How to Run PASTA So It Counts

In plain terms: keep PASTA and demote it. Name a recognised risk-management methodology as the frame, and run PASTA inside it as the analysis engine for the systems that justify the effort.

Step	What you do	Effort
1. Name the frame	Adopt a risk-management methodology from ENISA’s compendium [4] — ISO/IEC 27005:2022 is the one ENISA footnotes [3] — and write it into your risk management policy. State in the policy that PASTA is the analysis method applied to in-scope applications	Medium
2. Publish criteria before you model	Define likelihood and impact scales, the rule that produces a risk level, and your appetite and tolerance. PASTA Stage 7 then scores into your scales instead of its own	Medium
3. Scope PASTA deliberately	Apply it where attacker simulation earns its cost: internet-facing services, systems processing the data whose loss defines your worst case, and new builds. Everything else gets the standard assessment	Low
4. Land the output in the register	Every validated Stage 7 threat becomes a register row carrying a risk level from your scales, a treatment decision, a named owner and a target date	Medium
5. Cover what PASTA cannot see	Run a separate all-hazards pass for physical, environmental, personnel and supplier risk, and list single points of failure	Medium
6. Close the governance loop	Monitor the treatment plan, write up residual risks with reasons, record management-body acceptance, and review at least annually	High

Who owns which part. The commonest failure we see in this pattern is a good threat model that stalls because nobody outside the engineering team was ever assigned a role in it.

Role	Owns
Security architect / application security lead	PASTA Stages 2–6: technical scope, decomposition, threat library, attack modelling
Business risk owner	Whether a risk is accepted, and whether the impact scale reflects the business
CISO or security manager	Choosing the frame, mapping PASTA output into the register, commissioning the all-hazards pass
Compliance officer	The evidence chain, and the Article 2(2) written reasoning wherever a requirement is judged not applicable
Management body	Formal acceptance of assessment results and residual risks — point 2.1.1 places this with them specifically

If you do not build software, do not start here. PASTA earns its cost when you develop or heavily configure the systems you run. If you buy everything off the shelf, your effort belongs in the asset and scenario assessment the CIR list describes, and your Article 21(2)(e) evidence comes from supplier assurance rather than your own threat models. Our practical NIS2 risk assessment guide for SMEs covers that route.

The Evidence an Assessor Will Ask For

ENISA publishes example evidence for each Annex requirement [3]. Checked against what a PASTA engagement leaves behind:

Evidence ENISA lists for Annex point 2.1	Does PASTA produce it?
Documented risk management framework	No. PASTA documents a process, not your framework
Documented results from previous risk assessments	Partly. The threat model report is a documented result for its own scope
Documented risk treatment plan	No
Record of approval of risk assessment results by management bodies	No
Record of approval of residual risks	No

One more obligation is easy to miss. Where a relevant entity decides a requirement marked “where appropriate”, “where applicable” or “to the extent feasible” does not apply to it, Article 2(2) of the Regulation requires the reasoning to be documented in a comprehensible manner [2]. “We use PASTA instead” is not that reasoning. A short written rationale explaining which risks the threat model covers, which the all-hazards pass covers, and why the split is proportionate to your exposure, is.

For the wider set of obligations that Article 21(2)(a) carries beyond risk analysis itself, see our breakdown of the Article 21(2)(a) risk management requirements. If you are running an ISMS in parallel, the mechanics of a defensible methodology document are set out in our guide to building an ISO 27001 risk assessment methodology that passes audit.

Frequently Asked Questions

Does PASTA satisfy Article 21(2)(a) on its own?
No methodology satisfies a legal obligation on its own, and this site does not judge anyone compliant. On the evidence: PASTA addresses two of the twelve Annex requirements outright and contributes to three more, which leaves seven governance records to produce separately. Used inside a named risk-management frame, it makes the analysis in (e) unusually strong.

Is STRIDE a better fit for NIS2 than PASTA?
For the narrow purpose of evidencing threat modelling under Article 21(2)(e), STRIDE has one advantage that has nothing to do with quality: ENISA names it [3], and an assessor reading the guidance will recognise the word. For the analysis itself, PASTA’s attacker simulation and business-impact linkage go further than STRIDE’s categorisation. Many teams run STRIDE for breadth and PASTA on the systems that warrant depth. We work through the same Annex mapping for that method in STRIDE threat modeling under NIS2.

Do we need ISO 27005 as well?
Not specifically ISO/IEC 27005 — but you need something in that role, and 27005:2022 is the example ENISA footnotes [3]. EBIOS Risk Manager, MONARC, MAGERIT and the NIST SP 800-30 route are equally defensible choices from the same compendium [4]. What they share, and what a threat-modelling method does not attempt, is organisation-wide risk identification of the kind Annex 2.1.2(d) describes.

We are a hospital, not a cloud provider. Does the CIR Annex apply to us?
Not as binding law. Article 1 of Regulation 2024/2690 limits it to eleven digital categories [2]. Your Article 21(2)(a) obligation is identical, however, and the Annex is the Commission’s own articulation of what it means — which makes it the most defensible benchmark available while you check what your member state’s transposition adds.

Where does PASTA help most under NIS2?
Annex 2.1.2(e), the requirement to analyse threat, likelihood, impact and risk level using threat intelligence and vulnerabilities [2]. Its Stage 4 threat library and Stage 6 attack modelling produce exactly the reasoning chain that requirement describes, and it is the part of a risk assessment most organisations do thinnest.

Sources

1. European Union, Directive (EU) 2022/2555 (NIS2) — Article 21(1), Article 21(2) opening subparagraph and points (a) and (e).
2. European Commission, Commission Implementing Regulation (EU) 2024/2690 — Article 1 (scope), Article 2(2), and Annex points 2.1.1, 2.1.2(a) to (j), 2.1.3, 2.1.4 and 6.
3. ENISA, Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0, June 2025 (PDF) — guidance and evidence examples for Annex points 2.1 and 6.2, footnote 13. Non-binding, advisory only.
4. ENISA, Compendium of Risk Management Frameworks with Potential Interoperability, January 2022 (PDF) — sections 3.1 to 3.29, the 29 profiled frameworks.
5. VerSprite, PASTA Threat Modeling: The 7 Stages Explained — the published stage definitions, from the firm of PASTA co-creator Tony UcedaVélez.
6. Drata, PASTA Threat Modeling: Tutorial + Best Practices.
7. IriusRisk, Threat Modeling PASTA Methodology.
8. nis-2-directive.com, NIS 2 Directive, Article 21 — used as an independent second reading to verify the Article 21 text quoted above.

Occurrence counts in the two ENISA documents were produced by extracting the published PDFs and counting matches directly, on 16 September 2026. They describe those documents at that date, not ENISA’s position on any methodology.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.