Risk Treatment Plan: The NIS2 Rules Name 3 Options, ENISA Adds a 4th — How to Document Each

The EU text behind NIS2 names three ways to treat a cybersecurity risk, not four. Recital 11 of Commission Implementing Regulation (EU) 2024/2690 says options for risk treatment “include, in particular, avoiding, reducing or, in exceptional cases, accepting the risk.” Transfer — the option many registers use to record cyber insurance and outsourcing — is not in that sentence. It appears in ENISA’s guidance, with a caveat attached that is easy to miss.

The Directive itself says even less. We counted the full texts: “risk treatment” appears 16 times in the implementing regulation and zero times in Directive (EU) 2022/2555, where “insurance” is also absent. The familiar four-option model is a blend of a non-binding recital, agency guidance and ISO practice. This guide separates the layers and shows what each option has to look like on paper.

Who This Applies To

In plain terms: eleven types of digital-infrastructure providers are bound by the implementing regulation’s risk-treatment rules directly. Every other essential or important entity has the shorter Article 21 duty, transposed into national law, and will usually be measured against the same regulation as the practical benchmark.

Your entity	Binding source of the treatment duty	How to use this guide
DNS service providers, TLD name registries, cloud computing, data centre and CDN providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms, trust service providers	CIR 2024/2690, Article 1 and Annex point 2.1 — applies directly	Treat the Annex 2.1 duties below as binding requirements
All other essential and important entities (energy, transport, health, manufacturing, public administration, etc.)	Directive Article 21(2)(a), “policies on risk analysis and information system security”, via your national law	Use the CIR structure as a benchmark; check national guidance for anything stricter
Entities outside NIS2 scope	None under NIS2	The four options remain good practice (ISO/IEC 27005, NIST)

If you have not yet run the assessment that feeds a treatment plan, start with our NIS2 risk assessment guide. Treatment only makes sense once each risk has a level and has been evaluated against your criteria.

Three Options in the Regulation, Four in the Guidance, Five at NIST

In plain terms: the binding text tells you to choose and prioritise treatment options but never lists them. The list comes from a recital (three options), ENISA (four) and, if you work with US frameworks, NIST (five). They are compatible, but they aren’t the same.

Option	CIR 2024/2690, Recital 11	ENISA Technical Implementation Guidance	NIST SP 800-39
Avoid	“avoiding”	Risk avoidance	Risk avoidance
Reduce / mitigate	“reducing”	Risk mitigation	Risk mitigation
Transfer / share	Not named	“Risk transfer or sharing” (one option)	Two separate options: sharing and transfer
Accept	“in exceptional cases, accepting”	Risk acceptance	Risk acceptance
Status	Recital — interpretive, not an obligation	Guidance, explicitly “indicative, non-exhaustive”	US federal guidance, no EU legal effect

Three readings follow, and each changes how you write the plan.

The missing transfer option is not a ban. The recital says options “include, in particular” — a non-exhaustive list. Nothing prohibits buying insurance or outsourcing a function. But the EU text gives transfer no standing as a treatment in its own right, which is a good reason to never let it stand alone in your plan.

“In exceptional cases” is a signal, not a rule. Recitals explain intent; they do not create obligations. The operative Annex point 2.1.2(j) demands something different: “the reasons justifying the acceptance of residual risks in a comprehensible manner.” It requires a reason, not rarity. Still, a register where half the risks are marked “accept” reads badly against a recital that frames acceptance as the exception. If acceptance is your most common treatment, expect to be asked why.

The binding duty is about the choice, not the menu. Annex 2.1.2(g) requires you to “identify and prioritise appropriate risk treatment options and measures.” ENISA’s guidance adds that each risk should be associated with at least one option, or a combination, and at least one specific treatment measure. A row that says “accept” with no measure and no reason fails on both counts.

What Every Treatment Decision Must Record

In plain terms: whatever option you pick, the regulation fixes four things the plan must show — the measure, its owner, its deadline, and monitoring — plus a reason for anything you accept. ENISA turns that into a seven-element plan.

Annex point 2.1.2(h) requires you to “continuously monitor the implementation of the risk treatment measures”; (i) to “identify who is responsible for implementing the risk treatment measures and when they should be implemented.” Point 2.1.3 sets what the choice must weigh: the risk assessment results, your effectiveness-assessment results, “the cost of implementation in relation to the expected benefit”, your asset classification and your business impact analysis.

