ISO 27001 Clause 5.2: what your security policy must contain

The security questionnaire asks for your information security policy. You send a template with the company name swapped in, and the buyer's reviewer spots it in a minute. Auditors spot it faster. ISO 27001 Clause 5.2 is short, but it is prescriptive, and a policy that skips its content list costs you a finding at Stage 1.

This guide sets out what the clause requires and which two pledges auditors look for. It shows how to keep the document short and shareable, and what gets sampled at Stage 1 and Stage 2. It is written for security leads, compliance owners and founders at UK service providers and SaaS firms preparing for ISO 27001:2022 certification.

What does ISO 27001 Clause 5.2 require in the policy?

ISO 27001 Clause 5.2 requires top management to issue a written information security policy that fits the organisation's purpose. It must set security objectives or a way of setting them, and pledge to meet the obligations that apply and to keep improving the ISMS. Staff must know it, and outside parties can see it where appropriate.

Read the clause as seven checks. Four describe what the policy says, and three describe what you do with it. That is a short checklist, not a mountain.

The four content criteria:

• Fit to purpose. The text names your business, what it protects and why.
• Objectives. Security objectives sit in the policy, or the policy sets the frame for creating them under Clause 6.2.
• Obligations pledge. A written commitment to meet the security obligations that apply to you.
• Improvement pledge. A written commitment to keep improving the ISMS.

The three handling duties:

• Documented. The policy exists as controlled documented information, signed and versioned.
• Communicated internally. Staff meet the policy through onboarding and refreshers, as Clause 7.4 sets out.
• Available to interested parties. Where appropriate, customers and insurers can obtain a version.

Founders often underestimate how much detail this clause fixes. Most of the ISMS can be shaped around your business. The policy's content list is fixed, and auditors tick it off item by item.

The usual failure is template purchase syndrome. A bought policy reads like everyone else's, so it fits no one and fails the fit-to-purpose test. Use a template as scaffolding if it saves time, then rewrite until the document could only be yours.

Which two pledges must the policy contain, and how do UK obligations fit?

The policy must pledge, in words, to meet the security obligations that apply to the organisation and to keep improving the ISMS. Auditors look for both near-verbatim and treat them as pass/fail. For a UK provider, those obligations include UK GDPR duties, where the ICO names an information security policy as an organisational measure.

Tone does not count. A policy that implies the pledges through a general commitment to security still fails the check. Their absence is among the cheapest nonconformities to receive, because nothing needs sampling to prove it.

Write each pledge as one plain sentence, for example:

• Obligations pledge. "We are committed to meeting the information security requirements that apply to us, including legal, regulatory and contractual obligations."
• Improvement pledge. "We are committed to continually improving our information security management system."

For a UK provider, the obligations pledge has real content behind it. UK GDPR expects appropriate organisational measures, and the Information Commissioner's Office guide to data security gives an information security policy as an example of one. The same guide adds that, depending on your size and the data you handle, you may not need a formal policy document or a set of topic policies. What the policy commits to matters more than how many you hold. Customer contracts and any sector rules that bind you belong on the same list.

The pitfall is missing magic words. The pledges are absent because nobody drafted against the checklist, and good security practice elsewhere does not compensate. Before sign-off, search the text for both commitments and confirm each one is stated outright.

How does ISO 27001 Clause 5.2 risk appetite shape the policy?

The policy is where leadership can make its risk appetite explicit. Objectives, or the framework for setting them, should trace back to the context and obligations found under clauses 4.1 and 4.2. That makes the targets measurable rather than vague hopes. A policy written against that context cannot be moved to another company by find-and-replace.

Clause 4.1 gives you the context: the internal and external issues shaping your risk. Clause 4.2 gives you the interested parties and their requirements. The policy turns those two inputs into a stance: what the organisation will protect first, and what loss it will and will not accept.

Three tests show whether an objective is tied to that context:

• Traceable. You can point to the context issue or obligation it answers, such as a customer contract that demands prompt incident notification.
• Measurable. It carries a target and a measure, such as a time limit for patching critical vulnerabilities, rather than a pledge to "be secure".
• Owned. A named role reports it to top management, and Clause 6.2 plans how it will be met.

A policy that sets only a framework still meets the clause. It then states how objectives are set, who proposes them and how often leadership revisits them. That route suits smaller firms that want the policy to stay stable while the targets change each year.

Proportionality applies. A small SaaS company may state three objectives, on availability, customer data confidentiality and supplier assurance. A larger regulated provider will carry more, split by service line. Either way, the auditor asks the same fit question: what in this policy would differ if you were a different company?

How do you move leadership from sign-off to genuine ownership?

Top management must debate, amend and approve the policy rather than countersign a consultant's draft, because the signatory is questioned on it under Clause 5.1. The NCSC Board Toolkit makes the same point: cyber security belongs inside strategy, risk management, compliance and audit procedures, not solely with IT.

The NCSC Cyber Security Toolkit for Boards on embedding cyber governance frames this as integration into organisation-wide governance. A policy drafted in IT and forwarded for signature does the opposite. It leaves security with IT, when the Toolkit makes it the responsibility of the entire board.

Engagement is something you can evidence. Build it into the approval cycle:

• Brief the signatory first. Give the approver a one-page summary of the obligations the policy pledges to meet and the objectives it sets.
• Put it on a leadership agenda. Let directors debate and amend the wording, and let the minutes record the challenge.
• Approve with a date and a version. The approval trail names who approved, when, and which version.
• Rehearse the interview. Ask the signatory why the policy fits the business and what changed at the last review.

