Risk Appetite Appears Once in EU NIS2 Law — and It Decides What Your Board Can Sign

Search the full text of the NIS2 Directive for the phrase “risk appetite” and you find nothing. Zero occurrences across all 275,000-plus characters of Directive (EU) 2022/2555 [1]. The term appears exactly once in the binding EU rules that implement it, at point 2.1.2(b) of the Annex to Commission Implementing Regulation (EU) 2024/2690, inside a single subordinate clause: relevant entities shall “establish the risk tolerance level in accordance with the risk appetite of the relevant entities” [2].

That clause does far more work than its length suggests. It never defines appetite. It never says the appetite must be written down. It never names who sets it. What it does is make appetite the upstream input to every downstream threshold your organisation commits to, and those thresholds are what your management body ends up signing. Get the appetite wrong or leave it unwritten, and the signature further down the chain becomes hard to defend.

Where “risk appetite” actually appears in NIS2 law

In plain terms: risk appetite is not a NIS2 Directive concept at all. It enters through the implementing regulation, and it enters as an input to something else, never as a standalone obligation. A word-level search of the official texts returns this.

Instrument	“risk appetite”	What it says
Directive (EU) 2022/2555 (NIS2)	0	Nothing. “Risk tolerance”, “risk criteria” and “risk acceptance” are also absent [1].
CIR (EU) 2024/2690, Annex	1	Point 2.1.2(b): establish the risk tolerance level “in accordance with the risk appetite of the relevant entities” [2].
ENISA Technical Implementation Guidance v1.0	7	Non-binding guidance. Defines appetite and gives worked tolerance examples [3].

Does this bind you? Article 1 of the implementing regulation names eleven categories of “relevant entities” it applies to directly: DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking platforms, and trust service providers [2]. Outside that list, your obligation is the broader one in Article 21(2)(a) as transposed into national law, and the implementing regulation functions as the de facto specification rather than the letter of your duty.

Regulators are already reading it that way. Ireland’s National Cyber Security Centre addressed its draft NIS2 Risk Management Measures Guidance to essential and important entities generally, not only to the eleven categories, and ties control selection back to “the risk appetite of the organisation” throughout [5]. Our companion piece on what Article 20 actually requires your board to sign covers scoping in more detail.

The chain: appetite sets tolerance, tolerance decides what your board signs

Point 2.1.2 is a “shall” list of ten process elements, lettered (a) to (j). Four of them sit in sequence and form the mechanism that matters here.

Clause	What it demands	What breaks if appetite is unwritten
2.1.2(b)	Establish the risk tolerance level “in accordance with the risk appetite”	Your tolerance has no stated derivation, so it reads as an arbitrary number.
2.1.2(c)	“Establish and maintain relevant risk criteria”	Criteria cannot be shown to be consistent with anything above them.
2.1.2(f)	“Evaluate the identified risks based on the risk criteria”	Every evaluation inherits the same unexplained baseline.
2.1.2(j)	Document treatment measures “and the reasons justifying the acceptance of residual risks in a comprehensible manner”	This is where it surfaces. “We accepted it” is not comprehensible without the threshold it was measured against.
2.1.1	Risk assessment results and residual risks “shall be accepted by management bodies”	The board signs an acceptance whose standard was never recorded.
2.3.3	Corrective actions taken “or residual risk accepted according to the relevant entities’ risk acceptance criteria”	Independent-review findings close against criteria nobody can produce.

Read the chain end to end and an inversion appears that most guidance misses. The implementing regulation never requires a risk appetite statement. What it requires is that your reasons for accepting residual risk be comprehensible, and that the acceptance itself reach your management bodies. An unwritten appetite is precisely what makes those reasons incomprehensible. The statement is optional; the consequence of not having one is not.

ENISA makes the same point from the other direction in its guidance on 2.1.1, telling entities to ensure residual risks are accepted “in line with the acceptable residual risk levels of the entity” [3]. Levels the entity has never defined cannot be aligned with.

