ISO 27001 A.5.1: information security policies that pass audit

The Stage 1 auditor asks for your ISO 27001 A.5.1 policy suite. You have a 40-document template pack nobody has read, and no record that the contractor who started in March ever saw it. The certification your next enterprise deal depends on is waiting.

This guide covers what the control requires and how a 25–250 person firm builds a lean suite that survives sampling. It also shows how to run the lifecycle from a register and your onboarding workflow, not an annual scramble. It is written for founders, heads of IT and compliance leads who will be asked to produce the evidence.

What does information security management ISO 27001 A.5.1 actually require?

ISO 27001 A.5.1 requires a top-level information security policy plus topic-specific policies, each signed off by management, made available, explained to the people they bind and acknowledged by them. The suite is then reviewed on a schedule and whenever something significant changes. The top-level policy itself needs sign-off from top management.

The wording is short because the requirement is. Leadership's direction on security has to exist in writing, carry a signature from the top, and reach the people it binds. A.5.1 splits that into a top-level policy stating what the firm protects and why, and topic-level documents that turn intent into rules staff can follow. This is the front door of your information security management system, the ISMS that certification assesses.

Five verbs carry the whole control:

• Approve. Top management signs the top-level policy and any material revision, not whoever drafted it.
• Publish. Put the suite somewhere findable, in the tools people already use.
• Communicate. Tell the people each policy binds, at launch and again at onboarding.
• Acknowledge. Record that staff and contractors have read the rules that apply to them.
• Review. Revisit on a schedule, and again whenever the business, its technology or its obligations change in a way that matters.

Most teams stop at approval, because a signed PDF feels like the finish line.

A policy nobody has acknowledged is a document, not a control.

None of this needs a heavy programme. For a 50-person firm, the control mostly asks for what a good security lead already wants: rules written down, signed by the CEO and kept somewhere people can find them. The sections below show how to make that survive an audit.

Where does A.5.1 sit in the ISO 27001 Annex A controls list?

A.5.1 is the first control in the Organisational Controls theme of the ISO 27001 Annex A controls list, and most other Annex A work leans on it. It is a preventive control that sets rules for behaviour rather than enforcing them technically. Access control, supplier security and incident response documents all cite the approved suite as their source.

The audit interlock matters more than the numbering. The top-level policy is tested against Clause 5.2, with A.5.1 carrying the topic layer plus communication and acknowledgement. Clause 7.3 on awareness and Clause 7.5 on documented information then sample the same evidence from different angles.

One evidence set therefore answers three questions:

• Clause 5.2: does the top-level policy state the commitments and direction top management owns?
• Clause 7.3: do people know the policy and their part in it?
• Clause 7.5: are the documents controlled, versioned and current?

A.5.1 touches confidentiality, integrity and availability alike, because the policies govern the controls that protect each. It steers behaviour; it does not protect any one system directly.

Draft it early in the programme. Every dependent document needs an approved parent to cite, so a late A.5.1 stalls the rest of the Annex A work behind it.

Why do UK GDPR and board-level governance care about A.5.1 policies?

The ICO treats an information security policy as an example of an appropriate organisational measure under UK GDPR Article 32. The NCSC Cyber Governance Code of Practice expects Boards to own cyber risk. For a regulated firm, missing or unapproved policies read as absent management control, which is a regulatory finding.

Two sources set the tone. UK GDPR Article 32 on technical and organisational measures requires controllers and processors to apply measures appropriate to the risk. The Information Commissioner's Office guide to data security names an information security policy as an example of such a measure. It also notes that you may not need a formal policy document in every case, depending on your size and the data you process.

That leeway is a floor for UK GDPR compliance, not a way out of A.5.1. Certification still asks for a written, approved and communicated suite, so the policy you write for the auditor also becomes your answer to the regulator.

On governance, the NCSC Cyber Governance Code of Practice sets out the governance actions Boards and directors need to own. A CEO-signed top-level policy, reviewed through the annual management review, gives the Board a concrete artefact to own and a record that it did.

Customers read the same paperwork. Enterprise procurement teams and cyber insurers treat the policy set as a proxy for whether security has an owner. A stale approval date, or a policy that contradicts how the company actually works, tells a diligence reviewer more than any questionnaire answer. It also surfaces at Stage 1, the auditor's document review before the main assessment, as an area of concern logged before you have shown anything else.

How many policies does a 25–250 person firm need?

Build two tiers: one top-level information security policy of two to four pages, signed by the CEO. Beneath it sit eight to twelve topic-specific policies chosen by risk, not template count. Typical picks include access control, acceptable use, data classification, supplier security, incident management, backup and continuity, cryptography and, if you ship software, secure development.

Auditors check the top-level policy against a known list of elements, almost line by line, so treat the list as a checklist rather than inspiration. It needs to cover:

• what information security means for your business
• your security objectives, or how you will set them
• the principles that steer security decisions day to day
• a commitment to meet legal, regulatory and contractual obligations
• a commitment to improve the ISMS over time
• who holds which security responsibilities
• how exceptions are requested and approved

Give every document a named owner with the authority and competence to maintain it. Choosing by risk means choosing from your risk assessment. Each topic policy should trace to risks you have recorded and to controls your Statement of Applicability marks as applicable. When an auditor asks why a policy exists, that trace is the answer.

