--- title: "ISO 27001 Clause 5.2: what your security policy must contain" canonical: https://www.grcmana.io/vault/iso-27001/clause-5-2-policy published: 2022-12-09 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "Clause 5.2 Policy" journeyStage: implementation --- # ISO 27001 Clause 5.2: what your security policy must contain ## Key takeaways ISO 27001 Clause 5.2 requires leadership to issue a short, documented security policy that fits the business, carries objectives and pledges to meet obligations and keep improving. Auditors check these items line by line, so the wording, the approval date and the evidence of communication all matter. Keep the policy to principles, and automate the dates, acknowledgements and sharing. - **Content criteria** — The policy must fit the organisation's purpose, contain security objectives or a framework for setting them, and pledge both to meet applicable obligations and to improve the ISMS. - **Handling duties** — The policy must be documented, communicated internally through onboarding and refreshers, and available to interested parties such as customers and insurers where appropriate, ideally as a redacted or NDA-gated copy. - **Length and scope** — Keep the headline policy to two to four pages of principles. Operational detail belongs in topic-specific policies and process documents, which keeps the policy stable and shareable. - **Audit grading** — A missing pledge is an area of concern at the document review and a major nonconformity at the main audit. Overdue reviews and patchy acknowledgements grade minor, aggregating to major. 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](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-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](https://www.ncsc.gov.uk/collection/board-toolkit/principle-b-strategy/embedding-cyber-security-into-your-organisation) 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. | Clause 5.2 element | Evidence an auditor expects | What automation holds | | --- | --- | --- | | Fit to purpose | Policy text naming the business, what it protects and the obligations behind it | Owner review at every trigger | | Objectives | The objectives, or the framework, the policy points to | Objectives register linked to the policy record | | Two pledges | Obligations and improvement statements present in the text | Pre-approval wording check | | Approval and ownership | Signed, versioned policy, approval trail and leadership minutes | Governed record with owner, version and date | | Communication | Distribution and acknowledgement records for staff and contractors | Joiner-workflow export | | Review | Dated review history showing what triggered each pass | Event-triggered review log | | External availability | Trust-centre entry or NDA-gated copy | Trust-centre publishing | ## Frequently asked questions ### How often should the Clause 5.2 policy be reviewed? At least annually, with event triggers on top: an incident, a regulatory change, a restructuring or a major architecture shift. Record the date, the reviewer and the trigger even when nothing changes, because "reviewed, no change" is still evidence. ### Do contractors need to acknowledge the Clause 5.2 policy? Treat them like staff. The distribution and acknowledgement records an auditor expects cover contractors as well as employees, so route contractor onboarding through the same workflow. For a contractor who touches only a narrow system, a short acknowledgement at the start of the engagement is enough, provided it is dated and retrievable. ### Does the ISO 27001 5.2 policy need to state the ISMS scope? Not as a required element. The scope is its own documented information under Clause 4.3, and the Clause 5.2 content list does not include it. Many policies still name the scope in one sentence, so readers know what the commitments cover. If yours does, point to the scope document rather than copying its boundaries, so a scope change does not force a policy re-approval. ### Can one document satisfy both Clause 5.2 and Annex A 5.1 in a small company? Sometimes. Clause 5.2 wants one headline document. At small scale, a single well-structured document can serve both layers, provided the headline principles stay clearly separate from the topic detail. The risk is length. Once the document passes four pages or starts naming tools, split it, because the headline version is the one you share externally.