Article 21(1) puts a ceiling on how much appetite you may lawfully have

A risk appetite is a business decision, but under NIS2 it is not an unbounded one. Article 21(1) of the Directive sets a statutory proportionality test in its own words: when assessing the proportionality of the measures, “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, including their societal and economic impact” [1]. Article 2(2) of the implementing regulation repeats the same four factors for the eleven relevant-entity categories [2].

Read against each other, those obligations work in one direction only. A conservative appetite can pull your carried risk below the level the proportionality test would tolerate, and nothing in the Directive objects to spending more than the minimum. An expansive one cannot lawfully pull it above, because Article 21(1) is a “shall” obligation that fixes the required level of security by reference to those four factors rather than to the entity’s preferences. On that reading, “our board set a high risk appetite” describes a decision rather than defending it.

That matters because of where liability sits. Article 20(1) requires management bodies to approve the cybersecurity risk-management measures taken to comply with Article 21, to oversee implementation, and states that they “can be held liable for infringements by the entities of that Article” [1]. The liability hook is Article 21 compliance, and appetite is one of the few governance artefacts that can either evidence a considered Article 21(1) judgement or document a departure from it.

Writing the statement: five components, and what each one costs

ENISA defines the target plainly: risk appetite is “the amount of risk that the entity is strategically willing to accept to achieve its objectives”, shaped by business strategic objectives, stakeholder expectations, regulatory requirements and organisational culture, and varying with an entity’s size, complexity and sector [3]. Ireland’s NCSC is more prescriptive about form, describing “a clearly documented statement, approved by the Management Board and communicated to all stakeholders” — note the modal verb, which is “should be defined”, not “shall” [4].

Five components carry the weight. Effort levels below are our own estimate for a mid-sized entity with an existing risk register, not a regulatory grading.

Component	What goes in it	Effort
1. Scope and objectives	Which services, systems and entities the appetite covers, and the business objectives it serves. Anchor to the same scope your Article 21 measures use.	Low
2. Qualitative appetite statement	Two to four sentences per risk category saying what the organisation is willing to pursue and what it will not accept at any price.	Medium
3. Quantified tolerance levels	The numbers. Downtime, data loss, financial exposure, response time. This is the 2.1.2(b) deliverable.	High
4. Risk acceptance criteria	The rules for when a residual risk may be accepted rather than treated, feeding 2.1.2(j) and 2.3.3.	Medium
5. Approval and review record	Who approved it, on what date, and when it is next reviewed.	Low

For component 3, ENISA supplies worked examples, all of which it labels “indicative, non-exhaustive”: up to two hours of downtime per month for high-criticality systems; loss of low-criticality data within a 24-hour window; up to EUR 100,000 in recovery costs; willingness to invest 5% of annual revenue in measures; a maximum of 48 hours for containment; and tolerating one major incident every few years [3]. Treat these as illustrations of the required shape of a tolerance statement, not thresholds to copy. None of them is a regulatory standard, and adopting a number that does not match your operations is worse than picking a modest one you can actually evidence.

Once a tolerance level is in your approved documents it becomes the standard your own evidence is measured against, and point 2.1.4 requires those documents to be reviewed at planned intervals and at least annually [2]. A two-hour monthly downtime tolerance you breach every quarter is a documented failure against your own commitment, which is a materially worse audit position than a four-hour tolerance you meet. Our NIS2 risk management policy template guide shows how the appetite statement nests inside the wider policy.

Who signs what, and the approval your board cannot delegate

The implementing regulation splits authority in a way that is easy to flatten and expensive to get wrong.

Artefact	Who approves	Delegable?
The Article 21 risk-management measures	Management bodies (Art 20(1))	No escape clause in the text [1]
Security policy, with its formal approval date	Management bodies (Annex 1.1.1(k), 1.1.2)	No escape clause in the text [2]
Risk assessment results and residual risks	Management bodies, “or, where applicable, by persons who are accountable and have the authority to manage risks”	Yes, conditionally, and only with “adequate reporting to the management bodies” (Annex 2.1.1) [2]
Tolerance levels and risk criteria	Not assigned by the regulation	Your design choice, so record it

