ISO/IEC 27001:2022 requires roughly 15 pieces of documented information [1]. That covers your ISMS scope, information security policy, risk assessment methodology and results, Statement of Applicability, internal audit records, management review outputs, and corrective actions. The standard never prescribes format, length, or tooling, so most of these can be surprisingly short.
I have opened Stage 1 audits where the client handed me a 400-page document pack and others where everything lived in Notion across maybe 30 pages of actual content. Both passed. The difference was not volume; it was whether the documents said something real about how the organisation actually operates.
Clause-by-clause list
Here is every piece of documented information the standard explicitly requires you to maintain (documents) or retain (records). I have grouped them by the clause that creates the obligation.
| Clause | Document or record | Maintain or retain | What it actually is |
|---|---|---|---|
| 4.3 | ISMS scope | Maintain | A statement of what is in and out of scope: services, locations, teams, technology boundaries |
| 5.2 | Information security policy | Maintain | A short policy signed by top management, stating objectives and commitment to continual improvement |
| 6.1.2 | Risk assessment process | Maintain | Your methodology: how you identify, analyse, evaluate, and accept or treat risks |
| 6.1.3 | Risk treatment process | Maintain | How you decide what to do about each risk and who owns the actions |
| 6.1.3 d) | Statement of Applicability | Maintain | The SoA: every Annex A control listed with a justification for inclusion or exclusion |
| 6.2 | Information security objectives | Maintain | Measurable objectives, plus plans to achieve them |
| 7.2 | Evidence of competence | Retain | Training records, CVs, certificates, anything proving people can do their security-relevant jobs |
| 8.1 | Operational planning and control | Maintain/Retain | Documents needed to run the ISMS processes and evidence that they ran as planned |
| 8.2 | Risk assessment results | Retain | The output of each risk assessment cycle |
| 8.3 | Risk treatment results | Retain | Evidence that risk treatment plans were carried out |
| 9.1 | Monitoring and measurement results | Retain | Evidence of what you measured and what the results were |
| 9.2 | Internal audit programme and results | Retain | Your audit schedule, the audits themselves, and their findings |
| 9.3 | Management review results | Retain | Minutes or output of each management review, including decisions and actions |
| 10.1 | Nonconformities and corrective actions | Retain | A record of what went wrong, what you did about it, and whether it worked |
That is 14 to 15 items depending on how you count 8.1 [1][2]. Some auditors split risk assessment process and risk treatment process into one document; others count them separately. The number does not matter. What matters is that every requirement has documented evidence behind it.
Commonly needed extras
The standard says you must have documented information "determined by the organisation as being necessary for the effectiveness of the ISMS" (Clause 7.5.1 b) [1]. In practice, this means most organisations also write:
- An acceptable use policy (covering Annex A 5.10)
- An access control policy (5.15, 5.16, 5.18, 8.2 and others)
- A business continuity plan or ICT readiness plan (5.30)
- An incident management procedure (5.24, 5.25, 5.26)
- A supplier security policy or procedure (5.19, 5.20, 5.21)
These are not mandatory in the way Clause 4.3 or 6.1.3 d) are mandatory. But if you exclude them, an auditor will ask how you manage those controls without a documented approach, and "we just know" is not a convincing answer at a Stage 2 [3].
I usually tell founders to keep a shortlist of about eight policies and four or five procedures beyond the core mandatory set. That covers the Annex A controls you are almost certainly applying. You do not need a separate document for every one of the 93 Annex A controls; many controls share a policy.
The Statement of Applicability
The Statement of Applicability (SoA) is the single most important document in your ISMS. It lists all 93 controls from Annex A and, for each one, states whether it is applicable, how it is implemented, and if it is excluded, why [1][4].
I once opened a Stage 2 with a client whose SoA listed 114 controls against the 2022 standard, which only has 93. That is a bad start to a Tuesday. They had copied a 2013-era template and never updated it. The 2013 standard had 114 controls in 14 domains; the 2022 revision consolidated them into 93 controls across four themes [4].
Your SoA should reference your risk treatment plan (so there is a clear line from "we identified this risk" to "we applied this control"). Many auditors check this mapping first because it tells them whether the ISMS is a real system or a documentation exercise.
Document length
Shorter than you think. The standard says "documented information" and nothing about page counts, branded templates, or revision-controlled Word documents [1].
Your ISMS scope (4.3) can be one paragraph. I have seen a perfectly adequate scope statement in three sentences: "We provide X service from Y office. The ISMS covers all employees and contractors involved in delivering that service and the infrastructure supporting it. The following are out of scope: [list]."
Your information security policy (5.2) needs to state objectives, a commitment to continual improvement, and a commitment to satisfying applicable requirements. That is one page. The policy that nobody reads is the 18-page one that tries to combine policy, procedure, and training manual.
Your risk assessment methodology (6.1.2) needs to define how you identify assets and threats, how you rate likelihood and impact, and what your risk acceptance criteria are. Two pages is normal. One page works if you are concise [5].
The records (anything you retain rather than maintain) are evidence, not literature. A management review record can be a meeting note with decisions and action items. An internal audit record can be a spreadsheet with findings and dates closed. The auditor wants to see that the activity happened and produced outcomes, not that it produced a glossy report [3].
Common documentation mistakes
The biggest one is over-documentation. A 30-person SaaS company does not need 40 policies. It needs maybe 10 to 12 documents that reflect how it actually works, plus records proving those processes ran.
The second is orphaned documents. A policy that was written for certification, never read by staff, and never updated is worse than no policy at all, because it creates a gap between what you said you would do and what you actually do. That gap is a nonconformity waiting to happen [6].
The third is confusing "maintain" with "retain". Documents you maintain are living things (your scope, your policies, your SoA) that you keep current as the business changes. Records you retain are snapshots, like the results of last quarter's risk assessment or the minutes of your February management review, kept as evidence but never edited after the fact. Mix these up and your version control becomes a mess.
Getting started
If you are building your ISMS from scratch, start with the five documents that unlock everything else:
- ISMS scope (4.3), because you cannot assess risks on something you have not scoped
- Information security policy (5.2), because management commitment triggers the rest
- Risk assessment methodology (6.1.2), because you need this before you can run an assessment
- Risk assessment results (8.2), the output of actually doing the assessment
- Statement of Applicability (6.1.3 d), because this tells you which controls apply and therefore which additional policies you need to write
Everything else flows from those five. Your requirements become concrete once the SoA is done, because you can see exactly which controls you need to document and evidence.
At Calibre, we scope in hours rather than weeks precisely because companies that get these five documents right tend to breeze through the rest. The documentation is not the hard part. The hard part is making sure the documents describe what you actually do.
FAQ
No. The standard says "documented information" and never mentions Word, PDF, or any particular template [1]. Your documents can live in Notion, Confluence, Google Docs, a wiki, or even a git repository, provided they are controlled, versioned, and accessible to the people who need them.
Yes, and most people do. The risk is that a template describes a generic company, not yours. An auditor will spot copy-pasted content that does not match your actual operations, and that creates findings. Use templates as a starting point, then rewrite every section to describe what you actually do.
Sources
- 1.ISO/IEC. (2022). "ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection - Information security management systems - Requirements". https://www.iso.org/standard/27001
- 2.ISO/IEC. (2022). "ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection - Information security controls". https://www.iso.org/standard/75652.html
- 3.ISO/IEC. (2015). "ISO/IEC 17021-1:2015 Conformity assessment - Requirements for bodies providing audit and certification of management systems". https://www.iso.org/standard/61651.html
- 4.International Accreditation Forum. (2022). "IAF MD 26:2022 Transition Requirements for ISO/IEC 27001:2022". https://iaf.nu/en/iaf-documents/
- 5.ISO. (2025). "The ISO Survey of Management System Standard Certifications 2024". https://www.iso.org/the-iso-survey.html
- 6.Department for Science, Innovation and Technology. (2026). "Cyber Security Breaches Survey 2025/2026". GOV.UK. https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026
