NIS2 Risk Management Requirements: Article 21(2)(a) Binds Everyone, CIR 2024/2690 Binds 11 Entity Types

Article 21(2)(a) of the NIS2 Directive is nine words long: “policies on risk analysis and information system security” [1]. Everything else you have read about NIS2 risk management is somebody’s reading of those nine words — including the European Commission’s own. The Commission’s reading runs to 1,227 words across two chapters of the Annex to Implementing Regulation (EU) 2024/2690, and it is directly binding on exactly eleven categories of entity [2]. If yours is not one of them, that Annex is the best available benchmark and nothing more. Which side of that line you sit on decides what a supervisory authority can actually hold you to.

Does CIR 2024/2690 Bind You? The Eleven-Entity Test

In plain terms: the Directive’s obligation applies to every essential and important entity. The Implementing Regulation that spells out how to meet it does not. Article 1 of the CIR names its addressees — it calls them “the relevant entities” — and the list is closed.

Those eleven categories are: DNS service providers; TLD name registries; cloud computing service providers; data centre service providers; content delivery network providers; managed service providers; managed security service providers; providers of online market places; providers of online search engines; providers of social networking services platforms; and trust service providers [2].

The closed list traces back to Article 21(5), which instructed the Commission to adopt implementing acts for that specific group by 17 October 2024. Its second subparagraph adds that the Commission may adopt further acts for other entities — permissive, not mandatory, and none had been adopted for other sectors at the time of writing [1].

If your entity is…	What binds you under 21(2)(a)	Status of the CIR Annex for you
One of the 11 CIR categories	Article 21(2)(a) as transposed plus Annex chapters 1 and 2 of CIR 2024/2690, directly applicable	Binding law. A gap against 1.1.1(a)–(k) or 2.1.2(a)–(j) is an Article 21 infringement
A manufacturer, hospital, energy operator, transport operator, water utility, public administration body — any other essential or important entity	Article 21(2)(a) as transposed into your national law, plus whatever your competent authority has specified	Not binding. In practice the most authoritative available benchmark, and the structure most auditors reach for
A financial entity in scope of DORA	DORA’s ICT risk management provisions, as lex specialis	Largely displaced — check your national transposition for residual duties

The distinction bites in practice. If you sit outside the eleven, an assessor who writes you up for missing point 2.1.2(c) is citing a rule that does not apply to you — the finding may still be sound on its merits, but the citation is wrong. Which side you fall on depends first on your classification; our guide to the seven routes to essential entity status under Article 3(1) covers that step.

What Article 21(2)(a) Actually Says

The Directive gives you nine words and two qualifiers. Article 21(1) sets the standard: measures must be “appropriate and proportionate”, taking into account “the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation”, and must “ensure a level of security of network and information systems appropriate to the risks posed”. Proportionality is assessed against three named factors, and only three: the entity’s exposure to risks, the entity’s size, and the likelihood of incidents occurring and their severity, including societal and economic impact [1].

Article 21(2) then adds the two words doing the most work in the provision — “at least”. The ten measures are a floor, not a ceiling, and they rest on an “all-hazards approach” covering the systems and their physical environment [1]. Point (a) is the only one of the ten that the CIR expands into two Annex chapters, which tells you how broadly the Commission reads it.

Chapter 1: The Policy, and the Signature at Point (k)

In plain terms: chapter 1 is a specification for one document. It tells you eleven things that document must contain, and who has to sign it.

Point 1.1.1 lists contents (a) through (k). Most programmes cover the obvious ones — approach, security objectives, roles, topic-specific policies. Four are missed far more often:

• (e) — a commitment to provide the resources needed for implementation, naming “staff, financial resources, processes, tools and technologies”. A policy that commits to outcomes but not to budget does not meet (e).
• (h) — a list of the documentation to be kept and the duration of retention. The retention period is an explicit requirement, not an implied one.
• (j) — indicators and measures to monitor implementation and “the current status of relevant entities’ maturity level”.
• (k) — “the date of the formal approval by the management bodies”. A policy without a dated board approval on its face is incomplete on the text alone [2].

Point 1.1.2 sets the cadence: reviewed and, where appropriate, updated by management bodies at least annually and whenever significant incidents or significant changes to operations or risks occur, with each review documented. Point 1.2.3 adds a structural requirement easy to skip in a flat organisation — “at least one person shall report directly to the management bodies” on network and information system security [2].

A pattern worth naming: “management bodies” appears 14 times in the Annex’s 9,296 words, and 11 of those 14 sit in chapters 1 and 2. Board accountability across the whole technical specification is concentrated almost entirely in the risk-management measure — which is why Article 20 governance duties and Article 21(2)(a) are best worked as one file, not two.