Plan field	Binding (CIR Annex)	Guidance (ENISA)
Risk description and effect on security objectives	Implied by 2.1.2(d)–(f)	Yes — named element
Chosen treatment option	2.1.2(g) — choose and prioritise	Yes — avoid, mitigate, transfer/share or accept
Assets affected	Not named in 2.1; asset classification feeds 2.1.3	Yes — named element
Treatment measures	2.1.2(j)	Yes
How effectiveness will be assessed	2.1.3 uses effectiveness results as an input	Yes — a procedure per measure
Owner and implementation date	2.1.2(i)	Yes — “implementation timelines” and “responsible roles”
Reasons for accepting residual risk	2.1.2(j), “in a comprehensible manner”	Yes, plus a cost estimate and contingency (see below)
Review date	2.1.4 — at least annually	Review against audits, incidents, threat trends

The cost-benefit input in 2.1.3 is what makes a reasoned “no” legitimate: a measure whose cost is out of proportion to the risk it removes can be passed over, provided the comparison is written down. For how these fields sit as columns alongside likelihood, impact and risk level, see our risk register structure and governance hierarchy.

How to Document Each of the Four Options

In plain terms: each option fails audits in its own way. Avoidance fails when the activity quietly continues. Mitigation fails when nobody checks the control works. Transfer fails when it is treated as the whole answer. Acceptance fails when the reason is missing or the risk is critical.

Option	Fits when	The record must show	Typical audit failure
Avoid	The activity is worth less than its risk, or no workable control exists	What was stopped, when, and proof it stopped (inventory update, decommission record)	“Avoided” system still running on the network
Mitigate	A control brings the risk within your tolerance at proportionate cost	Measure, owner, deadline, effectiveness check, re-scored residual risk	Control listed but never tested; deadline passed with no update
Transfer / share	Part of the financial or operational impact can be carried by an insurer or supplier	Policy or contract reference, what impact moves, what obligation stays, the residual risk after transfer	Insurance recorded as the only treatment; no supplier security measures
Accept	The risk is within tolerance, or the cost of treatment exceeds the impact	Reason, approver, cost estimate, contingency, expiry or review trigger	No reason; accepted by someone without authority; critical vulnerability accepted indefinitely

Avoid: prove the activity actually stopped

ENISA’s Technical Implementation Guidance gives the classic example: “discontinuing the use of a vulnerable software application.” The decision is the easy part. The record has to show the software is gone: a dated change or decommission entry, the asset register updated, and the service owner’s confirmation. An avoided risk with no removal evidence is, to an auditor, an untreated risk. Also log any new risk the avoidance creates, such as users moving to an unmanaged alternative.

Mitigate: the measure is half the record

In practice, mitigation covers most rows, and the usual gap is the second half of the record. ENISA lists “a procedure for assessing the effectiveness of implementation of the measure(s)” as a plan element, and Article 21(2)(f) of the Directive makes effectiveness assessment one of the ten minimum measures in its own right. So each mitigating row needs an owner and date under 2.1.2(i), a named test (a configuration check, a restore test, a phishing simulation result), and a re-scored residual risk once the control is verified — not when it is merely bought.

For a CISO, the practical move is to tag each measure with the Article 21(2) letter it serves. That turns the treatment plan into the evidence trail for your Article 21 programme as a whole.

Transfer or share: what moves, and what never does

ENISA allows transfer — “typically through insurance or outsourcing certain functions” — and immediately limits it: “such arrangements do not eliminate the entity’s overall accountability or legal obligations regarding the risk.” Its own example: cyber insurance “may cover potential data breach costs, but the entity remains responsible for implementing appropriate security measures.”

The EU’s caution is easier to understand next to NIST SP 800-39, which treats sharing and transfer as two options. Transfer, in NIST’s definition, “shifts the entire risk responsibility or liability” to another organisation; sharing shifts “a portion.” NIST also notes that transfer “reduces neither the likelihood of harmful events occurring nor the consequences,” and that it is “less applicable” where “liability of organizations is generally established by legislation.” Under NIS2, liability is set by legislation: Article 20(1) of the NIS2 Directive makes management bodies approve the measures, oversee them, and answer for infringements. Read together, our view is that a NIS2 transfer always works like sharing in NIST’s sense: part of the cost moves, the obligation stays.

Outsourcing works the same way. Recital 83 of the Directive states that the measures “should apply … regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof.” The outsourced function lands in your supply chain, where Article 21(2)(d) applies. Pair every transfer row with a mitigation row. Our guide to what NIS2 cyber insurance covers walks through the policy side, including the costs no policy pays.

Accept: a reason, a cost estimate and an exit

Acceptance carries the heaviest documentation load, because it is the option where nothing visibly changes. Annex point 2.1.1 says 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.” ENISA adds that acceptance “should be clearly documented, supported by a realistic estimation of potential costs and including financial provisions to address the impact should the risk materialise,” and is “usually accompanied by a contingency plan.”

