ISO 27001 Clause 5.2: Security Policy
Your information security policy is the single most important document in your ISMS. It is the first thing auditors ask for, the document leadership signs off on, and the reference point for every security decision in your organization. Getting it right does not require a 50-page document - it requires clarity about what your organization commits to protecting and how.
ISO 27001:2022 Clause 5.2 mandates that top management establish an information security policy. But the standard is specific about what this policy must contain and how it must be maintained. Here is what you actually need.
What Clause 5.2 requires
The standard sets five explicit requirements for your information security policy:
1. Appropriate to the organization’s purpose. The policy must reflect your actual business context - not a generic template downloaded from the internet. A 15-person SaaS company handling customer data has different priorities than a manufacturing firm with OT systems. Your policy should make that clear.
2. Includes information security objectives or a framework for setting them. Either state your security objectives directly in the policy or describe how objectives are established and reviewed. Most organizations do the latter - referencing a separate objectives document that gets updated annually.
3. Includes a commitment to satisfy applicable requirements. This covers legal, regulatory, and contractual obligations. For a European SaaS company, this might mean GDPR, NIS2, and customer DPA commitments. Name the categories - you do not need to list every regulation, but auditors want to see that you have identified what applies.
4. Includes a commitment to continual improvement of the ISMS. A single sentence is enough, but it must be there. This connects your policy to the PDCA cycle that drives your management system forward.
5. Available as documented information. The policy must be documented, communicated within the organization, and available to interested parties as appropriate. This means version-controlled, approved by top management, and accessible to every employee.
What your policy should include
Beyond the mandatory Clause 5.2 elements, a practical information security policy typically covers these sections:
Purpose and scope. Define what the policy covers and who it applies to. Be specific - “all employees, contractors, and third parties who access company information assets” is clearer than “all relevant parties.” Reference your ISMS scope (Clause 4.3) so the boundaries are consistent.
Roles and responsibilities. Name the key roles - who owns the ISMS, who conducts risk assessments, who handles incident response, who approves exceptions. You do not need to name individuals (people change roles), but define the positions. At a minimum: ISMS owner, risk owner, and information security manager or vCISO.
Risk management approach. Briefly describe your approach to risk assessment and treatment. You do not need the full methodology here (that belongs in a separate risk assessment procedure), but the policy should state that you take a risk-based approach and reference the CIA triad - protecting confidentiality, integrity, and availability of information.
Policy compliance and consequences. State that compliance with the policy is mandatory and outline the consequences of non-compliance. This does not need to be punitive language - “violations may result in disciplinary action up to and including termination” is standard and sufficient.
Review cycle. Commit to reviewing the policy at defined intervals. Annual review is the standard minimum, but also specify that reviews happen after significant changes - organizational restructuring, major incidents, or new regulatory requirements.
What the policy is not
One of the most common mistakes is confusing the information security policy with operational procedures. The policy is a strategic document - it states what your organization commits to. Procedures describe how you implement those commitments.
| Information security policy | Procedures and guidelines |
|---|---|
| ”We protect information in transit using encryption” | Encryption standard: TLS 1.2+ for all external connections, AES-256 for data at rest |
| ”Access is granted on a need-to-know basis” | Access control procedure: request form, manager approval, quarterly review process |
| ”We respond to security incidents promptly” | Incident response plan: severity levels, escalation paths, communication templates |
| ”Employees receive security awareness training” | Training program: onboarding within 30 days, annual refresher, phishing simulations quarterly |
Keep your policy at the strategic level. If you find yourself writing step-by-step instructions, that content belongs in a separate procedure document. Your documentation framework should clearly separate policies from procedures, standards, and guidelines.
Connecting 5.2 to the rest of your ISMS
The information security policy does not exist in isolation - it connects to nearly every other clause in the standard.
Clause 5.1 connection. Leadership commitment is the authority behind the policy. Top management must establish and approve it, and their ongoing engagement ensures the policy stays relevant.
Clause 5.3 connection. Roles, responsibilities, and authorities flow directly from the policy. What the policy defines, Clause 5.3 assigns to specific positions in the organization.
Clause 4.1 connection. The policy must be appropriate to the organization’s purpose - which means it should reflect your organizational context. If your context changes significantly, the policy should be reviewed.
Clause 7.3 connection. Awareness requires every employee to know the policy exists and understand their obligations under it. Your training program should cover policy content during onboarding.
Clause 9.3 connection. Management review should assess whether the policy remains suitable. This is where the annual review cycle connects to the broader PDCA improvement cycle.
What auditors actually check
Having reviewed dozens of certification audits, here is what auditors focus on when they examine your information security policy:
Management signature. The policy must be approved by top management. Auditors check for a signature or formal approval record - not just a document with “Approved” written on it. They want evidence that the CEO, managing director, or equivalent has actually reviewed and endorsed the document.
Alignment with business context. They compare your policy against your context of the organization (Clause 4.1). If your context document identifies cloud services as critical but your policy does not mention cloud security, that is a gap.
Communication evidence. It is not enough to have the policy - you need evidence that it was communicated. Auditors look for distribution records, training acknowledgments, or an intranet page with access logs. A policy nobody reads is a nonconformity waiting to happen.
Review history. Auditors check version history and review dates. If your policy was last reviewed 18 months ago, they will raise it. If you claim annual reviews but there is no evidence of a review happening, that is a finding.
Consistency with controls. Your policy statements must match your actual control implementations. If the policy says “all access requires multi-factor authentication” but your Statement of Applicability shows MFA is not yet implemented for certain systems, auditors will flag the inconsistency.
Common mistakes to avoid
Copying a template without customization. Generic templates are fine as a starting point, but auditors can spot an unmodified template immediately. Your policy must reflect your organization’s actual context, risks, and commitments.
Making it too long. A 40-page information security policy signals that policies and procedures have been merged. Aim for 3-8 pages. Everything else should be in supporting procedures and standards.
Forgetting the audience. The policy should be understandable by every employee, not just the security team. Avoid unnecessary jargon. If someone in marketing cannot understand their obligations from reading the policy, it needs simplifying.
Treating it as static. A policy written in 2022 and never updated is a red flag. Your security awareness program should reference the current policy, and your management review (Clause 9.3) should assess whether the policy remains appropriate.
Missing the commitment to continual improvement. This is a surprisingly common omission. Without it, your policy technically fails Clause 5.2. One sentence is enough - “This organization is committed to the continual improvement of the information security management system” - but it must be there.
How 27kay can help
We help organizations develop information security policies that pass audits and actually get used - not documents that sit in a shared drive unopened. Whether you are building your ISMS from scratch or updating an existing policy for the 2022 version, we can help you write a policy that reflects your real business context and meets every Clause 5.2 requirement.
Need help with your information security policy? Let’s talk - we will review what you have and tell you exactly what needs to change.