Chapter 2: The Ten-Element Process at Point 2.1.2

In plain terms: chapter 2 is a specification for a process, not a document. Point 2.1.1 requires a risk management framework, documented risk assessments, and a risk treatment plan — and it names who accepts the leftovers: “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 the management bodies are adequately reported to [2].

Point 2.1.2 then sets out the cybersecurity risk management process as ten elements, (a) through (j):

Point	Requirement	The part most programmes miss
(a)	Follow a risk management methodology	Named and documented, not improvised per assessment
(b)	Establish the risk tolerance level per the entity’s risk appetite	Tolerance and appetite are two separate artefacts here
(c)	Establish and maintain relevant risk criteria	“Maintain” makes this a living document
(d)	Identify and document risks, all-hazards, “in particular in relation to third parties”, including “the identification of single point of failures”	Single points of failure are named explicitly — a register without them is short of the text
(e)	Analyse threat, likelihood, impact and risk level, taking cyber threat intelligence and vulnerabilities into account	CTI is an input to the analysis, not an optional extra
(f)	Evaluate the identified risks against the risk criteria	Evaluation is a distinct step from analysis
(g)	Identify and prioritise treatment options and measures	—
(h)	Continuously monitor implementation of the treatment measures	“Continuously” — not at review points
(i)	Identify who implements each measure and when	Named owner plus a date, per measure
(j)	Document the treatment plan and “the reasons justifying the acceptance of residual risks in a comprehensible manner”	The justification, not just the decision, is the deliverable

Point 2.1.3 pulls two other chapters into scope: prioritising treatment must take account of the asset classification at point 12.1 and the business impact analysis at point 4.1.3, alongside cost against expected benefit [2]. That is why asset work shows up in so many 21(2)(a) briefs — but note where it actually lives. The asset inventory requirement is point 12.4, and chapter 12 opens by stating it exists “for the purpose of Article 21(2), point (i)”. Asset management is measure (i); it reaches (a) only through the 2.1.3 cross-reference. File inventory under (a) in your control matrix and it will not line up with what a CIR-literate assessor asks about. Point 2.1.4 closes the chapter: review the results and the treatment plan at planned intervals and at least annually, and on significant change or significant incident.

ENISA’s non-binding guidance supplies a workable schema for the plan itself — risk description and its effect on security objectives, treatment option, associated assets, mitigating measures, a procedure for assessing whether those measures work, timelines, and responsible roles [3]. Seven fields, none controversial, and a reasonable default where the binding text stops short.

The Six Escape Hatches — and What Using One Costs You

The CIR builds in flexibility through three phrases: “where appropriate”, “where applicable” and “to the extent feasible”. Article 2(2) attaches a price to each. Where a relevant entity considers such a requirement not appropriate, applicable or feasible, it “shall in a comprehensible manner document its reasoning to that effect” [2]. Skipping a qualified requirement is permitted; skipping it silently is not.

What is less well known is how few hatches exist under point (a). Counted across the Official Journal text, the Annex as a whole carries 62 of these qualifiers. Chapters 1 and 2 carry six — three “where appropriate”, three “where applicable”, no “to the extent feasible” at all — against 31 instances of “shall”. Per thousand words, chapter 2 is among the least discretionary chapters in the entire Annex.

The consequence is practical: proportionality arguments do more work under supply chain security or cryptography than they do here. For most of point (a) there is no qualifier to hang one on. What scales with entity size is the depth of the assessment, not whether you perform it. Our control-by-control audit checklist for chapters 1 and 2 maps each requirement to the evidence it needs.

Where Ireland’s Draft Guidance Goes Further Than the CIR

Because the CIR binds only eleven categories, the specification applying to most entities is national. Ireland’s National Cyber Security Centre published draft Risk Management Measures guidance on 4 June 2025 — 16 measures (RMM001–RMM016), addressed to essential and important entities generally rather than to the CIR’s eleven [4]. It is a worked example of how a competent authority reads point (a), and it is not identical to Brussels. Three divergences matter:

• Risk owners. The CIR says residual risks are accepted by management bodies or by accountable persons with authority to manage risks. Ireland’s RMM004.FA02 names the role directly: residual risks are “either treated or risk accepted by risk owners, with adequate reporting to the management board”, and RMM004.SA01 requires that risk owners be identified and their responsibilities documented [4].
• A five-field acceptance schema. Where the CIR asks for reasons “in a comprehensible manner”, the Irish draft twice specifies the fields: the rationale should document “who, what, why, when and condition for review” [4]. That is a concrete, auditable format the EU text does not supply.
• Foundation versus Supporting. Ireland splits every measure into Foundation Actions — controls “which the NCSC consider to be the minimum required to meet the legislative obligations of the Directive” — and Supporting Actions: “Further controls may be required, depending on specific risks faced by the organisation.” [4] Most of the detailed process elements sit in RMM004’s Supporting actions, while the CIR states the equivalent elements at 2.1.2 in binding “shall” language. The two instruments address different populations, so they are not strictly in conflict — but an entity reading only the Irish structure could reasonably conclude the process detail is risk-dependent, where the CIR does not present it that way. If you operate across borders, close that gap deliberately rather than assume it away.