Only one row in that table carries a delegation clause, and our companion piece on IT governance versus Article 20 governance works the same seam from the operating-model side. Point 2.1.1 lets residual-risk acceptance move down to accountable risk owners provided the management bodies still get adequate reporting. Article 20(1) approval of the measures, and the dated formal approval of the policy under 1.1.1(k), carry no equivalent wording [1][2]. The practical consequence is uncomfortable for anyone drafting a RACI: putting “A” against the CISO for approving the security policy turns your own governance chart into documentary evidence that approval sat below where Article 20 places it.

Where you do delegate, the delegate needs standing. Ireland’s NCSC states that the risk owner “is accountable for accepting risk based on the organisations risk appetite and should be someone with the budget, authority and mandate to select the appropriate risk response” [4]. A risk owner without a budget cannot select a treatment, so every risk routed to them defaults to acceptance regardless of what the appetite says. Its draft measures guidance goes further, having the management board approve a policy suite “with the security objectives and the risk acceptance criteria that are compatible with the risk appetite of the entity” (RMM002.FA05), though that document is still a draft and addressed to Irish entities [5].

The evidence file an auditor can actually open

Nothing above is testable until it exists as a document with a date on it. ENISA’s evidence examples for point 2.1.2 include a “documented risk-management methodology and/or tools that take into account at least elements (a) to (f) in point 2.1.2 of the Annex to the regulation” [3]. That phrasing is worth reading twice: elements (a) to (f) include (b) tolerance derived from appetite and (c) risk criteria. The guidance is non-binding, but it is the closest thing to a stated expectation of what an assessor will open, and it places appetite and tolerance inside the minimum documented methodology rather than outside the evidence set as an optional maturity flourish.

Evidence	Clause it answers	Where it usually lives
Documented risk-management methodology covering appetite, tolerance and criteria	Annex 2.1.2(a)-(f) [2][3]	Risk assessment methodology document
Approved appetite and tolerance statement with an approval date	Annex 1.1.1(k) [2]	Security policy or board resolution
Record of residual-risk acceptance, naming the acceptor and the reasoning	Annex 2.1.1, 2.1.2(j) [2]	Risk treatment plan, acceptance register
Regular reporting of security status to management bodies	Annex 2.2.1 [2]	Board pack, minutes
Independent-review results with corrective action or documented acceptance	Annex 2.3.3 [2]	Internal audit file
Annual review of the assessment results and treatment plan	Annex 2.1.4 [2]	Change log, dated revision history

Ireland’s board guidance sets out ten questions it says the management board “should address” and then “document decisions” against, the second of which is “What is the board’s cyber risk appetite and tolerance for incidents impacting services?” [4]. That framing is useful for a CISO preparing a paper, because it means the appetite conversation is one the national authority tells the board to initiate. You are answering a question put to them, not asking them for a favour. For the reporting layer that sits on top, see our breakdown of the board metrics that satisfy auditors.

If you already run ISO/IEC 27005 or NIST CSF 2.0

NIST Cybersecurity Framework 2.0 carries subcategory GV.RM-02: “Risk appetite and risk tolerance statements are established, communicated, and maintained” [6]. That is a stricter ask than the implementing regulation makes, which requires only that a tolerance level be established in accordance with appetite. An organisation already meeting GV.RM-02 is comfortably over the NIS2 bar here and can cite the same artefacts for both.

For risk criteria, ENISA points directly at ISO/IEC 27005:2022, paragraph 6.4, and names the same standard as an example risk-management framework [3], so criteria already built to that clause satisfy 2.1.2(c). The Institute of Risk Management supplies the definition most boards will recognise, describing appetite as “the amount and type of risk that an organisation is willing to take in order to meet their strategic objectives” [7] — close enough to ENISA’s wording that you do not need two competing definitions in circulation.

