ISO 31000 Risk Management vs NIS2 Article 21: ENISA Names It Zero Times in 170 Pages — Here’s What It Still Buys You

Search ENISA’s 170-page technical implementation guidance for the NIS2 cybersecurity risk-management measures and ISO 31000 is not in it. Zero occurrences across 398,526 characters, and the same for IEC 31010. ISO/IEC 27005 appears twice, ISO/IEC 27001 five times, ISO/IEC 27002 nine times, NIST 109 times [3]. The Commission’s own account of what the implementing regulation was built from — recital 3 of CIR (EU) 2024/2690 — names ISO/IEC 27001, ISO/IEC 27002, ETSI EN 319401 and CEN/TS 18026:2024 [2]. ISO 31000 is absent there too.

That is not a verdict on the standard. It is a statement about which layer of your risk programme the EU chose to legislate. If ISO 31000 already runs across your enterprise, the useful question is not whether it “counts” — it is which parts of Article 21(2)(a) it carries, which parts it structurally cannot touch, and what a supervisor will ask you to produce that ISO 31000 never told you to write down.

What Article 21 binds you to — and the exact status of any standard

In plain terms: NIS2 never makes a standard mandatory. It makes an outcome mandatory and treats standards as one input among several.

Article 21(1) requires “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems”. Its second subparagraph then sets the frame every standards discussion has to fit inside: “Taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation, the measures … shall ensure a level of security of network and information systems appropriate to the risks posed” [1]. Standards sit behind a double qualifier — where applicable, and relevant.

Article 25(1) narrows the second qualifier further. Member States “shall, without imposing or discriminating in favour of the use of a particular type of technology, encourage the use of European and international standards and technical specifications relevant to the security of network and information systems” [1]. ISO 31000 is a general risk-management guidance document, written by ISO/TC 262 and applicable to any risk an organisation faces [7]. It is not, on its own terms, a network-and-information-security standard, which is why the EU’s cyber instruments keep reaching past it.

The practical consequence is one most framework-comparison articles get backwards. A gap between your programme and a standard is not, by itself, a legal breach — as ENISA puts it, none of the relevant risk-management publications “have any legal basis throughout the European Union” [4]. What is binding is the outcome in Article 21(1), the ten measures in Article 21(2), and the corrective-action duty in Article 21(4), which requires an entity that “finds that it does not comply with the measures” to take “all necessary, appropriate and proportionate corrective measures” without undue delay [1]. An undocumented deviation is the exposure, not the deviation itself. Our breakdown of the Article 21(2)(a) risk-management requirements covers who those obligations bind and where the implementing regulation takes over.

Your current position	What actually binds you	What to do with ISO 31000
ISO 31000 runs enterprise-wide; no cyber-specific risk method	Article 21(2)(a), plus CIR Annex points 1 and 2 if you are a relevant entity	Keep it as the container. Add a cyber-scoped process inside it — this is the case CIR 2.1.2 explicitly anticipates
ISO/IEC 27001 or 27005 in place; ISO 31000 not used	Same	No action needed. You are already at the layer ENISA and the Commission map to
Neither in place	Same	Pick the cyber-scoped guidance first. ISO 31000 is the container, not the content
You are one of the 11 entity types named in CIR Article 1 (DNS, TLD registries, cloud, data centres, CDN, MSP, MSSP, online marketplaces, search engines, social platforms, trust service providers)	CIR (EU) 2024/2690 Annex is directly applicable law, not good practice [2]	Points 2.1.1 to 2.1.4 are your checklist. Map ISO 31000 clauses to them, not the other way round

The zero-mention test: what the EU points to instead

Two EU documents decide, in practice, which standards a supervisor will recognise on sight: the implementing regulation’s recitals, and ENISA’s technical guidance. Neither reaches ISO 31000. Here is the count, run on the published texts.

Standard	ENISA Technical Implementation Guidance (170 pp) [3]	Named in CIR recital 3 as a basis? [2]
ISO 31000	0	No
IEC 31010 (risk assessment techniques)	0	No
ISO/IEC 27005	2	No
ISO/IEC 27001	5	Yes
ISO/IEC 27002	9	Yes
NIST (CSF 2.0 and SP 800 series)	109	No

Where ENISA does send you is instructive. At the guidance for CIR point 2.1.1 — the risk-management framework requirement — footnote 13 offers a worked example of a suitable methodology and names ISO/IEC 27005:2022. At the guidance on risk criteria, footnote 15 reads: “More information on risk criteria can be found in ISO/IEC 27005:2022, paragraph 6.4” [3]. Risk criteria are an ISO 31000 concept — the standard devotes clause 6.3.4 to defining them [7]. Even for its own vocabulary, ENISA routes readers to the information-security branch of the family rather than the parent.

