ISO 27001 leadership and the information security policy

ISO 27001:2022 clause 5 asks top management to lead the ISMS, not just fund it. They show commitment in specific ways (5.1), set an information security policy with required commitments (5.2), and make sure the roles that run the system are assigned and known across the organisation (5.3).

The requirement in plain English

Leadership and commitment (ISO 27001:2022 5.1). Top management must show they lead the ISMS. The clause lists how: setting the policy and objectives so they fit the business strategy, building security into everyday processes rather than running it on the side, providing resources, explaining why security matters, making sure the system achieves what it is for, directing and supporting the people who do the work, promoting improvement, and backing other managers in their own areas. A note added in 2022 says “business” can be read broadly, to cover whatever your organisation exists to do.

Policy (ISO 27001:2022 5.2). Top management must set an information security policy that suits your purpose, includes your security objectives or the framework for setting them (ISO 27001:2022 6.2 covers the objectives themselves), and commits to meeting applicable requirements and to continual improvement. It must be kept as documented information, communicated inside the organisation, and available to interested parties as appropriate. Annex A adds topic-specific policies below it, each approved by management and reviewed at planned intervals (ISO 27001:2022 Annex A 5.1).

Roles (ISO 27001:2022 5.3). Top management must make sure responsibilities and authorities for security roles are assigned and communicated within the organisation. Two must be assigned explicitly: making sure the ISMS conforms to the standard, and reporting its performance to top management. Annex A asks for defined security roles (ISO 27001:2022 Annex A 5.2) and for managers to require their people to follow the policies (ISO 27001:2022 Annex A 5.4).

This is guidance to help you understand the requirement, not legal advice.

What good looks like

At a 25-person fintech, the CEO signs a three-page information security policy. It states what the company protects and why, the three security objectives for the year and who sets them, the commitment to meet legal, regulatory and contractual requirements, and the commitment to keep improving. It points to eight topic-specific policies (access control, acceptable use, supplier security, incident management and others), each approved by the CTO and reviewed every year.

The CTO is the information security lead, named in the policy, with written authority to stop a release that breaks a security requirement. A one-page responsibility table shows who owns each topic policy, each register and each repeating check, and who reports on ISMS performance to the leadership team.

Security is a standing item at the monthly leadership meeting: open risks over appetite, incidents, overdue actions. The minutes show decisions, not just updates, such as approving budget for endpoint management or accepting a residual risk. New starters read the policy in their first week and confirm they understand it; existing staff do so again when a new version is approved.

The policy is reviewed every year and whenever something significant changes, such as a new market or an acquisition.

Evidence an auditor expects

Information security policy (required documented information): the auditor checks for the 5.2 commitments, a link to objectives, top management approval and a review date.
Topic-specific policies: sampled for management approval, review dates and whether people affected know them.
Roles and responsibilities: the auditor checks the two 5.3 assignments are named and asks staff who they would report an incident to.
Communication evidence: policy acknowledgements, onboarding records or intranet notices showing the policy reached everyone in scope.
Leadership meeting minutes: usual rather than required; the auditor looks for decisions about security made by top management.
Interview with top management: the auditor asks what the objectives are and how the ISMS supports the business; a vague answer is a finding.

Common mistakes

Leadership delegated to the IT team

The policy is signed by the IT manager and the CEO has never read it. Clause 5.1 is about top management by name, and auditors interview them. Have a member of top management approve the policy and attend the closing meeting of every audit.

A policy that copies Annex A

Some top-level policies run to 20 pages and restate every control. Nobody reads them, and every control change forces a new version of the whole policy. Keep the top-level policy short and put the detail in topic-specific policies with their own owners.

Missing the required commitments

Auditors check the 5.2 elements one by one. A policy without the commitment to meet applicable requirements, or without objectives or a way to set them, is a nonconformity however well written the rest is. Check the four elements before approval.

Roles assigned but not communicated

The responsibility table exists but sits in a folder only the security lead opens. The 2022 wording says “within the organization”, and auditors test it by asking a developer or a support agent. Put the key roles in onboarding material and the policy itself.

Commitment that appears only at audit time

A burst of signatures in the month before stage 2 shows up plainly in the dates. Spread the evidence: approvals, reviews and leadership decisions with dates across the year.

How Sted helps

Sted’s knowledge base carries an Information Security Policy (POL-ISP) for ISO 27001’s leadership clauses 5.1 to 5.3 and Annex A 5.1 and 5.2; it has no record template of its own.
An administrator, or a Policy and Process Owner who owns the document, approves a Draft or starts a new version of an Approved one, and only an administrator assigns a document’s owner; a document still awaiting review cannot be approved.
Approving sets an effective date and a review date, which starts at the effective date plus the document’s review frequency; a review task opens 30 days before the review date and turns overdue after it.
Training in Sted is the person’s own attestation, on the current approved version, that they are aware of and understand the document and accept their role in it; nobody can complete it for someone else.

Sted drafts and versions the policy and records who approved it and who has read it. Top management still has to lead the system; an auditor will interview them, not Sted.

ISO 27001: the hub, and where clause 5 sits in the loop.
Context of the organisation: the issues and requirements the policy has to answer.
Support, competence, awareness and documented information: how the policy is communicated and controlled.
Policy adoption and roll-out: approving the policy and getting people to read it.
Approving documents and versions: who approves a policy in Sted, and how review dates work.

Frequently asked questions

Who counts as top management in a small company?

The person or group who directs and controls the organisation at the highest level, which in most small companies means the founders or the leadership team. A security lead can run the ISMS day to day, but cannot stand in for them at the audit. The auditor will want to speak to at least one of them.

How long should an information security policy be?

Two to four pages is enough for most organisations. The top-level policy states direction, objectives or how they are set, and the commitments clause 5.2 requires; the detail belongs in topic-specific policies such as access control or supplier security, which Annex A 5.1 expects you to have as well.