ISO 27005:2022 Satisfies Most of Article 21(2)(a) — But Misses the Proportionality Test, Significance Thresholds, and Annual Review Trigger

Most organisations treating ISO 27005:2022 as their Article 21(2)(a) risk assessment framework cover the core risk methodology requirements well — and are confidently unaware of the gap. The standard provides an excellent process backbone: structured identification, layered analysis methods, and a monitoring cycle that maps cleanly to what NIS2 calls “policies on risk analysis and information system security.” What it does not provide is the regulatory scaffolding CIR 2024/2690 adds on top: mandatory cyber threat intelligence inputs, single point of failure documentation, a specific annual review trigger, and a proportionality test you must be able to show an auditor.

This article maps ISO 27005:2022 clause by clause against Article 21(2)(a) and the CIR 2024/2690 Annex I mandatory fields, identifies where the standard exceeds what NIS2 requires, and names the three specific obligations ISO 27005 cannot satisfy on its own.

What Article 21(2)(a) and CIR 2024/2690 Actually Require

Article 21(2)(a) of Directive (EU) 2022/2555 establishes the foundational obligation: entities must implement “policies on risk analysis and information system security.” [1] The text is intentionally broad — a principle, not a specification. The practical requirements for your NIS2 risk assessment documentation are detailed in implementing acts and member-state transposition, not in Article 21 itself.

The most precise specification applies through Commission Implementing Regulation (EU) 2024/2690, which entered into force in October 2024 and covers DNS service providers, TLD registries, cloud service providers, data centres, content delivery networks, managed service providers, managed security service providers, online marketplace and social network platforms, and trust service providers. [6] For these entities, Annex I Section 2 of the CIR translates Article 21(2)(a) into a concrete field list.

For NIS2 entities outside the CIR’s direct scope — manufacturing, healthcare, energy, and public administration — Article 21 plus each member state’s transposition act governs. The gap analysis below remains relevant; the CIR-specific field requirements apply directly only to CIR-covered entities.

The table below maps CIR Annex I Section 2 mandatory fields against ISO 27005:2022 coverage:

CIR Annex I Mandatory Field	ISO 27005:2022 Coverage
Documented risk methodology with risk criteria and risk appetite alignment	Full — Clauses 6.2 and 6.4
Risk identification: threats, vulnerabilities, existing controls	Full — Clause 6.3 (asset-based and event-based approaches)
Risk analysis: likelihood, impact, and risk level	Full — Clause 7 (qualitative, quantitative, semi-quantitative)
Risk evaluation against risk acceptance criteria	Full — Clause 8
Risk treatment plan with documented options and responsibilities	Full — Clause 9
Residual risk justification in a comprehensible manner	Partial — ISO 27005 requires acceptance; the “comprehensible manner” standard is CIR-specific
Cyber threat intelligence as a mandatory input to risk analysis	Not addressed — ISO 27005 treats CTI as an optional enhancement
Explicit identification of single points of failure	Not addressed — implicit in asset-based analysis but not a named deliverable
Management body residual risk acceptance with documented authority	Not addressed — governance requirement specific to NIS2 and CIR
Annual review minimum and significant-incident trigger	Partial — ISO 27005 specifies “planned intervals”; the annual floor and trigger mechanism are CIR-specific
Proportionality documentation per Article 21(1)	Not addressed — regulatory dimension outside ISO 27005 scope

What ISO 27005:2022 Delivers: The Risk Process Foundation

ISO 27005:2022 is the only ISO standard dedicated entirely to information security risk management — ISO 27001 requires you to conduct a risk assessment; ISO 27005 tells you how. [3] Its 2022 revision restructured significantly: from twelve clauses and six annexes in the 2018 version to ten clauses and one annex, producing a more flexible and methodology-neutral framework. [3]

Context establishment (Clause 6.2): Define the scope, organisational context, and risk acceptance criteria before identifying a single threat. This creates the documented risk criteria that Article 21(2)(a) policies must establish. ISO 27005 section 6.4 — specifically referenced in ENISA’s NIS2 Technical Implementation Guidance [7] — covers risk criteria definition in detail, including acceptable risk levels and risk appetite boundaries.

