IT Security Policy Template: The 11 Elements NIS2 Now Requires by Name

Until October 2024, the legal specification for an IT security policy in the EU ran to eight words: Article 21(2), point (a) of the NIS2 Directive asks for “policies on risk analysis and information system security” [2]. That is not a specification. It is a category.

Commission Implementing Regulation (EU) 2024/2690 replaced those eight words with eleven lettered requirements. Annex point 1.1.1 (a) to (k) sets out what the top-level policy must state, commit to, list, lay down and date [1]. Any IT security policy template you download today was almost certainly written before that list existed — and five of the eleven elements are things a normal policy template has no reason to contain. This guide walks the eleven, marks the five, and hands you the register of subordinate policies the regulation names for you.

Does this rulebook actually apply to you?

In plain terms: the eleven-element list is directly binding on eleven specific types of digital entity. If you are not one of them, it is still the most precise published statement of what a NIS2 regulator expects a security policy to contain.

Article 1 of the Implementing Regulation limits its scope to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, online search engines and social networking services platforms, and trust service providers [1]. Hospitals, energy operators, water utilities, transport and manufacturing are in NIS2 scope, but not in this regulation’s scope.

Your situation	What names your policy requirements	How binding
You are one of the 11 digital entity types in Article 1	CIR 2024/2690 Annex 1.1.1 (a)–(k), in full	Directly applicable — no national law needed
You are an essential or important entity in any other sector	Article 21(2)(a) plus your Member State’s transposing law	Binding via national law; the Annex is persuasive, not binding
You supply one of the 11 types	Their supply chain obligations reach you by contract	Contractual, and increasingly non-negotiable
You hold ISO 27001 and want one policy set	Clause 5.2 plus Annex 1.1.1 — the Annex is the superset	Write to the superset once

A timing wrinkle inverts what most people assume. A directive needs national transposition; a regulation does not — and the Implementing Regulation’s concluding formula states that it “shall be binding in its entirety and directly applicable in all Member States” [1]. Meanwhile, on 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify complete transposition of NIS2, asking the Court to impose a lump sum and daily penalties [6]. A Dutch cloud provider therefore has a live content standard for its security policy while its national supervisory framework is still being litigated. “Our country hasn’t transposed yet” is an argument about who inspects you and when — not about what your policy has to say.

The 11 elements the regulation names, letter by letter

In plain terms: this is the table to hold your existing template against. Read the middle column, then check your document.

Annex 1.1.1	What the policy must do	In a typical downloaded template?
(a)	Set out your approach to managing the security of network and information systems	Yes — the part templates do well
(b)	Be appropriate to and complementary with your business strategy and objectives	Partly — usually a generic “purpose” clause
(c)	Set out network and information security objectives	Usually yes
(d)	Include a commitment to continual improvement	Sometimes, often as a closing platitude
(e)	Commit to providing the resources needed for implementation — staff, financial resources, processes, tools and technologies	Rarely
(f)	Be communicated to and acknowledged by relevant employees and relevant interested external parties	Communication yes, acknowledgement rarely
(g)	Lay down roles and responsibilities	Usually yes
(h)	List the documentation to be kept and the duration of its retention	Almost never
(i)	List the topic-specific policies	Almost never as a register
(j)	Lay down indicators and measures to monitor implementation and current maturity level	Almost never
(k)	Indicate the date of formal approval by the management bodies	Almost never

The right-hand column is our own assessment from reviewing the free IT security policy templates currently ranking for this search term — not a figure from any regulator. Treat it as a prompt to check your own document.

The five elements downloadable templates leave out

Elements (e), (h), (i), (j) and (k) share a property: none of them are about security. They are about governability. A template author writing for a global audience has no reason to include them, because they only matter once a supervisor needs to establish that a named group of people owned this document on a named date.

(e) The resource commitment. A policy that mandates controls without committing resources is a wish. Naming staff, budget, processes, tools and technologies turns it into something the board has funded — which is what makes it evidence of the oversight Article 20(1) requires [4].

(h) Documentation and retention. This clause is what makes every other record findable. Without it, an inspector asking for two years of review minutes is asking a question your organisation has never answered. Note the wording: the list of documentation and the duration of retention — a period, per document type.

(i) The topic-specific policy list. Not a mention in passing. A list. It turns the master policy from an essay into an index, and it is the single change that most improves how a policy set reads to an outsider.

(j) Indicators and measures. The policy itself must lay down how implementation will be monitored, including current maturity level. Read it carefully: it asks you to define indicators, not to publish a score. Recital 9 gives the reason — they exist “to facilitate the oversight of the implementation of the cybersecurity risk-management measures through the management bodies” [1]. Instruments for your own board, not a grade you submit.

(k) The approval date. One line, and the most commonly missing one. ENISA lists it as a standalone item of evidence: “the date of the formal approval by the management bodies of the relevant entities, indicated in the policy” [5]. A policy without a date is a draft, whatever the header says.

Who signs what: the two approval levels

In plain terms: the top-level policy needs the board. The policies underneath it do not. Getting this backwards either burns months of board agenda time or produces a policy set with no board fingerprint at all.