The same pattern holds in ENISA’s Compendium of Risk Management Frameworks with Potential Interoperability, the document footnote 13 points to for a wider survey. It catalogues around 30 frameworks in sections 3.1 to 3.30 — ISO/IEC 27005, five NIST publications, BSI 200-2, OCTAVE, EBIOS Risk Manager, MAGERIT, MEHARI, MONARC, FAIR, COSO ERM and more. ISO 31000 is not one of the catalogued entries. It appears three times in the whole report, and every time as the ancestry of something else: OCTAVE FORTE is “partly based on” it, EBIOS Risk Manager is “compatible” with it, MEHARI is “compliant with the guidelines set by the ISO 27005:2011 standard, and ISO 31000” [5].

Read that as a layer problem, not disapproval. ENISA states plainly that its guidance “is not legally binding and is only of an advisory character”, that “the mapping should not be interpreted as a measure of equivalency among different standards or frameworks”, and — the line worth quoting to your own steering committee — that “to implement the requirements, the relevant entities may build upon their current usage of standards or frameworks, if available” [3]. The regulator’s position is extend what you have, not replace it. ISO 31000 is also not alone in this — the same silence surrounds ISO 27701, the privacy management standard NIS2 never names. Our summary of the ENISA technical implementation guidance sets out how the whole document is structured.

The two texts do not mean the same thing by “risk”

This is the gap that causes real rework, and no competing guide covers it: ISO 31000 and NIS2 define the central word differently, and the difference is directional.

Concept	ISO 31000:2018	NIS2 / CIR 2024/2690
“Risk”	“Effect of uncertainty on objectives” (clause 3.1) [6]. Not limited to adverse effects — clause 6.5.2 treats pursuing an opportunity as a legitimate risk treatment [4]	“The potential for loss or disruption caused by an incident … expressed as a combination of the magnitude of such loss or disruption and the likelihood of occurrence of the incident” (Article 6(9)) [1]
Anchor point	Organisational objectives	An incident affecting network and information systems
Upside risk	In scope. Clause 6.5.2 lists “taking or increasing the risk in order to pursue an opportunity” as a valid treatment option [4]	Out of scope. CIR 2.1.2(g) to (j) recognise treatment, monitoring, ownership and documented residual-risk acceptance — no opportunity branch [2]
What it means for your register	Entries may include opportunities and strategic upside	A supervisor’s view of your Article 21(2)(a) evidence has no place to put those entries

ENISA spotted this collision years ago, against the earlier directive. Its 2022 Risk Management Standards report observes that ISO definitions “diverge depending on whether a risk is connected to a defined objective (ISO 31000) or not”, then notes that in Directive (EU) 2016/1148 “there is a different definition of risk”, where “the focus here is on the threat component in relation to the source of risk not to the effect” [4]. NIS2’s Article 6(9) tightened that further by pinning risk to an incident and to a magnitude-times-likelihood expression.

The reconciliation runs one way only, and ISO says so itself. IWA 31:2020, ISO’s own workshop agreement on using ISO 31000 inside management systems, notes that some sectors use a narrower sense of the term that “focuses on the potential negative impact of deviations from the expected”, and that “this approach can be considered to be included in the broader definition of risk in ISO 31000:2018, 3.1” [6]. Every NIS2 risk is an ISO 31000 risk. The reverse does not hold.

So the work is filtering, not rebuilding. If you already maintain an ISO 31000 register, do not start a second one. Derive a cyber-scoped view from it: keep every entry whose loss or disruption traces to an incident affecting network and information systems, drop the opportunity entries from that view, and re-express what remains as magnitude and likelihood in the sense Article 6(9) uses. Keep the parent register intact — the next section is the reason why.

Where ISO 31000 earns its place: the CIR integration clause

There is one sentence in binding EU law that an enterprise-wide ISO 31000 framework answers better than any information-security standard does. CIR Annex point 2.1.2 requires relevant entities to establish a cybersecurity risk management process, and then adds: “The cybersecurity risk management process shall be an integral part of the relevant entities’ overall risk management process, where applicable” [2].

That clause presupposes an overall risk management process and says the cyber one has to be part of it, not parallel to it. Governing that overall process is precisely what ISO 31000 is for — ENISA’s own characterisation is exact: “ISO 31000:2018 does not give guidance on a risk management system but describes a risk management framework” [4]. A framework is what clause 2.1.2 is asking you to plug into. ISO 31000’s clause 5 (leadership, integration, design, implementation, evaluation, improvement) and its eight principles [6] are the integration machinery; clause 6 supplies the process shape the CIR then itemises.

