NIS2 Risk Management Policy Template: The Disciplinary Clause Most Programs Miss

Article 21(2)(a) of the NIS2 Directive requires “policies on risk analysis and information system security” from every essential and important entity. That single clause has spawned dozens of downloadable “NIS2 policy templates” — most of which restate the same six or seven headings and call it done. None of the ones we reviewed while researching this article included the one clause the Commission’s own implementing regulation treats as non-negotiable: a disciplinary process for policy violations, cross-referenced from the policy itself.

This article walks through what your risk management policy document legally needs, in the order an auditor would check it: which elements are mandatory versus merely good practice, the disciplinary-process requirement almost everyone misses, how to run the policy’s review and approval lifecycle, and a section-by-section template you can adapt directly.

Who This Applies To — And Why the Rules Differ by Entity Type

Two different rulebooks are in play here, and conflating them is the most common scoping mistake we see.

Article 21(2)(a) of Directive (EU) 2022/2555 applies to every essential and important entity in scope of NIS2. It requires “policies on risk analysis and information system security” as part of an all-hazards, proportionate risk management approach [1]. It does not, however, spell out what those policies must contain in technical detail — that’s left to national transposition and, for one specific group of entities, to a Commission implementing act.

That implementing act is Commission Implementing Regulation (EU) 2024/2690, adopted under Article 21(5) of the Directive. It is directly applicable across the EU with no national transposition needed — but only for a defined list of entities: DNS service providers, TLD name registries, cloud computing providers, data centre service providers, 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 [1].

Entity type	Is CIR 2024/2690 Annex I legally mandatory?	What governs your policy instead
DNS, cloud, data centre, CDN, MSP/MSSP, marketplace, search, social platform, trust service providers	Yes — Annex I structure and content are binding	Directly applicable regulation, no national implementation needed
All other essential/important entities (energy, health, transport, manufacturing, finance, etc.)	No	National law transposing Article 21(2)(a); Annex I widely used as best-practice reference since it’s the only detailed EU-level specification

In practice, national competent authorities and auditors outside the CIR’s direct scope routinely benchmark policies against the Annex I structure anyway, because it’s the only place the Commission has defined what a compliant policy document actually contains. That’s the practical reason to build against it even if you’re not legally bound by it — treat the checklist below as mandatory if you’re on the CIR list, and as the strongest available reference otherwise. Check your entity classification before assuming either way.

Article 21(1) also builds proportionality into the general obligation: entities must take measures appropriate to their size, exposure, and the likelihood and severity of incidents they face, taking the state of the art and implementation cost into account [2]. That matters for how much policy you actually need to write. A five-person managed service provider and a multinational cloud operator are both bound by Annex I in full if they’re in scope — but the depth of the risk methodology, the number of named roles, and the granularity of the monitoring indicators inside that policy should scale with the entity, not copy a template built for a much larger organisation. A one-page policy with all eleven elements present beats a twenty-page policy missing three of them.

The 11 Elements Your Policy Must Contain Under CIR 2024/2690

Annex I, point 1.1.1 lists what the network and information system security policy must set out. In CIR-bound entities, all eleven are mandatory. For everyone else, treat this as the recommended baseline — the elements map directly onto what ISO/IEC 27001’s information security policy clause and most national guidance already expect.

#	Element (Annex I §1.1.1)	Plain-language translation
a	Approach to managing NIS security	State your overall philosophy — risk-based, proportionate, tied to business objectives
b	Alignment with business strategy	The policy can’t read like a generic IT document; it has to reference your actual business objectives
c	Security objectives	Name 3-5 measurable goals, not just “be secure”
d	Commitment to continual improvement	One sentence committing to periodic revision — ties directly into §1.1.2 below
e	Commitment to adequate resourcing	Staff, budget, tools — named, not implied
f	Communication to staff and external parties	Prove it was distributed and acknowledged, not just written
g	Roles and responsibilities (per §1.2)	Named roles, not “IT department”
h	Documentation retention list and duration	What records you keep and for how long
i	List of topic-specific policies	Your policy is the umbrella; it must index the specific policies underneath it (access control, backup, encryption, etc.)
j	Monitoring indicators and maturity measures	How you’ll know the policy is actually working
k	Date of formal management-body approval	Not just “approved” — a dated, documented approval event

Element (i) is where most self-written policies fail quietly: they describe security measures in the same document instead of indexing separate topic-specific policies (access control, backup, encryption, and so on) as CIR 2024/2690 expects. A risk management policy that tries to also be your access control policy usually ends up too vague to be either.

The Disciplinary Clause Almost Every Policy Template Skips

Annex I, point 10.4 — inside the human resources security section, not the policy section — requires relevant entities to establish, communicate and maintain a disciplinary process for handling violations of network and information system security policies, taking into account relevant legal, statutory, contractual and business requirements. That process must itself be reviewed and updated at planned intervals, and whenever legal changes or significant operational changes make it necessary [4][5].

Here’s why it gets missed: whoever drafts the risk management policy is usually the CISO or IT security lead, and the disciplinary process sits in HR’s domain. The two documents get written by different people, at different times, and never reference each other. The result is a technically complete information security policy that has no enforceable consequence attached to violating it — which is precisely what an auditor checking §1.1.1(g) (roles and responsibilities) and §10.4 together will flag.

The fix isn’t to duplicate HR’s disciplinary procedure inside your security policy. It’s a one- or two-sentence cross-reference: name the disciplinary process document, state that violations of this policy are handled under it, and confirm HR and Legal have reviewed that cross-reference. That’s the entire gap, and it costs one paragraph to close.

