_1762866128417-DS2_OO1j.png)
Required by the standard, required by risk
ISO/IEC 27001 has two sources of documentation requirements. Clauses 4 to 10 explicitly require documented information in certain places – such as the scope, the risk assessment or the statement of applicability. In addition, documents follow from the Annex A controls you have declared applicable based on your risk assessment. Some of these controls explicitly require documented rules, such as policies or documented operating procedures.
As with all ISO management systems, clause 7.5.1 b also applies: you determine which further documentation is necessary for the effectiveness of your ISMS. The extent depends on size, activities, complexity and the competence of the people involved.
Mandatory documents from clauses 4 to 10
| Clause | Document or record | Type |
|---|---|---|
| 4.3 | ISMS scope | Maintain |
| 5.2 | Information security policy | Maintain |
| 6.1.2 | Information security risk assessment process | Maintain |
| 6.1.3 | Risk treatment process | Maintain |
| 6.1.3 d | Statement of applicability (SoA) | Maintain |
| 6.1.3 e | Risk treatment plan | Maintain |
| 6.2 | Information security objectives | Maintain |
| 7.2 | Evidence of competence | Retain |
| 8.1 | Evidence that processes were carried out as planned | Retain |
| 8.2 | Results of risk assessments | Retain |
| 8.3 | Results of risk treatment | Retain |
| 9.1 | Monitoring and measurement results | Retain |
| 9.2 | Audit programme and audit results | Retain |
| 9.3 | Results of the management review | Retain |
| 10.2 | Nonconformities, actions taken and results of corrective actions | Retain |
The statement of applicability (SoA)
The SoA links the risk assessment to the controls. It lists all 93 Annex A controls and answers three questions for each: is the control applicable? Why or why not? Is it implemented? You can also add your own controls beyond Annex A.
| Column | Content | Example |
|---|---|---|
| Control | Number and title from Annex A | A.8.13 Information backup |
| Applicable | Yes or no | Yes |
| Justification | Link to risk, law or contract | Risk R-12 data loss; customer contracts |
| Implementation status | Implemented, partial, planned | Implemented |
| Evidence | Reference to policy or record | Backup policy, restore tests |
Exclusions are allowed but must be justified traceably. "We have no in-house software development" is a good reason to exclude A.8.25 to A.8.28 – "too much effort" is not.
Documents for the Annex A controls
Which policies and procedures you need depends on your SoA. This overview shows documents found in almost every ISMS:
| Control | Typical document |
|---|---|
| A.5.1 | Topic-specific information security policies |
| A.5.9 | Inventory of information and other associated assets |
| A.5.10 | Acceptable use of information and assets |
| A.5.15–A.5.18 | Access control, identity and access rights management |
| A.5.19–A.5.23 | Supplier relationships and use of cloud services |
| A.5.24–A.5.28 | Information security incident management and collection of evidence |
| A.5.29, A.5.30 | Information security during disruption, ICT readiness for business continuity |
| A.5.31 | Register of legal, statutory, regulatory and contractual requirements |
| A.5.37 | Documented operating procedures |
| A.6.1–A.6.6 | Screening, terms of employment, awareness, confidentiality agreements |
| A.8.13 | Information backup |
| A.8.32 | Change management |
The eleven new controls in the 2022 edition
The 2022 edition restructured Annex A from 114 to 93 controls. Many were merged and eleven are new. Check whether your documentation covers these topics:
- A.5.7 Threat intelligence
- A.5.23 Information security for use of cloud services
- A.5.30 ICT readiness for business continuity
- A.7.4 Physical security monitoring
- A.8.9 Configuration management
- A.8.10 Information deletion
- A.8.11 Data masking
- A.8.12 Data leakage prevention
- A.8.16 Monitoring activities
- A.8.23 Web filtering
- A.8.28 Secure coding
A sensible document structure
| Level | Content | Size |
|---|---|---|
| Policy | Information security policy with objectives and management commitment | 1 to 3 pages |
| Methods | Scope, risk method, SoA, risk treatment plan | Core of the ISMS |
| Topic policies | Access, cryptography, backup, suppliers, incidents, remote working | 1 to 5 pages each |
| Operating procedures | Specific workflows for IT and business areas | As needed |
| Records | Logs, reports, trainings, tests | Ongoing |
Many companies summarise the rules for employees in one short policy – passwords, clean desk, remote working, email and AI tools. This policy is distributed with a read acknowledgement and covered in the annual awareness training.
Example: document set of a SaaS provider
A software provider with 80 employees and cloud infrastructure typically ends up with this set:
- Policy, scope, roles, objectives
- Risk method, risk register, risk treatment plan, SoA
- Asset inventory and classification policy
- Policies on access, cryptography, backup, logging, change and secure development
- Supplier and cloud policy with provider evaluations
- Incident management with reporting paths and playbooks
- Business continuity concept with restore tests
- Security rules for employees and training concept
- Audit programme, audit reports, management review, action list
What auditors look for
- A common thread: can risks, SoA, policies and evidence be linked without gaps?
- Currency: were the risk assessment and SoA revised after significant changes?
- Implementation: are policies lived – for example, are access reviews actually carried out and documented?
- Approval: has management demonstrably approved the policy and residual risks?
- Competence: is there evidence of training and awareness for all employees?
Common mistakes in ISMS documentation
- Template policies without adaptation: purchased templates describe controls that are not actually implemented. Auditors quickly spot the gap between paper and practice.
- SoA without link to risks: controls are marked applicable across the board, without justification from the risk assessment.
- Outdated inventory: new cloud services, systems or sites are missing from the asset inventory and therefore from the risk assessment.
- Missing evidence: policies require regular checks – such as of access rights or backups – but there are no records of them.
- Too many documents: extensive manuals nobody reads do more harm than good. Short, role-based rules are more likely to be followed.
ISO 27001 documents and NIS2
Organisations in scope of NIS2 can largely reuse their ISO 27001 documentation. Mainly add documentation of the scoping and registration, reporting paths and deadlines for significant incidents, and evidence of management approval of the measures and of management training. The guide NIS2 incident reporting describes the deadlines in detail.
Step by step to a complete document set
- 1
Define the scope
Determine sites, organisational units, systems and interfaces.
- 2
Risk method and inventory
Describe the method, record information assets and name risk owners.
- 3
Assess and treat risks
Create the risk register, select controls, derive the SoA.
- 4
Write policies
For each applicable control decide whether a policy, a procedure or a record is sufficient.
- 5
Approve, distribute, train
Approve documents, distribute them with read acknowledgements and raise employee awareness.
- 6
Collect evidence
Document operations, audit internally, hold the management review.
ISO 27001 documentation with docxpert
docxpert includes 27 templates mapped to ISO 27001, including risk assessment and treatment, statement of applicability, information assets and access control, security rules for staff, technical controls, security incidents and business continuity. The requirement catalogue for the gap analysis covers clauses and Annex A; traceability links controls to your evidence.
Frequently asked questions
What is the difference between the risk treatment plan and the SoA?
The SoA lists all Annex A controls with applicability, justification and implementation status. The risk treatment plan describes which controls are implemented for which risks, by whom and by when. The two are closely linked and usually maintained together.
May documents be in a language other than the local one?
Yes, the standard does not prescribe a language. What matters is that employees understand the rules relevant to them. Policies for staff should therefore be available in the language spoken in the company.
How many mandatory documents does ISO 27001 have?
Clauses 4 to 10 contain around 15 explicitly required documents and records. Policies and procedures for the applicable Annex A controls come on top, so a typical ISMS has 20 to 40 controlled documents.
Is the statement of applicability mandatory?
Yes. The SoA is explicitly required in 6.1.3 d and is one of the most important documents in the certification audit.
Do I need a separate policy for every Annex A control?
No. Many controls can be grouped into topic policies; others are evidenced by technical configuration or records. What matters is that the SoA references the relevant evidence.
Does the risk register have to be a separate document?
The standard requires the results of the risk assessment as retained information, but no specific format. A register as a spreadsheet or in software is common.
How often must ISMS documents be reviewed?
At least as part of the annual management review and whenever significant changes, incidents or new requirements occur. The risk assessment must be repeated at planned intervals.
Can I reuse documents from ISO 9001?
Yes. Control of documented information, internal audit, management review and corrective action can be shared and extended with ISMS-specific content.
How do I link an Annex A control to credible evidence?
Start with the statement of applicability and record why a control applies or is excluded. Then point to evidence that demonstrates its actual implementation: an approved policy, system configuration, log, contract or documented test may support different parts of the claim. Check that the evidence is current, covers the relevant scope and has an accountable owner. A document title alone does not demonstrate effectiveness; add results from checks or samples where needed. If a control is not applicable, keep the rationale and review it when circumstances change. This mapping makes the relationship between risk, decision and implementation understandable without creating a separate document for every control.