Residual Risk Under NIS2: Document It Against the 4 CIR Clauses, Not the Directive

Search the full text of the NIS2 Directive for “residual risk” and you get nothing. Zero hits, recitals included. The same for “risk acceptance”, “risk appetite”, “risk tolerance” and “risk criteria” — none of those phrases appear anywhere in Directive (EU) 2022/2555.

Every residual-risk obligation in EU NIS2 law lives in Commission Implementing Regulation (EU) 2024/2690, where the phrase appears exactly four times. Those four clauses do not say the same thing: different triggers, two different acceptance standards, and one requirement most programmes satisfy by half.

Where the Residual-Risk Duty Actually Lives

The short version: if you are one of eleven named digital-infrastructure categories, a binding regulation tells you exactly what to document. If you are anything else — energy, health, transport, water, manufacturing, public administration — no EU instrument mentions residual risk at you at all, and that same regulation is still the benchmark you will be measured against.

Your entity	Is CIR 2024/2690 binding?	What that means for your records
DNS providers, TLD registries, cloud providers, data centre providers, CDN providers, MSPs, MSSPs, online marketplaces, online search engines, social networking platforms, trust service providers	Yes, directly. Article 1 names these eleven categories and no others.	The four Annex clauses below are binding text. “Shall” means shall.
Every other essential or important entity under NIS2	No. The Regulation does not reach you.	No EU rule names residual risk at you. The duty is inferred, and the CIR is the de facto specification supervisors and auditors read from.

For that second group the obligation is real but indirect. Article 21(1) requires “appropriate and proportionate technical, operational and organisational measures to manage the risks”, and Article 20(1) requires the management body to approve those measures and makes it liable for infringements. Approving a set of measures is, in substance, approving what they leave behind — but that is a reading of two provisions together, not a stated rule, and your documentation should say so.

The Regulation also uses “residual risk” without ever defining it. ENISA’s technical implementation guidance fills the gap by footnote, importing the ISACA Glossary definition — “the remaining risk after management has implemented a risk response”. That footnote is the closest thing to an EU-backed definition that exists. The Article 21(2)(a) risk management requirements sit upstream of everything on this page.

The Four Clauses, and Why They Don’t Say the Same Thing

Most guidance collapses these into one sentence: the board must accept residual risk. That is true of one clause out of four. The other three have different triggers, and two of them do not route the decision to the board at all.

Annex point	What triggers it	Who accepts	What has to exist on paper
2.1.1	The routine risk assessment and treatment cycle	“Management bodies or, where applicable, persons who are accountable and have the authority to manage risks, provided that the relevant entities ensure adequate reporting to the management bodies”	Accepted risk assessment results and accepted residual risks, plus a risk treatment plan that is established, implemented and monitored
2.1.2(j)	The same cycle — this is the documentation limb	Not specified	“The chosen risk treatment measures in a risk treatment plan and the reasons justifying the acceptance of residual risks in a comprehensible manner”
2.3.3	An independent review, compliance monitoring, or effectiveness measurement produces a finding	Decided “according to the relevant entities’ risk acceptance criteria”; results reported to the management bodies	Either a corrective action or an accepted residual risk. There is no third state.
6.6.1(d)	A security patch is unavailable, or you decided under 6.6.2 not to apply one	Not specified	“Additional measures are implemented and residual risks are accepted” — both, not either

Point 2.3.3 catches programmes out. It does not send the finding to the board for a decision; it sends the results to the board, then applies criteria you wrote yourself. And it offers exactly two outcomes. A finding open for three quarters with neither a corrective action nor a recorded acceptance is not slow remediation — it is the state the clause was drafted to exclude.

A correction worth making, because the framing circulates: one widely cited NIS2 risk-assessment guide states that the framework permits risk acceptance “only in exceptional and explicitly justified cases”. Neither instrument says that. ENISA lists acceptance alongside avoidance, mitigation and transfer as an ordinary treatment option and gives nine worked examples of when it fits. The text demands the reason, not the rarity — and a register built on an assumption of exceptionality produces the opposite of compliance, because teams leave risks undocumented rather than record an acceptance they believe they are not allowed to make. The risk register structure is where those four clauses become columns.

What “In a Comprehensible Manner” Has to Contain

Point 2.1.2(j) sets a standard and defines nothing. Comprehensible to whom, containing what, at what length — the Regulation is silent. Two competent sources have filled that silence differently.

Ireland’s NCSC supplies a five-field schema, stated twice in its draft Risk Management Measures Guidance: where risk treatment is “accept”, the rationale “should be documented to include who, what, why, when and condition for review”. Three caveats travel with it. The modal is “should”, not “shall”; the document is a draft addressed to Irish entities; and it writes “comprehensive manner” where the Regulation writes “comprehensible”. Quote each as it stands rather than reconciling them.