Mapped against the ten sub-duties in CIR 2.1.2, the picture is consistent: the shape is there, the security-specific content is not.

CIR Annex 2.1.2 sub-duty	Nearest ISO 31000:2018 clause	Verdict
(a) Follow a risk management methodology	Clause 6 (Process)	Covered in form. The methodology itself must still be written down for your context
(b) Risk tolerance in accordance with risk appetite	6.3.4 Defining risk criteria	Partial. ISO 31000 sets criteria against objectives; the CIR expects a stated appetite and a derived tolerance
(c) Establish and maintain risk criteria	6.3.4	Covered in form
(d) Identify risks, all-hazards, including third parties and single points of failure	6.4.2 Risk identification	Partial. The all-hazards breadth is native to ISO 31000; the named cyber factors are not
(e) Analyse threat, likelihood, impact, risk level, using cyber threat intelligence and vulnerabilities	6.4.3 Risk analysis	Not covered. Threat intelligence and vulnerability inputs are outside ISO 31000’s scope
(f) Evaluate against risk criteria	6.4.4 Risk evaluation	Covered in form
(g) Identify and prioritise treatment options	6.5.2 Selection of risk treatment options	Covered, minus the opportunity branch (see previous section)
(h) Continuously monitor implementation of treatment measures	6.6 Monitoring and review	Covered in form; no interval is specified
(i) Identify who implements each measure and when	6.5.3 Preparing and implementing risk treatment plans	Covered in form
(j) Document treatment in a plan, and the reasons justifying residual-risk acceptance “in a comprehensible manner”	6.7 Recording and reporting	Partial. ISO 31000 requires recording; the comprehensibility standard and the justification duty are the CIR’s own

If you want a documented bridge rather than an improvised one, IWA 31:2020 exists for exactly this: its Annex A maps ISO 31000’s clauses to the high level structure used by ISO management system standards [6]. It is a workshop agreement, not a standard, so treat it as a useful artefact rather than evidence in itself.

Three gaps ISO 31000 will not close

These are the items a supervisor asks for that ISO 31000 gives you no instruction to produce. Effort estimates below are practitioner judgement for an organisation that already has a working risk process, not a figure from any source.

Gap	What ISO 31000 gives you	What NIS2 or the CIR requires	Effort to close
Who accepts residual risk	Approval by the risk owner, a role ISO 31000 leaves you to define	CIR 2.1.1: “Risk assessment results and residual risks shall be accepted by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks, provided that the relevant entities ensure adequate reporting to the management bodies” [2]	Low to medium — mostly a delegation decision plus a signature record
How often you review	Clause 6.6 requires monitoring and review; it sets no period	CIR 2.1.4: review and update the risk assessment results and treatment plan “at planned intervals and at least annually, and when significant changes to operations or risks or significant incidents occur” [2]	Low — a calendar entry and a trigger list, then hold to it
How you prove any of it to a third party	Nothing. The ISO catalogue abstract for the standard states it “is not intended for the purpose of certification” [8]	Your own documentation is the evidence. ENISA’s guidance lists what that looks like: a documented risk management framework, documented results from previous assessments, a documented treatment plan, and records of management approval [3]	Medium — this is where most of the real work sits

The non-certifiability point catches people out in both directions. It does not weaken ISO 31000; it means no certificate exists to hand over, so the burden falls entirely on your documentation. If you need an attestable route, that runs through ISO/IEC 27001, which is one of the two standards the CIR names in recital 3. The overlap and the shortfall in the neighbouring standard are covered in our ISO 27005 versus NIS2 comparison — note that the review-interval gap above is one both standards share.

What to do next, by role

Risk manager or CISO. Do not stand up a second register. Derive the cyber-scoped view from the ISO 31000 one, then close the three gaps in the table above in order: named acceptor, review calendar, evidence pack. Write the methodology document even though ISO 31000 does not ask for one — CIR 2.1.2(a) does.

Compliance officer. Your exposure is documentary. Check that the residual-risk acceptance record names a person or body with the authority the CIR describes, that the reasons for acceptance are written “in a comprehensible manner”, and that the last review is inside twelve months. If you are not one of the 11 CIR entity types, these points are the best available benchmark rather than direct obligations — but supervisors read the same document.

Board or management body. The question to ask is not “are we ISO 31000 compliant”. It is “who signed the residual risks, on what evidence, and when was it last refreshed”. Article 21(4)’s corrective-action duty starts running the moment an entity finds a non-compliance, so a review that surfaces a gap starts a clock.

