An information security policy should state management's direction, scope, objectives, authority and core rules for protecting information. Supporting standards and procedures then explain mandatory control requirements and operational steps. The goal is a governed policy system that people follow and the organisation can evidence, not a large library copied from a framework.
ISO/IEC 27001:2022 is the published ISMS requirements standard, with Amendment 1:2024. NIS2 Article 21 requires appropriate and proportionate cybersecurity risk-management measures for in-scope entities, starting with risk-analysis and information-system-security policies. SOC 2 is a CPA attestation engagement against applicable Trust Services Criteria, not a policy certification.
Use a clear document hierarchy
| Layer | Purpose | Example |
|---|---|---|
| Policy | Management direction and mandatory principles | Information security policy |
| Standard | Specific mandatory requirements | Identity and access standard |
| Procedure | Repeatable operational steps | Joiner-mover-leaver procedure |
| Guideline | Recommended method where judgement is allowed | Secure remote-working guide |
| Record | Evidence that work occurred | Access-review approval |
Keep definitions consistent across layers. Every supporting document should name an owner, approver, scope, effective date, review trigger and controlled location.
What the top-level policy should cover
The top-level policy normally addresses:
- purpose, organisational scope and information forms covered;
- management commitment and security objectives;
- roles, authority, segregation and escalation;
- risk assessment and risk-acceptance principles;
- classification and handling expectations;
- identity, access, asset and acceptable-use principles;
- supplier, development and change-management expectations;
- incident reporting, continuity and recovery;
- training, monitoring, compliance and enforcement;
- exceptions and documented risk acceptance; and
- review, approval and communication.
Keep implementation detail out of the top-level document when it changes frequently. Put configuration values, tool instructions and step sequences in standards or procedures.
Build the supporting policy set from risk
Start with obligations, information flows, systems, incidents and risk treatment—not a promised number of documents. Typical domains include access control, asset management, data classification, cryptography, secure development, vulnerability management, logging, incident response, continuity, supplier security, physical security, personnel security and privacy.
Map each risk treatment and applicable requirement to one accountable rule and its operational evidence. Consolidate documents when the same audience, owner and review cycle apply. Split them when different teams need precise instructions or restricted access.
For NIS2, confirm that the policy system and underlying measures address all Article 21(2) areas, including incident handling, continuity, supply-chain security, secure acquisition and maintenance, effectiveness assessment, cyber hygiene and training, cryptography, personnel and access security, asset management, and appropriate multifactor or secure communications measures. National law and sector-specific implementing requirements can add detail.
Make policies operational
Use language that states who must do what, under which conditions, and what evidence is retained. Replace vague instructions such as “use strong security” with a referenced standard, accountable owner and exception path.
Implementation sequence:
- confirm scope, obligations, risk owners and audiences;
- inventory existing documents and remove contradictions;
- draft rules with the people who operate them;
- obtain legal, privacy, HR and technical review as relevant;
- approve through the defined authority;
- communicate by role and provide training where needed;
- implement workflows, tooling and evidence collection;
- test effectiveness through metrics, sampling, exercises and audit; and
- track exceptions and corrective actions.
A signed PDF is not evidence that access reviews, backups, supplier checks or incident escalation work. Test the real control and keep the resulting record.
Govern exceptions and review
An exception should identify the rule, affected scope, reason, risk, compensating measures, owner, approver and expiry. Do not allow permanent exceptions without periodic risk review.
Review policies on a defined schedule and when material triggers occur: changes in law, business model, technology, threat, supplier, incident lessons or organisational structure. Version control should show what changed, why, who approved it and when it became effective.
Our cybersecurity advisory services can help turn policy requirements into implemented controls and auditable evidence.
Sources and review
This guide was substantively reviewed on 8 August 2026. It avoids claiming a mandatory policy count or treating a policy document as proof of implementation.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.