ISO 27001 requires far fewer documents than most implementations produce. The standard names a specific list; everything beyond it is your choice — and every optional document you create becomes something you must review, approve and keep current, forever.
The mandatory documents
- Scope of the ISMS — what is in and out.
- Information security policy, approved by top management.
- Risk assessment and risk treatment process — the method, documented before you use it.
- Statement of Applicability — applicable controls, justifications, implementation status, and reasons for every exclusion.
- Risk treatment plan.
- Information security objectives and how they will be achieved.
The mandatory records
Records prove the system operated. These are what auditors sample:
- Evidence of competence and awareness.
- Results of risk assessment and risk treatment.
- Monitoring and measurement results.
- Internal audit programme and its results.
- Management review minutes.
- Nonconformities and corrective actions taken.
Note the split: documents state intent and get revised; records prove what happened and must not change. The standard controls them differently, and conflating the two is behind a large share of routine findings.
Keep the required set current, automatically
GRC Copilot holds your policies, SoA, risk register and evidence together with review dates and owners, so nothing quietly expires.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
What is not mandatory
Frequently produced, never required by the standard: an asset inventory as a standalone document (you need the information, not the artefact), individual topic policies, procedures for every control, and a formal ISMS manual — a carry-over from older standards that no longer serves a purpose.
Produce these only where they change behaviour. A procedure that exists because a template listed it, which nobody follows, is worse than nothing: it creates a documented standard you are visibly failing.
The over-documentation trap
Large document sets fail in a predictable way. Each document needs an owner, an annual review and approval evidence. A set of forty policies means forty review cycles — and the first surveillance audit finds a dozen of them overdue, which is a nonconformity you manufactured for yourself.
A small organisation is usually better served by one information security policy with focused sections than by twenty separate policy documents.
What auditors actually check
- The mandatory list exists and is approved.
- Version, owner, approval date and approver are on the document itself, not only in repository metadata.
- One authoritative location — three versions in a wiki, a drive and an inbox means the document is not controlled.
- Review happened on schedule, evidenced even when nothing changed. "Reviewed, no changes required" with a date and a name is valid; silence is not.
- People can find the documents that apply to them, and know they exist.
Frequently asked questions
Do we need a separate policy per Annex A control?
No. Coverage matters, not document count. One policy can address many controls.
How often must documents be reviewed?
Annually is the common baseline, plus on significant change. Whatever interval your own policy states becomes the standard you are audited against.
Is an ISMS manual required?
No. It is a legacy artefact from older management system standards and adds maintenance without adding assurance.
Can policies live in a wiki?
Yes, provided it supports approval, version history and access control. Freely editable pages with no approval trail are weak for policy.
Key takeaways
- The mandatory list is short — six documents and six record types.
- Every optional document is a permanent review obligation.
- One authoritative location, with version and approval on the document itself.
- Evidence the review happened even when nothing changed.