Risk identification (Clause 6.3): ISO 27005:2022 provides two complementary approaches. The event-based approach starts from threat scenarios and works backwards to affected assets — practical for organisations beginning with threat intelligence feeds. The asset-based approach catalogues assets first, then identifies threats and vulnerabilities specific to each. [3] Both require documenting already-implemented controls as part of identification, which establishes the inherent-versus-residual risk distinction that auditors check against treatment plans. [4]

Risk analysis (Clause 7): Three analysis methods are supported: qualitative (descriptive scales), quantitative (financial values), and semi-quantitative (numeric scoring without full financial modelling — added in the 2022 revision). [3] ISO 27005 requires factoring in already-implemented controls when calculating risk levels, which means your risk register documents residual risk rather than theoretical inherent risk from the start.

Risk evaluation (Clause 8): Assessed risks are compared against the risk criteria from context stage. ISO 27005 explicitly links evaluation to risk appetite — the same concept CIR Annex I Section 2.1.2 mandates as “explicit risk tolerance and appetite alignment.” [2] The standard’s language maps directly to the regulatory requirement.

Risk treatment (Clause 9): Four options — avoid, reduce, transfer, or accept — with documented treatment decisions and residual risk acceptance for each assessed risk. This maps to CIR Section 2.1.2(j)’s requirement for a documented treatment plan, though the CIR adds a “comprehensible manner” standard for residual risk justifications that ISO 27005 does not specify. [2]

Monitoring and review (Clause 10): Continuous tracking of risk levels and periodic reassessment at planned intervals. This clause provides the review cycle structure. The CIR adds an annual minimum frequency and an event-driven trigger — the practical gap addressed below.

An organisation running ISO 27005:2022 correctly has a documented methodology, risk criteria, risk appetite alignment, treatment decisions, and a monitoring cycle — the full process backbone of Article 21(2)(a) compliance. Four CIR-specific regulatory layers, however, sit outside the standard’s scope.

Where ISO 27005:2022 Goes Beyond NIS2

Article 21 does not require asset valuation. It does not prescribe a specific risk analysis method. It does not provide a threat taxonomy. ISO 27005:2022 delivers all three — and applying the standard typically produces risk documentation richer than the regulatory minimum, which strengthens your position in a supervisory review.

Asset valuation depth: ISO 27005 supports structured valuation of information assets across financial, operational, and reputational dimensions. [4] CIR Annex I Point 12.1 requires asset classification — categorisation by criticality — but does not require quantified valuation. An ISO 27005 process that includes asset valuation provides a documented business-value rationale for each classification decision. An auditor asking “why is this system high-criticality?” receives a documented answer rather than a judgment call.

Dual identification approaches: The 2022 revision introduced a methodological choice NIS2 does not prescribe. The event-based approach is effective when starting from threat intelligence or structured threat frameworks; the asset-based approach is the natural method for mapping single points of failure — a CIR-specific requirement. [3] Using both approaches in a single risk assessment cycle provides more defensible completeness than either method alone, and gives the risk register coverage from two analytical directions.

Semi-quantitative analysis: For organisations wanting numeric risk scores without full actuarial financial modelling, ISO 27005:2022’s semi-quantitative option provides a repeatable, documented methodology with auditable results. [3] NIS2 requires proportionate measures, not a specific scoring scale — but a documented scoring method makes proportionality claims quantitative rather than qualitative. “Our residual risk score of 4 falls below our accepted threshold of 6” is more auditable than “we determined this risk is acceptable.”

Threat taxonomy framework: ISO 27005 provides structured threat categorisation across cyber, physical, human, and environmental threat sources. [4] CIR mandates cyber threat intelligence integration but provides no standardised categorisation schema. Organisations using an ISO 27005 methodology have a taxonomy structure for systematically mapping incoming CTI feeds to pre-defined threat categories — making the mandatory CTI integration step traceable and auditable rather than informal.

The Three CIR Gaps ISO 27005 Does Not Cover

