How to Write an Information Security Policy (ISO 27001 Clause 5.2)

The information security policy required by ISO 27001 Clause 5.2 is a single, top-level document established by top management. It states what the organization commits to and why — and it is deliberately short. One to two pages is normal. Ten is a sign that something which belongs in a sub-policy has wandered in.

This is the document most often confused with an entire policy library. If what you actually need is the set of policies — acceptable use, access control, incident response and the rest — start with the minimum policy set mapped to Trust Services Criteria or our nine internal company policies with templates. This article is about the one policy that sits above all of them.

What Clause 5.2 Requires

The standard is unusually specific here. Top management must establish an information security policy that:

• Is appropriate to the purpose of the organization. A payments company and a design agency should not have the same policy. Generic text is the fastest way to signal that nobody senior engaged with it.
• Includes information security objectives, or provides the framework for setting them. Either state the objectives, or state how and by whom they get set and reviewed. Most organizations choose the framework option and keep the objectives themselves in a separate, more frequently updated document.
• Includes a commitment to satisfy applicable requirements related to information security — legal, regulatory, and contractual.
• Includes a commitment to continual improvement of the information security management system.

And the policy itself must:

• Be available as documented information
• Be communicated within the organization
• Be available to interested parties, as appropriate

Those last three lines are where audits actually go wrong. Writing the policy is the easy half; proving it reached people is the half teams forget. More on that below.

A Section-by-Section Skeleton

A structure that satisfies Clause 5.2 without bloating:

1. Purpose and scope — one paragraph on why the policy exists and what it applies to, aligned with your ISMS scope statement. Don't restate the scope; reference it.
2. Commitment statement — what the organization commits to protecting, in plain language: the confidentiality, integrity, and availability of customer and company information.
3. Objectives or the framework for setting them — either the objectives themselves, or a sentence explaining that objectives are set annually by management review and tracked as documented information.
4. Commitment to applicable requirements — legal, regulatory, and contractual obligations relevant to information security.
5. Commitment to continual improvement — of the ISMS, referencing Clause 10 in practice if not by number.
6. Roles and responsibilities — who owns the ISMS, who approves policy, what is expected of every employee. Keep it to named roles rather than named people so the document doesn't churn with every hire.
7. Supporting policies — a list of the sub-policies that sit beneath this one, so a reader knows where the detail lives.
8. Consequences of non-compliance — a short, honest statement, consistent with your employment terms.
9. Approval and review — who approved it, when, and the review cadence.

What Does Not Belong in It

The clearest way to keep this document short is to be strict about what goes elsewhere. Operational detail belongs in sub-policies and procedures:

• Password length and MFA specifics → access control policy
• What employees may install on a laptop → acceptable use policy
• Severity levels and escalation paths → incident response plan
• Backup schedules and retention periods → backup and continuity documentation
• How suppliers are assessed → supplier security policy

The reason isn't tidiness. It's change velocity. The top-level policy should be stable enough that top management can reapprove it once a year without reading a diff. Anything you expect to change quarterly needs to live somewhere that can change quarterly without a management-review cycle. For running that lifecycle across the whole set, see internal policy management.

The Test Worth Applying

Hand the policy to a founder or a senior manager who did not write it, wait a week, and ask them to summarise what the company commits to. If they can — accurately, without the document in front of them — it is appropriate to the purpose of the organization in the way Clause 5.2 means. If they produce a shrug, you have a template with your logo on it, and an auditor interviewing that same person will reach the same conclusion.

This is not a hypothetical audit technique. Auditors do interview staff, and "top management demonstrates leadership and commitment" is assessed partly through whether the people at the top can speak to their own policy. See Clause 5 on leadership for what else falls under that heading.

Communicating It — and Proving You Did

"Communicated within the organization" is a requirement, and an auditor will ask you to evidence it. Publishing the document to a shared drive is not communication; it is availability. The two are separate requirements in the clause for a reason.

What works as evidence:

• Acknowledgement records — a per-employee record that they read the current version, with a date and the version they acknowledged.
• Onboarding coverage — the policy is part of induction, with a record for each new joiner.
• Re-acknowledgement on material change — when the policy changes substantively, people acknowledge the new version rather than the old one silently remaining "accepted."
• Availability to interested parties — where appropriate, a public summary or a version supplied to customers under NDA. A trust centre is a common way to satisfy this without publishing internal detail.

Version control matters more than teams expect here. If acknowledgements aren't tied to a version, you cannot show who accepted what, and the record stops being evidence.

Approval and Review Cadence

The policy is approved by top management — in a startup, a founder or the CTO, whoever genuinely holds authority over the ISMS. Annual review is the common cadence, usually folded into management review under Clause 9.3, plus an out-of-cycle review when something material changes: a new regulatory obligation, a significant incident, a change of scope, or an acquisition.

Record the approval. A policy whose approval history is "last modified by" metadata in a document editor is thin evidence that top management established anything.

The Takeaway

Write one or two pages that sound like your company, cover the four things Clause 5.2 names, and point to the sub-policies where the detail lives. Then spend your remaining effort on the part that actually fails audits: getting it acknowledged, versioned, and reviewed on a cadence you can show.

Next: Clause 5 in full, the minimum policy set for what sits beneath this one, or the whole Clause 4–10 walkthrough.