NIS2 Risk Management: The Risk Register Structure and Governance Hierarchy Behind Article 21(2)(a)

This article provides general information only and does not constitute legal advice. NIS2 implementation varies by member state and sector — always verify requirements against your national transposition law and applicable authority guidance.

Article 21(2)(a) sounds like a single line item: “policies on risk analysis and information system security.” In practice it’s the measure everything else in Article 21 hangs off — your incident handling, supply chain security, and business continuity plans all reference the risk register this measure produces. Most implementation guides stop at “run a risk assessment.” Three things they skip: which hazards actually belong in the register, who is legally supposed to sign which policy, and what a proportionate risk appetite looks like for a 40-person firm versus a 4,000-person one.

In plain language: you need two documents — a risk analysis policy (how you find and rate risks) and an information system security policy (how you protect what you found) — backed by a live risk register, approved at the right level of management, scaled to your actual size and exposure. The rest of this guide builds each piece.

What Article 21(2)(a) Actually Requires

Under Article 21(1) of the NIS2 Directive (EU) 2022/2555, essential and important entities must take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems.” Article 21(2) then states that these measures “shall be based on an all-hazards approach” and lists ten minimum areas, the first being “policies on risk analysis and information system security” [1].

Commission Implementing Regulation (EU) 2024/2690 turns that one line into an actual process. Its Annex, section 2.1.2, requires entities to: follow a documented risk management methodology; set a risk tolerance level consistent with their risk appetite; establish risk criteria; identify and document risks (including third-party risk); analyse each risk by threat, likelihood, impact and resulting risk level; evaluate risks against the criteria; prioritise treatment options; monitor treatment implementation; assign an owner and timeline to each measure; and document the accepted residual risk with a stated justification [2]. That’s a process specification — not a form. Nowhere does the regulation hand you a template with named columns, which is exactly why so many registers end up incomplete: teams build a spreadsheet that satisfies the risk-scoring habit (likelihood × impact) and quietly skip the ownership, treatment-monitoring, and residual-risk-justification steps CIR 2024/2690 also requires.

For the step-by-step mechanics of running the assessment itself — a 5×5 scoring matrix, threat catalogue, and worked SME example — see our NIS2 risk assessment guide. This article covers the layer above it: the policy structure, register design, and governance sign-off that turn a one-off assessment into an audit-ready Article 21(2)(a) program.

Why this one measure carries so much weight: every other Article 21(2) measure references the same risk register. Incident handling prioritises response based on the risk level you already assigned. Business continuity plans around the highest-impact scenarios your register identifies. Supply chain security is, in effect, the third-party rows of this same register with extra contractual controls layered on top. Get the risk analysis and register wrong at 21(2)(a), and the gap propagates into every measure built on it — which is also why supervisory reviewers tend to start here.

The All-Hazards Scope: Why Your Risk Register Can’t Be Cyber-Only

The most common Article 21(2)(a) gap isn’t a missing control — it’s a register that only contains cyber risk. Article 21(2) is explicit that measures must follow “an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents” [1]. Recital 79 illustrates what that physical environment includes: “theft, fire, flood, telecommunication or power failures, or unauthorised physical access and damage to, and interference with” an entity’s information and processing facilities [1]. A recital doesn’t create a binding obligation by itself, but it signals how regulators are meant to read the operative all-hazards clause in Article 21(2) — and every national competent authority we reviewed applies it that way.

In practice, that means your register needs three risk domains, not one:

Domain	What belongs here	Typical register gap
Cyber	Malware, phishing, unpatched software, misconfigured cloud access, credential compromise	Usually covered — the default starting point for most teams
Physical	Fire, flood, power/telecom failure, theft, unauthorised access to server rooms or offices	Often missing entirely, or handled by facilities management with no link to the IT register
Supply chain	Direct-supplier compromise, managed-service-provider access, software dependency vulnerabilities	Present as a supplier list, rarely rated with the same likelihood/impact criteria as cyber risk

The fix is structural, not just additive: use one risk register with a “domain” field, one set of likelihood/impact criteria applied consistently across all three domains, and one owner list that includes facilities and procurement alongside IT. Splitting these into three separate spreadsheets is the single most common reason supervisory reviews flag an Article 21(2)(a) program as incomplete — not because the physical or supply-chain risks are unassessed, but because they’re unassessed in the same system the regulation expects to see.

Article 21(2)(d) covers supply chain security as its own measure, with deeper contractual requirements than we can cover here — our supply chain security guide goes into supplier classification and contract clauses. What matters for 21(2)(a) is simpler: your risk register needs a row for supply-chain risk, not a separate document for it.

The Governance Policy Hierarchy: What the Board Signs vs What Management Signs

