NIS2 ISMS Policy: What Each Section Must Say to Survive an Audit (+ Template)

How to use this guide: CISO / IT Security Manager — focus on Sections 3–4 (policy hierarchy and section walkthrough) and the compliance checklist. Compliance Officer / Legal — pay particular attention to Section 4h (disciplinary clause) and the management body sign-off section. SME Owner / non-technical — read Sections 1, 2, and the common mistakes section first.

Most organisations entering NIS2 compliance already have some form of information security policy. The gap — and what distinguishes entities that pass supervisory review from those that receive improvement orders — is what that policy actually contains.

Article 21(2)(a) of the NIS2 Directive [1] requires essential and important entities to maintain “policies on risk analysis and information system security.” That requirement is not satisfied by having a document with this title. It is satisfied by a top-level governance instrument, formally approved by your management body, that states your organisation’s security approach, assigns accountability, defines your risk methodology, and contains an enforcement mechanism.

This walkthrough covers each mandatory section of a compliant NIS2 information security policy — grounded in Article 21, Article 20, Commission Implementing Regulation (EU) 2024/2690 [2], and ENISA’s June 2025 Technical Implementation Guidance [3]. By the end, you will know what each section must say, what auditors check for, and where most policies fall short.

What NIS2 Actually Requires

Two articles of Directive (EU) 2022/2555 drive the information security policy requirement together.

Article 21(2)(a) [1] lists “policies on risk analysis and information system security” as the first of ten mandatory cybersecurity risk-management measures. It is first on the list deliberately: without a documented, approved policy framework, every other control is floating without an anchor. Risk assessments have no authorised methodology. Access controls have no stated rationale. Incident procedures have no governance authority.

Article 20 [1] assigns management body responsibility. Management bodies must approve cybersecurity risk-management measures and oversee their implementation. This is not a sign-off that can be delegated to the CISO or IT Director — the directive creates personal liability for management body members who fail to fulfil this obligation.

For entities in scope of Commission Implementing Regulation (EU) 2024/2690 [2] — cloud computing service providers, DNS service providers, content delivery network providers, managed service providers, and others listed in Article 2 of the CIR — the Annex to that regulation translates Article 21(2)(a) into specific, binding requirements. For all other essential and important entities, ENISA’s Technical Implementation Guidance [3] published in June 2025 provides equivalent practical guidance. Both frameworks converge on the same structural requirements, which this article uses as the baseline.

The distinction that most guides miss: Article 21(2)(a) refers to “policies” in the plural, structured as a hierarchy. There is one top-level policy and a set of topic-specific policies below it. Writing one large document that tries to cover everything violates this architecture and produces a governance instrument that is simultaneously too vague to enforce and too detailed to use as a governing document.

Who Must Have One?

Every essential and important entity covered by NIS2 must maintain a top-level information security policy. The obligation level and the specificity of technical requirements differ by entity type.

Entity Type	Obligation Source	Technical Requirements	Audit Approach
Essential entities	NIS2 Art. 21 + national law	ENISA June 2025 guidance + national authority rules	Proactive; can be unannounced
Important entities	NIS2 Art. 21 + national law	ENISA June 2025 guidance + national authority rules	Primarily reactive (post-incident or spot checks)
CIR-scope entities (cloud, DNS, CDN, MSP, trust services)	NIS2 Art. 21 + CIR 2024/2690	CIR Annex (binding) + ENISA guidance	Proactive for essential; reactive for important

If you are not certain whether your organisation qualifies as essential or important, see our guide to essential vs. important entity classification before proceeding.

Top-Level Policy vs. Topic-Specific Policies

CIR Annex section 1.1.1 [2] is explicit that the top-level policy must reference “topic-specific policies” — meaning the architecture requires multiple documents, not one.

The top-level information security policy is the board-approved governing document. It is typically 5–10 pages. Its purpose is to state the organisation’s overall security approach, assign accountability at the senior level, define the risk methodology at a high level, and list the subordinate policy framework. It does not contain operational procedures or technical controls.

