Documenting ISO 27001 controls is where most implementations waste time or get the focus wrong. The common problem is not a lack of documentation, it is documentation that does not reflect what actually happens in the organisation, or that came from generic templates nobody on the team recognises as their own.
A certification auditor does not value the thickness of the binders: they value the coherence between what the policies say, what the records show and what the team answers when asked. This guide explains how to reach that coherence efficiently, without producing documentation that nobody will maintain.
What ISO 27001 means by “documented information”
The current version of ISO/IEC 27001 uses the term documented information instead of the classic “documents and records”. The distinction matters because the standard separates two functions:
- Documents: describe how things are done (policies, procedures, methodologies). They are written and updated when a process changes.
- Records: prove that what the document says was actually done (minutes, logs, review evidence). They are generated in day-to-day operations.
The most frequent mistake is creating many documents and few records. An auditor can live with a brief policy if records demonstrate the process works. They cannot pass a system full of perfect policies with no evidence that anyone follows them.
The standard explicitly requires documented information at specific points in clauses 4 to 10. For the Annex A controls, the catalogue of 93 controls in ISO 27001:2022, the requirement is not to document every control with its own procedure, but to be able to demonstrate that the control exists and works.
The Statement of Applicability (SoA): the ISMS’s central document
The Statement of Applicability (SoA) is the document that connects the Annex A controls to your organisation’s reality. It is mandatory and is usually the first thing a certification auditor requests.
For each of the 93 Annex A controls, the SoA must record:
- Whether the control applies or not, and if not, the justification.
- Whether the control is implemented, and to what degree.
- The reference to the policy, procedure or evidence that supports it.
A well-built SoA is not a spreadsheet with 93 rows of “yes applies / yes implemented” with nothing else. Each row must be traceable to something real: a procedure, a system, a record. If you cannot make that connection for a control you mark as implemented, you have a potential non-conformity before the audit begins.
Practical guidance:
- Do not exclude controls for convenience. Excluding a control requires solid justification (the risk does not exist, or another control covers it equivalently). Auditors review exclusions with particular attention.
- Use real cross-references. If control 8.1 (information assets management) is covered by your asset inventory tool, say exactly which tool and where the records can be seen.
- Keep the SoA alive. It is a document that must be updated when the scope changes, when a new system is introduced or when a relevant process changes.
What documentation is mandatory by clause
Beyond the SoA, the standard requires documented information at specific points in clauses 4 to 10. The minimum list no ISMS can go into audit without:
Clause 4: Context
- ISMS scope (explicitly documented).
Clause 5: Leadership
- Information security policy (approved by management, available to relevant interested parties).
Clause 6: Planning
- Risk assessment and treatment methodology.
- Risk assessment results (the actual analysis).
- Risk treatment plan.
- Statement of Applicability (SoA).
- Information security objectives.
Clause 7: Support
- Competencies of staff with security roles.
- Evidence of training and awareness.
Clause 8: Operation
- Updated risk assessment results.
- Updated risk treatment results.
Clause 9: Performance evaluation
- Monitoring and metrics results.
- Internal audit results and audit programme.
- Management review results.
Clause 10: Improvement
- Non-conformities and corrective actions taken.
Everything else, operating procedures, technical instructions, incident records, access logs, is recommended or needed to evidence controls, but the standard does not prescribe a specific format. That is good news: you can adapt the level of detail to your organisation.
How to document each Annex A control without drowning in paperwork
The catalogue of 93 Annex A controls can seem overwhelming. The key is understanding that not all controls require the same level of documentation.
Process controls (such as access management, incident management, change management) need:
- A procedure describing who does what, when and with what authorisation.
- Records proving the process runs (tickets, minutes, logs).
Technical controls (encryption, vulnerability management, backups) need:
- A documented technical policy or decision (which algorithm, what frequency, what scope).
- Technical evidence that it is running (configuration, automated reports, test results).
Organisational controls (periodic reviews, supplier management, training) need:
- The procedure establishing the frequency and owner.
- The record that it was done: review minutes, a contract with security clauses, completed training evidence.
An efficient way to organise this is a controls matrix: a table where each row is an Annex A control and the columns capture the policy/procedure that covers it, the type of evidence generated and the control owner. Well maintained, this matrix can serve simultaneously as an ISMS reference and as an internal audit guide.
If you are building the ISO 27001 risk assessment in parallel, control selection and documentation must be aligned: every control selected in the risk treatment plan must appear in the SoA with its evidence.
What the auditor really looks for in control documentation
Understanding the auditor’s perspective saves many hours of unnecessary work. An ISO 27001 certification auditor is not looking for documentary perfection: they are looking for evidence of a working system.
Questions the auditor asks about each control:
- Does the policy exist? Is there a document establishing the organisation’s intention regarding this control?
- Is it approved and current? Does it have an approval date, an owner and a next review date?
- Do people know about it? Is there evidence that relevant staff have received or been trained on it?
- Is it applied in practice? Do records demonstrate the control was applied during the audited period?
- Is there measurement or periodic review? Does someone check that the control is working correctly?
If you can answer yes to all five questions for every control you declare as implemented in your SoA, you are in good shape for the audit. The guide on how to prepare for a NIS2 audit shares similar logic, because security framework auditors apply the same approach: coherence between paper and practice.
The most common finding in a first certification is not the absence of a technical control it is the absence of evidence for a control that does exist but that nobody recorded. That is entirely preventable with a minimal, well-designed recording system from the start.
Formats that work (and those that do not)
Formats that work:
- Policy and procedure in a single brief document. For simple operational controls, a two-page policy that includes the basic procedure is more maintainable than a twenty-page document with sections nobody reads.
- Records in existing tools. If your access management lives in the corporate directory, the logs from that directory are your access control records. You do not need to create an additional register.
- Minimal templates for repeatable processes. For the quarterly access review or the annual vendor review, a minutes template with the minimum fields ensures evidence is always captured, without depending on the memory of whoever runs it.
Formats that do not work:
- Documents downloaded from the internet without adaptation. Auditors recognise generic templates. And worse, the team does not recognise them as their own, so they do not apply them.
- Policies without an owner or review date. A policy without a last review date is an out-of-date policy by default.
- Procedures that describe an ideal process nobody follows. If the procedure says “the security manager reviews access monthly” and the records show a single review over two years, that is a major non-conformity.
Maintenance: the real challenge of ISO 27001 documentation
Many organisations reach certification with reasonably good documentation and lose it at the first surveillance audit because nobody updated it. Maintenance is the part of the ISMS most frequently underestimated.
Three mechanisms that work in practice:
Formalised annual review. Once a year, before the surveillance audit, the owner of each policy and procedure checks whether it is still accurate. A “reviewed by / date” field and a minimal record are enough. The ISO 27001 readiness checklist can serve as a guide for structuring that review.
Update on relevant changes. Every time a system, supplier or process with a security impact changes, the owner of the affected control updates the documentation. If this is not built in as a step in the change management process, it tends to be forgotten.
Non-conformity and corrective action register. Every finding from an internal audit, incident or detected deviation must be recorded with the corrective action taken and its follow-up. This is not only a clause 10 requirement, it is the primary evidence that the ISMS improves over time, which is precisely what justifies recertification.
To understand how ISMS maintenance fits into the broader compliance cycle, the guide on staying compliant with NIS2 covers principles equally applicable to ISO 27001.
ISO 27001 and other frameworks: reusing documentation
If your organisation works with more than one framework, GDPR, NIS2, ENS, DORA, ISO 27001 control documentation can be reused efficiently.
The access management documented for ISO 27001 also covers the equivalent control under NIS2. The ISMS risk analysis can serve as a basis for the DPIA under GDPR when affected processes involve personal data. The encryption policy covers requirements across multiple frameworks simultaneously.
The key is designing from the start with a multi-framework control map: a layer that connects each Annex A control from ISO 27001 to the equivalent requirements of the other frameworks in scope. This avoids duplicated work and reduces the non-conformity surface when multiple auditors arrive in the same period.
The ISO 27001 vs SOC 2 comparison helps understand which controls are shared and where relevant differences lie when working with both frameworks.
What Privalex offers for ISO 27001 implementation
Privalex supports compliance teams, CISOs and management in implementing ISO/IEC 27001 with a focus on documentation that is useful from day one: not binders of policies nobody applies, but documented controls that hold up in conversation with the auditor and that the team recognises as their own.
We cover the initial gap assessment, scope and SoA design, control implementation with evidence, and certification audit preparation. We also support complementary frameworks, ENS, NIS2, ISO 27701, DORA, when the organisation needs to cover more than one standard simultaneously.
To start with an assessment of your current situation, access the free risk assessment. To align scope and plan with your team, book a strategy session.
Conclusion
Documenting ISO 27001 controls is not a writing exercise, it is an exercise in coherence between what the organisation decides, what the team does and what gets recorded. The earlier that coherence is designed in, the less rework is needed before the audit and the more sustainable the ISMS becomes across surveillance and recertification cycles.
Frequently Asked Questions
The standard does not set a fixed number of documents. It requires documented information at specific points in clauses 4 to 10: scope, policy, risk methodology, SoA, internal audit results and management review, among others. For Annex A controls, the requirement is to be able to demonstrate they exist and work, not necessarily with a specific procedure for each one.
Not every control needs to apply. Those that are excluded must be justified in the SoA. Those that do apply must be backed by some form of evidence, not necessarily a dedicated procedure; it can be a technical record, a documented configuration or a reference to an existing tool.
The SoA records for each Annex A control whether it applies, whether it is implemented and what evidence supports it. It must be formally approved by management or the ISMS owner with sufficient authority. It is one of the first documents the auditor requests in the opening hours of a certification audit.
At minimum, a formalised annual review of all policies and procedures. Additionally, an immediate update whenever the process, system or supplier that the control covers changes. Records, evidence that the control is working, are generated continuously in operations; they are not periodically updated documents but traces that accumulate over time.
To a large extent, yes. ISO 27001 Annex A controls overlap significantly with many NIS2 and ENS requirements. With a well-designed multi-framework control map, ISO 27001 documentation and evidence also cover equivalent requirements from other frameworks, avoiding duplicated work. The main differences are usually in specific notification requirements and sector-specific controls.
The most common is the gap between the procedure and real practice: the document states something is done at a certain frequency or in a certain way, but the records show it did not happen that way. Second is the absence of records for controls that do work technically but that nobody documented. Both are preventable if the recording system is designed from the start as part of the process, not as an extra step.