An information security policy is the foundation of every ISO 27001 programme. It states what the organization wants to protect, why, and who is responsible. Without it, controls become a random set of tools, and auditors have nothing to measure them against.
This guide explains what ISO/IEC 27001:2022 expects from your policies, how control 5.1 replaced the old Annex A.5 of the 2013 edition, and how to write policies that pass an audit and actually guide people.
From A.5 (2013) to control 5.1 (2022)
The 2013 edition had a small domain, A.5 “Information security policies”, with two controls. In the 2022 edition, both were merged into one control.
| ISO 27001:2013 | ISO 27001:2022 |
|---|---|
| A.5.1.1 Policies for information security | 5.1 Policies for information security |
| A.5.1.2 Review of the policies for information security | 5.1 Policies for information security |
Note that certification to the 2013 edition ended on 31 October 2025, so all certified organizations now work to the 2022 version.
Two levels of information security policy
ISO 27001:2022 asks for policies at two levels. It helps to keep them separate.
1. The information security policy (clause 5.2)
First, there is the short, top-level document that top management approves. Clause 5.2 of the standard says it must:
- suit the purpose of the organization;
- include information security objectives, or a framework for setting them;
- commit to meeting applicable requirements;
- commit to continual improvement of the ISMS.
In addition, it must be documented, communicated inside the organization and available to interested parties where appropriate. One or two pages is usually enough.
2. Topic-specific policies (control 5.1)
Second, control 5.1 adds more detailed policies for specific areas. ISO/IEC 27002:2022 gives examples, such as:
- access control
- physical and environmental security
- asset management
- information transfer
- secure configuration of endpoint devices
- networking security
- incident management
- backup
- cryptography and key management
- information classification and handling
- technical vulnerability management
- secure development
You do not need a separate document for each topic. For example, small organizations often combine them into one policy manual. What matters is that each relevant topic is covered, approved and assigned an owner.
What control 5.1 requires
In plain terms, the control expects you to:
- Define the policies, consistent with the top-level policy.
- Approve them by the right level of management.
- Publish and communicate them to staff and relevant external parties.
- Get acknowledgement, so people confirm they have read and understood them.
- Review them at planned intervals and when significant changes occur.
For instance, significant changes include a new business line, a move to the cloud, a major incident or a new law, such as India’s DPDP Act.
How to write a policy people will follow
Many policies fail because nobody reads them. Therefore, keep them practical:
- Be short. State rules, not essays. Put detailed steps in procedures.
- Use “must” and “must not”. Vague words like “should consider” are hard to audit.
- Name owners. Every policy needs a person responsible for keeping it current.
- Link to risk. Each rule should address a risk from your risk assessment.
- Version it. Show the version, approval date, approver and next review date.
Example structure of a topic-specific policy
| Section | Contents |
|---|---|
| Purpose | Why the policy exists, in one or two sentences |
| Scope | People, systems and locations it covers |
| Policy statements | The rules, written as clear requirements |
| Roles | Who approves, who implements, who monitors |
| Exceptions | How to request and approve an exception |
| Compliance | How you check compliance and what happens on breach |
| Review | Owner, review frequency and version history |
What auditors look for
During a certification audit, for example, the auditor will usually check:
- the signed or approved top-level policy, with evidence of communication;
- a list of topic-specific policies, each with an owner and review date;
- records showing reviews actually happened;
- staff awareness, often by asking employees about key rules;
- consistency between policies, the Statement of Applicability and real practice.
However, a common finding is a policy that says one thing while IT does another. For instance, a policy demands quarterly access reviews, but no review records exist.
Related 2022 controls
In addition, control 5.1 works together with:
- 5.4 Management responsibilities: managers must require staff to follow the policies.
- 5.36 Compliance with policies, rules and standards: you must check that people follow them.
- 6.3 Awareness, education and training: staff must learn the policies.
- 6.4 Disciplinary process: there must be consequences for serious breaches.
FAQ
How often should we review the information security policy?
ISO 27001 says “at planned intervals”. In practice, however, most organizations review at least once a year, and also after major changes.
Who should approve the policy?
Top management must approve the top-level information security policy. Topic-specific policies can be approved by an appropriate manager, such as the CISO.
Related guides
- ISO 27001:2022 Annex A: all 93 controls and the 2013 mapping
- Free ISO 27001:2022 readiness checklist
- What is an ISMS? Concept, benefits and the PDCA cycle
Sources
- ISO/IEC 27001:2022, Information security management systems (ISO)
- ISO/IEC 27002:2022, Information security controls (ISO)
Preparing for an ISO 27001 or IT audit? Our ISO 27001 readiness assessment finds your gaps before the auditor does. You can also start with our free ISO 27001:2022 readiness checklist, or contact us for a quote.