CIR 2024/2690’s Annex, section 1.1, draws a line that most generic templates blur: the entity’s highest-level policy on the security of network and information systems “shall be approved by the management bodies,” while topic-specific policies “shall be approved by an appropriate level of management” [2]. That’s two distinct approval tiers, not one policy document rubber-stamped twice.

• Tier 1 — the top-level security policy: board or senior-management-body approval. Sets risk appetite, security objectives, and overall governance structure. Reviewed and re-approved on a fixed cycle (annually is standard practice).
• Tier 2 — topic-specific policies: risk analysis methodology, access control, incident handling, supply chain security, cryptography, and the rest of the Article 21(2) measures. Approved by the relevant department head or security function — CISO, IT lead, or equivalent — operating within the risk appetite Tier 1 set.

Article 20 NIS2 reinforces why Tier 1 sign-off can’t be delegated away entirely: management bodies must approve the cybersecurity risk-management measures, oversee their implementation, and can be held personally liable for non-compliance. For a deeper look at oversight models and how to structure board minutes that evidence this, see our Article 20 board governance guide. The practical failure mode we see most often: a CISO writes and approves the entire policy stack, including the top-level document, with no board resolution on file. That’s a Tier 1 gap even when every topic-specific policy underneath it is solid.

The Proportionality Test: Setting Risk Appetite by Entity Size

Article 21(1)’s proportionality clause is a legal principle, not an opt-out: “due account shall be taken of the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity” [1]. In practice, that means an SME and an enterprise can both be fully compliant with Article 21(2)(a) while running very different risk-management operations. What we haven’t found in any competing guide is a concrete way to tell the two apart. Here’s a practical starting framework — treat it as a planning tool, not a legal threshold:

Factor	SME (roughly <250 staff, single site)	Enterprise (multi-site or >250 staff)
Risk assessment frequency	Annually, plus after major IT changes	Continuous or quarterly, with event-triggered re-assessment
Methodology	Simple scoring matrix (e.g. 5×5 likelihood/impact)	ISO 27005 or NIST SP 800-30 formal methodology, often both combined
Register granularity	Risk-by-asset-category (e.g. “customer database,” “on-site servers”)	Risk-by-individual-asset, tracked in a GRC platform
Residual risk acceptance	Owner + one senior manager sign-off	Formal risk committee with documented rationale per accepted risk
Realistic effort to stand up	1–2 person-weeks using existing templates	Ongoing function, typically a fractional or full FTE role

The National Cyber Security Centre (NCSC) Ireland — the Irish national competent authority for a large share of NIS2 sectors — points smaller entities toward the CyberFundamentals (CyFun) framework specifically because it’s a tiered, standards-based tool rather than a single fixed bar [3]. Recent academic work on SME cybersecurity governance under NIS2 makes a related point: for the smallest entities, the constraint usually isn’t which framework to pick, it’s building the internal awareness and habit of risk review in the first place — proportionality achieved through prioritisation of the highest-impact steps rather than a formal tiering exercise [5]. Either way, “proportionate” never means “no documented risk register” — it means the depth and frequency of that register scales to your actual exposure.

The Risk Register Structure: An Original Framework Built From CIR 2024/2690

To be precise about what follows: CIR 2024/2690 specifies a risk-management process (the ten steps in section 2.1.2 above) — it does not hand you a register template. The structure below is our own practical synthesis, built to capture every one of those process steps in a single working document. Treat the left column as the legal anchor and the rest as recommended practice.

Register field	CIR 2.1.2 step it satisfies	Status
Asset / domain (cyber, physical, supply chain)	(d) identify and document risks	Practical structure
Threat and vulnerability description	(d), (e) analyse threat, likelihood, impact	Practical structure
Likelihood and impact rating	(e) analyse; (f) evaluate against risk criteria	Legally required output
Resulting risk level	(e), (f)	Legally required output
Treatment measure and owner	(g) prioritise treatment; (i) assign responsibility and timeline	Legally required output
Treatment status / monitoring note	(h) continuously monitor implementation	Legally required output
Residual risk and acceptance justification	(j) document residual risk acceptance reasoning	Legally required output

Seven fields, four of which map directly to a named CIR requirement rather than general good practice — which is the real audit risk in most registers we’ve reviewed: teams complete the first three or four columns (asset, threat, likelihood/impact) because that’s what a basic risk-matrix template teaches, then leave treatment ownership, monitoring status, and residual-risk justification blank. Those three are exactly the fields CIR 2.1.2(g)–(j) singles out, and a reviewer checking Article 21(2)(a) compliance will ask for them by name.

Implementation Roadmap: From Gap to Audit-Ready

Sequencing matters more than speed here — a register built before the governance tier is approved has no risk appetite to score against.