Topic-specific policies are subordinate documents covering individual control domains: access control, cryptography, acceptable use, incident response, business continuity, supply chain security, secure development, and human resources security. Each is typically 3–6 pages, focused on one domain, and referenced from the top-level policy.

The audit implication is practical. If a national competent authority asks to see your information security policy under Article 21(2)(a), they expect the top-level document. Handing over a 70-page omnibus document covering every control will typically prompt a request to restructure — or a finding that the governance architecture does not meet the framework requirements in the NIS2 implementing regulation.

Think of the top-level policy as your organisation’s articles of association: it sets the governance framework and authority structure. Individual topic-specific policies are the operating rules within that framework. Keep the governing document governing.

Section-by-Section Walkthrough

The following eight sections represent the complete content structure required by CIR Annex 1.1 [2] and ENISA guidance [3]. Each section includes what it must contain, what auditors verify, and the most common drafting failure. Effort ratings indicate the work required to draft each section for the first time.

1. Scope Statement

Effort: Low | Owner: CISO | Audit evidence: Policy document + network/service inventory

The scope statement defines precisely what is covered by the policy: which legal entities, which systems and services, which geographic locations, and which third-party relationships fall within the policy boundary. CIR Annex 1.1.1 [2] requires this boundary to be explicit.

A compliant scope statement specifies:

• Legal entity name(s) covered, including subsidiaries if applicable
• The specific services and networks included — and any explicitly excluded
• Geographic scope if operations span multiple locations or jurisdictions
• Whether the policy covers third-party-operated infrastructure or only internally managed systems

Most common failure: A scope that reads “all information systems operated by [Organisation]” with no further definition. Supervisory authorities treat this as evidence that the organisation has not analysed its security perimeter. If everything is in scope with no boundaries, nothing can be specifically measured or controlled. Define the boundary deliberately — and if you are excluding certain systems, state why.

2. Management Commitment Statement

Effort: Low | Owner: Board / CEO | Audit evidence: Board minutes, dated policy signature

Article 20 [1] requires management bodies to approve cybersecurity risk-management measures. The management commitment section is the documented evidence that this approval is substantive, not ceremonial.

A compliant management commitment section contains:

• The specific management body or governance structure that approved the policy (board of directors, executive committee, or equivalent)
• The date of approval and the date of the next scheduled review
• A commitment to allocating necessary resources for implementing the policy
• Assignment of the security function to a named role (CISO or equivalent) with a stated reporting line
• A reference to the organisation’s obligations under NIS2 and applicable national law

What auditors check: Board minutes confirming the policy was on the agenda and actively reviewed — not circulated for signature outside a meeting. A policy with a management commitment section but no supporting board minutes satisfies the legal form while missing the governance substance that Article 20 requires.

3. Roles and Responsibilities

Effort: Medium | Owner: CISO + HR | Audit evidence: Policy + org chart + role descriptions

CIR Annex sections 1.2.1 through 1.2.6 [2] specify role requirements that go beyond what a standard ISO 27001 ISMS policy typically contains. Three requirements stand out:

CISO reporting line: The CISO — or whoever holds the equivalent function — must report directly to the management body, not through a CIO or IT Director. This reporting line is checked during supervisory review. An indirect reporting chain is treated as a governance gap under the CIR because it dilutes management body visibility over security decisions.

Segregation of conflicting duties: The policy must acknowledge where conflicts could arise between operational and oversight roles — for example, one individual who both operates and audits the same system — and state how those conflicts are managed. This acknowledgement is required even where the conflicts are unavoidable for resource reasons, provided the compensating controls are documented.

Role assignment, not role description: Roles must be assigned to named positions with defined accountabilities, not described abstractly. The policy should state which role owns each security function — risk assessment, incident coordination, supplier oversight, access management governance — rather than listing the functions in the abstract.

A RACI table covering the main security functions is the most audit-efficient format for this section. Cover at minimum: governance of this policy itself, risk assessment, incident management, supplier security, and access control oversight.

4. Risk Approach