ENISA also draws a line that is easy to miss: make sure risk from vulnerabilities in the highest severity class — “‘critical’ in the common vulnerability scoring system (CVSS)” — “is not accepted, if possible.” That is guidance, not a ban, but an accepted critical vulnerability needs an unusually strong reason. The approver, the “comprehensible manner” standard and the expiry question are covered in depth in our guide to residual risk documentation.

The Floor No Option Can Go Below

In plain terms: the four options decide how you handle a specific risk. They do not let you skip one of the ten Article 21(2) measures.

Article 21(2) states that the measures “shall include at least the following,” then lists ten, from risk analysis policies to multi-factor authentication. Article 21(4) adds that an entity that finds it does not comply with those measures must take “without undue delay, all necessary, appropriate and proportionate corrective measures.” Our reading is that treatment options work inside each measure — how strong, how fast, at what cost — not as a way out of one. Accepting one exposure is a decision; accepting the absence of incident handling is a compliance gap.

Where the regulation does allow you not to apply something, it prescribes its own paper trail. Article 2(2) of the implementing regulation requires you to “document its reasoning” “in a comprehensible manner” when you judge a “where appropriate” requirement inapplicable. Annex 6.6.2 lets you skip a security patch when its disadvantages “outweigh the cybersecurity benefits,” provided you “duly document and substantiate the reasons.” Annex 6.10.3 requires a mitigation plan for vulnerabilities whose impact justifies it, and in other cases a documented reason “why the vulnerability does not require remediation.” Each is a treatment decision and belongs in the plan. Our vulnerability and patch management guide covers the patching exceptions in detail.

Who Owns Which Decision

Role	Owns	What to do first
Board / management body	Approving the measures (Art 20(1)); accepting residual risk unless properly delegated (Annex 2.1.1)	Ask for the list of accepted risks with reasons and expiry dates — not just the heat map
CISO / IT security manager	Choosing options, specifying measures, effectiveness tests	Tag every mitigation with its Article 21(2) letter; pair every transfer row with a control
Risk owner	Delivering the measure by the date in the plan (2.1.2(i))	Confirm deadlines are realistic before the plan goes for approval
Compliance officer / legal	Plan completeness, review cycle (2.1.4), exception records	Check that each “accept” row has a reason, an approver and a review trigger
SME owner (often all of the above)	The whole cycle	Keep the plan short: your top risks, one option each, one owner, one date. Use the 2.1.3 cost-benefit test to justify what you leave for later

A small company does not need a risk committee. It does need an acceptor who can actually authorise the decision, and a board that has seen the list.

Frequently Asked Questions

What are the four risk mitigation strategies under NIS2?

Avoid, mitigate (reduce), transfer or share, and accept. That is ENISA’s list. The implementing regulation’s Recital 11 names only three — avoiding, reducing and, “in exceptional cases,” accepting — and the Directive names none. Transfer is allowed but should never be the only treatment for a risk.

Does NIS2 require a risk treatment plan?

For the eleven entity types covered by CIR 2024/2690, yes: Annex point 2.1.1 requires them to “establish, implement and monitor a risk treatment plan.” For other entities, Article 21(2)(a) requires risk analysis policies as transposed into national law; check your national authority’s guidance for how it expects treatment decisions to be recorded.

Can cyber insurance count as risk treatment?

It can be recorded as transfer or sharing of financial impact. ENISA states it does not remove your accountability or legal obligations, and Article 20(1) keeps liability with the management body. Record it alongside the security measures, never instead of them.

How often must the treatment plan be reviewed?

Annex point 2.1.4 requires review “at planned intervals and at least annually,” and when significant changes to operations or risks, or significant incidents, occur.

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 (linked above). Source of Recital 11, Article 1, Article 2(2) and Annex points 2.1.1–2.1.4, 6.6.2 and 6.10.3, quoted verbatim, and of the count of 16 occurrences of “risk treatment”.
• Directive (EU) 2022/2555 (NIS2) — EUR-Lex (linked above). Source of Articles 20(1), 21(2) and 21(4) and Recital 83, and of the zero counts for “risk treatment” and “insurance”.
• Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025 (PDF, linked above). Source of the seven treatment-plan elements, the four treatment options and their examples, the acceptance documentation conditions and the CVSS-critical tip. ENISA’s guidance is indicative and non-exhaustive, not part of the binding Annex.
• NIST Special Publication 800-39, Managing Information Security Risk — National Institute of Standards and Technology, March 2011 (PDF, linked above). Source of the five risk response types and the transfer/sharing definitions in Task 3-1. US guidance, used for comparison only.