NIS2 cybersecurity policies document: practical guide for GV.PO-01 approval

“Cybersecurity policies” are explicitly listed in Appendix C and require approval by governing and management bodies under GV.PO-01 point 1. A policy package should define decision principles, control expectations, and accountability rules across the full NIS baseline scope.

Key takeaways

The policy document set is mandatory and board-approved in first application.
Policies should define governance direction; procedures should define execution steps.
Policy quality depends on consistency across risk, incident, continuity, access, and supplier domains.
A modular template library helps maintain coherence while scaling updates.

What an approvable policy package must include

Requirement area	Minimum policy output	Typical evidence
Governance and ownership	Policy owner, approver, review cycle	Signed approval page and version log
Scope and applicability	Covered systems/services and exclusions	Scope register and rationale notes
Control principles	Mandatory control directions by domain	Control mapping matrix
Exceptions and risk rationale	Documented derogation rules	Exception register and approvals

Recommended policy architecture using templates

1. Core governance policy

Set common principles, accountability model, and decision rights.

2. Domain policies (modular)

Use dedicated documents for key areas (for example: risk, supply chain, assets, vulnerabilities, continuity, access, data, networks, monitoring, incident response).

3. Link to operational procedures

Each policy should reference related procedures without duplicating step-by-step instructions.

4. Unified review and change model

Keep one review cadence and one change-control logic across the policy set to avoid drift.

Policy vs procedure: avoid structural confusion

Element	Policy	Procedure
Purpose	Defines rules and governance intent	Defines execution steps
Level	Management/governance	Operational/technical
Approval	Governing and management bodies	Responsible operational owners (as defined internally)
Update driver	Regulatory change, risk change, governance review	Process changes, incidents, tool changes

Frequent policy drafting mistakes

Mixing policy rules and operational steps in one text.
Inconsistent terminology across policy documents.
Missing explicit approval and review sections.
Policy statements not traceable to risk or control rationale.
No link between policies and evidence-producing procedures.

20-day policy hardening checklist

Build a master index of policy documents and owners.
Normalize terminology and scope definitions across all policy files.
Add mandatory blocks: purpose, scope, responsibilities, exceptions, review cycle.
Map each policy to related procedures and evidence outputs.
Run legal/compliance coherence review before board submission.
Schedule board approval and update the policy change log immediately after decisions.

FAQ

Do all cybersecurity policies require board-level approval?

Appendix C requires approval of the cybersecurity policies document set under GV.PO-01 point 1.

Is one single policy document enough?

It can be, but in practice a modular set is usually more manageable and auditable, as long as governance coherence is preserved.

How should we handle policy updates in 2026?

Use a controlled review cycle tied to regulatory evolution, risk outcomes, and incident lessons learned, with formal re-approval where required.

Conclusion and next steps

A strong policy package is the governance backbone of NIS execution. Teams should prioritize consistency, traceability, and formal approval discipline, then connect each policy to procedures and records that prove implementation in daily operations.

Contacts

Follow us