ISO 27001 A.5.1: Policies People Can Apply

What A.5.1 requires in practice

Annex A control A.5.1 asks for two kinds of direction: an overall information security policy and policies on particular topics. The control sets out a life cycle for them. They must be written down and approved by management, then published, shared with the relevant personnel and interested parties, and acknowledged by them. They must then be reviewed at planned intervals and again when significant changes occur.

Each part has a practical meaning. Defined means someone has decided the content. Approved means a management route exists that carries real authority. Published and communicated mean that the people affected can find and understand the current version, including relevant outside parties. Acknowledged means there is some way of knowing it reached them. Reviewed means it stays in step with the organisation.

The control does not say how many policies are needed or what each must be called. Those are choices made through risk treatment.

Separate direction from instructions

The information security policy establishes the organisation’s direction. Topic policies make decisions clearer in areas such as access, suppliers or information handling. Operating instructions then explain how particular work is performed. A reader should not need to search a long technical procedure to discover whether a proposed activity is permitted.

The number of documents is an implementation choice. A smaller business may combine several topics in one controlled document; a group may use a short central policy with approved local supplements. Test the arrangement by following one decision across documents. If two documents give different answers, document volume has created uncertainty instead of reducing it.

Make approval a business decision

Identify an owner capable of maintaining each policy and an appropriate management approval route. Before approval, examine whether the proposed rules are feasible with available systems, staffing and contracts. A rule that prohibits a working method while providing no usable alternative is likely to drive the activity into informal channels.

Exceptions need a defined route. The organisation can decide who assesses a departure, what risk information is needed and when the arrangement expires or is reconsidered. Those are suggested governance choices, rather than a prescribed ISO form. A policy owner should be able to see whether repeated exceptions indicate that the policy or underlying service needs redesign.

Communicate the decision, not merely the file

Acknowledgement shows that a policy reached someone; it does not prove understanding or compliance. Explain the change relevant to the audience, provide access to the current version and clarify where questions go. An external service team may need a particular handling requirement without receiving internal information unrelated to its work.

For material changes, a short scenario discussion can reveal misunderstandings. Ask a team how it would handle an urgent customer request that conflicts with a sharing rule. The answer tests whether people recognise the issue and know the authorised route. Connect learning with awareness, education and training, rather than relying solely on a click-through acknowledgement.

Why policy direction matters to the business

Policies are how leadership turns its security intentions into something staff and suppliers can act on. When they are clear and current, people make consistent decisions under pressure, customers see credible governance, and the organisation can show that its rules were known when something goes wrong. When they are vague, contradictory or ignored, the same document becomes evidence of a gap between what was said and what happened.

For audits and customer questionnaires, policy is usually the first thing examined and the thing people most want to see applied. A policy set that people can actually follow reduces exceptions, saves time answering assurance requests and shows that management direction extends into daily work.

How to implement A.5.1

Aim for a small set of policies that real decisions can be traced to, rather than a long library nobody reads. Keep each rule tied to a decision someone will really face.

1. List the topics where staff regularly need a clear decision, such as access, suppliers, information handling and remote work, and decide which deserve their own policy.
2. Give each policy an owner who can maintain it and a management approver with suitable authority.
3. Test draft rules against real services and contracts before approval, so you do not prohibit something people have no alternative to doing.
4. Publish current versions where staff and relevant outside parties can find them, and tell each audience what changes for them.
5. Capture acknowledgement in a way that fits your people, and follow up with short scenario discussions for material changes.
6. Set a review rhythm and a trigger for earlier review after major change, and track repeated exceptions as a signal that a rule needs rethinking.

Illustrative software example: sharing diagnostic data

Illustrative construction example: a joint project portal

A hypothetical construction contractor joins a project whose document portal is operated by another company. Its central policy requires specified protections for sensitive commercial information. Procurement and project management establish which portal arrangements meet those requirements and what additional restrictions are needed for tender information.

The project team receives a concise explanation of approved use and escalation. The central policy remains consistent, while the project supplement explains the actual interface. The company records the decision instead of treating the customer’s portal as automatically exempt from its own security expectations.

Review evidence and expose contradictions

Common nonconformities with A.5.1

Assessors usually find problems not in the existence of a policy but in how it is governed and used.

• A policy has no clear approval, or the approver cannot be identified.
• Reviews have lapsed, or a significant change in the business happened without any reconsideration of the policies.
• Staff or contractors cannot say where the current policy is, or cite a superseded version.
• Topic policies contradict the top-level policy or each other, so a reader reaches different answers.
• Acknowledgement is recorded for some groups but not relevant external parties who handle information.