This blog explains how an ISO 27001 information security policy helps organizations protect their information and pass certification audits. It walks through what ISO 27001 requires, what auditors look for, and practical steps to build and maintain a policy you can prove is working.
Key Takeaways
✅ ISO 27001 requires a written information security policy, approved by top management, that includes your security objectives and commits to meeting requirements and improving over time.
✅ Auditors look for proof, not just a document: management approval, regular reviews, and evidence that employees have seen and understood the policy.
✅ Keep the policy short and high-level, and use separate topic-specific policies for details, so it stays accurate, current, and easy to audit.
Who Should Read This?
This guide is ideal for business owners, IT leaders, and compliance teams trying to earn or keep ISO 27001 certification. It’s especially useful if you’re starting from scratch, relying on a generic template, or unsure what auditors expect to see.
An ISO 27001 information security policy is the top-level document that sets management’s direction for protecting information within an information security management system (ISMS). Clause 5.2 of ISO/IEC 27001:2022 requires it, and it is usually the first document an auditor asks to see. It establishes management’s expectations, defines security responsibilities, and provides guidance for how risks should be managed across the business.
For organizations pursuing ISO 27001 certification, this document often serves as the foundation for governance, compliance, and audit activities. It helps demonstrate leadership commitment, supports risk management efforts, and creates a framework for implementing security controls. Just as importantly, it provides employees, contractors, and external partners with a clear understanding of their role in protecting sensitive information.
Whether your company is building a security program from the ground up or strengthening existing documentation, a well-developed policy can help support compliance objectives while improving consistency across security policies and procedures.
What Is an ISO 27001 Information Security Policy?
An information security policy is a high-level document that defines how a company protects information and manages security risks. Rather than providing detailed technical instructions, it establishes the overall direction for security activities and communicates management's expectations.
This document serves as the foundation for a broader collection of policies and procedures that address specific topics such as access control, password management, data protection, mobile devices, business continuity, backup processes, and disaster recovery. While each supporting document focuses on a particular area, the policy provides the governance structure that connects them.
A strong policy should align with business objectives, legal obligations, contractual commitments, and operational requirements. It should also reflect the company's risk environment and provide guidance for maintaining the confidentiality, integrity, and availability of information.
Because security requirements affect nearly every department, the policy should not be viewed solely as an IT document. It is a business document that helps define responsibilities, establish accountability, and communicate how information should be protected throughout the organization.
ISO 27001 Information Security Policy Requirements (Clause 5.2)
ISO 27001 doesn’t just recommend a security policy; it requires one. Clause 5.2 states that top management must establish an information security policy, which means it can’t simply be handed off to IT. The clause sets out what the policy must contain and how it must be handled:
Requirement
What it means in practice
Appropriate to the organization's purpose
Reflects your business, size, industry, and risk environment, not a generic template with the name swapped out.
Includes security objectives, or a framework for setting them
Either states objectives directly or explains how they're set and reviewed. This connects to the objectives planning in clause 6.2.
Commits to meeting applicable requirements
Covers legal, regulatory, and contractual obligations related to information security.
Commits to continual improvement
Commits to improving the ISMS over time. Auditors often check that this wording is present.
Documented
Maintained as controlled documented information, with versioning, approval, and ownership (clause 7.5).
Communicated within the organization
Employees and relevant contractors know it exists, where to find it, and what it means for them.
Available to interested parties, as appropriate
Customers, partners, regulators, and auditors can access it where relevant. Many companies publish a summary version rather than the full internal document.
Annex A 5.1: Policies for Information Security and Topic-Specific Policies
Clause 5.2 requires the policy itself. Annex A control 5.1 addresses how the policy set is governed. It expects an information security policy and topic-specific policies to be defined, approved by management, published, communicated to and acknowledged by relevant personnel and interested parties, and reviewed at planned intervals and when significant changes occur.
The two work together as a hierarchy:
Information security policy (clause 5.2): the high-level document covering direction, commitments, and responsibilities.
Topic-specific policies (Annex A 5.1): more detailed policies for individual areas such as access control (A 5.15), acceptable use (A 5.10), backup (A 8.13), and data retention (see our guide to an ISO 27001 data retention policy).
Procedures and standards: the step-by-step instructions that implement them.
Keep the top-level policy short and strategic, and put technical detail in the topic-specific documents, where it can change without reopening the whole policy.
How the Policy Fits Into the ISMS and Statement of Applicability
The policy is the starting point of your ISMS, the system of policies, processes, and controls you use to manage information security. It sets direction, and the rest of the ISMS carries it out: the scope (clause 4.3), risk assessment and treatment (6.1), objectives (6.2), documented information (7.5), internal audits (9.2), management review (9.3), and improvement (10).
The policy also needs to be consistent with your Statement of Applicability (SoA). Clause 6.1.3 requires the SoA to list the Annex A controls you’ve determined are necessary, whether each is implemented, and why any control is included or excluded. Control 5.1 is almost always applicable, so your SoA should reference the policy and the topic-specific policies by name and version. If the policy commits to something the SoA or scope contradicts, an auditor will notice.
What ISO 27001 Auditors Expect in Your Policy
Auditors evaluate more than whether a document exists.
Expect them to look for:
Management approval: named top management, a date, and a version number. A policy approved by someone who has since left, or never formally approved, is a common finding.
A defined review cadence: the standard requires review at planned intervals and after significant change, and annual review is the common practice. Evidence includes version history and management review records.
Evidence of communication: onboarding acknowledgments, training records, intranet publication, and signed acceptance by staff and relevant contractors.
Availability to interested parties: a way for customers or partners to see the policy or a summary of it.
Consistency with practice: auditors interview staff and compare what the policy says to what people actually do.
Measurable objectives: objectives that are tracked, not just stated.
Alignment across documents: the policy, scope, risk treatment plan, and SoA should tell the same story.
Common nonconformities include missing continual improvement language, an out-of-date version, no proof the policy reached contractors, and objectives that exist on paper but are never measured.
What Changed in ISO 27001:2022
ISO/IEC 27001:2022 replaced the 2013 edition and reorganized Annex A from 114 controls to 93, grouped into four themes: organizational, people, physical, and technological.
It added 11 new controls and merged many existing ones. For policies specifically, the old A.5.1.1 (policies) and A.5.1.2 (review of policies) were combined into the single control 5.1.
The transition period for certified organizations ended on October 31, 2025, so certificates must now be to the 2022 version. In practice, check that your policy and supporting documents don’t cite 2013 control numbers (such as A.5.1.1 or A.12.3.1). Auditors treat outdated references as a sign the documentation hasn’t been maintained. Amendment 1:2024 also added a requirement to consider climate change in clauses 4.1 and 4.2, which can be reflected in how you describe your context.
Why Your ISO 27001 Certification Depends on the Policy
ISO 27001 treats the information security policy as a mandatory control point, not paperwork. Without a clearly documented policy, security efforts often become inconsistent. Different teams may interpret requirements differently, apply controls unevenly, or make decisions that increase risk without fully understanding the consequences.
A well-designed policy creates a common understanding of security expectations across the organization. It establishes governance principles, defines responsibilities, and supports decision-making when new technologies, business processes, or external relationships introduce additional risk.
It also shapes the certification audit itself. The policy is typically one of the first documents reviewed, and it sets the context for how auditors judge everything else in your ISMS. A current, approved policy shows that top management has set formal expectations for protecting information assets.
As organizations adopt cloud services, support remote work, expand vendor relationships, and explore AI technologies, documented requirements become more important. The policy gives you a framework for evaluating new risks while keeping security aligned with business objectives.
What to Include in Your ISO 27001 Information Security Policy
Beyond the mandatory clause 5.2 elements, effective policies generally address several common areas.
Scope. Define what information, systems, personnel, and business functions are covered. A clearly defined scope eliminates confusion and ensures expectations are applied consistently, and it should match the scope of your ISMS.
Risk management. Organizations need a process for identifying threats, evaluating vulnerabilities, performing risk assessments, and implementing risk treatment activities. Security controls should be selected based on identified risks rather than assumptions or generic best practices.
Access control. Employees should only have access to the information and systems necessary for their responsibilities. The policy should set expectations for user access, account management, authentication, and the protection of credentials such as passwords.
Data protection. Sensitive information may exist in databases, cloud environments, email systems, endpoints, mobile devices, and third-party applications. The policy should set expectations for protecting information throughout its lifecycle.
Vendor management. Third-party providers often have access to business systems, customer information, or sensitive data. Establishing security requirements for vendors, as described in our guide to a third-party risk management policy, reduces risk and improves accountability.
Business continuity and recovery. Security programs should support the organization’s ability to continue operations during disruptions. This often includes requirements for backup processes, disaster recovery capabilities, incident response procedures, and recovery objectives.
Enforcement and accountability. Employees should understand their responsibilities and know how potential violations should be reported and addressed.
How to Keep Your Policy Audit-Ready Between Reviews
Certification is not the finish line. Surveillance audits and recertification expect the policy to stay current, so build maintenance into your ISMS calendar.
Creating a policy is only the beginning, and to remain effective, documentation should evolve alongside the business and its risk environment.
Keep leadership involved. Senior management approval shows that security is a business priority and not simply a technical initiative. Leadership support also improves adoption across departments and strengthens accountability.
Review regularly. Security threats, technologies, regulatory requirements, and business operations change over time. Policies that are never updated may no longer reflect current practices or adequately address emerging risks.
Communicate clearly. Employees cannot follow requirements they do not understand. Reinforce expectations through awareness programs, training initiatives, and internal communications, and keep records of them.
Match documentation to practice. Auditors compare written requirements against real-world practices. When policies don’t reflect how systems are managed or how employees work, compliance gaps emerge.
Align with recognized frameworks. Many companies benefit from aligning security requirements with recognized frameworks such as NIST, industry regulations, and compliance programs like SOC 2. Mapping one policy to several frameworks can strengthen governance and reduce duplicated effort.
Common ISO 27001 Policy Mistakes That Lead to Audit Findings
Treating the policy as a one-time project. Documentation written for the certification audit and then ignored quickly loses value. Annex A 5.1 expects review at planned intervals and after significant change, and an unreviewed policy is a common finding at surveillance audits.
Leaving out required commitments. Policies that omit the continual improvement commitment or the commitment to meet applicable requirements fall short of clause 5.2, however polished the rest of the document is.
Making the policy too technical. The top-level policy should provide direction, not configuration instructions. Technical detail belongs in topic-specific policies and procedures, where it can be updated without reopening the whole document.
Unclear ownership. Clause 5.3 expects top management to assign and communicate security roles and authorities. Without named people responsible for approval, maintenance, review, and enforcement, policies become outdated or inconsistent.
Weak communication. Clauses 7.3 (awareness) and 7.4 (communication) apply here. Employees may unknowingly violate requirements when they haven’t seen the policy, and auditors will ask for proof that they have.
Using a template without customizing it. A policy that doesn’t match your scope, size, or actual practices is easy for an auditor to spot. This includes references to ISO 27001:2013 control numbers.
ISO 27001 Information Security Policy Template
Developing documentation from scratch can be time-consuming, particularly for organizations preparing for certification or building a formal security program for the first time. This is why many organizations begin with a policy template.
A template provides structure and helps ensure important topics aren’t overlooked. A quality ISO 27001 template includes the clause 5.2 elements (purpose, objectives, commitments, communication), governance and risk management, security responsibilities, data protection, compliance requirements, and management approval. It should also provide a place to record version history, review dates, and approval, which auditors will ask to see.
When evaluating a template, consider whether it addresses your business requirements, security objectives, and compliance obligations. Areas such as third-party relationships, cloud services, mobile devices, access control, business continuity, and incident response may need additional customization.
Most organizations also maintain supporting policies and procedures that expand on the high-level requirements in the policy. Depending on the environment, these may include a backup policy, access control policy, acceptable use policy, vendor management procedures, disaster recovery documentation, and risk treatment processes.
Taking time to customize a template improves audit readiness, strengthens governance, and creates documentation that accurately reflects how information is protected across the organization.
How K2 GRC Helps You Build and Maintain Your ISO 27001 Policy
Writing the policy is the easy part. The harder work is proving it’s approved, communicated, reviewed, and actually followed, which is what auditors test. K2 GRC is a governance, risk, and compliance platform that brings that work into one place instead of spreading it across Word documents, spreadsheets, and email threads.
What auditors expect
How K2 GRC supports it
A policy tied to your scope and assets
The platform lets you map critical assets, including people, vendors, applications, and facilities, so your policy and scope reflect what you actually operate.
Documented commitments and policies
A governance layer for documenting organizational commitments, business requirements, and policies in one place.
Risk-based control selection
Risk management features let you score risks, link them to specific controls, and track treatment, with a FAIR-based approach for quantifying risk in financial terms. See K2 GRC risk management.
Evidence of communication and awareness
A built-in learning management system and phishing simulations assign training based on roles, risk levels, and your defined policies, so staff receive the right content and completion is tracked.
Alignment across frameworks
Compliance tracking across more than 30 frameworks, including ISO 27001, SOC 2, HIPAA, CMMC, and NIST, with gap tracking and audit-readiness reporting. Mapping shared controls once also reduces duplicated work, as we explain in our guide to a common controls framework.
Vendor oversight
Vendor assessment tools combine structured questionnaires with risk scoring and continuous monitoring. Our guide to a third-party risk assessment questionnaire shows how this works in practice.
Ongoing evidence, not a once-a-year scramble
An API-first design with read-only integrations to your business systems, so configuration and evidence can be collected continuously rather than gathered by hand before each audit.
What this means for your ISMS. Because governance, risk, compliance, and training share one connected system, a change in one area carries through to the others. Update a policy, and the related controls, risks, and training assignments stay in view. That’s the consistency auditors look for across your policy, risk treatment plan, and Statement of Applicability.
What K2 GRC doesn’t do. K2 GRC prepares you for audits with the data and reports you need, but it doesn’t perform audits itself. You’ll still work with an accredited certification body for ISO 27001 certification.
Conclusion
An ISO 27001 information security policy provides the foundation for an effective security program. It establishes management’s expectations, supports governance activities, communicates security requirements, and helps organizations manage risk more consistently.
Strong documentation goes beyond satisfying audit requirements. It defines responsibilities, supports data protection efforts, guides decision-making, and creates a framework for maintaining security across changing technologies and business environments. The policy only holds its value if it stays approved, communicated, and reviewed, so the systems you use to manage it matter as much as the wording.
For organizations pursuing ISO 27001 certification or strengthening existing compliance initiatives, a well-developed policy remains one of the most valuable tools for protecting sensitive information. Pairing it with a platform like K2 GRC can make that policy easier to maintain and easier to prove at audit time.
❓ Frequently Asked Questions About ISO 27001 Information Security Policy
Is an ISO 27001 information security policy required for certification?
Yes. Clause 5.2 of ISO 27001 requires top management to establish an information security policy, so you can't be certified without one. Auditors usually review it early in the audit because it sets the direction for your entire security program.
What should an ISO 27001 information security policy include?
It must fit your organization's purpose and include security objectives or a way to set them. It must also commit to meeting applicable requirements and to continual improvement. The policy has to be documented, shared within the organization, and made available to interested parties where appropriate.
How often should you review your information security policy?
ISO 27001 requires reviews at planned intervals and whenever significant changes occur. Most organizations review the policy at least once a year. Keep records of each review, such as version history and management review notes, because auditors will ask for them.
Who needs to approve an ISO 27001 information security policy?
Top management is responsible for establishing the policy, so a senior leader should approve it. Auditors expect to see the approver's name, the approval date, and a version number on the document.
What's the difference between an information security policy and topic-specific policies?
The ISO 27001 information security policy is a short, high-level document that sets management's direction and commitments. Topic-specific policies cover areas like access control, backups, and acceptable use in more detail. Keeping them separate makes the main policy easier to maintain.
What do ISO 27001 auditors look for in a security policy?
Auditors check for management approval, a regular review schedule, and proof that employees have received the policy. They also compare what the policy says to what your team actually does. A strong ISO 27001 information security policy matches real daily practice, not just the written document.
Can I use a template for my ISO 27001 information security policy?
Yes, a template is a good starting point because it covers the required sections. You still need to customize it to your business, scope, and risks. Auditors can spot a generic policy quickly, so update names, objectives, and control references to match your own ISMS.
Learn how to build an AI risk management policy that addresses governance, risk appetite, AI security risks, regulatory requirements, and ongoing monitoring.
A risk register helps organizations identify, assess, and manage potential risks in one centralized place. Learn the key components of a risk register, how to create and maintain one, and how it supports a more proactive approach to risk management.
