ISO 27001 policies list: what's mandatory and what's typical
ISO/IEC 27001:2022 requires exactly one policy by name: the information security policy (clause 5.2). Everything else on a typical "ISO 27001 policies list" is either another kind of required record (scope, risk assessment, Statement of Applicability and so on), or a topic-specific policy you write because you've chosen an Annex A control that needs one.
That distinction matters for a small business. Template packs often sell 30 or 40 policies. You don't need 40. You need the mandatory documents, plus the policies that match the controls in your Statement of Applicability, written so they describe what you actually do.
Mandatory documented information in clauses 4 to 10
These come straight from the requirements. If your ISMS is certified against ISO/IEC 27001:2022, the auditor will expect each of them.
| Clause | Document or record | What it is |
|---|---|---|
| 4.3 | Scope of the ISMS | What the ISMS covers and its boundaries |
| 5.2 | Information security policy | Top-level policy set by top management |
| 6.1.2 | Risk assessment process | Your method, including risk criteria |
| 6.1.3 | Risk treatment process | How you decide what to do about each risk |
| 6.1.3 d | Statement of Applicability | All 93 Annex A controls, included or excluded, with reasons and status |
| 6.2 | Information security objectives | Measurable goals with owners and dates |
| 7.2 | Evidence of competence | Training records, qualifications, experience |
| 7.5.1 b | Other documents you decide are necessary | Whatever your ISMS needs to work |
| 8.1 | Operational records | Enough to show processes were carried out as planned |
| 8.2 | Risk assessment results | Your risk register |
| 8.3 | Risk treatment results | What was done about each risk |
| 9.1 | Monitoring and measurement results | What you measured and what it showed |
| 9.2 | Internal audit programme and results | The plan and the audit reports |
| 9.3 | Management review results | Minutes and decisions |
| 10.2 | Nonconformities and corrective actions | What went wrong, what you did, and the result |
Two points people often miss:
- The risk treatment plan (6.1.3 e) has to exist and be approved by the risk owners, and the standard requires you to keep documented information about the treatment process. In practice, it's a document.
- Clause 7.5.1 b is open-ended on purpose. The standard leaves it to you to decide what else needs writing down. That's where most topic-specific policies and procedures come in.
What Annex A says about policies
Annex A control 5.1 Policies for information security says you should have an information security policy and topic-specific policies, approved by management, published, communicated to the people they apply to, and reviewed at planned intervals or when things change.
Annex A doesn't give a fixed list of topic-specific policies. ISO/IEC 27002:2022, the guidance that accompanies it, gives examples, and several other controls are easiest to evidence with a short written policy or rule set. Because Annex A controls apply only when you've included them in your Statement of Applicability, these policies are expected where the control applies, not mandatory for everyone.
A few controls explicitly expect something written down when you include them, for example:
- 5.10 Acceptable use: rules for acceptable use of information and assets, identified, documented and implemented.
- 5.31 Legal, statutory, regulatory and contractual requirements: identified, documented and kept up to date.
- 5.37 Documented operating procedures: procedures for your information processing facilities, documented and made available to the people who need them.
- 6.6 Confidentiality or non-disclosure agreements: identified, documented, reviewed and signed.
The typical topic-specific policies list
This is the list most small businesses end up with. Each line names the Annex A control it mainly supports, so you can drop a policy if you've excluded the control (with a reason) in your Statement of Applicability, or fold several into one document.
| Policy | Main Annex A controls | What it usually covers |
|---|---|---|
| Acceptable use | 5.10 | What staff may and may not do with company devices, email and data |
| Access control | 5.15 to 5.18, 8.2, 8.5 | Joiners, movers and leavers, passwords and MFA, admin accounts, access reviews |
| Asset management | 5.9, 5.11 | The inventory, owners, returning equipment when people leave |
| Information classification and handling | 5.12, 5.13 | Your classification levels and how each is labelled, stored and shared |
| Information transfer | 5.14 | Sending data by email, file share or removable media, and to whom |
| Supplier security | 5.19 to 5.22 | Checking suppliers before use, contract terms, ongoing review |
| Cloud services | 5.23 | Choosing, using and leaving cloud services |
| Incident management | 5.24 to 5.28, 6.8 | How to report, who decides, how you respond and learn |
| Business continuity | 5.29, 5.30 | Keeping information secure and systems available through disruption |
| Privacy and protection of personal data | 5.34 | How you meet UK GDPR in practice |
| Human resources security | 6.1 to 6.5 | Screening, terms of employment, training, disciplinary process, leavers |
| Remote working | 6.7 | Working from home and travelling, devices and networks |
| Physical security and clear desk | 7.1 to 7.4, 7.7 | Office access, visitors, clear desk and clear screen |
| User endpoint devices | 8.1 | Laptops and phones: management, encryption, updates, lost devices |
| Technical vulnerability management | 8.8 | Patching and vulnerability scanning timescales |
| Backup | 8.13 | What's backed up, how often, where, and how restores are tested |
| Logging and monitoring | 8.15, 8.16 | What you log, how long you keep it, who reviews it |
| Cryptography | 8.24 | Where you use encryption and how keys are managed |
| Secure development | 8.25 to 8.29 | Only if you build software: secure coding, testing, environments |
| Change management | 8.32 | How changes to systems are requested, approved and tested |
Most of these can be a page or two. An auditor would rather read a short policy that matches what happens than a long one that doesn't.
Policies, procedures and records: keep them apart
- A policy says what you require and why ("leavers lose access on their last day").
- A procedure says how it's done, step by step (the leaver checklist).
- A record proves it happened (the completed checklist for each leaver).
The auditor will test the record against the policy. If your access control policy says access is reviewed every quarter, they'll ask for four quarterly reviews. Write policies you can keep.
How to keep the list short
- Start from your Statement of Applicability, not from a template pack. If a control is excluded with a good reason, you don't need its policy.
- Combine where it reads naturally. Many small businesses put acceptable use, remote working, clear desk and endpoint devices into one staff-facing "IT and security rules" document. That's fine as long as each control's requirements are covered and you can show where.
- Write for the reader. Staff need a short acceptable use document they'll actually read. Your IT person needs the access control and backup detail.
- Give every document an owner, a version and a review date, and record who approved it. Clause 7.5 and control 5.1 both expect that discipline.
- Review on a schedule and after changes. A new system, a new supplier or an incident is a reason to look again.
Example: a small business policy set
Larkspur Veterinary Group (fictional), a group of practices with around 60 staff and a cloud-based practice management system, might end up with:
- the information security policy (mandatory, signed off by the directors);
- an access control policy;
- a staff "IT and security rules" document covering acceptable use, remote working, clear desk and devices;
- a supplier and cloud services policy;
- an incident management procedure;
- a backup and continuity plan;
- a data protection policy (they already had one for UK GDPR);
- the mandatory scope, risk method, risk register, Statement of Applicability, treatment plan and objectives.
Secure development is excluded, because they don't build software, and the SoA says so. That's roughly a dozen documents rather than forty.
For the full order of work, from scope to certification audit, see our ISO 27001 checklist.
How ClearIMS helps
ClearIMS helps you generate and maintain the core ISMS documents: scope, Statement of Applicability, risk register, policies and control documents. You describe your business in plain English and it drafts them, so you're editing a draft about your business rather than filling in a template pack. Everything stays a draft until a named person approves it; the AI never approves anything. When you link a policy to a control in the Statement of Applicability, you can highlight the sections that relate to it, so "show me" takes you straight there.
We make the software. Your certification is yours, awarded by your certification body.
Take the 2-minute readiness check, or book a 20-minute call.