Navigating ISO 27001 Annex A: Control A.5.1

Welcome to our ISO 27001 Annex A Blog series:

October marks Cybersecurity Awareness Month. The perfect time to launch this series!

Over the years, we’ve noticed, both in the market and through countless audits, that the Annex A controls of ISO 27001 are often misunderstood or difficult to apply in practice.

With this series, published every two weeks, we’ll unpack each control from Annex A and the ISO 27002 guidance, breaking them down into clear, structured insights you can use.

We’ll start today with Control 5.1 – Policies for Information Security.

I’ll also share some of my own observations and lessons learned from auditing organisations in the UK and internationally, adding a personal spin.

Control A.5.1 requires that organisations establish a clear and effective policy framework for managing information security.

Information security policies, including those on specific topics, should be established and approved by management. They must be published, communicated to relevant personnel and stakeholders, acknowledged by them, and reviewed regularly or whenever significant changes occur.

At the highest level, an organisation must define an Information Security Policy, approved by top management, which sets out the overall approach to protecting information.

• Reflect business strategy, legal and contractual obligations, and the current and projected threat landscape.
• Contain statements defining information security, objectives or frameworks for setting objectives, guiding principles, commitments to meet requirements, continual improvement, assignment of responsibilities, and handling of exceptions.
• Be approved and owned by top management, who must also approve any subsequent changes.

Supporting the high-level document are topic-specific policies. These provide detailed requirements for specific domains such as access control, asset management, network security, secure configuration, incident management, backup, cryptography, or software development. Each should be owned and approved by managers with suitable authority and expertise.

All policies must be communicated, accessible, and acknowledged by the personnel and external parties to whom they apply. They must be reviewed periodically and whenever major organisational, technological, or regulatory changes occur.

The information security policy is the foundation of the ISMS. It translates top management’s vision into a binding statement of intent.

Without it, there’s no clear direction for how security supports the organisation’s mission, no alignment with risk management, and no evidence of leadership commitment.

• Strategic alignment between security, business objectives, and compliance needs.
• Consistency in decision-making and implementation across departments and sites.
• Clarity of responsibility—who owns what within the ISMS.
• Cultural reinforcement—a shared understanding among employees that information security is everyone’s responsibility.

From my experience auditing, I’ve noticed that this is often the first “mirror” management holds up to its own maturity. When a policy feels like a genuine leadership statement -> short, purposeful, and understood by staff, it sets the tone for the entire certification journey.

Auditors evaluate both the existence and the effectiveness of the policy framework.
When I’m auditing this control of the standard these are the elements I always look for.

• A formally approved top-level information security policy.
• Topic-specific policies that support it and address relevant domains.
• Evidence that policies are communicated and acknowledged by employees and relevant external parties.
• Version control and review records, showing planned reviews, updates after changes, and senior approval.
• Alignment between the policy, risk assessment, SoA, and implemented controls.
• Interviews confirming that staff understand the policy’s intent and their responsibilities.

We often may also verify that policies are consistent across sites, reflect current risks, and are not outdated or contradictory.

Keep it strategic: The top-level policy should set direction, not detail controls.

Link to the SoA: Ensure that controls and risk-treatment decisions flow naturally from policy commitments.

Appoint a policy owner: Give someone responsibility for maintenance, communication, and version control.

Integrate reviews: Combine policy review with management-review meetings (ISO 27001 Clause 9).

Use controlled distribution: Label controlled and uncontrolled copies. Manage redacted versions for external distribution.

Make it visible: Reinforce policy messages through awareness campaigns, intranet banners, and onboarding sessions. We have seen clients place the core policy statement on every login screen-> simple, effective, and audit-proof.

Overly generic policies -> copied templates that don’t reflect the organisation’s context or risks.

No clear approval -> missing evidence of top-management endorsement.

Uncommunicated policies -> staff unaware of existence or relevance.

Out-of-date documents -> last reviewed years ago, referencing obsolete standards or processes. I’ve even seen policies still referencing ISO 27001:2013, instant red flag.

Narrow scope -> excluding critical outsourced processes or systems.

No linkage -> disconnect between policy statements, risk assessments, and implemented controls.

Control A.5.1 embodies the leadership principle of ISO 27001: Security direction must come from the top.

Your information security policy is more than a compliance requirement. It’s a strategic charter for how your organisation protects information and manages risk.

Keep it concise, relevant, owned, reviewed, and communicated. When auditors see that management drives the policy and that employees understand and apply it, they’ll see an ISMS that truly works, not just one that’s certified.