5.2 — Information security policy

The most frequently downloaded, least frequently read document in most companies’ ISMS — and yet its four required contents are exactly what an auditor checks first.

In plain language

5.2 requires top management to establish an information security policy that actually fits your organization, sets or frames your security objectives, commits to meeting your applicable requirements, and commits to continual improvement — then make sure it is documented, communicated internally, and available to interested parties as appropriate.

Why this requirement exists

A generic policy downloaded from a template and lightly edited signals to an auditor — and to your own staff — that security is a compliance formality rather than something the organization actually means. This requirement exists to force the policy to say something specific enough that it could only belong to your organization, not any company in your industry.

Scenario: an employee asked to describe the company’s security policy can only say “we have one, I think it is on the intranet somewhere.” The policy exists, technically satisfying the documentation requirement, but the communication requirement — that staff actually know it exists and roughly what it says — has clearly not been met.

What the standard expects

The standard expects top management to establish an information security policy that is appropriate to the purpose of the organization; includes information security objectives, or provides the framework for setting them; includes a commitment to satisfy applicable requirements related to information security; and includes a commitment to continual improvement of the ISMS. The policy must be available as documented information, communicated within the organization, and available to interested parties as appropriate.

In practice

• Keep the policy short and readable — a one-to-two-page statement of intent, not a technical control manual (that belongs in separate procedures).
• Reference your actual industry, risk posture, and strategic priorities rather than generic security language that could belong to any company.
• Actively communicate it — an onboarding step, an internal posting, a periodic reminder — rather than filing it and hoping staff find it.
• Decide deliberately what external version, if any, gets shared with customers or partners who ask for it.

Evidence the auditor will ask for

• The current, approved policy document, dated and version-controlled.
• Evidence of internal communication — an onboarding checklist, an intranet posting, an acknowledgment record.
• Interviews with staff at random confirming they are at least aware the policy exists and broadly what it covers.

Common pitfalls

• A generic, template-derived policy with no reference to the organization’s actual purpose or context.
• A policy filed on an intranet with no active communication step, so staff cannot demonstrate awareness of it.
• A policy that has not been updated since certification despite significant changes to scope, context, or objectives.

Related requirements

• 5.1 Leadership and commitment — the strategic alignment this policy is expected to reflect.
• 6.2 Security objectives — the measurable targets this policy either sets or frames.
• 7.3 Awareness — where staff actually learn what this policy says and why it matters.
• Parent clause: Clause 5 · Leadership