At the 25–50 end, one combined document is acceptable. For a firm this size, budget two to four weeks from blank page to approved, published suite.

Forty policies you don't follow are worse than eight you do.

The template-pack trap works like this. A 40-document pack arrives covering every Annex A theme, and each file becomes a review-cycle liability with its own owner, version and due date. Auditors test practice against paper, so every sentence that doesn't match how you work is a finding waiting to be sampled. A 30-person firm doesn't need a standalone document per theme. Use templates as a starting point, then cut them down to the risks you actually carry.

What does an auditor sample for A.5.1?

At Stage 1 the auditor reads the documents; at Stage 2 they test practice. Expect them to ask for the acknowledgement records of two or three recent joiners, often contractors. They will also trace one topic document's approval trail, cross-check policies against interviews and walk one granted exception through sign-off.

Expect questions along these lines in the room:

• "Show me your information security policy. Who approved it, and when?"
• "How does a new starter find out which rules apply to them, and how do you know they've read them?"
• "When was this last reviewed, what inputs did the review consider, and what changed?"
• "How does a change to a policy get proposed, approved and communicated?"
• "You had an incident in March. Did it trigger a policy review?"

The sampling tends to expose three weaknesses:

• Approval without authority. Sign-off must sit with top management, not whoever drafted the document.
• Acknowledgement gaps. Contractors and mid-year joiners are usually discovered only when the auditor samples them.
• Sloppy document hygiene. A front page whose version disagrees with the change history, or reviewer comments still sitting in the published copy.

Hygiene errors are cheap to fix. They are also the details that prime an auditor to dig harder everywhere else.

The interview cross-check is the one paperwork cannot cover. Staff in other sessions describe how they actually work, and the auditor compares that with what the policy claims. The practical defence is a shorter suite: people can describe a rule they have read recently, and a lean set gives interviewers less to contradict.

Expect certification bodies to grade on the pattern. No approved, communicated policy suite is the absence of a requirement and grades major. A lapsed review date, a sampled acknowledgement gap or a version-control slip grades minor, though a pattern of minors can aggregate to a major.

What evidence should an A.5.1 audit file hold?

An A.5.1 evidence file holds five things. These are the current policy documents showing version history, owner, approval date and approver; management or board minutes recording approval; acknowledgement records for staff and contractors including recent joiners; a review log showing what changed; and a communication trail covering launch announcement, onboarding pack and intranet location.

Assemble the file once, then refresh it at each review instead of rebuilding it before every audit. Each artefact answers a specific sampling test from the previous section:

• Policy documents answer the version-history and approval-trail requests.
• Minutes answer "who approved it, and when?"
• Acknowledgement records answer the joiner and contractor sample. Export them from the HR platform or LMS so the request takes minutes.
• The review log answers "what changed, and why?", including reviews that changed nothing.
• The communication trail answers how a new starter finds the rules that apply to them.

Keep superseded versions and their approvals rather than overwriting them. Clause 7.5 expects documented information to be retained under control, and an auditor tracing an incident will ask which version was in force at the time.

Can you share your A.5.1 policies with prospects and insurers?

Yes, and enterprise buyers and cyber insurers will ask to see them. Send an external-safe copy: the same commitments, approval date and approver as the internal master, with the operational detail removed. The copy must still match how you actually work, because a reviewer will compare it with your questionnaire answers.

Keep two versions of each document you expect to send out: the internal master and the external-safe copy. Produce the external copy from the master, never as a separate rewrite, so the two cannot drift apart. Before anything leaves the business, remove:

• internal system and tool names
• network and architecture detail
• reviewer comments and tracked changes
• anything else you would not want a stranger to hold

Cut detail, never commitments. If the external copy promises controls your teams don't run, it will contradict your questionnaire answers. Host the external copies in a trust centre, or release them on a simple NDA request. That stops each new prospect's request turning into a fresh email thread.

How do you automate the A.5.1 policy lifecycle?

Treat the policy suite as data. A register records each document's owner, version, approval date and review-due date; HR onboarding triggers acknowledgement tasks for joiners and contractors; incident closures and contract signatures trigger out-of-cycle reviews; and ticketed changes capture the approval trail automatically.

Four pieces of plumbing do the work:

1. Build the register. One record per document, so "what's current and what's overdue" is a dashboard query with automated owner reminders, not a spreadsheet someone forgets.
2. Wire onboarding. A joiner or contractor created in the HR platform triggers the acknowledgement task, and completion is recorded as it happens. The auditor's sampling request becomes an export, not a two-day email hunt.
3. Hook the review triggers. Incident closure, a regulatory watchlist hit or a major contract signature opens a review, and the trigger itself is saved as evidence.
4. Route changes through tickets. Proposer, approver and date are captured as a by-product of making the change, so the audit trail assembles itself.

Publish where people already work, whether that is Notion, Confluence or SharePoint, and link the register to those live pages. When one document changes, sanity-check its neighbours for consistency.

Automation does not lower the bar on what a review means. Reviewers expect to see the inputs considered, such as incidents, audit results and business change, even when the outcome is no change.

A review that only changes the date on the front page isn't a review.

At 25–250 staff, this is what lets one compliance owner keep the suite current without a standing project. The annual review becomes a meeting with its inputs already collected, and the table below sets the four mechanisms side by side.

Frequently asked questions