Skip to main content
Policies 6 min read

How to Write an ISO 27001 Information Security Policy

Clause 5.2 requires a top-level information security policy approved by management. Here is exactly what it must say, what it does not need to include, and how to make it audit-proof.

Rounak Maheshwari

Founder, ISO READY 360 · ISO 27001:2022 Practitioner

The information security policy is the foundational document of your ISMS. It sits above all other policies, communicates management's commitment to information security, and sets the direction for everything in your management system. Auditors read it first and refer back to it throughout the audit.

The most common mistake organisations make is confusing this policy with their detailed security policies — acceptable use, access control, password policy, and so on. The information security policy is a high-level strategic document, typically 1–3 pages long. It does not describe how controls work. It says why information security matters to the organisation and commits to a framework for achieving it.

ISO 27001:2022 Clause 5.2 — Mandatory Content

Appropriate to the organisation

The policy must fit your size, sector, and risk profile — not be a generic template left unchanged.

Information security objectives

Must include the information security objectives or provide a framework for setting them (linking to Clause 6.2).

Commitment to satisfy requirements

A statement that the organisation is committed to meeting applicable requirements related to information security.

Commitment to continual improvement

A statement committing to continually improve the ISMS — not just maintain it.

The Mandatory Requirements

Clause 5.2 specifies five things the policy must do. Auditors check these explicitly in Stage 1:

  1. 1

    Be appropriate to the purpose and context of the organisation

    A generic policy that could belong to any company fails this test. The policy must reference your actual business activities, the types of information you handle, and your operating context (regulatory environment, customer requirements, etc.).

  2. 2

    Include information security objectives or provide a framework for setting them

    Either list the objectives directly, or reference that objectives are set separately per Clause 6.2 and reviewed in management review. Many organisations do the latter — the policy says objectives are documented elsewhere, and the separate objectives document is what auditors review.

  3. 3

    Include a commitment to satisfy applicable information security requirements

    This includes legal requirements (GDPR, sector regulation), contractual requirements (customer security obligations), and the requirements of the ISO 27001 standard itself.

  4. 4

    Include a commitment to continual improvement of the ISMS

    A statement explicitly committing to improving the ISMS over time — not just maintaining it. This is a direct ISO 27001 requirement and auditors will note its absence.

  5. 5

    Be available as documented information

    Must be documented, version-controlled, approved by top management, and available to interested parties. "Available to interested parties" typically means it is accessible to staff (intranet), and can be provided to customers or certification bodies on request. Some organisations publish it on their website.

What the Policy Does Not Need to Include

This is as important as knowing what to include. The information security policy should not describe specific controls or procedures. Those belong in separate, more detailed policies. Keeping the top-level policy high-level makes it easier to maintain and less likely to become outdated.

✓ Belongs in this policy

  • — Management commitment statement
  • — Purpose and scope of the ISMS
  • — Reference to security objectives
  • — Commitment to comply with requirements
  • — Commitment to continual improvement
  • — Ownership and accountability structure
  • — Reference to supporting policies
  • — Consequences of non-compliance (high level)

✗ Does not belong here

  • — Password complexity rules
  • — Access control procedures
  • — Incident response steps
  • — Backup frequency requirements
  • — Encryption standards and key lengths
  • — Specific system configurations
  • — Supplier assessment questionnaires
  • — Data classification categories

How to Structure the Policy

There is no prescribed structure, but most effective policies follow this pattern:

Recommended Policy Structure

1. Purpose and Scope

Why this policy exists, which parts of the organisation it covers, and what types of information it protects.

2. Management Commitment

A statement from the CEO or board confirming their commitment — signed and dated. This is the most audited section.

3. Information Security Objectives

Either the objectives themselves (e.g. zero critical unpatched vulnerabilities, 100% staff training completion) or a reference to where they are documented separately.

4. Roles and Responsibilities

Who owns information security (typically a CISO or Information Security Officer), how it is governed, and what responsibilities all staff have.

5. Policy Framework

A summary of the supporting policies that implement this commitment — acceptable use, access control, incident management, etc.

6. Compliance

Commitments to relevant legal, regulatory, and contractual requirements. Reference to the legal register.

7. Review and Continual Improvement

When the policy is reviewed (typically annually), who is responsible, and the commitment to improving the ISMS.

8. Exceptions

How exceptions to this or supporting policies are requested and approved.

Approval and Communication

Clause 5.2 requires the policy to be approved by top management — this means a named senior leader (CEO, Managing Director, CTO, or Board) signing and dating the document. A countersignature by a middle manager does not satisfy this requirement.

The policy must also be communicated to all staff and relevant interested parties. Evidence of communication — a screenshot of an all-staff email, an intranet page with view counts, or training completion records that include policy acknowledgement — is required as a record.

Auditors frequently ask staff: "Have you seen the information security policy? Do you know what it requires of you?" If frontline staff look blank, this becomes an observation or finding. The policy must be genuinely communicated, not just filed away.

What Auditors Check in Stage 1

Stage 1 audit checklist for information security policy

Is the policy approved by top management with a name, title, and date?
Does it reference the organisation's context — not just generic language?
Does it include or reference measurable information security objectives?
Does it explicitly commit to satisfying applicable requirements?
Does it explicitly commit to continual improvement?
Is it controlled as documented information (version, review date, owner)?
Is there evidence it has been communicated to staff?
Is the policy available to interested parties upon request?

Get a Policy That Passes Audit on the First Try

Our policies are written to satisfy every Clause 5.2 requirement — pre-approved structure, the right commitments, ready for management sign-off. Or book a free call for a review of your current policy draft.