Recital 9 of the Implementing Regulation states that the policy on the security of network and information systems “should be the highest-level document” and “should be approved by the management bodies”, while “the topic-specific policies should be approved by an appropriate level of management” [1]. A recital explains intent rather than creating an obligation, so read both as strong direction rather than a rule you can be cited for breaking. ENISA repeats the split as two separate instructions [5]. Article 20(1) supplies the reason: management bodies approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements [4].

Role	What you own here	What you should be asking for
Board / management body	Formal approval of the master policy and of every revision and exception	A dated resolution, an annual review slot, and a briefing you can show you understood
CISO / IT security manager	Elements (a), (c), (g), (i), (j) — the substance and the register	Agreement on which indicators go in, before the board sees the draft
Compliance officer / legal	Elements (f), (h), (k) — acknowledgement records, retention periods, approval evidence	Where acknowledgements are stored and who can retrieve them on request
SME owner wearing all three hats	All of the above, proportionately	One signed, dated document and one honest register — not a 60-page set

One structural requirement hides in the roles section rather than the policy section: Annex point 1.2.3 states that at least one person shall report directly to the management bodies on matters of network and information system security [1]. That reporting line belongs in the master policy, because point 1.2.1 places roles and authorities inside it.

The topic-specific policy register the regulation writes for you

In plain terms: element (i) asks you to list your topic-specific policies. You do not have to invent that list — the Annex enumerates them.

Here is the structural fact that catches most policy sets short. Article 21(2) has ten points, (a) to (j). The Annex has thirteen sections, and the mapping is not one-to-one: point (a) alone produces two sections, and point (i) produces four [1]. Build your policy set by working down the ten-point list and you finish with a set that is structurally incomplete against the document your supervisor is reading from.

Annex section	Document the Annex names	Article 21(2) point
1	Policy on the security of network and information systems (the master)	(a)
2	Risk management framework and risk treatment plan	(a)
3.1	Incident handling policy	(b)
4.1	Business continuity and disaster recovery plan	(c)
5.1	Supply chain security policy	(d)
6.5	Security testing policy and procedures	(e)
7.1	Policy and procedures to assess effectiveness of the measures	(f)
8.2	Security training programme	(g)
9.1	Cryptography policy and procedures	(h)
10.4	Disciplinary process	(i)
11.1	Access control policy	(i) and (j)
12.2	Asset handling policy	(i)
12.3	Removable media policy	(i)
13	Environmental and physical security measures	(c), (e) and (i)

Two of these carry their own drafting traps. The supplier security policy at Annex 5.1 has to survive contact with suppliers who never signed up for your compliance programme. And if you are aligning to ISO 27001 in parallel, the ISMS scope statement does the work element (b) assumes is already done — establishing which parts of the business the policy speaks for. For the master policy’s internal wording, clause by clause, we have a separate section-by-section walkthrough; this guide is about the architecture around it.

What to do about the parts you cannot do

In plain terms: omitting something is allowed. Omitting it silently is not.

Article 2(2) provides that where the Annex qualifies a requirement with “where appropriate”, “where applicable” or “to the extent feasible”, and an entity considers it not appropriate, not applicable or not feasible, the entity “shall in a comprehensible manner document its reasoning to that effect” [1].

Read that as a permission with a price. A twelve-person managed service provider is not expected to segregate conflicting duties the way a bank does — Annex 1.2.5 says “where applicable”. But the moment you lean on that qualifier, the reasoning becomes a document you are obliged to hold, and “comprehensible” sets the bar: a reader who does not work for you has to follow it. Practitioners coming from ISO 27001 will recognise the shape of this from the Statement of Applicability, where exclusions carry written justification. The instruments are different and one does not satisfy the other — but if you already keep justifications in that form, you have somewhere to put these.

ENISA adds a requirement absent from the Annex text: make sure the policy “includes detailed guidance on the procedures for managing policy exceptions” [5]. That is guidance rather than binding law, so treat it as strongly recommended rather than mandatory — but an exceptions procedure is cheap to write, and it is the difference between a controlled deviation and an undocumented one.

What an inspection actually asks for

In plain terms: the Directive names your policy in its supervisory powers. It names evidence that people followed it separately.

Article 32(2) lists what competent authorities may subject essential entities to. Point (e) covers “requests for information necessary to assess the cybersecurity risk-management measures adopted by the entity concerned, including documented cybersecurity policies”. Point (g) covers “requests for evidence of implementation of cybersecurity policies, such as the results of security audits” [3]. Two separate powers — the document, then the proof it is real. A policy set that is immaculate and unevidenced fails the second.

ENISA’s technical implementation guidance sets out what that proof looks like for the master policy: the documented policy containing elements (a) to (k); the approval date indicated in it; signed acknowledgement forms or employment contracts confirming personnel have read and understood the policies; and evidence that the management bodies understand their role — resource allocation, communications to staff, initiatives promoting improvement. For revisions it adds change logs and records that updates and exceptions were approved [5].

