ISO 27001 A.5.1 — Policies for information security

What ISO 27001 A.5.1 requires

Policies for information security is one of 37 Organisational Controls in ISO/IEC 27001:2022 Annex A. Define, approve, publish, communicate and regularly review information security policies aligned to business strategy and applicable regulations. Organisational controls are judged on governance rather than tooling: an auditor wants a named owner, an approval trail, and evidence the control is exercised on a defined cadence rather than written once and filed.

Audit evidence assessors look for

When preparing your Statement of Applicability (SoA) for A.5.1, gather artefacts such as:

Approved IS policy document signed by top management
Distribution records (intranet, email, onboarding packs)
Annual policy review records with change log
Version-controlled policy register
Evidence of staff acknowledgement

How to implement A.5.1

Write one topic-specific policy set, not one giant documentA single 80-page "information security policy" is hard to approve, harder to review, and forces every change through the same sign-off. Split it into a short apex policy that states intent and ownership, plus topic policies (access control, cryptography, supplier security) that can each be revised on their own cycle.
Get approval at the right level and record itClause 5.2 requires top management to establish the policy, so approval has to come from someone with genuine authority — a CEO, board, or an executive with a documented delegation. An IT manager signature on the apex policy is a finding waiting to happen. Record who approved, when, and against which version.
Publish where staff actually look, and prove they saw itCommunication is a separate requirement from publication. Intranet availability alone does not satisfy it. Tie policy acknowledgement to onboarding and to your annual awareness cycle, and keep the completion report — that report is the evidence, not the policy itself.
Set a review trigger, not just an annual dateAnnual review is the norm, but the standard asks for review at planned intervals and on significant change. Write down what counts as significant — a new regulator, an acquisition, a major incident, a change of hosting model — so an auditor can see the trigger existed rather than judging it after the fact.
Version-control the registerKeep a policy register listing each policy, its owner, approval date, next review date and current version. This one artefact answers most of what an auditor will ask about A.5.1 and makes the gaps visible to you first.

Common audit findings for A.5.1

What actually gets raised against A.5.1, in rough order of how often it comes up:

Policies approved by IT rather than by top management, which does not satisfy the Clause 5.2 expectation behind this control.
A review date that has passed. An out-of-date review is worse than no schedule at all, because it demonstrates a process you are not following.
Acknowledgement records that cover new joiners but not existing staff, so the majority of the workforce has never formally seen the current version.
Topic policies that contradict the apex policy, usually because they were revised at different times by different owners.

Scoping A.5.1

A.5.1 is applicable to essentially every ISMS — excluding it is very difficult to justify, because the management-system clauses independently require a policy. If your organisation is small enough that one person writes and approves everything, the control still applies; what changes is the formality, not the requirement.

How A.5.1 maps to SOC 2 and NIST CSF

If you run more than one framework, the same evidence usually satisfies all of them. A.5.1 aligns with:

SOC 2: CC1.1 Integrity and ethical values, CC5.3 Policies and procedures

NIST CSF 2.0: GV.PO-01 Policy established and communicated, GV.PO-02 Policy reviewed and updated

ISO 27001:2013 mapping

A.5.1 consolidates the following ISO 27001:2013 control(s): A.5.1.1, A.5.1.2. If you are transitioning an existing ISMS, map your prior evidence for these to A.5.1 in your updated SoA.

Map A.5.1 to NIST CSF & SOC 2 →

Crosswalk this control in the Control Mapper & Gap Assessment.

Document the risk →

Record treatment for gaps against A.5.1 in the Risk Register.

Related Annex A controls

A.5.37 Documented operating procedures A.5.4 Management responsibilities A.6.2 Terms and conditions of employment A.6.6 Confidentiality or non-disclosure agreements A.5.10 Acceptable use of information and other associated assets A.5.36 Compliance with policies, rules and standards for information security

See all 37 Organisational Controls →

Frequently asked questions

Is ISO 27001 A.5.1 mandatory?

Annex A controls are not mandatory in the abstract. Clause 6.1.3 requires you to compare your risk treatment plan against Annex A and justify, in the Statement of Applicability, any control you exclude. If your risk assessment surfaces a risk that A.5.1 addresses, excluding it needs a documented, risk-based rationale that an auditor will test.

How do auditors test ISO 27001 A.5.1?

In two passes. First design: does a documented control exist, is it owned, and does it address the risk? Then operating effectiveness: the auditor samples records from across the audit period to confirm the control actually ran. A Stage 2 audit will typically pull several samples, so evidence that only exists for the month before the audit is a common finding.

How often should A.5.1 be reviewed?

ISO 27001 sets no fixed interval — it requires review at "planned intervals" and after significant change. Annual review is the norm most certification bodies expect, with an out-of-cycle review triggered by incidents, major system changes, restructures, or new regulatory obligations. Record the review date and outcome either way; an undated control is treated as unreviewed.

What does ISO 27001 A.5.1 map to in SOC 2 and NIST CSF?

A.5.1 aligns with SOC 2 CC1.1, CC5.3 and NIST CSF GV.PO-01, GV.PO-02. Evidence gathered for one framework will usually satisfy the others, which is the basis for a test-once, satisfy-many control library.

What was A.5.1 in ISO 27001:2013?

A.5.1 consolidates 2 control(s) from the 2013 edition: A.5.1.1, A.5.1.2. When transitioning, re-point the existing evidence rather than rebuilding it — the underlying requirement has not changed materially.

What are the most common audit findings for A.5.1?

Policies approved by IT rather than by top management, which does not satisfy the Clause 5.2 expectation behind this control. A review date that has passed. An out-of-date review is worse than no schedule at all, because it demonstrates a process you are not following.