Role	What they own in this clause
CISO / Security Lead	Drafts the cross-reference in the security policy; confirms it names the correct disciplinary document
HR	Owns and maintains the actual disciplinary process; reviews it at planned intervals per §10.4
Legal / Compliance Officer	Confirms the process accounts for local employment law and contractual terms before sign-off

Policy Lifecycle — Review Triggers, Version Control, and Board Approval Evidence

Annex I, point 1.1.2 sets the review cadence: the policy shall be reviewed and, where appropriate, updated by management bodies at least annually and whenever significant incidents or significant changes to operations or risks occur, with the results of each review documented [1][3]. That’s three distinct triggers — a calendar date, an incident-driven trigger, and a change-driven trigger — and a policy that only satisfies the first one is incomplete.

Version control. A single “Information Security Policy v3.docx” file with no history is not what an auditor wants to see. The minimum defensible record is a document control table: version number, date, author, summary of what changed, and the approver. Keep it on the first or last page of the policy itself — it’s the fastest thing an auditor checks and the easiest thing to get right.

Version	Date	Changed by	Summary of change	Approved by
1.0	Initial adoption date	Author name/role	First issue	Management body, dated
1.1	Trigger date (annual / incident / change)	Author name/role	One-line description of what changed and why	Management body, dated

Board approval evidence. Element (k) of §1.1.1 requires the policy to indicate the date of formal approval by the management bodies — but “the board saw it” is not evidence; a dated approval record is. What auditors typically expect is one of: a board or management-body meeting minute referencing the specific policy version, a signed approval page attached to the policy itself, or a standalone resolution document. Larger entities increasingly use the last option specifically so the approval trail survives even if the policy document itself is later superseded. Our board governance framework guide covers how to structure that oversight beyond this one document.

Worked Template Walkthrough, Section by Section

Here’s how the eleven CIR elements map onto an actual document structure, with a rough current-state-to-compliant-state effort estimate for a policy that already exists but hasn’t been updated against Annex I.

Section	Covers CIR elements	Typical gap in an existing policy	Effort to close
1. Purpose & scope	a, b	Usually present but generic	Low
2. Roles & responsibilities	g	Named departments instead of named roles	Medium
3. Risk management approach	a, c	References a separate risk methodology document without cross-linking it	Low
4. Objectives & resourcing commitment	c, d, e	Objectives are vague (“improve security”) rather than measurable	Medium
5. Topic-specific policy index	i	Missing entirely — most common gap after the disciplinary clause	Medium
6. Disciplinary process cross-reference	(links to §10.4)	Absent in almost every self-written policy	Low
7. Communication & acknowledgement record	f	Policy exists but no proof staff read it	Medium
8. Monitoring indicators	j	No defined maturity metric	High
9. Document control & review history	d, h	Missing or a single “last updated” date with no history	Low
10. Formal approval record	k	Approval implied, not dated or evidenced	Low

Sections 5, 6 and 8 are consistently where existing policies fall short — and not coincidentally, they’re the three elements that require coordination with another team (legal/HR for the disciplinary reference, other policy owners for the index, and whoever owns your metrics or GRC tooling for monitoring indicators). Budget for those conversations before you budget for the drafting itself.

Documentation Checklist Before You Call This Policy Audit-Ready

Run this checklist against your current draft before it goes to the board, not after. Every item traces to a specific Annex I point cited earlier in this article, so a missing item tells you exactly which section to go back and fix rather than leaving you guessing at what an auditor actually wants to see.

• All eleven §1.1.1 elements present, including the topic-specific policy index (element i)
• Roles and responsibilities name specific positions, not departments (§1.2)
• A one-paragraph disciplinary process cross-reference, confirmed with HR and Legal (§10.4)
• Document control table showing version history with named approvers
• Dated, evidenced management-body approval — minute reference, signed page, or resolution
• A defined review cadence covering the annual date, an incident trigger, and a change trigger (§1.1.2)
• At least one monitoring indicator tied to the policy’s stated objectives
• Proof of communication to staff (training record, acknowledgement log, or intranet read-receipt)

Frequently Asked Questions

Does every NIS2 entity legally need to follow CIR 2024/2690’s Annex I structure?
No. The regulation directly binds only the specific digital-infrastructure and ICT-service entities listed under Article 21(5) — DNS providers, cloud, data centres, CDN, MSP/MSSP, marketplaces, search engines, social platforms, and trust service providers. Every other essential/important entity is bound only by Article 21(2)(a)’s general requirement, though Annex I is widely used as the closest thing to an official EU template [1][2].

Where exactly does the disciplinary clause requirement come from?
Annex I, point 10.4, in the human resources security section of CIR 2024/2690 — not the network and information system security policy section itself. That’s precisely why it’s easy to miss when drafting the policy in isolation [4][5].

How often must the policy actually be reviewed?
At least annually, and whenever a significant incident occurs or significant changes to operations or risk occur — with the outcome of each review documented, per Annex I §1.1.2 [1][3].

My organisation is small and doesn’t have a formal board — who approves the policy?
Annex I §1.1.1(k) refers to “management bodies,” which in a small entity can be the owner, managing director, or leadership team rather than a formal board. What matters for the evidence trail isn’t the title of the approver — it’s that someone with genuine management authority signed and dated the approval, and that the record survives independently of the policy document itself.

Sources

• [1] Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex
• [2] NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
• [3] Advisera — CIR 2024-2690 Annex I, technical and methodological requirements
• [4] cyberday.ai — NIS2 Guide, Annex point 10.4: Disciplinary process
• [5] OpenKRITIS — CIR 2024/2690 implementing-act mapping

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.