ISO 27001 Documentation: What You Need
Less than you think, more than nothing
ISO 27001 requires documented information, but it does not require bureaucracy. A 20-person SaaS company can pass certification with 15-20 concise documents. A 500-person enterprise might need more, but the standard is clear about what must be documented versus what is optional. The key is understanding what auditors actually look for - and it is rarely volume.
The mandatory documents
ISO 27001:2022 explicitly requires these documented items. If any are missing, your auditor will raise a nonconformity.
| Document | Clause | What it covers |
|---|---|---|
| ISMS scope | 4.3 | Boundaries, applicability, and justification for exclusions |
| Information security policy | 5.2 | Leadership commitment, direction, and framework for objectives |
| Risk assessment methodology | 6.1.2 | How you identify, analyze, and evaluate risks - repeatable and consistent |
| Risk treatment plan | 6.1.3 | Actions, owners, timelines for addressing unacceptable risks |
| Statement of Applicability | 6.1.3 d) | Which Annex A controls apply, which do not, and why |
| Information security objectives | 6.2 | Measurable goals, who is responsible, how progress is tracked |
| Evidence of competence | 7.2 | Training records, qualifications, certifications for key roles |
| Operational planning and control | 8.1 | How you manage processes needed to meet ISMS requirements |
| Risk assessment results | 8.2 | The output of each risk assessment cycle |
| Risk treatment results | 8.3 | Evidence that treatment actions were implemented |
| Monitoring and measurement results | 9.1 | How you measure ISMS effectiveness |
| Internal audit program and results | 9.2 | Audit plans, reports, findings, corrective actions |
| Management review results | 9.3 | Minutes, decisions, and actions from management reviews |
| Nonconformities and corrective actions | 10.2 | What went wrong, root cause analysis, what you did about it |
Beyond these core documents, specific Annex A controls require their own documented information. Asset inventories (A.5.9), acceptable use policies (A.5.10), incident response procedures (A.5.26), access control records (A.5.18), and backup policies (A.8.13) are among the most commonly audited.
What auditors actually check
Auditors do not read every document cover to cover. They sample. Their approach typically follows this pattern:
They verify mandatory documents exist and are current. A policy dated three years ago that has never been reviewed is a finding. Documents must show evidence of regular review - even if the review concluded no changes were needed.
They trace from risk to control to evidence. An auditor picks a risk from your register, follows it to the treatment plan, checks the Statement of Applicability for the relevant controls, then asks to see evidence that those controls are operating. This chain must be consistent and traceable.
They interview staff. Documentation only matters if people follow it. An auditor will ask a developer about the secure coding policy, a new joiner about onboarding security training, or a system administrator about access review procedures. If staff do not know the policies exist, polished documents will not save you.
They look for the PDCA cycle. Plan-Do-Check-Act should be visible throughout your documentation. Policies are planned, controls are implemented, audits check effectiveness, and management reviews drive improvement. If your documents show only “plan” and “do” but no “check” and “act,” expect questions.
How much documentation is enough
The standard says “documented information” - it does not say “200-page policy manual.” Here is what we see work in practice:
Policies: One to two pages each. State the purpose, scope, key requirements, roles, and review cycle. A good information security policy fits on a single page. Supporting policies (access control, acceptable use, incident management) should be similarly concise.
Procedures: Step-by-step instructions for critical processes. These need enough detail that someone could follow them without the author present, but they should not describe every click in every tool. Focus on decisions, escalation paths, and expected outcomes.
Records: Evidence that processes were followed. Risk assessment outputs, audit reports, management review minutes, training logs, incident records. These accumulate over time and form the evidence base your auditor will sample from.
The format does not matter. ISO 27001 does not require Word documents, SharePoint sites, or dedicated GRC platforms. We have seen organizations pass certification with documentation in Notion, Confluence, Google Docs, or even well-organized markdown files in Git. What matters is that documents are version-controlled, accessible to the right people, and reviewed regularly.
For a small organization (under 50 people), a practical documentation set typically includes:
- 1 overarching information security policy
- 8-12 supporting policies (access control, acceptable use, incident management, change management, supplier security, backup, cryptography, physical security, HR security, BYOD)
- A risk register and treatment plan (often a single spreadsheet)
- A Statement of Applicability
- An internal audit program and reports
- Management review minutes
- Training and competence records
That is roughly 15-20 documents plus operational records. Not the mountain of paperwork people expect.
Common documentation mistakes
Writing policies nobody reads. A 30-page access control policy is worse than a 2-page one if nobody knows what it says. Write for your audience. Technical procedures for technical staff. Executive summaries for leadership. Keep language direct and specific.
Copying templates without tailoring. Generic templates are fine as starting points, but your documentation must reflect your actual organization. An auditor will notice when your “small SaaS company” policy references “factory floor access controls.” Tailor everything to your context and scope.
Documenting and forgetting. Every mandatory document needs a review cycle. Annual review is the standard expectation for policies. Risk assessments should be reviewed at least annually or when significant changes occur. If your documents have not been touched since initial certification, your surveillance audit will flag this.
Over-documenting. More documentation creates more maintenance burden and more opportunities for inconsistency. If two documents say different things about the same process, that is a finding. Keep your documentation set lean and consistent rather than comprehensive and contradictory.
Missing the records. Policies describe what should happen. Records prove it did happen. Organizations sometimes focus heavily on writing policies but forget to collect the evidence - training sign-off sheets, access review logs, incident reports, backup test results. Without records, policies are just aspirations.
How 27kay can help
We help organizations build documentation that passes certification without creating a maintenance nightmare. Our approach starts lean - the minimum viable documentation set for your scope and size - and we help you build habits for maintaining it over time. No 300-page policy libraries that gather dust.
Whether you are starting from scratch or preparing existing documentation for a surveillance audit, let’s talk - we will review what you have, identify what is missing, and help you close the gaps efficiently.