The Irish document is a draft and describes the National Cybersecurity Bill transposing NIS2 as upcoming [4]. Treat it as a strong signal of supervisory expectation, not as settled national law.

What This Means for Your Role

Role	Your part of point (a)	Effort
Board / management body	Approve the policy and date the approval (1.1.1(k)); accept risk assessment results and residual risks (2.1.1); review the policy at least annually (1.1.2)	Low effort, non-delegable
CISO / IT security manager	Own the ten-element process at 2.1.2, including CTI inputs, single points of failure, and continuous monitoring of treatment measures (2.1.2(d), (e), (h))	High
Compliance officer / legal	Maintain the documentation list and retention durations (1.1.1(h)); hold the Article 2(2) reasoning records for every qualified requirement you disapply	Medium
SME owner without a security team	Establish the direct reporting line to the board (1.2.3) and arrange the independent review, using alternative impartiality measures where your size prevents separation of authority (2.3.2)	Medium

The documentation set that closes point (a) is short: a dated, board-approved security policy meeting 1.1.1(a)–(k); a documented risk management framework and methodology; documented risk assessment results; a treatment plan with named owners and dates; records of management-body acceptance of results and residual risks; the review records required by 1.1.2 and 2.1.4; and, inside the eleven, your Article 2(2) reasoning notes. ENISA lists substantially the same artefacts as its evidence examples [3]. For the register structure behind these, see our guide to the risk register and governance hierarchy under Article 21(2)(a).

Infringements of Article 21 carry administrative fines of a maximum of at least EUR 10 000 000 or 2% of total worldwide annual turnover for essential entities, whichever is higher, and EUR 7 000 000 or 1.4% for important entities [1]. Article 21(4) adds that an entity finding itself non-compliant must take corrective measures “without undue delay” — a self-identified gap starts a clock.

Frequently Asked Questions

If CIR 2024/2690 doesn’t bind my sector, can I ignore it?
You can decline to treat it as law and be right on the text. Ignoring it is a different matter: it is the only Commission-level specification of what point (a) means, ENISA’s guidance is written against it, and national frameworks such as Ireland’s draft RMMs track it closely. In practice it is the structure most assessors reach for.

Does ISO 27001 or ISO 27005 satisfy Article 21(2)(a)?
Neither the Directive nor the CIR certifies any standard as sufficient. Article 21(1) requires relevant European and international standards to be taken into account “where applicable”, and ENISA names ISO/IEC 27005:2022 as an example methodology under 2.1.1 [3]. A mature ISMS covers much of the ground; the gaps tend to be the NIS2-specific items — the dated board approval, the maturity indicators at 1.1.1(j), and the retention durations at 1.1.1(h). Our comparison of ISO 27005 against Article 21(2)(a) works through the delta.

Who signs off residual risk — the board or a risk owner, and how often is it revisited?
Under the CIR, either: management bodies, or “persons who are accountable and have the authority to manage risks”, provided the management bodies receive adequate reporting (2.1.1) [2]. Ireland’s draft guidance assigns it to risk owners reporting to the management board [4]. If you delegate, that reporting line is the condition making the delegation valid — not an optional add-on. Cadence is set separately at 2.1.4: at planned intervals and at least annually, plus on significant change or significant incident.

Is asset inventory part of Article 21(2)(a)?
Not directly. Asset management is measure (i), specified at chapter 12, with the inventory at point 12.4. Point 2.1.3 requires the asset classification at 12.1 to be taken into account when prioritising treatment, which is how the two connect [2]. Filing inventory under (a) misaligns your evidence.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) — Articles 20, 21 and 34. EUR-Lex, Official Journal
2. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — Articles 1 and 2, and Annex chapters 1, 2 and 12. EUR-Lex, Official Journal
3. ENISA, Technical Implementation Guidance on Commission Implementing Regulation (EU) 2024/2690, version 1.0, June 2025 (non-binding). ENISA (PDF)
4. National Cyber Security Centre Ireland, NIS 2 Risk Management Measures Guidance, draft dated 4 June 2025. NCSC Ireland (PDF)

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.