These are the requirements that create audit exposure for organisations treating ISO 27005 as complete NIS2 risk coverage. Each is explicit in CIR 2024/2690 or Article 21(1) of the Directive. None appears in ISO 27005:2022.

Gap 1: The Proportionality Test

ISO 27005 is methodology-neutral. The standard makes no distinction between a cloud hyperscaler and a DNS resolver handling 10,000 queries per day. Article 21(1) is explicit: cybersecurity measures must be “appropriate and proportionate” considering the entity’s degree of risk exposure, size, incident likelihood and severity, and implementation costs relative to risk. [1]

Your risk documentation must therefore include a proportionality determination — a documented explanation of why your risk management programme is calibrated to your organisation’s specific risk profile. A competent authority inspector expects evidence that you considered your sector classification, entity size, and cost-benefit trade-offs when scoping the programme. Understanding whether you are an Essential or Important entity directly affects the expected depth of this proportionality assessment. ISO 27005 has no clause for this regulatory determination. It must be added as a named step in your risk methodology and updated whenever your entity classification changes.

Gap 2: The Annual Review Trigger

CIR Annex I Section 2.1.4 mandates review “at planned intervals and at least annually, and when significant changes to operations or risks or significant incidents occur.” [2] ISO 27005 Clause 10 specifies monitoring “at planned intervals” — identical phrasing, but missing two critical elements: the annual minimum floor and the event-driven trigger mechanism.

The trigger is where organisations most commonly fail. A “planned interval” can be quarterly, annual, or longer — ISO 27005 does not prescribe a frequency. CIR sets the floor at once per year. More importantly, the CIR creates an event-driven reassessment obligation: a significant incident must trigger a risk assessment review, not wait for the next scheduled cycle. CIR Article 3 establishes significance criteria for covered entities, defining what constitutes a significant incident that activates the review requirement. [6] An ISO 27005 monitoring cycle operating only on a calendar schedule does not satisfy this trigger obligation.

Gap 3: Three CIR-Specific Mandatory Documentation Fields

Cyber threat intelligence as a mandatory input: CIR Annex I Section 2.1.2 requires risk analysis to incorporate “cyber threat intelligence and vulnerabilities” — not as an optional enrichment, but as a named mandatory component. [2] ISO 27005 treats CTI as an input to threat identification, useful but not prescribed. Under the CIR, you must document your CTI sources and demonstrate their integration into the risk analysis process. Referencing ENISA’s Threat Landscape, sector-specific ISAC feeds, or national CERT advisories in your methodology — with a documented review step before completing risk identification — satisfies this. A risk register with no CTI provenance does not.

Single point of failure identification: CIR Annex I Section 2.1.2 requires explicit identification of single points of failure alongside standard risk parameters. [2] ISO 27005 Clause 6.3 covers dependency identification through asset-based analysis but does not require a named SPOF step or a SPOF register as a distinct deliverable. For CIR-covered entities, this must be explicit: a dependency mapping output that identifies which service failures cascade into availability loss, and how each flagged SPOF is addressed in the risk treatment plan. The SPOF register is a distinct deliverable, not an implicit output of the risk identification phase.

Management body residual risk acceptance: CIR Annex I Section 2.1.1 requires residual risks to be accepted by management bodies “with accountable and authority to manage risks,” with established reporting lines. [2] ISO 27005 Clause 9 covers residual risk acceptance as a process step but does not require documented governance authority or named sign-off chains. Under NIS2’s Article 20, management bodies bear personal accountability for cybersecurity governance decisions. The CIR’s residual risk acceptance requirement links the risk process to that accountability framework — the risk treatment record must carry named management body approval with documented authority, not just a process-step sign-off.

Practical Integration: Building a CIR-Compliant Risk Process on an ISO 27005 Foundation

The correct approach is to treat ISO 27005 as the methodology engine and add five NIS2-specific documentation layers on top. This preserves a working process while closing the CIR Annex I audit gaps.

