Writing an information security policy suite for ISO 27001 means producing one top-level information security policy under clause 5.2, then a set of topic-specific policies that map to Annex A's 93 controls across four themes: organizational, people, physical, and technological. Miss the mapping step and auditors reject the suite at certification, no matter how well-written the prose is.
Why this matters
An information security policy suite isn't paperwork you write once and file away. It's the evidence base your auditor uses to test whether controls actually exist, and it's the document set your team is meant to follow day to day.
Get the structure wrong in 2026 and you'll spend the next certification cycle rewriting policies mid-audit, which is the most expensive way to fix a gap. A gap analysis before certification catches this before it costs you a failed audit.
How to write an information security policy suite for ISO 27001
Follow this order — skipping steps is how policy suites end up disconnected from the controls they're supposed to prove.
- Write the top-level information security policy first. Clause 5.2 requires a single overarching policy signed off by top management, stating your commitment to the ISMS and its objectives.
- Run a gap analysis against Annex A. Identify which of the 93 controls you already have evidence for and which need a new policy from scratch.
- Draft topic-specific policies per control theme. Organizational controls need access control and supplier policies. People controls need HR security and remote working policies. Physical controls need a physical security policy. Technological controls need cryptography, backup, and network security policies.
- Map every policy to your Statement of Applicability. Each policy should trace to at least one Annex A control reference — completing the Statement of Applicability is the step that turns a policy folder into audit evidence.
- Assign an owner and a review date to each document. Auditors check for named accountability, not just a policy title.
- Get management sign-off in writing. No policy counts as approved without a dated signature or logged approval in your compliance platform.
- Publish and train staff on the policies that apply to their role. A policy nobody's read is a policy that fails an interview-style audit question.
Core policies and the Annex A themes they cover
| Policy | Annex A theme | Typical owner |
|---|---|---|
| Information security policy | All (overarching) | Senior management |
| Access control policy | Organisational | IT / Security lead |
| Acceptable use policy | People | HR / IT |
| Physical security policy | Physical | Facilities / Office manager |
| Cryptography policy | Technological | IT / Engineering |
| Supplier security policy | Organisational | Procurement / Security lead |
| Incident response policy | Organisational | Security lead |
| Backup and recovery policy | Technological | IT / Engineering |
This isn't the full list — larger ISMS scopes need more granular policies, especially around cloud configuration and remote access. Mapping Annex A controls to existing IT controls tells you which gaps in this table apply to your environment specifically.
Why the size of your policy suite varies
- ISMS scope — a suite covering one product line needs fewer policies than one covering the whole company.
- Cloud vs on-premise infrastructure — cloud-heavy environments need cryptography and configuration policies that on-prem shops can sometimes fold into fewer documents.
- Overlapping regulation — GDPR, DORA, or sector rules mean some policies (data protection, third-party risk) do double duty and get written once, referenced twice.
- Headcount and locations — multi-site businesses need physical security policies per site, or one policy with site-specific annexes.
- Whether you also hold Cyber Essentials — some technical controls overlap, which can shrink the technological-theme policy set.
- Audit history — a first-time certification in 2026 typically needs more explicit documentation than a business renewing after several successful surveillance audits.
A policy suite mapped correctly to all 93 Annex A controls is the single strongest signal an auditor looks for on day one of a certification audit.
Writing and maintaining that mapping by hand in spreadsheets is where most lean teams lose weeks. OneClickComply automates the policy-to-control mapping and flags gaps against your Statement of Applicability before an auditor does.
Automate your ISO 27001 policy suite
Map policies to Annex A controls and keep evidence audit-ready.
How many policies do you need for ISO 27001?
There's no fixed number in the standard itself. ISO 27001:2022 sets the requirement — clause 5.2 for the top-level policy, Annex A control 5.1 for topic-specific policies — but leaves the count to your scope. Most businesses end up with one overarching policy plus a set of topic-specific policies sized to however many of the 93 controls remain applicable after scoping.
Is a single security policy enough for ISO 27001 certification?
No — a single policy is not enough for ISO 27001 certification in 2026, or under any prior version of the standard. Clause 5.2 requires the overarching policy, and Annex A control 5.1 separately requires topic-specific policies covering areas like access control, cryptography, and supplier relationships.
Do you need a physical security policy for ISO 27001?
Yes, a physical security policy is required for ISO 27001 if your ISMS scope includes any physical premises, covering secure areas, equipment siting, and clear desk practices. Fully remote businesses with no office or data centre in scope can narrow this policy significantly, but it rarely disappears entirely.
How long does it take to write an ISO 27001 policy suite?
Writing a full policy suite from scratch typically takes several weeks for a small team working manually, driven mostly by the mapping work between policies and the 93 Annex A controls, not the writing itself. Teams using compliance automation start from control-mapped templates instead of blank documents — ISO 27001 compliance software for lean security teams shows what that looks like in practice.
Frequently asked questions
One last thing
The policy rewritten most often after a failed audit isn't a technical one — it's the supplier security policy, because businesses scope it too narrowly and miss subcontractors sitting two tiers down the supply chain. Check that policy against your actual vendor list before your next audit, not after. Seriously simple cyber compliance starts with a policy suite that matches reality.