The pitfall is sign-and-forget approval. A director countersigns a consultant's draft, and months later cannot say what it commits the company to. Leadership that argued over the wording answers the interview in its own voice, and minutes that record the debate are the evidence.

A policy its signatory cannot discuss is a document, not a commitment.

Where does the Clause 5.2 policy end and Annex A 5.1 begin?

Clause 5.2 governs the headline policy, best kept to a two-to-four-page statement of principles and commitments. Annex A 5.1 governs the topic-specific policies beneath it and the acknowledgement machinery. Keep the what in the headline policy and the how in process documents, so the policy stays stable and safe to share externally.

The split follows who tests what. Clause 5.2 tests the headline document. Annex A 5.1 tests the topic layer beneath it, such as access control, supplier or acceptable use policies. It also tests how those policies are shared and acknowledged. The acknowledgement records you build for one serve the other.

Use this test to decide where a sentence belongs:

• A principle or commitment: keep it in the headline policy.
• Who does what, how often, with which tool: move it to a topic-specific policy or process document.
• Architecture, vendor names and network detail: keep it in controlled technical documentation, out of the policy.

Separating the what from the how keeps the policy stable. It changes rarely, so reviews stay light and approval dates stay current.

The pitfall is procedure creep. Operational detail creeps into the headline policy one incident at a time, until it is too big to maintain or to share. The owner then stops reviewing it, because every review has become a rewrite.

Two to four pages is the discipline. If a section needs a table of tools, it is a process document. Timing helps too. With context and obligations from clauses 4.1 and 4.2 in hand, drafting takes days, not weeks. The rest of the ISMS documentation then cites the policy as its authority.

How do you share the policy with enterprise procurement and insurers?

Prepare an external-safe version before anyone asks. Enterprise procurement teams and insurers ask for the policy during security questionnaires and underwriting. A redacted or NDA-gated copy, or a trust-centre entry, turns the request into a non-event. Because the headline policy holds principles rather than architecture, sharing it exposes nothing sensitive.

Procurement teams and insurers both read the policy as a proxy for governance. A stale approval date or generic language tells them nobody owns security, long before any interview takes place.

Three routes serve the request:

• Redacted copy: the policy minus internal names and any detail you prefer to withhold.
• NDA-gated copy: the complete text, released after the buyer signs.
• Trust-centre entry: a hosted page that answers "send us your policy" without an email thread, and records who looked.

Decide which route applies to which audience, and write it down. Procurement teams usually accept a trust-centre link, while a regulated buyer's third-party review may want the signed PDF. Keep the version history identical across routes, so the approval date a buyer sees matches the one the auditor sees.

Done once, that turns a scramble before every renewal into a link you can send in a minute.

What do auditors sample at Stage 1 and Stage 2, and where do policies fail?

Auditors check the policy text line by line against the clause's content list and test the approval date against the last twelve months. They also ask sampled staff whether they know the policy exists. A missing pledge is an area of concern at Stage 1 and a major nonconformity at Stage 2. Overdue reviews and patchy acknowledgements grade minor.

Expect these questions in the room:

• "Show me where this policy commits you to meeting your obligations and to improving the system."
• "Why does this policy fit your business? What would differ if you were a different company?"
• "Who approved it, when, and what changed at the last review?"
• "How would a new joiner encounter this policy, and how do you know they did?"
• "A client asks for your security policy. What do they receive?"

Stage 1 is the document review before the main assessment, so a missing pledge or a stale date surfaces before anyone is interviewed. Stage 2 tests whether the policy is lived: staff are asked where it lives, and each pass in the review history should show what triggered it.

Grading follows certification-body practice:

• No policy, or missing mandated pledges: an area of concern at Stage 1, a major nonconformity at Stage 2.
• Overdue review, patchy acknowledgement coverage or version-control slips: a minor nonconformity.
• A pattern of minors: can aggregate to a major.

Two failure modes dominate. The first is a review cadence that exists on paper. The policy says "reviewed annually", yet the register shows no review date, no reviewer and no reason for the last change.

A review cadence with no dated evidence is a calendar entry, not a control.

The second is communication assumed rather than tracked. Everyone was emailed the policy at launch, but joiners since then never saw it, and the auditor finds out when a sampled employee shrugs. Contractors count too, because the evidence expected covers distribution records for staff and contractors alike.

Acknowledgement nobody tracked is communication nobody can prove.

How do you automate Clause 5.2 with GRC engineering?

Treat the policy as a governed record: owner, version, approval and review-due date held as data, so currency becomes a query rather than a memory. Wire acknowledgement to the joiner workflow, subscribe review triggers to real events such as incident closure, and serve external copies from a trust centre.

Manual tracking is where Clause 5.2 decays. The policy sits in a shared drive, acknowledgements live in a spreadsheet and the review reminder lives in one person's head. GRC engineering replaces each of those with a record that maintains itself.

Four moves cover the clause:

1. Policy as a governed record. Owner, version, approval date and review-due date are fields, with automated reminders to the owner.
2. Acknowledgement in the joiner workflow. New starters, contractors included, acknowledge on day one, and coverage exports on demand.
3. Event-driven review triggers. Incident closure, regulatory watchlist hits and organisational changes open a review task, and the trigger itself is logged as evidence.
4. Trust-centre sharing. "Send us your policy" costs nothing and leaves a record of who received which version.

The human layer stays where judgement matters: leadership debating the wording, deciding what the objectives should be, and signing. Tooling carries the dates, the reminders and the exports.

At this scale, the auditor's questions about currency, coverage and external sharing are answered by a query, not a search through inboxes.

Frequently asked questions