What Is ISO 27001 Annex A Control 5.1?
If you are working through an ISO 27001 implementation, Annex A Control 5.1 is one of the first places you need to get right. It sits at the very top of the Annex A control set for a reason. Without a clear, well-structured information security policy, everything else you build around it lacks direction.
On this page
Control 5.1 is titled Policies for Information Security. Its purpose is straightforward: your organisation must define, approve, publish, and communicate a set of policies that govern how information security is managed across the business. These policies need to come from the top, reflect the organisation's risk appetite, and be reviewed regularly to stay relevant.
This article breaks down exactly what Control 5.1 requires, what it looks like in practice, common mistakes organisations make, and how to write policies that actually satisfy an auditor rather than just filling a folder.
Why Control 5.1 Matters More Than Most People Realise
A lot of businesses treat information security policies as a box-ticking exercise. They download a template, put their logo on it, and call it done. That approach will not hold up under audit, and more importantly, it will not protect your business.
Control 5.1 is the foundation for your entire Information Security Management System (ISMS). Every other control in Annex A, whether it relates to access control, supplier relationships, incident management, or cryptography, is underpinned by the intent and direction set in your policies. If your policies are vague, inconsistent, or disconnected from how your business actually operates, your ISMS will reflect that weakness throughout.
From an auditor's perspective, the first thing we look at when reviewing an ISMS is the policy framework. If the policies are generic and clearly not tailored to the organisation, it signals that the implementation may be superficial. Auditors are trained to spot this quickly.
For a deeper understanding of what the ISO 27001 standard covers at a foundational level, the ISO 27001 beginner's guide is a useful starting point before diving into individual controls.
What the Standard Actually Requires
The ISO/IEC 27001:2022 standard sets out the requirement clearly. Control 5.1 states that an information security policy and topic-specific policies must be defined, approved by management, published, communicated to relevant personnel, and reviewed at planned intervals or when significant changes occur.
There are two layers to this requirement that businesses often miss.
Layer One: The Overarching Information Security Policy
This is the top-level policy document. It sets the overall direction and intent of your organisation's approach to information security. Think of it as your organisation's public commitment to protecting information. It should be signed off by senior leadership, ideally the CEO or equivalent, and it should be accessible to all staff.
The overarching policy typically covers:
- The organisation's commitment to protecting information assets
- Alignment with the organisation's strategic objectives
- Compliance obligations relevant to information security, including legal, regulatory, and contractual requirements
- The overall risk management approach
- Roles and responsibilities at a high level
- Consequences of non-compliance
This document does not need to be long. A well-written overarching information security policy can be one to two pages. What matters is that it is genuine, specific to your organisation, and endorsed at the leadership level.
Layer Two: Topic-Specific Policies
This is where Control 5.1 goes deeper than many organisations expect. In addition to the overarching policy, the standard requires topic-specific policies that address particular areas of information security. These are sometimes called sub-policies or supporting policies.
Examples of topic-specific policies include:
- Access control policy
- Acceptable use policy
- Mobile device and remote working policy
- Password and authentication policy
- Data classification policy
- Incident response policy
- Supplier security policy
- Cryptography and encryption policy
- Clear desk and clear screen policy
The number of topic-specific policies you need depends on your organisation's size, the nature of your information assets, and the risks you face. A small software company with 15 staff will have a different policy set than a financial services firm with 500 employees handling sensitive client data.
Real-World Examples of Control 5.1 in Practice
Let's look at how this plays out across different types of organisations.
Example One: A Small IT Managed Services Provider
An IT managed services provider in Melbourne with 20 staff handles sensitive client data across dozens of customer environments. Their overarching information security policy is a two-page document signed by the Managing Director, outlining the company's commitment to confidentiality, integrity, and availability of information. It references their risk assessment process and compliance with the Australian Privacy Act.
Their topic-specific policies include a remote access policy (critical given most staff work from client sites or home), an acceptable use policy covering personal device use, a data handling and classification policy, and a supplier security policy governing how they manage third-party software vendors. Each policy is stored in their intranet, reviewed annually, and staff are required to acknowledge reading them during onboarding and each annual review.
Example Two: A Healthcare Organisation
A private healthcare provider in Brisbane operates under significant regulatory pressure. Their overarching information security policy references compliance with the My Health Records Act, the Privacy Act, and the Australian Digital Health Agency's guidelines. It is approved by the Board and reviewed every 12 months.
Their topic-specific policies go into considerable detail. Their data classification policy distinguishes between general administrative data, patient health information, and highly sensitive clinical records. Their access control policy restricts access to patient records based on clinical role. Their incident response policy includes specific steps for notifying the Office of the Australian Information Commissioner in the event of an eligible data breach under the Notifiable Data Breaches scheme.
Example Three: A Manufacturing Business Seeking ISO 27001 for the First Time
A mid-sized manufacturer in Adelaide is pursuing ISO 27001 certification primarily to satisfy a major customer's supplier requirements. They have never had formal information security policies before. Their consultant helps them develop an overarching policy and six topic-specific policies tailored to their environment, which includes engineering drawings, supplier contracts, and customer pricing data.
The key point here is that their policies are written to reflect what they actually do, not what an ideal organisation might do. Their clear desk policy, for example, references the physical drawing files stored in the engineering department and specifies how they must be locked away at end of day. That specificity is what makes the policy credible to an auditor.
How to Write Policies That Actually Work
Writing information security policies is one of those tasks that sounds straightforward but trips up a lot of organisations. Here is practical advice based on what works in real audits.
Tailor Everything to Your Organisation
Generic templates are a starting point, not a finish line. Every policy should reference your actual systems, your actual roles, and your actual risks. If your policy mentions technologies or processes you do not use, it undermines credibility immediately. An auditor will ask about anything in your policy, so only include what you can demonstrate.
Get Genuine Leadership Sign-Off
Control 5.1 requires management approval. This is not just a signature formality. The person signing off should understand what is in the policy and be prepared to enforce it. If your CEO signs a policy they have never read, that will become apparent during an audit when the auditor interviews them. Leadership commitment to information security is a recurring theme throughout ISO 27001, and it starts here.
Make Policies Accessible and Understandable
A policy that staff cannot find or cannot understand is not an effective policy. Plain language matters. Avoid legal jargon where possible. Store policies somewhere staff can actually access them, whether that is a shared drive, an intranet, or a document management system. Consider whether you need translated versions for staff whose first language is not English.
Build in a Review Cycle
Control 5.1 explicitly requires policies to be reviewed at planned intervals or when significant changes occur. Document your review schedule. Most organisations review annually, which is reasonable for stable environments. If you go through a significant change, such as adopting a new cloud platform, expanding to a new country, or acquiring another business, your policies should be reviewed as part of that change process.
Understanding how controlled documents work is essential here. Your policies are controlled documents, and they need version control, approval records, and a clear distribution process.
Connect Policies to Your Risk Assessment
Your policies should reflect the outcomes of your risk assessment. If your risk assessment identifies that phishing is a significant threat, your acceptable use policy and email security policy should address that. If you handle sensitive personal data, your data classification and retention policies should reflect that risk. Policies that are disconnected from your risk profile look like they were written in isolation, because they usually were.
If you are not sure how to approach the risk assessment side of things, the ISO 27001 risk assessment guide for non-technical business owners explains the process in plain English.
Common Mistakes Auditors Find With Control 5.1
Having reviewed dozens of ISMS implementations, the same mistakes come up repeatedly with Control 5.1. Here are the most common ones.
One Policy Document That Tries to Cover Everything
Some organisations produce a single 30-page document that attempts to cover every aspect of information security. This is difficult to read, difficult to maintain, and difficult to communicate effectively to staff. The better approach is a short overarching policy supported by focused topic-specific policies that can be updated independently when needed.
Policies That Are Not Communicated to Staff
Having a policy document is not enough. Control 5.1 requires that policies are communicated to relevant personnel. During an audit, staff are often interviewed and asked whether they are aware of information security policies and where to find them. If staff have no idea the policies exist, that is a non-conformity. Communication evidence matters, whether that is training records, acknowledgement sign-offs, or intranet access logs.
Policies That Have Never Been Reviewed
An information security policy with a review date two years in the past, and no evidence of any review activity, is a red flag. Even if the content is still accurate, the absence of a review record suggests the organisation is not actively managing its ISMS. Review records, even brief ones noting that the policy was reviewed and no changes were required, demonstrate ongoing commitment.
Policies That Do Not Reflect Reality
This is the most serious issue. If your access control policy states that all privileged access is reviewed quarterly but you have no evidence of quarterly reviews ever taking place, you have a significant conformity problem. Policies must describe what you actually do, or what you genuinely intend to do and can demonstrate you are working toward.
How Control 5.1 Connects to Other Parts of ISO 27001
Control 5.1 does not operate in isolation. It connects directly to several other parts of the standard.
Clause 5 of ISO 27001 (Leadership) requires top management to establish an information security policy that is appropriate to the organisation's purpose and includes commitments to satisfy applicable requirements and to continual improvement. Control 5.1 in Annex A is where those commitments are documented in practice.
The topic-specific policies you develop under Control 5.1 provide the rules that other Annex A controls are built on. Your access control policy supports Controls 5.15 through 5.18. Your supplier security policy supports Control 5.19. Your incident response policy supports Controls 5.24 through 5.28. The policy framework is the connective tissue of the entire ISMS.
For those also working with privacy requirements alongside ISO 27001, the ISO 27701 privacy information management guide covers how privacy policies integrate with your information security framework.
Preparing for an Audit on Control 5.1
When an auditor reviews Control 5.1, they will typically ask for the following evidence:
- The overarching information security policy document, with approval signature and date
- A list of topic-specific policies and their current versions
- Evidence that policies have been communicated to staff, such as training records, acknowledgement logs, or intranet screenshots
- Evidence of policy reviews, including review dates and any changes made
- Evidence that policies are available to relevant personnel
They may also interview staff to check awareness, and they will cross-reference your policies against other controls to check for consistency. Preparation is straightforward if your documentation is in order and your staff are genuinely familiar with the policies that apply to their roles.
If you are still in the process of deciding whether ISO 27001 is the right path for your organisation, understanding the real cost of ISO 27001 certification in Australia will help you plan your investment accurately.
Getting Started With Control 5.1
If you are starting from scratch, here is a practical sequence to follow.
- Conduct or review your risk assessment to understand what information assets matter most and what threats apply to your organisation.
- Draft the overarching information security policy, keeping it concise and specific to your organisation's context and objectives.
- Identify which topic-specific policies your organisation needs based on your risk profile and the controls you are implementing.
- Draft each topic-specific policy with input from the relevant teams, such as IT for access control policies, HR for acceptable use policies, and procurement for supplier security policies.
- Get formal sign-off from senior management on all policies.
- Communicate policies to all relevant staff and document that communication.
- Set review dates and assign responsibility for maintaining each policy.
This does not need to happen all at once. A phased approach is practical for most organisations, provided you have a clear plan and timeline.
If you are finding the process complex or want expert guidance to make sure your policy framework will hold up under audit, CertBetter can connect you with verified ISO 27001 consultants who specialise in information security management. Submit one form and receive up to three competing quotes from vetted providers, completely free of charge.