Effort: Medium | Owner: CISO + Risk Owner | Audit evidence: Policy + risk register

Article 21(1) [1] mandates an all-hazards approach covering physical environment threats, telecommunications failures, and cyber threats together, not in separate silos. The risk approach section of the top-level policy must reflect this.

This section does not reproduce your full risk methodology — that belongs in a separate risk management procedure. It states:

• That the organisation uses a structured, documented risk assessment process
• That the approach is all-hazards, explicitly covering physical threats (power disruption, environmental damage, physical access) alongside technical and operational threats
• That risk treatment decisions are proportionate to the impact on service delivery and the criticality of those services
• A cross-reference to the risk assessment procedure or policy

For sector-specific entities — energy, healthcare, transport, water — the all-hazards requirement carries particular weight because physical and cyber risks are tightly coupled in operational environments. See our NIS2 risk assessment guide for methodology requirements.

5. Security Objectives

Effort: Medium | Owner: CISO | Audit evidence: Objective register, progress tracking records

Security objectives translate the management commitment into measurable targets for the policy period. CIR Annex 1.1.1 [2] requires that objectives be documented and aligned to business requirements; ENISA guidance [3] adds that they must be reviewed as part of the regular policy review cycle.

Compliant security objectives share four characteristics:

• Specific: “Achieve multi-factor authentication on all administrative accounts by Q4 2025” rather than “improve access security”
• Time-bound: Assigned to a planning cycle, not left open-ended
• Owned: Each objective assigned to a named role accountable for delivery
• Risk-linked: Traceable to a specific risk identified in the risk assessment, so the objective’s priority is justified

Five to eight objectives at the top-level policy is typical. Detailed KPIs, metrics, and implementation milestones belong in the security management programme or annual security plan, not the policy itself. The policy sets direction; the programme tracks delivery.

6. Topic-Specific Policies Reference

Effort: Low | Owner: CISO | Audit evidence: Policy document register with version and review dates

The top-level policy must list all subordinate topic-specific policies. This list is the governance map showing that the policy framework is complete and actively maintained.

Minimum coverage at the time of supervisory review:

• Access control policy — see our NIS2 access control requirements guide
• Cryptography and encryption policy
• Incident response policy
• Business continuity and disaster recovery policy
• Supply chain security policy
• Acceptable use policy
• Human resources security policy (onboarding, training, offboarding)
• Secure development policy (if applicable)

For each policy in the list, include: policy title, version number, and last review date. This transforms the reference list into a living document control register that demonstrates the framework is maintained rather than static. A list of policies with no version or review dates is an audit finding waiting to happen.

7. Review and Update Cadence

Effort: Low | Owner: CISO | Audit evidence: Policy version history, review records, board minutes

CIR Annex 1.1.2 [2] states that the policy must be reviewed “regularly, at least annually, and after significant incidents and organisational changes.” This is a binding requirement for CIR-scope entities and is mirrored in ENISA guidance [3] for all others.

The policy must contain:

• A defined minimum review frequency (at least annual)
• Named trigger conditions for unscheduled reviews: significant security incidents, major organisational changes (mergers, acquisitions, service expansions), and material changes in the regulatory environment
• The role responsible for initiating and coordinating each review
• The approval process for any policy changes — which must return to the management body for approval, not stop at the CISO

Most common failure: An expired review date. A policy dated 2023 with no evidence of a 2024 review creates an immediate audit finding under CIR Annex 1.1.2. The annual review is mandatory, not advisory. Set a calendar trigger tied to your fiscal year, treat the review date as a compliance deadline, and ensure the management body approves any resulting changes with minutes to document the discussion.

8. Disciplinary and Sanctions Clause

Effort: Low | Owner: HR + Legal | Audit evidence: Policy + HR disciplinary procedure cross-reference

This section is the most frequently omitted element of NIS2 information security policies. NCSC Ireland’s NIS2 Risk Management Measures Guidance [5] explicitly states the requirement: organisations must “establish, communicate, and maintain a disciplinary process for handling wilful, malicious, or negligent violations of network and information security policies, taking into consideration relevant legal, statutory, contractual and business requirements.”