Frequently asked questions

Does NIS2 legally require a written risk appetite statement?
No. Neither the Directive nor the implementing regulation requires one as a standalone document. The regulation requires a tolerance level established in accordance with appetite, risk criteria, and documented reasons for accepting residual risks “in a comprehensible manner” [2]. In practice those three obligations are difficult to evidence without a written appetite, which is why Ireland’s NCSC recommends one [4] and NIST CSF 2.0 asks for one at GV.RM-02 [6].

Who has to approve it?
The regulation assigns appetite and tolerance approval to nobody. It does require management bodies to accept risk assessment results and residual risks, subject to conditional delegation with reporting back (Annex 2.1.1), and requires the security policy to carry the date of formal approval by the management bodies (Annex 1.1.1(k)) [2]. Attaching the appetite statement to the policy your board already dates is the cleanest route.

How often must it be reviewed?
There is no named cadence for appetite itself. The nearest binding clocks are point 2.1.4 (assessment results and treatment plan, at least annually) and point 1.1.2 (security policy, reviewed by management bodies at least annually) [2]. Annual review alongside the policy is the defensible default.

Can we simply state that our appetite is “low” and leave it there?
You can, but it does no work. A one-word appetite cannot generate the tolerance level 2.1.2(b) asks for, cannot produce the risk criteria in 2.1.2(c), and gives an auditor nothing against which to test the acceptance reasons in 2.1.2(j) [2]. The minimum useful version pairs a qualitative sentence per risk category with at least one quantified tolerance.

Does any of this apply if we are not one of the eleven CIR entity types?
The implementing regulation does not bind you directly [2]. Article 21(2)(a) as transposed into your national law does, and national guidance is converging on the CIR and the ENISA document as the reference specification [3][5].

Key takeaways

• “Risk appetite” appears zero times in Directive (EU) 2022/2555 and exactly once in CIR (EU) 2024/2690, at Annex point 2.1.2(b), where it is named only as the input to your tolerance level [1][2].
• No EU rule requires an appetite statement. Several rules require outcomes that are hard to evidence without one, most sharply the “comprehensible manner” test in 2.1.2(j) [2].
• Article 21(1)’s proportionality test caps how much risk you may lawfully carry, so an expansive appetite is a recorded decision, not a defence [1].
• Residual-risk acceptance can be delegated with reporting under 2.1.1; Article 20(1) approval of the measures and the dated policy approval under 1.1.1(k) carry no such clause [1][2].
• ENISA places appetite, tolerance and criteria inside the minimum documented methodology, via elements (a) to (f) of point 2.1.2 [3].

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. Directive (EU) 2022/2555 (NIS2), Articles 20 and 21 — official text on EUR-Lex. Word-frequency figures in this article were counted over that text.
2. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, Articles 1 and 2 and Annex points 1.1.1, 1.1.2, 2.1.1, 2.1.2, 2.1.4, 2.2.1 and 2.3.3 — official text on EUR-Lex.
3. ENISA, Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0, June 2025 (PDF) — guidance and evidence examples for Annex points 2.1.1 and 2.1.2. Non-binding.
4. National Cyber Security Centre Ireland, Guidance on Cyber Governance for Management Board Members in NIS2 entities (PDF), sections 3.1 to 3.5.
5. National Cyber Security Centre Ireland, NIS 2 Risk Management Measures Guidance, draft dated 04/06/2025 (PDF) — RMM002 and RMM005. Draft status; addressed to Irish entities.
6. NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST.CSWP.29 (PDF) — subcategory GV.RM-02.
7. Institute of Risk Management, Risk appetite and tolerance: guidance for practitioners — definition of risk appetite.
8. ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks, paragraph 6.4 (risk criteria), as cited by ENISA in source 3.