ENISA works from the other end, offering nine examples of risk acceptance criteria, all flagged indicative and non-exhaustive. Among them: where the cost of mitigation exceeds the potential impact; a vulnerability accepted for a defined period, such as “outdated software for three months until a full upgrade can be completed”; impact below a financial threshold, such as “losses under EUR 50,000 accepted without further action”; and a compliance gap with a commitment to remediate “within six months”. Notice what nearly all of them share: an end date.

Combining the binding text with both sets of guidance, an acceptance record that reads cold carries eight things. This field set is a practical construction, not a legal requirement — the only field the Regulation names outright is the reason.

1. The risk, and which of confidentiality, integrity, availability or authenticity it threatens
2. The assets it attaches to — ENISA’s treatment-plan guidance names these explicitly
3. The measures already in place, and the residual level after them
4. Which of your own risk acceptance criteria this acceptance satisfies — the criteria you are required to establish under 2.1.2(c)
5. Why further treatment was rejected. Point 2.1.3 hands you the vocabulary: “the cost of implementation in relation to the expected benefit”
6. Who accepted it, named, with the role that carries the authority
7. The date of acceptance
8. The review trigger and the condition that would reopen it

Fields six through eight are where most registers fail. A spreadsheet cell reading “accepted — low likelihood” satisfies none of them. If you are building this from scratch, the risk management policy template is where the acceptance criteria themselves belong.

Who Signs, and Why the Answer Splits Three Ways

Ask three authoritative sources who accepts a residual risk and you get three answers.

• The Regulation, point 2.1.1: management bodies, or accountable persons with the authority to manage risks — conditional on adequate reporting back to the management bodies.
• NCSC Ireland, RMM004.FA02: “Residual risks to be either treated or risk accepted by risk owners, with adequate reporting to the management board.”
• ENISA’s summary tips for chapter 2.3: “Approval of the residual risks by management bodies” — with the delegation escape clause dropped entirely.

Do not resolve this by picking one. Record which instrument binds you, apply that one, note the divergence in your methodology. What all three share is the reporting condition: delegation is available, invisibility is not.

One asymmetry belongs in any delegation decision. Point 2.1.1 conditionally delegates residual-risk acceptance; Article 20(1) — approval of the Article 21 measures themselves, and the liability that follows — contains no equivalent escape clause. A RACI that pushes measure approval down to the CISO is not a delegation. It is documentary evidence that approval sat below where Article 20 puts it.

Role	What they own in the acceptance record
Management body / board	Article 20(1) approval of the measures, which carries no delegation clause. Acceptance under 2.1.1, delegable only with reporting back. Receipt of review results under 2.3.3.
Risk owner (business)	The accept-or-treat decision where delegation applies, and the rationale in field five. Named in the record, not “the business”.
CISO / security manager	The residual level after controls, the measures in field three, and the review trigger — not the acceptance itself, unless 2.1.1 delegation has been formally granted.
Compliance officer	That the record exists, carries all eight fields, matches the policy’s criteria, and has not aged past its review date.

When an Accepted Risk Expires

Annually at the latest — and the chain that gets you there is worth following, because almost nobody writes it down.

Point 2.1.2(j) puts the reasons justifying acceptance inside the risk treatment plan. Point 2.1.4 then requires the entity to “review and, where appropriate, update the risk assessment results and the risk treatment plan at planned intervals and at least annually, and when significant changes to operations or risks or significant incidents occur”. On a plain reading of the two points together, the plan’s clock runs on the acceptance reasons inside it: an acceptance signed in March is in scope the following March whether or not anything changed, and immediately if something significant did.

Both guidance documents land in the same place from different directions. NCSC Ireland, on accepted patching risks: “Should the risk be accepted, particularly where a patch is not available, the risk should be reviewed regularly.” ENISA’s acceptance examples mostly carry their own expiry — three months, six months, a defined period.

The consequence cuts both ways. The acceptance criteria you write under 2.1.2(c) become the benchmark you are measured against, because there is no external standard for them — yours is the only one an auditor has. An undated acceptance with no review condition has no failure state, so it can never be shown to have been breached. That sounds like safety. In a register, it reads as a decision nobody was willing to own.

The Patch Clause Is a Different Animal

Point 6.6.1(d) requires that “additional measures are implemented and residual risks are accepted in cases where a patch is not available or not applied pursuant to point 6.6.2″. It is conjunctive. Compensating controls without a recorded acceptance is half the clause; a signed acceptance without compensating controls is the other half.