If the policy is…	What the authority can reach for
Missing or not produced on request	Art. 32(2)(e)–(f): information and document requests; escalation to on-site inspection under (a)
Present but unimplemented	Art. 32(2)(g): requests for evidence of implementation; Art. 32(2)(b)–(c): targeted or ad hoc audits
Deficient and left uncorrected	Art. 32(4): warnings, binding instructions, orders to cease conduct, public disclosure of the infringement, administrative fines, a designated monitoring officer; where those fail, temporary suspension of certification and a temporary ban on managers exercising managerial functions
Deficient and found by you first	Art. 21(4): take corrective measures without undue delay — self-correction is the route the Directive writes in [2]

Keeping it alive: review cadence and off-cycle triggers

Annex 1.1.2 sets the cadence: the policy shall be reviewed and, where appropriate, updated by management bodies at least annually and when significant incidents or significant changes to operations or risks occur, and “the result of the reviews shall be documented” [1]. Note the subject of that sentence — the review is performed by management bodies, not merely approved by them.

ENISA’s list of what to feed into that review is more useful than the cadence itself: updated risk assessment results and the risk treatment plan, changes in legislation, recommendations from authorities, changes in industry good practice, feedback from interested parties, findings of compliance monitoring and independent reviews including policy violations and exceptions, and incidents “even those affecting similar entities in the sector” [5].

That last item is the one to steal. A significant incident at a comparable provider is a documented trigger for reviewing your own policy — so a short note concluding “we reviewed the sector incident and no change was needed” is itself evidence of a working review process. Most organisations do this thinking and never write it down.

Pre-approval checklist

Run this before the document goes to the board, not after.

1. All eleven elements (a) to (k) are present and individually identifiable in the document.
2. Element (e) names actual resources — headcount, budget line, named tooling — not a commitment to “adequate resources”.
3. Element (h) gives a retention period per document type, not one blanket figure.
4. Element (i) lists topic-specific policies by title and owner, and the list matches what exists.
5. Element (j) defines indicators your board will actually receive, with a stated reporting frequency.
6. Element (k) carries a real date, and the corresponding resolution or minute exists.
7. The reporting line to the management bodies required by Annex 1.2.3 is written into the policy.
8. Every “where appropriate” or “where applicable” qualifier you rely on has a written, comprehensible justification.
9. An exceptions procedure exists and says who may approve an exception, and for how long.
10. Acknowledgement is arranged for employees and relevant external parties, and you know where the records live.
11. What you distribute externally is an extract or summary that does not disclose confidential detail [5].
12. The review trigger list is written into the policy, including significant incidents at comparable entities.

Frequently asked questions

Is an ISO 27001 information security policy enough for NIS2? Not by itself. Recital 3 of the Implementing Regulation records that the Annex requirements are based on European and international standards including ISO/IEC 27001 and ISO/IEC 27002 [1], so a mature ISO policy will satisfy much of the list. But elements (h), (i), (j) and (k) are specified more concretely in the Annex than in Clause 5.2, and approval sits with management bodies as NIS2 defines them. Treat the Annex as the superset and write once.

How long should the master policy be? The regulation sets no length. The structure it describes — an approach, objectives, commitments, a role map, a documentation register, a policy register, indicators and a date — is naturally short, because the detail lives in the topic-specific policies. If your master policy runs past roughly fifteen pages, some of it probably belongs one level down.

Do topic-specific policies need board approval too? No. The recitals and ENISA’s guidance both place them with “an appropriate level of management” [1][5]. Only the master policy, its revisions and its exceptions go to the management bodies.

We are not one of the eleven digital entity types — should we still use this list? It is not binding on you, and you should say so internally rather than overclaim. In practice it is the most detailed published statement of what the Commission considers an adequate NIS2 security policy, and national authorities read it. Writing to it is a defensible choice; presenting it as law that applies to you is not.

Summary

The gap between a downloadable IT security policy template and a NIS2-defensible master policy is five clauses and one table. The five clauses commit resources, set retention periods, register your subordinate policies, define the indicators your board will see, and record who approved the document and when. The table is the register at element (i) — and the regulation has already written it for you, thirteen sections deep, if you read the Annex rather than the ten-point list everyone quotes.

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. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, Official Journal L, 18.10.2024 (Recitals 3 and 9; Article 1; Article 2(2); Annex points 1.1.1, 1.1.2, 1.2 and chapters 1–13). Linked in the introduction above.
2. NIS2 Directive, Article 21 — Cybersecurity risk-management measures — Directive (EU) 2022/2555
3. NIS2 Directive, Article 32 — Supervisory and enforcement measures — Directive (EU) 2022/2555
4. NIS2 Directive, Article 20 — Governance — Directive (EU) 2022/2555
5. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025 (guidance and examples of evidence for Annex points 1.1 and 1.2). Linked in “What an inspection actually asks for” above.
6. Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose the rules on cybersecurity — European Commission, 8 July 2026
7. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex
8. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements, Clause 5.2 and Annex A 5.1 (referenced for structural orientation only; no direct link, as iso.org blocks automated access)