Why ISO 27001 is policy-heavy
ISO 27001 is a management system standard, not a technical checklist. Auditors do not care how clever your firewall is — they care that you decided how it should be configured, wrote it down, communicated it, reviewed it and proved you followed it. Documented policies are the connective tissue that turns scattered security practices into a defensible management system.
The 2022 revision (ISO/IEC 27001:2022) reorganised Annex A from 114 controls across 14 domains into 93 controls grouped under four themes — Organizational (37), People (8), Physical (14) and Technological (34) — and introduced 11 genuinely new controls such as threat intelligence, information security for cloud services, and data leakage prevention. The clause requirements that drive your documentation, however, did not change in spirit: clauses 4 to 10 still tell you exactly what you must write down.
Two kinds of "required" documents
A point that trips up most first-timers: ISO 27001 has two distinct documentation obligations, and conflating them is a common cause of audit friction.
- Mandatory documented information — these are explicitly required by clauses 4–10 of the standard regardless of your scope. They include the scope of the ISMS (clause 4.3), the information security policy (5.2), the risk assessment and risk treatment process (6.1.2–6.1.3), the Statement of Applicability (6.1.3 d), security objectives (6.2), evidence of competence (7.2), and records of monitoring, internal audit and management review (9.1–9.3). If any of these is missing, you have a major non-conformity — full stop.
- Annex A control policies — Annex A control 5.1 requires "policies for information security" to be defined and approved. The standard does not hand you a fixed list of policy titles; it expects you to produce the topic-specific policies your risk assessment justifies. The 14 below are the practical baseline that virtually every SaaS ends up writing.
In other words: the *information security policy* is mandatory by name; the other thirteen are mandatory in *effect* because Annex A 5.1, 5.15, 8.24 and friends require those topics to be governed by approved policy.
The 14 baseline policies, mapped to Annex A:2022
| # | Policy | Primary Annex A:2022 control |
|---|---|---|
| 1 | Information security policy | 5.1 |
| 2 | Acceptable use policy | 5.10, 8.1 |
| 3 | Access control policy | 5.15, 5.16, 5.18 |
| 4 | Password / authentication policy | 5.17, 8.5 |
| 5 | Cryptography & key management policy | 8.24 |
| 6 | Backup policy | 8.13 |
| 7 | Endpoint / malware protection policy | 8.1, 8.7 |
| 8 | Change management policy | 8.32 |
| 9 | Incident response policy | 5.24, 5.25, 5.26 |
| 10 | Business continuity policy | 5.29, 5.30 |
| 11 | Data classification & handling policy | 5.12, 5.13 |
| 12 | Supplier security policy | 5.19, 5.20, 5.21 |
| 13 | Remote work policy | 6.7 |
| 14 | Secure network & remote access policy | 8.20, 8.21, 8.22 |
You can scope a smaller set, but you must be able to justify every exclusion in your Statement of Applicability. In practice, removing any of these fourteen invites questions an auditor would rather you had pre-empted.
Anatomy of a policy that passes
A policy that survives an audit is not the longest one — it is the one that answers the auditor's three questions on its own front page. Take an access control policy as the worked example:
- Purpose & scope — one paragraph: which systems, which identities, which environments.
- The actual rules — least privilege by default; access granted only via a ticketed request approved by the data owner; MFA mandatory on all internet-facing admin access; quarterly access reviews; revocation within 24 hours of an employee leaving.
- Roles — who approves access, who performs the quarterly review, who owns the policy.
- Approval block — name, role, version, date approved.
- Review date — next scheduled review, and the trigger events that force an earlier one.
Notice that the rules are *specific and testable*. "Access is controlled appropriately" is unauditable. "Access is reviewed every quarter and revoked within 24 hours of offboarding" gives the auditor something to sample against your HR records and your ticketing system.
What auditors actually check
For each policy, the auditor asks three questions — and then looks for evidence:
- Approval — who approved it, when, on what version? (They will ask to see the signature or the approval record.)
- Communication — how did employees learn about it (induction email, intranet, signed acknowledgement)? (They will sample a few staff.)
- Review — when was it last reviewed, annually or after a major change? (They will check the review date is not stale.)
If you cannot answer all three, the policy fails — even if its content is flawless. This is why a documented, tamper-evident change history matters more than perfect prose.
Maintaining the set after certification
Certification is a three-year cycle with surveillance audits in years one and two and recertification in year three. The fastest way to lose a certificate is to let the policies freeze the day after the stage-two audit. Build in:
- An annual review of every policy, plus an out-of-cycle review whenever a control materially changes.
- A management review at least annually that revisits objectives, incidents, audit results and the risk treatment plan (clause 9.3).
- A living Statement of Applicability — every time you adopt or retire a control, the SoA and the relevant policy move together.
Primary sources worth reading
- ISO/IEC 27001:2022 — the standard itself (iso.org/standard/27001).
- ENISA guidance on information security management for SMEs (enisa.europa.eu).
- NIST SP 800-63B for modern, evidence-based authentication requirements that align well with control 8.5 (pages.nist.gov/800-63-3/sp800-63b.html).
How PolicyForge accelerates this
Every PolicyForge template is mapped to its specific Annex A:2022 control, comes in English and French, and includes an approval block, communication notes and a review date field. You generate the fourteen baseline policies in under 30 minutes and walk into your audit with the documentation already structured the way an auditor reads it.