The top-level policy must state:

• That violations of this policy and all subordinate topic-specific policies are subject to disciplinary action
• A reference to the organisation’s HR disciplinary procedure for the process detail
• A distinction between negligent violations (procedural breach) and wilful or malicious violations (typically treated as gross misconduct under employment law)
• That the policy applies to all staff, contractors, and third parties with access to systems — not only employees

What this section is not: it is not a detailed disciplinary procedure. That belongs in HR policy. What the information security policy contributes is the statement that security rules are binding and enforceable. A policy that contains no enforcement mechanism is aspirational rather than operative — it may document intent but cannot demonstrate control.

Common Mistakes That Cause Audit Failures

These six patterns appear most frequently in NIS2 information security policies that receive audit findings or supervisory improvement orders.

Scope covering “everything” with no defined boundary. Auditors interpret a universal scope as evidence that the organisation has not analysed its security perimeter. A boundary that includes everything cannot be specifically assessed, controlled, or evidenced. Define what is in scope and be equally clear about what is not.

Generic management commitment language. “The management of [Organisation] is committed to information security and takes cybersecurity seriously” satisfies no requirement in Article 20. The commitment section must name the approving body, record the approval date, document the resource allocation decision, and assign the security function to a named role. Anything less is decoration.

Missing disciplinary clause. A policy with no enforcement mechanism cannot demonstrate that security obligations are binding. Compliance practitioners reviewing NIS2 policy frameworks in 2024–2025 have consistently identified this as the most common substantive gap. Add the clause and cross-reference the HR disciplinary procedure.

Review date expired. An annual review is mandatory under CIR Annex 1.1.2, not advisory. A policy last reviewed two or more years ago creates an immediate finding. The review must be documented, changes must be approved by the management body, and the updated policy version must be redistributed. Treat the review date as a compliance deadline.

ISO 27001 policy adopted without NIS2 mapping. ISO 27001 and NIS2 overlap substantially, but the gaps matter. ISO 27001 does not require management body approval under the NIS2 definition, does not name the all-hazards approach explicitly, and typically omits the disciplinary clause as a policy element. An unmodified ISO 27001 information security policy will have these gaps. For a full comparison, see our NIS2 vs ISO 27001 analysis.

Top-level policy that contains every control. A 60-page document covering access control procedures, cryptographic key management, incident escalation paths, and HR security in a single file is not a governance instrument — it is an unmanageable reference library. Topic-specific policies exist to hold this operational content. The top-level policy should be readable in under 30 minutes by a management body member with no technical background.

Management Body Sign-Off: What Article 20 Actually Requires

Article 20 of the NIS2 Directive [1] creates personal accountability for management body members who fail to oversee cybersecurity risk management. The directive provides for individual sanctions including temporary bans from management functions, which means the management body’s engagement with the information security policy is not an administrative formality.

Supervisory authorities verify three things when reviewing management body involvement:

Board minutes confirming the policy was a substantive agenda item — reviewed, discussed, and approved — not circulated for signature outside a meeting and returned. A signed policy without corresponding board minutes satisfies the legal form of Article 20 while missing its governance substance.

Evidence of management body briefing before the approval vote, demonstrating that members understood the policy’s content and their obligations under NIS2. A signature from a management body member who was not briefed on what they were approving is a liability, not a compliance asset. The briefing itself is evidence of the management awareness that Article 20 implicitly requires.

Individual accountability assignments showing that specific Article 21 domains — supply chain security, business continuity, access management — are assigned to named management positions rather than left as a collective board obligation. Collective responsibility for all ten Article 21 measures is the same as no accountability for any of them.

For more on structuring the board-level NIS2 process and managing management body training, see our guide to board-level NIS2 obligations. On the personal penalty exposure that makes this process critical, see our NIS2 penalties overview.

Compliance Checklist: Pre-Approval Verification

Before submitting the policy for management body approval, verify each section against the requirements below. For CIR-scope entities, cross-reference with the Annex requirements using our implementing regulation guide.

