Mandatory documents for ISO 27001
Many organisations think they need thick manuals for ISO 27001 . That is a misunderstanding. The standard requires a limited set of mandatory documents, supplemented by records as evidence that processes are followed. Anything you produce beyond that is a choice. Fewer documents that everyone knows work better than an archive nobody reads.
On this page, you will find a complete overview of what ISO 27001 requires, per clause and for Annex A. Just as important: what the standard does not require.
Two types of documented information
ISO 27001 distinguishes two kinds of documented information:
| Type | What it is | Purpose |
|---|---|---|
| Documents | Policies, procedures, plans, scope | Describe how you work |
| Records | Logs, minutes, reports, training overviews | Prove that you do what you say |
You describe documents in advance. You capture records afterwards. Both are mandatory, but for different clauses.
Mandatory documents per clause
The table below shows which documents the standard explicitly requires, grouped by clause. The wording “[documented information]” in the standard is the indication that something is mandatory.
| Clause | Mandatory document or record |
|---|---|
| 4.3 | Scope of the ISMS |
| 5.2 | Information security policy |
| 6.1.2 | Results of the risk assessment |
| 6.1.3 | Risk treatment plan |
| 6.1.3 | Statement of Applicability (SoA), see Statement of Applicability |
| 6.2 | Information security objectives |
| 7.2 | Evidence of competence (training records) |
| 8.1 | Evidence of operational planning and control |
| 8.2 | Results of risk assessments (up to date) |
| 8.3 | Results of risk treatment |
| 9.1 | Results of monitoring and measurement |
| 9.2 | Audit programme and internal audit results |
| 9.3 | Results of management reviews |
| 10.2 | Nonconformities and corrective actions |
The SoA (clause 6.1.3) is the most unique document in ISO 27001. No other ISO management system standard has this document. It is also the first document the auditor asks for in Stage 1. More on this in the Statement of Applicability page.
Additional mandatory records from Annex A
In addition to the clause requirements, some Annex A controls also require records. These are the most common:
| Annex A control | Mandatory record |
|---|---|
| A.5.9 Inventory of information | Asset register |
| A.5.12-5.13 Classification and labelling | Classification scheme and evidence of use |
| A.5.24-5.28 Incident management | Incident register |
| A.6.1 Screening | Evidence of background checks (in line with privacy legislation) |
| A.6.3 Information security awareness | Training records |
| A.6.5 Responsibilities after termination | Evidence of revoking access rights |
| A.8.8 Management of technical vulnerabilities | Patch records or vulnerability log |
Which Annex A controls are mandatory for you depends on your SoA. If you exclude a control, the related record requirement also falls away.
What is NOT mandatory
Many organisations document more than the standard asks for. This is understandable, because more paper feels safer, but it backfires. Documents that nobody reads are proof that the system does not work. Whether you need a separate manual is covered on that page.
The standard does not require the following commonly mentioned items:
| What people think is mandatory | What the standard actually requires |
|---|---|
| A separate manual | Nothing required; integrate documents into an existing wiki or SharePoint |
| Procedures for all 93 Annex A controls | Only for the controls in your SoA, and only where the standard asks for a procedure |
| A fully described threat catalogue | A documented, repeatable risk assessment |
| A separate ISMS tool or GRC software | No software requirement; a well-organised folder structure is sufficient |
| Annual employee training as a video | Any form of awareness that is documented; the format is free |
A common mistake in small companies is downloading a comprehensive template package and filling it in. The auditor checks whether the documentation fits your organisation and is demonstrably used. A lean, workable system is stronger than a thick archive that nobody knows.
Keeping documentation lean: practical tips
One document per topic
Do not write the information security policy as a 20-page document. One or two pages that clearly describe the starting points are enough. Write procedures in the language employees understand, not in the language of the standard.
Use existing systems
Do you have Microsoft 365 or Google Workspace? Use SharePoint, Notion or Confluence as document storage. You do not need a separate GRC tool for a first certification. A version control system is required, though. Use what you already have.
Version control and approval are mandatory
ISO 27001 requires that documents are controlled: they have a version, a date, an author and an approval. This does not need to be complicated. A footer that reads “Version 1.2, approved by [name], [date]” is enough.
Link to existing processes
Do you already have an onboarding process? Add the security check and the removal of access rights at offboarding to that process. That way, you do not need to write a separate awareness policy that is managed on its own.
The documentation set in the step-by-step guide
You build the documentation set during the implementation project. You start with the scope and the policy (phase 1), the risk assessment and SoA (phases 3 and 4), and the procedures and records (phases 5 to 7). In phase 7, you bring everything together and check whether the set is complete before the internal audit takes place.
Want to know which documents need to be ready in each phase? See the full step-by-step guide.
More information
- Statement of Applicability: The SoA step by step
- Requirements of the standard: All clauses explained
- Step-by-step guide: When do you create which document?
- Annex A: The 93 controls
- NEN-EN-ISO/IEC 27001:2022 : Official standard text (NEN)