An information security policy is a formal document that defines an organisation's rules and commitments for protecting information assets, required by ISO 27001 (Clause 5.2), SOC 2 Trust Services Criteria, NIS2, and GDPR as the foundation of any auditable security programme.
Policies are the backbone of every information security programme. They translate your organisation's security commitments into actionable rules that employees, contractors, and partners must follow. Without policies, security controls lack authority, audit evidence is incomplete, and compliance claims are unsubstantiated.
Yet policy development is one of the most time-consuming aspects of building a security programme. A typical ISO 27001 implementation requires 15–25 policies; add SOC 2, GDPR, NIS2, and DORA requirements, and the policy library can grow to 30+ documents. Each policy needs to be written clearly, approved by management, communicated to relevant staff, and reviewed regularly.
This guide provides a complete framework for building your information security policy library — with prioritised lists, writing guidelines, and templates aligned to ISO 27001, SOC 2, NIS2, GDPR, and DORA.
| Quick Reference | Details |
|---|---|
| What is an information security policy? | A formal document that defines the organisation's approach to managing and protecting information assets |
| Key standard | ISO 27001:2022 — requires an Information Security Policy (Clause 5.2) and supporting policies (Annex A.5.1) |
| Typical policy library size | 15–30 policies depending on scope and regulations |
| Approval authority | Senior management (CEO, CISO, or designated executive) |
| Review frequency | At least annually; update when circumstances change |
| Communication | All relevant staff must be aware of and have access to applicable policies |
| SOC 2 requirement | Policies documented for each Trust Services Criteria area |
| NIS2 requirement | Cybersecurity risk management policies (Article 21) |
| DORA requirement | ICT risk management policies (Article 6) |
Key Takeaways
- An information security policy is the top-level document that sets the direction for your security programme — every other policy flows from it
- ISO 27001 requires a formal information security policy plus supporting policies for each applicable Annex A control
- A well-structured policy library typically contains 15–25 core policies plus supporting procedures and guidelines
- Policies should be concise, clear, and actionable — a policy nobody reads provides zero security value
- Policy hierarchy matters: policies define "what" and "why"; standards define "how much"; procedures define "how"; guidelines provide recommendations
- Every policy needs an owner, an approval authority, a review date, and a clear scope
- Prioritise: build your Tier 1 (essential) policies first, then expand to Tier 2 and Tier 3 as your programme matures
- Policies are living documents — they must evolve with your organisation, threat landscape, and regulatory environment
Table of Contents
- What Is an Information Security Policy?
- Policy Hierarchy: Policies, Standards, Procedures, Guidelines
- The Complete Policy Library: All Policies You Need
- Tier 1: Essential Policies (Build First)
- Tier 2: Important Policies (Build Next)
- Tier 3: Advanced Policies (Build as Needed)
- Policy Mapping to Frameworks
- How to Write an Effective Security Policy
- Policy Template Structure
- Information Security Policy Template
- Acceptable Use Policy Template
- Access Control Policy Template
- Policy Approval and Communication
- Policy Review and Maintenance
- Common Policy Mistakes
- Frequently Asked Questions
- Related Resources
What Is an Information Security Policy?
An information security policy is a formal, management-approved document that states the organisation's intent and direction for protecting information assets. The top-level information security policy (sometimes called the "ISMS policy" in ISO 27001 contexts) sets the overall framework within which all other security policies, standards, procedures, and guidelines operate.
What a Good Policy Does
| Function | Example |
|---|---|
| Sets direction | "The organisation shall protect all information assets commensurate with their classification and risk level" |
| Establishes authority | "The CISO is responsible for the information security programme" |
| Defines scope | "This policy applies to all employees, contractors, and third parties with access to company information" |
| Creates accountability | "Department heads are responsible for compliance within their teams" |
| Enables enforcement | "Violations may result in disciplinary action, up to and including termination" |
| Demonstrates compliance | Provides documented evidence for auditors, regulators, and customers |
Policy Hierarchy: Policies, Standards, Procedures, Guidelines
| Level | Definition | Example | Mandatory? |
|---|---|---|---|
| Policy | High-level statement of intent and direction; defines "what" and "why" | "All systems must be protected by access controls appropriate to their classification" | Yes — mandatory for all in scope |
| Standard | Specific, measurable requirements; defines "how much" | "Passwords must be at least 14 characters with complexity requirements" | Yes — mandatory for all in scope |
| Procedure | Step-by-step instructions; defines "how" | "To reset your password: 1) Go to portal.example.com, 2) Click 'Forgot Password'..." | Yes — for those performing the task |
| Guideline | Recommended practices; not mandatory | "When choosing a password, consider using a passphrase of 4+ random words" | No — advisory/recommended |
Why this matters for audits: Auditors check that policies exist (management intent), standards are defined (measurable requirements), and procedures are followed (operational evidence). Mixing these levels in a single document creates confusion about what's mandatory vs. recommended.
The Complete Policy Library: All Policies You Need
Here is a comprehensive list of information security policies, organised by priority tier:
Full Policy List
| # | Policy | Tier | ISO 27001 | SOC 2 | NIS2 | GDPR |
|---|---|---|---|---|---|---|
| 1 | Information Security Policy | 1 | A.5.1 | CC1.1 | Art. 21 | — |
| 2 | Acceptable Use Policy | 1 | A.5.10 | CC6.1 | — | — |
| 3 | Access Control Policy | 1 | A.5.15–A.5.18, A.8.2–A.8.5 | CC6.1–CC6.8 | Art. 21 | Art. 32 |
| 4 | Data Classification Policy | 1 | A.5.12–A.5.13 | CC6.1 | — | — |
| 5 | Incident Response Policy | 1 | A.5.24–A.5.28 | CC7.3–CC7.5 | Art. 23 | Art. 33–34 |
| 6 | Data Protection / Privacy Policy | 1 | A.5.34 | Privacy criteria | — | Arts. 5–14 |
| 7 | Risk Management Policy | 1 | Clause 6.1 | CC3.1–CC3.4 | Art. 21 | — |
| 8 | Backup and Recovery Policy | 1 | A.8.13 | A1.2 | Art. 21(2)(c) | Art. 32 |
| 9 | Vendor/Third-Party Risk Policy | 1 | A.5.19–A.5.23 | CC9.2 | Art. 21(2)(d) | Art. 28 |
| 10 | Password/Authentication Policy | 2 | A.5.17, A.8.5 | CC6.1 | — | — |
| 11 | Encryption Policy | 2 | A.8.24 | CC6.1, CC6.7 | — | Art. 32 |
| 12 | Network Security Policy | 2 | A.8.20–A.8.23 | CC6.6 | Art. 21 | — |
| 13 | Change Management Policy | 2 | A.8.32 | CC8.1 | — | — |
| 14 | Vulnerability Management Policy | 2 | A.8.8 | CC7.1 | Art. 21 | — |
| 15 | Business Continuity Policy | 2 | A.5.29–A.5.30 | A1.1–A1.3 | Art. 21(2)(c) | — |
| 16 | Physical Security Policy | 2 | A.7.1–A.7.14 | CC6.4 | — | Art. 32 |
| 17 | Security Awareness Training Policy | 2 | A.6.3 | CC1.4 | Art. 21(2)(g) | — |
| 18 | Logging and Monitoring Policy | 2 | A.8.15–A.8.16 | CC7.1–CC7.2 | — | — |
| 19 | Mobile Device / BYOD Policy | 2 | A.8.1 | CC6.7 | — | — |
| 20 | Remote Working Policy | 2 | A.6.7 | CC6.6 | — | — |
| 21 | Data Retention and Disposal Policy | 2 | A.8.10 | C1.1 | — | Art. 5(1)(e) |
| 22 | Secure Development Policy | 3 | A.8.25–A.8.31 | CC8.1 | — | Art. 25 |
| 23 | Cloud Security Policy | 3 | A.5.23 | CC6.7 | — | — |
| 24 | Cryptographic Key Management Policy | 3 | A.8.24 | CC6.1 | — | — |
| 25 | Clean Desk / Clear Screen Policy | 3 | A.7.7 | CC6.4 | — | — |
Tier 1: Essential Policies (Build First)
These 9 policies form the minimum viable policy library. Build them first.
| Policy | What It Covers | Why It's Essential |
|---|---|---|
| Information Security Policy | Overall security direction, scope, roles, management commitment | Required by ISO 27001 (Clause 5.2); foundation for all other policies |
| Acceptable Use Policy | Permitted and prohibited use of company IT resources | Sets behavioural expectations; enables enforcement |
| Access Control Policy | Who can access what; principle of least privilege; authentication requirements | Prevents unauthorised access; core audit control |
| Data Classification Policy | How to classify and handle information by sensitivity | Enables appropriate protection for different data types |
| Incident Response Policy | How to detect, report, respond to, and learn from security incidents | Required by GDPR, NIS2, DORA, ISO 27001; critical operational need |
| Data Protection / Privacy Policy | How personal data is collected, used, protected, and managed under GDPR | GDPR compliance foundation; customer and employee trust |
| Risk Management Policy | How information security risks are identified, assessed, and treated | Required by ISO 27001 (Clause 6.1); NIS2 Art. 21 |
| Backup and Recovery Policy | Backup frequency, testing, offsite storage, recovery procedures | NIS2, DORA requirement; protection against data loss and ransomware |
| Vendor/Third-Party Risk Policy | How vendors are assessed, managed, and monitored | GDPR Art. 28; NIS2 Art. 21(2)(d); DORA Arts. 28–30 |
Tier 2: Important Policies (Build Next)
Build these once your Tier 1 policies are in place and approved.
| Policy | What It Covers |
|---|---|
| Password/Authentication Policy | Password complexity, MFA requirements, credential management |
| Encryption Policy | When and how data must be encrypted (at rest, in transit) |
| Network Security Policy | Firewall rules, network segmentation, VPN, wireless security |
| Change Management Policy | How changes to systems and applications are approved and documented |
| Vulnerability Management Policy | Scanning frequency, patching timelines, risk-based prioritisation |
| Business Continuity Policy | Business continuity planning, testing, and maintenance requirements |
| Physical Security Policy | Physical access controls, visitor management, environmental controls |
| Security Awareness Training Policy | Training requirements, frequency, topics, metrics |
| Logging and Monitoring Policy | What is logged, how long logs are retained, who reviews them |
| Mobile Device / BYOD Policy | Use of personal devices for work; mobile device management |
| Remote Working Policy | Security requirements for working outside the office |
| Data Retention and Disposal Policy | How long data is kept; how it's securely destroyed |
Tier 3: Advanced Policies (Build as Needed)
| Policy | When You Need It |
|---|---|
| Secure Development Policy | If you develop software (internal or customer-facing) |
| Cloud Security Policy | If you use cloud services extensively (most organisations do) |
| Cryptographic Key Management Policy | If you manage encryption keys (beyond using vendor-managed encryption) |
| Clean Desk / Clear Screen Policy | If you handle sensitive documents in office environments |
Policy Mapping to Frameworks
| Policy | ISO 27001 | SOC 2 | NIS2 | DORA | GDPR |
|---|---|---|---|---|---|
| Information Security Policy | Clause 5.2, A.5.1 | CC1.1 | Art. 21 | Art. 6 | — |
| Access Control | A.5.15–A.5.18 | CC6.1–CC6.8 | Art. 21(2)(i) | Art. 9 | Art. 32 |
| Incident Response | A.5.24–A.5.28 | CC7.3–CC7.5 | Art. 23 | Art. 17 | Arts. 33–34 |
| Vendor Risk | A.5.19–A.5.23 | CC9.2 | Art. 21(2)(d) | Arts. 28–30 | Art. 28 |
| Business Continuity | A.5.29–A.5.30 | A1.1–A1.3 | Art. 21(2)(c) | Arts. 11–13 | — |
| Encryption | A.8.24 | CC6.1, CC6.7 | Art. 21(2)(h) | Art. 9 | Art. 32 |
| Risk Management | Clause 6.1 | CC3.1–CC3.4 | Art. 21 | Art. 6 | — |
| Training | A.6.3 | CC1.4 | Art. 21(2)(g) | Art. 13 | — |
How to Write an Effective Security Policy
Writing Principles
| Principle | Explanation | Bad Example | Good Example |
|---|---|---|---|
| Be specific | Vague policies are unenforceable | "Use strong passwords" | "Passwords must be at least 14 characters including uppercase, lowercase, numbers, and symbols" |
| Be concise | Policies should be as short as possible while covering the scope | 30-page information security policy | 3–5 page policy with references to supporting standards and procedures |
| Use plain language | Everyone in scope must understand the policy | "Utilise multi-factor authentication mechanisms across all ingress points" | "Use MFA (e.g., authenticator app) when logging in to all company systems" |
| Be enforceable | Every requirement must be verifiable | "Be careful with sensitive data" | "Sensitive data must not be stored on personal devices or shared via unapproved channels" |
| Be realistic | Requirements must be achievable | "All emails must be encrypted" | "Emails containing personal or confidential data must be encrypted or sent via the secure file-sharing platform" |
| Assign responsibility | Every requirement must have an owner | "Systems must be patched" | "The IT team must apply critical patches within 72 hours of release" |
Policy Template Structure
Every policy should follow a consistent structure:
| Section | Content |
|---|---|
| 1. Document Control | Policy ID, version, approval date, next review date, owner, classification |
| 2. Purpose | Why the policy exists (1–2 sentences) |
| 3. Scope | Who and what the policy applies to |
| 4. Policy Statements | The actual requirements (the core of the document) |
| 5. Roles and Responsibilities | Who is responsible for what |
| 6. Compliance and Enforcement | Consequences of non-compliance |
| 7. Exceptions | Process for requesting policy exceptions |
| 8. Related Documents | References to related policies, standards, procedures |
| 9. Definitions | Key terms used in the policy |
| 10. Revision History | Log of changes |
Information Security Policy Template
Document Control
| Field | Value |
|---|---|
| Policy ID | ISP-001 |
| Title | Information Security Policy |
| Version | 1.0 |
| Owner | Chief Information Security Officer |
| Approved by | [CEO / Board / Management Committee] |
| Approval date | [Date] |
| Next review date | [Date + 12 months] |
| Classification | Internal |
Purpose
This policy establishes the organisation's commitment to information security and provides the framework within which all information security activities are governed.
Scope
This policy applies to all employees, contractors, temporary staff, and third parties who access the organisation's information systems, data, or facilities.
Policy Statements (Key Areas)
| Area | Policy Statement |
|---|---|
| Management commitment | Senior management is committed to protecting the organisation's information assets and supporting the information security management system |
| Risk-based approach | Information security controls shall be implemented based on a formal risk assessment process |
| Compliance | The organisation shall comply with all applicable laws, regulations, contractual obligations, and industry standards |
| Classification | All information assets shall be classified and handled according to their sensitivity |
| Access control | Access to information and systems shall be granted on a need-to-know basis following the principle of least privilege |
| Incident management | All security incidents shall be reported, investigated, and resolved promptly |
| Awareness | All staff shall receive appropriate information security awareness training |
| Third parties | Third parties with access to the organisation's information must comply with this policy and applicable security requirements |
| Continuous improvement | The information security programme shall be regularly reviewed and improved |
Acceptable Use Policy Template
Key Sections
| Topic | Policy Statement |
|---|---|
| General use | Company IT resources are provided for business use; limited personal use is permitted provided it does not interfere with work or violate this policy |
| Company email must not be used for sending unsolicited bulk messages, sharing confidential information with unauthorised recipients, or any illegal activity | |
| Internet | Internet access may be monitored; accessing illegal, offensive, or malicious content is prohibited |
| Software | Only authorised software may be installed on company devices; software licences must be respected |
| Data handling | Confidential and personal data must be handled according to the Data Classification Policy and Data Protection Policy |
| Personal devices | Personal devices used for work must comply with the Mobile Device / BYOD Policy |
| Social media | Company information must not be shared on social media without authorisation |
| Reporting | Users must report any suspected security incidents, policy violations, or suspicious activity |
Access Control Policy Template
Key Sections
| Topic | Policy Statement |
|---|---|
| Least privilege | Access shall be granted only to the extent necessary for the user's role and responsibilities |
| Account management | User accounts must be approved by the employee's manager; accounts must be disabled within 24 hours of departure |
| Authentication | All users must authenticate using unique credentials; shared accounts are prohibited except where technically unavoidable (documented and approved) |
| MFA | Multi-factor authentication is required for all remote access, administrative access, and access to systems processing sensitive data |
| Password requirements | Passwords must meet minimum complexity requirements as defined in the Password Standard |
| Privileged access | Administrative and privileged accounts must be individually assigned, logged, and reviewed quarterly |
| Access reviews | User access rights must be reviewed at least quarterly for critical systems and annually for all systems |
| Third-party access | Third-party access requires approval, is limited to the minimum necessary, and is revoked when no longer needed |
| Separation of duties | Critical functions must be segregated to prevent any single individual from having end-to-end control |
Policy Approval and Communication
Approval Process
| Step | Activity | Responsible |
|---|---|---|
| 1 | Draft policy | Policy author (CISO, DPO, or designated owner) |
| 2 | Peer review | Security team, legal, affected stakeholders |
| 3 | Management review | Senior management or security committee |
| 4 | Formal approval | CEO, CISO, or designated approver (signed and dated) |
| 5 | Communicate to all in scope | HR / Communications / IT (via intranet, email, training) |
| 6 | Obtain acknowledgement | Staff acknowledge receipt and understanding (electronic or written) |
Communication Methods
| Method | Use For | Advantage |
|---|---|---|
| Intranet / wiki | Publishing all policies for reference | Always accessible; version controlled |
| Email announcement | Notifying staff of new or updated policies | Direct reach; creates a record |
| Training session | Explaining complex or high-impact policies | Interactive; allows questions |
| Onboarding | Introducing policies to new joiners | Sets expectations from day one |
| Annual acknowledgement | Confirming staff awareness of key policies | Creates compliance evidence |
Policy Review and Maintenance
| Activity | Frequency | Who |
|---|---|---|
| Scheduled review | Annually (every policy) | Policy owner |
| Trigger-based review | When regulations change, incidents occur, or business changes | Policy owner + CISO |
| Version control | Every change documented | Policy owner |
| Compliance check | Annually | Internal audit or CISO |
| Staff acknowledgement | Annually or at policy update | All staff in scope |
Review Checklist
| # | Check | Pass/Fail |
|---|---|---|
| 1 | Policy reflects current regulations and standards | |
| 2 | Scope still appropriate (covers all relevant staff, systems, processes) | |
| 3 | Policy statements are still realistic and enforceable | |
| 4 | Roles and responsibilities are still accurate | |
| 5 | No conflicts with other policies | |
| 6 | Exceptions register reviewed and still valid | |
| 7 | Policy communicated to all in scope |
Common Policy Mistakes
| # | Mistake | Consequence | Prevention |
|---|---|---|---|
| 1 | Copying templates without customisation | Policy doesn't reflect your organisation; auditors see through it immediately | Customise every policy to your context, systems, and risks |
| 2 | Policies too long and complex | Nobody reads them; non-compliance through ignorance | Keep policies concise; put details in standards and procedures |
| 3 | No management approval | Policy lacks authority; enforcement is undermined | Require formal sign-off from senior management |
| 4 | Never communicated | Staff don't know the policies exist | Communicate at onboarding and annually; publish on intranet |
| 5 | Never reviewed | Policies become outdated and irrelevant | Annual review cycle with assigned owners |
| 6 | No enforcement mechanism | Policies are ignored without consequence | Include compliance and enforcement section; connect to HR disciplinary process |
| 7 | Inconsistent terminology | Confusion about what terms mean | Create a definitions section; use consistent language across all policies |
| 8 | Missing exception process | People bypass policies without governance | Define a formal exception request and approval process |
| 9 | Too many policies at once | Quality suffers; staff overwhelmed | Prioritise by tiers; roll out gradually |
| 10 | No version control | Can't tell which version is current; audit evidence compromised | Use document control headers; maintain a master policy register |
Frequently Asked Questions
How many policies do I need for ISO 27001?
ISO 27001 requires a minimum of: an Information Security Policy (Clause 5.2), a risk assessment methodology (Clause 6.1.2), a risk treatment plan (Clause 6.1.3), a Statement of Applicability, and supporting policies for applicable Annex A controls. In practice, this translates to 15–25 policies for most organisations. The exact number depends on your scope and which Annex A controls are applicable.
Can I combine multiple policies into one document?
Yes — for smaller organisations, combining related policies (e.g., access control + password + MFA in one "Access Management Policy") is practical and acceptable for auditors. The key is that all required topics are covered, documented, and communicated. Avoid creating a single massive "security policy" document that covers everything — it becomes unmanageable.
Do policies need to be signed by every employee?
Policies should be acknowledged by every employee in scope — this can be an electronic acknowledgement (clicking "I have read and understood") rather than a physical signature. Annual re-acknowledgement of key policies (Information Security, Acceptable Use, Data Protection) is good practice and provides audit evidence.
How do I handle policy exceptions?
Establish a formal exception process: the requester documents the exception needed and the business justification; the policy owner and risk team assess the risk; a designated authority approves or rejects the exception; approved exceptions have an expiry date and are reviewed regularly. Document all exceptions in an exceptions register.
Should policies be public or internal?
Most information security policies are internal documents — they contain details about your security controls that should not be publicly shared. Exceptions: your privacy policy (required to be public under GDPR), and sometimes a high-level security overview document for customers. For SOC 2 and ISO 27001 audits, policies are shared with the auditor under NDA.
How long should a policy be?
A good policy is 2–5 pages for the core policy statements, plus any appendices. The Information Security Policy (top-level) can be 3–5 pages. Specific policies (Access Control, Incident Response) can be 3–8 pages. If a policy exceeds 10 pages, consider whether the detailed procedures should be in a separate procedure document referenced by the policy.
What's the difference between a policy and a procedure?
A policy states what must be done and why (management intent). A procedure states how to do it, step by step (operational detail). Example: the Access Control Policy states "User access must be reviewed quarterly." The Access Review Procedure states "1. Export user list from Active Directory. 2. Send to each department head. 3. Department head confirms or revokes each account..."
How do I ensure policies are actually followed?
Policies require four reinforcing mechanisms: (1) Communication — staff must know the policy exists, (2) Training — staff must understand what it requires, (3) Monitoring — compliance must be checked (audits, access reviews, log analysis), (4) Enforcement — non-compliance must have consequences. Without all four, policies become aspirational statements.
Related Resources
- ISO 27001 Implementation Guide — Full ISO 27001 implementation guide; policies are a core component
- SOC 2 vs ISO 27001 Guide — Understand policy requirements for both frameworks
- Virtual CISO Guide — How a virtual CISO develops and manages your policy library
- Incident Response Plan Guide — Detailed guide for the Incident Response Policy
- Vendor Risk Assessment Guide — Detailed guide for the Vendor Risk Management Policy
Related Articles
- ISO 27001 Certification: The Complete Implementation Guide — Full ISMS implementation from gap analysis to certification
- What Is NIS2? Complete Guide to EU Cybersecurity Compliance — NIS2 directive scope, requirements, and compliance roadmap
- Incident Response Plan Template & Guide — Building a cyber incident response plan with templates
Conclusion
Your information security policy library is the documented foundation of your security programme. It's what auditors check first, what regulators ask for, and what gives your security controls the authority to be enforced. The key is to build policies that are real — not copied templates, but documents that reflect your actual organisation, your actual risks, and your actual way of working.
Start with the 9 Tier 1 policies. Get them approved and communicated. Then build out. Your security programme will be stronger for it.
Need help building your policy library? Vision Compliance develops customised information security policies aligned to ISO 27001, SOC 2, NIS2, GDPR, and DORA. We don't copy templates — we write policies that reflect your organisation and pass audits. Schedule a free consultation →
Sources: ISO/IEC 27001:2022, ISO/IEC 27002:2022, AICPA Trust Services Criteria, NIS2 Directive (EU 2022/2555), DORA (EU 2022/2554), NIST SP 800-53 Rev. 5
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.