Step 1 — Document the proportionality determination. Before your first risk assessment cycle, produce a proportionality statement covering your NIS2 entity classification, relevant size metrics, a representative worst-case incident impact scenario, and the cost-benefit rationale for your programme’s scope and depth. Attach it to your risk management policy and update it when your classification changes. This document does not exist within ISO 27005 — it is a purely regulatory deliverable.

Step 2 — Name your CTI sources in the methodology. Add a named sub-step to your ISO 27005 identification phase: “Review current CTI inputs for new threats and vulnerabilities before completing risk identification.” Document the sources — ENISA Threat Landscape, [7] relevant sector ISAC feeds, national CERT advisories — in the methodology document itself. This elevates CTI from informal background knowledge to a documented, auditable process step with named inputs.

Step 3 — Add SPOF identification as a named deliverable. Within your asset-based identification phase, add a dependency mapping exercise with an explicit output register. For each critical service, document its upstream technical dependencies, whether each represents a single point of failure, and the risk treatment applied to each flagged SPOF. This is a distinct register, not an output of the main risk register.

Step 4 — Formalise the review trigger, not just the review calendar. Your risk management policy must define two things: the annual review date, and the criteria triggering an unscheduled review. For CIR-covered entities, reference Article 3 significance criteria. [6] For others, reference your national competent authority’s guidance. Document who is notified when a trigger event occurs, what scope is re-assessed, and within what timeframe the review must be completed.

Step 5 — Add named management body sign-off to treatment records. Amend your risk treatment approval procedure to require explicit management body acceptance, identifying the approving role by title and delegated authority. Residual risk justifications must be written in non-technical language a board member can read and meaningfully approve — this is what CIR Section 2.1.2(j)’s “comprehensible manner” standard requires. [2] The justification document bridges the risk team’s technical analysis and the board’s governance accountability under Article 20.

Frequently Asked Questions

Does using ISO 27005:2022 as my methodology satisfy Article 21(2)(a)?

ISO 27005 is an accepted framework — ENISA’s NIS2 Technical Implementation Guidance explicitly references it alongside ISO 27001 and NIST CSF. [7] Using it addresses the process requirement of Article 21(2)(a). It does not by itself satisfy the proportionality documentation, CTI integration, SPOF register, or management body acceptance requirements imposed by CIR 2024/2690 or national transposition acts on top of Article 21.

Is there an ISO 27005 certification my organisation can obtain?

No. ISO 27005 is a process standard, not a certification scheme. Organisations implement it; they do not certify against it. ISO 27001 certification — which requires a risk assessment process without mandating ISO 27005 as the method — is the most common certification pathway for demonstrating NIS2 risk management maturity to competent authorities. [5]

My organisation is not in the CIR’s scope. Does this analysis apply?

The three documented gaps reflect CIR requirements explicitly. For non-CIR entities, Article 21(1)’s proportionality obligation and Article 20’s management accountability framework create equivalent obligations at a less specified level. The gap direction is the same; the documentation specificity depends on your member state’s transposition act and your national competent authority’s supervisory expectations. [5]

What is the practical audit risk of relying solely on ISO 27005?

Competent authorities reviewing risk assessment documentation expect CTI integration evidence and documented management body acceptance — both referenced in ENISA’s implementation guidance. [7] An ISO 27005-based risk register with no CTI documentation and a process-step signature rather than named management body approval with documented authority may pass internal self-assessment but is unlikely to satisfy a formal supervisory review under CIR 2024/2690.

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.

Sources

1. European Parliament. “Directive (EU) 2022/2555 (NIS2) — Article 21.” NIS2 Directive Resource. nis-2-directive.com
2. Advisera. “CIR 2024-2690 Annex I: Technical and Methodological Requirements.” advisera.com
3. Secureframe. “The ISO 27005 Approach to Information Security Risk Management: 2022 Updates Explained.” secureframe.com
4. Securapilot. “Risk Management according to ISO 27005: Practical Guide.” securapilot.com
5. Legiscope. “NIS2 Risk Management and Security Requirements.” legiscope.com
6. NISD2.eu. “CIR 2024/2690 — NIS2 Technical Measures.” nisd2.eu
7. ENISA. “NIS2 Technical Implementation Guidance.” enisa.europa.eu