Step	What to do	Effort
1	Get the top-level security policy drafted and approved by the management body (sets risk appetite)	Medium
2	Write the risk analysis methodology as a topic-specific policy (scoring criteria, frequency, roles)	Low
3	Build the register with all three domains (cyber, physical, supply chain) and the seven fields above	Medium
4	Run the first full assessment cycle and populate treatment owners and timelines	High
5	Document residual risk acceptance with management sign-off for anything not fully treated	Low
6	Set a review cadence (annual minimum; event-triggered on major IT or organisational change)	Low

Who Owns This: A Role-Responsibility Table

Role	Responsibility under Article 21(2)(a)
Board / management body	Approves the top-level security policy and risk appetite; oversees implementation (Article 20)
CISO / security lead	Owns the risk analysis methodology, runs assessments, maintains the register
Compliance / legal officer	Confirms documentation meets CIR 2024/2690 process requirements; maintains the audit trail
Department / asset owners	Own individual treatment measures and residual-risk justifications for their area

Documentation Checklist: What to Have Ready Before a Review

A supervisory review or internal audit of Article 21(2)(a) typically asks for the same handful of documents. Missing any one of these is a more common finding than a missing technical control:

• Top-level security policy with a visible management-body approval date
• Risk analysis methodology document, version-controlled
• Current risk register covering cyber, physical, and supply-chain domains
• Evidence of treatment measure ownership and monitoring (not just a static list)
• Residual risk acceptance records with named sign-off and reasoning
• Review history showing at least an annual cadence

Note: reporting expectations, review cadence, and the specific format a national competent authority will accept can vary by member state and sector — transposition of NIS2 is not yet uniform across the EU [4]. Confirm current expectations with your national competent authority before an audit.

Common Mistakes That Fail Reviews

Current state	Required state	Effort to close
Register only covers cyber risk	All-hazards register: cyber, physical, supply chain in one system	Medium
Top-level policy approved by IT/CISO only	Management-body (board) approval on file	Low — mainly a governance-process fix
Register scores likelihood/impact but leaves treatment owner blank	Every risk has a named owner and timeline (CIR 2.1.2(i))	Low
No record of why an unmitigated risk was accepted	Documented residual-risk justification, signed off (CIR 2.1.2(j))	Low
Same policy and register reused for 2+ years unchanged	Annual review minimum, event-triggered re-assessment	Low

Frequently Asked Questions

Does Article 21(2)(a) require a specific risk register template?

No. CIR 2024/2690 specifies the risk-management process (documented methodology, risk criteria, treatment tracking, residual-risk justification) but does not mandate column names or a fixed template [2]. The seven-field structure in this guide is a practical way to satisfy that process, not a legally required form.

Can a small business use a simpler methodology than an enterprise?

Yes, within limits. Article 21(1)’s proportionality principle allows the depth and frequency of your risk process to scale with your size and exposure — but it does not remove the requirement for a documented methodology, a register, and management sign-off [1].

Who has to approve the top-level security policy?

Per CIR 2024/2690 Annex section 1.1, the highest-level policy on network and information system security must be approved by the entity’s management body — not delegated entirely to IT or a security function [2].

Does the risk register need to include physical and supply-chain risks, or just cyber?

All three. Article 21(2) requires an all-hazards approach explicitly aimed at protecting both network/information systems and their physical environment, and Article 21(2)(d) separately covers supply-chain security [1].

Is ISO 27005 enough to satisfy Article 21(2)(a) on its own?

It covers most of the risk-analysis process but not all of it. ISO 27005:2022 gives you a solid risk-identification and evaluation method; it doesn’t build in NIS2’s proportionality test, significance-threshold logic, or the CIR-mandated annual review trigger. Our ISO 27005 gap analysis breaks down exactly where the standard stops and CIR 2024/2690 picks up.

For a complete step-by-step walkthrough, see which entities CIR 2024/2690 actually binds under Article 21(2)(a).

Sources

1. European Parliament and Council. Directive (EU) 2022/2555 on Measures for a High Common Level of Cybersecurity Across the Union (NIS2 Directive) — Articles 20, 21 and Recital 79. EUR-Lex
2. European Commission. Commission Implementing Regulation (EU) 2024/2690 — Technical and Methodological Requirements for Cybersecurity Risk-Management Measures, Annex Sections 1.1 and 2.1.2. EUR-Lex
3. National Cyber Security Centre (NCSC) Ireland. NIS 2 Cyber Security Risk Management Measures. NCSC Ireland
4. European Commission. NIS2 Directive Transposition in EU Countries. Shaping Europe’s Digital Future
5. Garrone, R. Proportionate Cybersecurity for Micro-SMEs: A Governance Design Model Under NIS2. arXiv