Clause 5.2
Information security policy

Six short blocks cover everything Clause 5.2 requires, in an order that reads naturally:

• •Purpose and context – Two or three sentences on what the organization does and why information security matters to it specifically. This is where "appropriate to the purpose of the organization" is satisfied — a SaaS platform holding customer production data should sound nothing like a manufacturing firm protecting design IP.
• •Scope reference – One line pointing to the ISMS scope statement (Clause 4.3) rather than restating it. Restated scope drifts out of sync the first time the scope changes.
• •Commitments – The two the clause demands, in plain words: satisfying applicable legal, regulatory, and contractual requirements, and continually improving the ISMS. Add further commitments (protecting customer data, security by design) only if you intend to resource them — each one is auditable.
• •Objectives framework – Either the objectives themselves or, far more practically, how objectives are set: who proposes them, who approves them, how they are measured, and in which forum they are reviewed. This block is the bridge to Clause 6.2.
• •Roles summary – A short paragraph naming who owns the ISMS, who approves this policy, and where detailed responsibilities live (the Clause 5.3 assignments and A.5.2 documentation). Names of roles, not names of people — people change faster than policies should.
• •Review clause – Who reviews the policy, at what planned interval, and what triggers an off-cycle review (major incident, reorganization, new law). A policy without a review clause is a policy that will quietly expire.

The policy must be readable by every employee in one sitting, because Clause 5.2 requires it to be communicated to all of them — and Stage 2 auditors test whether the communication worked. That sets the length: one to three pages. It also sets the tone: plain language a new hire in any department can parse without a glossary. If a reasonable person cannot say what the policy means for their own work after one read, the document is too long, too abstract, or both.

Everything detailed belongs elsewhere: control rules in topic-specific policies, numbers and targets in the objectives documentation, how-to content in procedures. The discipline is editorial — every sentence that explains how something is done is a sentence that belongs in a different document.

ISO 27001 separates the top-level policy (Clause 5.2) from topic-specific policies (control A.5.1) — access control, cryptography and key management, information transfer, supplier security, incident management, acceptable use, and whatever else your Statement of Applicability makes relevant. The top policy sets direction and commitments for everyone; topic-specific policies carry operational rules for their audiences and are owned at the appropriate management level.

The recurring mistake is merging the whole family into one 25-page "Information Security Policy". The merged document fails both jobs simultaneously: it is far too long to communicate meaningfully to every employee, and far too shallow to direct any specialist. It also concentrates review pain — every minor rule change forces a top-management re-approval. Keep the top policy short and stable, list or link the topic-specific family within it, and let each layer change at its own pace.

The policy must be established by top management, and that must be provable: a board or leadership meeting minute, a signed copy, or an e-signature trail — plus version metadata (number, date, approver, next review) on the document itself. An unapproved policy is, for audit purposes, a draft.

Communication needs the same evidence discipline. Publish the policy where staff actually work — intranet, wiki, or HR system, not a buried compliance folder. Put acknowledgment into onboarding, and refresh it through the awareness program (Clause 7.3) so long-tenured staff are not relying on what they read five years ago. Track acknowledgments; coverage gaps cluster among contractors and acquired teams. For availability to interested parties, decide deliberately: many organizations share the full policy under NDA during vendor reviews and publish a short public summary — either pattern works if it is consistent and repeatable.

• •Template boilerplate left intact – Another company's name in a header or footer, references to laws that do not apply to you, placeholder text like "[Company]" three pages in. Search the document before it ships; auditors find these in the first pass.
• •No review date, owner, or version history – A policy with no metadata reads as written-once-and-forgotten, and usually is.
• •Commitments nobody resources – Promising "industry-leading security" or sweeping improvement programs with no budget or log behind them; every commitment is a claim the auditor may test.
• •Mission-statement vagueness – Fine words about valuing security with no objectives framework, leaving Clause 6.2 hanging from nothing.
• •The monster merge – Every topic-specific policy folded into one unreadable document (see the hierarchy section above).
• •Policy contradicting practice – The policy promises annual access reviews while the access-review log shows none; contradictions between the top document and operating evidence are among the worst findings to explain.

At Stage 1, the document itself: that it exists as controlled documented information with version, date, and approver; that the four content elements are present — appropriateness to purpose, objectives or their framework, the commitment to applicable requirements, the commitment to continual improvement; and that approval by top management is evidenced, not asserted.

At Stage 2, the policy in motion: staff awareness via the corridor test; communication and acknowledgment records; whether the objectives framework actually produced the Clause 6.2 objectives; whether the applicable-requirements commitment is backed by a real legal and contractual register (control A.5.31); and whether improvement is visible in management review minutes and the corrective action log. The policy is the promise — the rest of the audit checks whether the organization keeps it.