Section	Minimum Requirement	Audit Evidence Required
Scope statement	Legal entity names, specific systems/services with defined boundary	Policy document; network/service inventory
Management commitment	Named approving body, approval date, resource commitment, named security role	Board minutes; signed policy with date
Roles and responsibilities	CISO reports to management body; RACI for key functions; segregation of duties noted	Policy; org chart; role descriptions
Risk approach	All-hazards reference, proportionality principle, cross-reference to risk procedure	Policy; risk register; risk assessment procedure
Security objectives	Specific, time-bound, named owner, linked to identified risks	Policy; objective register or annual security plan
Topic-specific policy list	All required domains listed with version numbers and review dates	Policy; document control register
Review and update cadence	Annual minimum stated; trigger conditions listed; approval process specified	Policy; review records; board minutes for each review
Disciplinary and sanctions clause	Violations subject to process; HR procedure referenced; scope covers staff and contractors	Policy; HR disciplinary procedure

Frequently Asked Questions

Does an existing ISO 27001 information security policy satisfy NIS2?
Likely not without modification. ISO 27001 does not require management body approval under the NIS2 definition, does not name the all-hazards approach explicitly, and typically omits the disciplinary clause as a policy element. Review against Article 20 and Article 21(2)(a) specifically before assuming alignment.

How long should the top-level policy be?
Five to ten pages is standard. Longer usually means topic-specific content has migrated in that belongs in subordinate policies. Shorter may indicate required sections are absent. Length is not itself a compliance criterion — but it is a reliable proxy for whether the policy hierarchy is correctly structured.

How often must the policy be reviewed?
At minimum annually. Trigger an unscheduled review after any significant security incident, major organisational change — including mergers, acquisitions, or substantial new services — or a material change in the regulatory environment. Each review requires management body approval of any changes, documented in board minutes.

What is the difference between the top-level policy and the risk management policy?
The top-level information security policy states that a risk assessment process exists and references it. The risk management policy or procedure describes the methodology — how risks are identified, rated, treated, and tracked. The top-level policy governs; the risk management procedure operationalises. See our risk assessment guide for what the subordinate document must contain.

What happens if the management body has not formally approved the policy?
Under Article 20, management body approval is mandatory. A policy not approved at this level does not satisfy the NIS2 requirement. Additionally, if a security incident occurs while the policy was not properly approved, the entity’s management faces increased personal liability exposure under the individual accountability provisions of the directive.

Does the disciplinary clause need to specify the penalties?
No. The top-level policy states that violations are subject to disciplinary action and cross-references the HR disciplinary procedure. The specific process, sanctions scale, and appeal rights belong in that HR document. The policy’s role is to establish that the rules are binding and that a process exists — not to replicate HR procedure in a governance document.

Summary

A compliant NIS2 information security policy is the governance instrument that makes every other control auditable. Risk assessments, access controls, and incident procedures all derive their authority from it. An unapproved policy, or a policy with missing sections, does not just create a compliance gap on paper — it weakens the entire control framework that depends on it for its authority.

The eight sections in this walkthrough correspond directly to the requirements in CIR 2024/2690 Annex 1 [2] and ENISA’s June 2025 guidance [3]. Cover each with specificity, obtain management body approval with board minutes to evidence it, and keep the review date current.

For organisations starting from scratch or updating a non-compliant policy, a structured template saves significant drafting time and reduces the risk of missing a required element. Our NIS2 policy template library includes a top-level information security policy template structured to these eight sections, with instructional notes mapping each field to the specific CIR Annex requirement it satisfies.

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 Directive) — EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex Official Journal
3. NIS2 Technical Implementation Guidance — ENISA, June 2025
4. NIS2 Implementing Act (EU) 2024/2690: NIS2, ISO 27001 Mapping — OpenKRITIS
5. NIS2 Draft Risk Management Measures Guidance — NCSC Ireland, June 2025
6. NIS2 Article 21 Risk Management Measures Explained — GloCert International