An information security policy is a foundational document of your ISO 27001 Information Security Management System (ISMS), or any serious approach to security in a business. It lays out your stall and tells everyone what the organisation’s expectations are regarding security, pointing to sub-policies where necessary. It’s the first thing most auditors will ask to see, and it’s the document that sets the tone for everything else.
Getting it right isn’t complicated (though I have seen people make it so) — but there are specific requirements it must meet to satisfy ISO 27001, and common mistakes that can lead auditors to raise observations.
What Is the Information Security Policy?
The information security policy is a high-level document that expresses your organisation’s commitment to information security and defines the overall approach. It’s not a technical manual or a list of rules — I’d always recommend that those go in separate supporting policies and procedures.
Think of it as the why and the what of your ISMS. It says: “Our organisation takes information security seriously, this is why, and this is the framework within which we operate.”
It’s required by ISO 27001 Control 5.1 (Policies for information security) and referenced throughout the standard; as a result, I don’t suggest publishing it to staff until you’ve completed your Statement of Applicability and considered any necessary adjustments. Otherwise, you’ll end up constantly telling people to check it for your updates.
What Must the Information Security Policy Contain?
ISO 27001 specifies what the policy must include. Here’s what the standard requires:
1. A clear statement of commitment
The policy must state that the organisation is committed to information security.
It sounds obvious, but auditors look for an explicit commitment statement — not just implied support. This is also where senior leadership signs off: the policy should be authorised (ideally signed) by the most senior relevant person in the organisation — the CEO, MD, or equivalent. Sometimes a supporting statement can help.
2. Alignment with the organisation’s purpose
The policy should reflect your organisation’s specific context — what you do, what information you handle, and why security matters for your particular business. A generic policy that could apply to any organisation in any sector is a yellow flag for auditors.
So, when you take an AI template (ergh…) or a template form my toolkit (of which the Information Security Policy is one of the free templates), you need to ensure it is adjusted appropriatly for your business, and not blindly put in.
3. A framework for setting information security objectives
The policy needs to provide the framework within which your information security objectives are set. It doesn’t need to list the objectives themselves (those usually live in a separate document or in your management review outputs), but it should make clear that objectives will be established, reviewed, and pursued.
4. A commitment to satisfying applicable requirements
This includes legal and regulatory requirements (GDPR, sector-specific regulations), contractual obligations, and the requirements of the ISO 27001 standard itself. The policy should commit to understanding and meeting these.
5. A commitment to continual improvement
The policy must commit to continually improving the ISMS. This is one of the core principles of the standard and needs to be explicitly stated.
What the Policy Doesn’t Need to Include
This is where many organisations go wrong. They make the information security policy far too long by including things that should be in separate supporting documents.
The top-level information security policy (in my opinion) should not include:
- Detailed password rules (that go in a password policy)
- Specific procedures for handling incidents (that go in an incident response procedure)
- Technical controls and system configurations
- Long lists of dos and don’ts for staff
Keep the top-level policy at a high level — typically one to three pages is the right length.
Note: You cannot get compliance if people don’t understand what they are reading or cannot be bothered because it reads like a phonebook (remember them?). So make sure any policy you draft is easy to read and understand. I’ve seen huge Information Security Policies that read like legal jargon and at 25 pages long. Something like that is helping nobody except the author’s self-importance.
Supporting Policies vs. The Top-Level Policy
ISO 27001 actually refers to “policies for information security” (plural) in Control 5.1. This recognises that most organisations will have a suite of policies, not just one.
A typical policy structure looks like this:
Top-level information security policy — the overarching commitment and framework
Supporting policies:
- Acceptable use policy
- Password and authentication policy
- Remote working policy
- Access control policy
- Data classification and handling policy
- Clear desk and clear screen policy
- Physical security policy
- Supplier security policy
- Incident response policy
- Data retention and disposal policy
- BYOD policy
Each supporting policy deals with a specific topic in more detail. They’re shorter, more specific, and easier to keep up to date.
A Suggested Structure for Your Information Security Policy
Here’s a structure that works well in practice and satisfies auditors — based on my own policy used by organisations certified to ISO 27001:2022:
Purpose of This Document
Why does this policy exist, and what is it trying to achieve?
This is also where senior management makes its commitment explicit (an ISO 27001 requirement) to setting and reviewing information security objectives, satisfying applicable legal, regulatory, and contractual requirements, and continually improving the ISMS. Keep it concise, but make the commitment unambiguous.
Scope and Applicability
What does this policy cover?
Typically: all organisational and customer information, regardless of format, and all individuals associated with the organisation; employees, contractors, and temporary workers.
If your ISMS has a defined scope boundary, reference the ISMS Scope Document here rather than repeating it. That way, you can adjust the boundary in one place without having to update lots of documents.
Context of Information Security
A brief pointer to where the full context of your ISMS is documented, including the internal and external factors, interested parties, and scope statement. This section keeps the policy concise while signposting auditors to the right supporting document.
Roles & Responsibilities
Who is accountable for what?
A practical structure assigns responsibility across four levels: a governing body or Information Security Group (who approve and oversee the policy), an Information Security Manager (who manages the ISMS day to day), System and Information Owners (who manage risks within their areas), Line Managers (who grant access and ensure team compliance), and All Staff (who comply, report breaches, and request exceptions through the correct channel).
Point to a fuller RACI or roles document for the details; you just want the headlines here.
Related ISMS Policies
Rather than trying to cover every control in one document, list the supporting policies that sit beneath this one. A table works well here — policy name in one column, a one-line description in the other.
This is where you reference your Acceptable Use Policy, Access Control Policy, Password Policy, Remote Working Policy, Supplier Security Policy, and so on. Staff should know these exist and that they’re required to comply with them.
Information Security Objectives
This is another ISO 27001 requirement; either the objectives themselves, or a reference to the framework and where the objectives can be found. Create a statement that objectives are set by the governing body, stored in a named location, and reviewed on a defined cycle (quarterly works well).
The actual objectives should really live in a separate document (IMHO) — this section just confirms they exist, who sets them, and where to find them.
Core Security Commitments
This is where your policy can include concise, direct statements covering key operational areas: training and awareness expectations, physical security requirements, how to handle oral communications in public, third-party and supplier obligations, employment screening, access control principles (least privilege, regular audits), password and credential handling, and cryptographic controls.
Each one should be a short paragraph—enough to set expectations, with detailed sub-policies handling the rest.
Information Classifications
Define your classification tiers clearly. Three levels is the standard approach:
- Confidential (restricted to those with a business need, requires encryption in transit and at rest, specific breach protocol),
- Internal (free to share within the organisation, encrypted in transit, not shared externally without permission), and
- Public (approved for external release, no encryption required). Include brief handling guidance for each tier — storage, transfer, disposal, and breach response — so staff know what to do with each type of information in practice.
Breaches of Security
A clear, simple instruction on where to report a security concern.
Separate the reporting path for IT/system breaches from physical breaches, and reference the Incident Response process for significant events and the Data Protection Policy for personal data breaches.
Monitoring and Filtering
A statement that the organisation monitors its IT systems and that logging exists to ensure security and policy adherence. This sets the expectation and provides the basis for monitoring activities.
Risk Assessment and Treatment Methodology
A commitment to the organisation’s risk management approach — identifying threats, assessing likelihood and impact, selecting treatment options, and monitoring effectiveness.
Reference the separate Risk Assessment and Treatment Methodology document rather than detailing the methodology here.
Sign-off Block
Version number, owner, approved by (name and title), date last updated, review frequency, and next review date. This is non-negotiable for audit purposes.
ISO 27001 Full Document Toolkit
Every document your auditor
expects to see.
130 Word & Excel templates, ready to edit. Policies, risk register, Statement of Applicability, audit pack, staff communications — all updated for ISO 27001:2022.
130 templates
Instant download
Written by practising consultant
ISO 27001:2022
What Auditors Look For
When an ISO 27001 auditor reviews your information security policy, they’re checking for several things:
Is it genuinely signed off by senior management? Not just “approved” in a document management system — actually reviewed and committed to by the right person. Auditors sometimes ask senior managers whether they’ve read and understood the policy, so make sure they actually have.
Does it reflect your organisation specifically? Generic templates are fine as a starting point, but auditors look for signs that the policy has been thought through for your context. Reference your sector, your key information assets, or your specific regulatory environment.
Is it accessible to staff? The policy needs to be communicated to all relevant people. Auditors will ask how staff access it and may ask whether staff members know it exists.
Is it reviewed regularly? There should be a review date and evidence that previous reviews have happened. A policy with a 2019 review date and no subsequent review is a common audit finding.
Is it at the right level? Too short (a single paragraph) suggests it hasn’t been thought through. Too long (twenty pages of rules) suggests the policy structure is confused.
Common Mistakes to Avoid
Copying a generic template verbatim.
Auditors can often tell. More importantly, it rarely reflects your actual organisation, which means it’s less useful internally and less convincing to an auditor.
Burying the policy where staff can’t find it.
The policy needs to be communicated. “It’s on the intranet” is fine as long as staff actually know it’s there and can access it.
Forgetting to update it.
A policy with an annual review date needs to actually be reviewed annually. Set a calendar reminder.
Not getting sign-off from the right person.
The MD or CEO needs to be the signatory, not the IT manager. Information security is a business matter, not just a technical one.
Making it too long.
Keep it high-level. The details go in the supporting policies.
Getting Started
The fastest way to create an information security policy that passes audit is to adapt a proven template rather than start from scratch. The ISO 27001 toolkit includes a ready-to-edit information security policy — and all the supporting policies you’ll need — aligned to ISO/IEC 27001:2022.
You can also read more about the mandatory documents that the standard requires, to understand how the information security policy fits into the broader document structure.
ISO 27001 Full Document Toolkit
Every document your auditor
expects to see.
130 Word & Excel templates, ready to edit. Policies, risk register, Statement of Applicability, audit pack, staff communications — all updated for ISO 27001:2022.
130 templates
Instant download
Written by practising consultant
ISO 27001:2022
FAQs
How long should an information security policy be?
For most small and medium-sized organisations, one to three pages is the right length. The top-level policy sets the commitment and framework — the detail belongs in your supporting policies. An overly long top-level policy is often a sign that the document structure hasn’t been thought through clearly, and auditors will notice.
Does the information security policy need to be signed by the CEO?
It should be signed or explicitly approved by the most senior relevant person — typically the CEO, MD, or equivalent. ISO 27001 requires visible leadership commitment to information security, and an auditor may ask your senior management whether they’ve read and understood the policy. Having the right signatory matters, but so does making sure they’ve genuinely engaged with it.
How often does an information security policy need to be reviewed?
At least annually, and whenever there are significant changes to the organisation, its risk profile, or the regulatory environment. The policy itself should state the review frequency and next review date. A policy with an outdated review date — and no evidence of subsequent reviews — is one of the more common findings in certification audits.
What’s the difference between the information security policy and supporting policies like the password policy or acceptable use policy?
The top-level information security policy sets the overarching commitment, framework, and governance structure. Supporting policies — such as your password policy, acceptable use policy, remote working policy, and supplier security policy — each deal with a specific topic in more detail. Think of the top-level policy as the “why and what” of your ISMS, and the supporting policies as the “how” for each subject area. ISO 27001 Control 5.1 actually refers to “policies for information security” in the plural, recognising that most organisations will have a suite of documents rather than a single policy trying to cover everything.
Can we use a template for our information security policy?
Yes — and it’s a sensible starting point. The important thing is that you adapt it to reflect your organisation specifically: your scope, your key information assets, your regulatory context, and your actual roles and responsibilities. A generic template copied verbatim is a yellow flag for auditors, not because templates are wrong, but because it suggests the policy hasn’t been genuinely considered for your context.