Owner of a smaller entity without a formal framework. Start with the assessment, not the framework. Our practical NIS2 risk assessment guide for SMEs works through a first cycle at a proportionate scale; adopt ISO 31000’s framework layer later, when there is more than one risk domain to integrate.

Key takeaways

• ISO 31000 appears zero times in ENISA’s 170-page NIS2 technical implementation guidance and is not among the standards CIR recital 3 names as the regulation’s basis [2][3].
• That reflects layering, not rejection. NIS2 legislates an outcome; Article 25(1) only encourages standards “relevant to the security of network and information systems” [1].
• The definitions differ directionally: ISO 31000’s “effect of uncertainty on objectives” contains NIS2’s incident-anchored, loss-only definition, not the reverse [1][6].
• CIR Annex 2.1.2 requires the cyber risk process to be “an integral part of the … overall risk management process” — the one clause where an ISO 31000 framework is a direct asset [2].
• Three gaps remain regardless: management-body acceptance of residual risk, the at-least-annual review floor, and the absence of any certification route [2][8].

Frequently asked questions

Does ISO 31000 certification prove NIS2 compliance?
No such certification exists for organisations. The published ISO abstract for ISO 31000:2018 states it “is not intended for the purpose of certification” [8]. Individual training certificates exist, but they attest to a person’s knowledge, not to an organisation’s risk programme. Under NIS2 your evidence is your own documentation either way.

If we already run ISO 31000, do we have to adopt ISO/IEC 27005 as well?
Nothing in NIS2 or CIR 2024/2690 requires either standard. What is required is a documented cybersecurity risk management process meeting the sub-duties in CIR Annex 2.1.2 [2]. ISO 31000 supplies the framework and the process shape; the cyber-specific analysis inputs in 2.1.2(e) — threat intelligence, vulnerabilities — are where practitioners generally reach for ISO/IEC 27005, which is also where ENISA points [3].

Why does ENISA reference ISO 31000 in some reports but not in its NIS2 guidance?
Both are true and consistent. ENISA’s 2022 Risk Management Standards report identifies ISO 31000 and ISO/IEC 27005 as “the most relevant risk management standards in the international domain” and recommends European standards bodies adopt them as European Norms [4]. Its 2025 NIS2 implementation guidance maps requirements to standards that address network and information system security specifically, and ISO 31000 does not [3].

Does the all-hazards wording in Article 21(2) favour ISO 31000?
Partly, and it is ISO 31000’s strongest argument. Article 21(2) requires measures “based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents”, and CIR 2.1.2(d) repeats the phrase [1][2]. ISO 31000 is genuinely hazard-agnostic. But the all-hazards scope in NIS2 is still bounded by “incidents” affecting those systems — it widens the hazard set, not the definition of risk.

Is CIR 2024/2690 binding on us at all?
Directly, only if you are one of the 11 entity types named in its Article 1 — DNS service providers, TLD name registries, cloud computing providers, data centre providers, CDN providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers [2]. For everyone else it is the most detailed published statement of what a competent authority considers adequate under Article 21(2), which is why it is worth treating as the working benchmark.

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 Union, Directive (EU) 2022/2555 (NIS2) — Article 6(9) definition of risk, Article 21(1) to (4), Article 25(1) standardisation.
2. European Commission, Commission Implementing Regulation (EU) 2024/2690 — recital 3, Article 1, and Annex points 2.1.1, 2.1.2 and 2.1.4.
3. ENISA, Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0, June 2025 (PDF) — guidance and evidence examples for Annex point 2.1, footnotes 13 and 15. Non-binding, advisory only.
4. ENISA, Risk Management Standards, March 2022 (PDF) — comparison of risk definitions, characterisation of ISO 31000 as a framework rather than a management system, and recommendation 9.
5. ENISA, Compendium of Risk Management Frameworks with Potential Interoperability, January 2022 (PDF) — sections 3.1 to 3.30, and the ISO 31000 references under OCTAVE FORTE, EBIOS Risk Manager and MEHARI.
6. ISO, IWA 31:2020, Risk management — Guidelines on using ISO 31000 in management systems (PDF preview) — clause 4 on the use of the term “risk”, clause 5 on the eight principles, Annex A.
7. ISO, ISO 31000:2018, Risk management — Guidelines, redline preview (PDF) — foreword (ISO/TC 262) and the complete clause 4 to 6 contents list.
8. AFNOR, ISO 31000:2018 catalogue record — the published ISO abstract, including “It is not intended for the purpose of certification”.