The exception is also widely misread. Point 6.6.2 lets an entity decline a patch “when the disadvantages of applying the security patches outweigh the cybersecurity benefits” — but it is drafted “by way of derogation from point 6.6.1(a)”, and 6.6.1(a) concerns patches applied “after they become available”. Where a vendor has ended support and no patch exists, there is nothing for 6.6.2 to derogate from. The governing limb is 6.6.1(d), an obligation rather than an exception: for a genuinely unpatchable system there is no exemption to claim, only measures plus a documented acceptance.

ENISA’s evidence list for this chapter names four artefacts, and the fourth is the one almost nobody prepares in advance: “incident reports related to unpatched vulnerabilities to check the effectiveness of the mitigation measures during the entity’s response”. Your compensating controls get tested by the next incident, and the incident report is where a supervisor finds out whether they worked.

What a Missing Record Actually Exposes You To

“You could be fined” undersells it. For essential entities, Article 32(4) gives competent authorities a ladder of powers sitting entirely below the fine: binding instructions and orders to remedy identified deficiencies (b); an order that your measures comply with Article 21 “in a specified manner and within a specified period” (d); an order to implement security-audit recommendations “within a reasonable deadline” (f); designation of a monitoring officer (g); and an order “to make public aspects of infringements” (h). The administrative fine under point (i) is expressly available in addition to points (a) to (h), not instead of them, and Article 32(5) adds suspension of certifications or authorisations where the earlier measures prove ineffective.

Important entities sit under Article 33 instead, which is ex post — the powers engage on evidence or indication of non-compliance, not on a supervisor’s own initiative.

Calibrate the concern honestly: there is no published enforcement practice on residual-risk records specifically, and no competent authority has said an undocumented acceptance triggers any particular rung. This is exposure, not prediction. What makes it worth acting on is the cheapness of the fix — the distance between a record that reads as a decision and one that reads as a gap is three fields and a date.

Frequently Asked Questions

Does the NIS2 Directive itself require us to document residual risk?
No. The term does not appear in Directive (EU) 2022/2555. The documentation duty is created by CIR 2024/2690, which binds eleven digital-infrastructure categories. For every other entity it is inferred from Articles 21(1) and 20(1) plus national guidance, and should be described that way rather than cited as a direct requirement.

Can we delegate residual-risk acceptance away from the board?
Under point 2.1.1, yes — to “persons who are accountable and have the authority to manage risks”, but only where the entity ensures adequate reporting back to the management bodies. The approval of the Article 21 measures under Article 20(1) carries no comparable delegation clause.

How often does an accepted residual risk have to be reviewed?
The acceptance reasons live inside the risk treatment plan under 2.1.2(j), and point 2.1.4 requires the plan to be reviewed at planned intervals and at least annually, plus on significant changes or incidents. Practically: annually as a floor, sooner if the risk or the environment moves.

Is there a limit on how many risks we can accept?
Nothing in either instrument caps the number. But Article 21(1) requires measures appropriate to the risk, judged against exposure, entity size, and the likelihood and severity of incidents including their societal and economic impact. That proportionality test binds independently of what an organisation is willing to tolerate — so an acceptance policy can carry risk below that line and arguably cannot lawfully carry it above. Treat that as a reading of the text, not settled law.

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

• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, Official Journal. Source of Article 1’s eleven categories and of Annex points 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.3.3, 6.6.1 and 6.6.2, all quoted verbatim, and of the four-occurrence count for “residual risk”.
• Directive (EU) 2022/2555 (NIS2) — EUR-Lex. Source of Articles 20(1), 21(1), 21(2)(a), 32(4), 32(5) and 33, and of the zero-occurrence count for “residual risk”, “risk acceptance”, “risk appetite”, “risk tolerance” and “risk criteria” across the full text.
• Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025 (PDF). Source of the nine risk acceptance criteria examples, the treatment-plan content list, the examples of evidence under points 2.1.1, 2.3.3 and 6.6, and the imported definition of residual risk at footnote 12. ENISA’s guidance and evidence bullets are explicitly indicative and non-exhaustive, and are not part of the binding Annex.
• NIS 2 Risk Management Measures Guidance (Draft, 04/06/2025) — National Cyber Security Centre, Ireland (PDF). Source of RMM004.FA02, RMM004.SA01’s five-field schema, RMM005.SA07 and RMM013.SA16. A draft, addressed to Irish essential and important entities.
• ISACA Glossary — ISACA. The source ENISA’s footnote 12 names for its definition of residual risk.
• NIS2 Risk Assessment: a Method That Survives Audit — Jimber. Cited only as a documented example of the prevailing market reading that acceptance is permitted “only in exceptional and explicitly justified cases”, which is corrected above against the primary text.