The ISO 27001 standard is famously open about documentation. Clause 7.5 demands "documented information" -but the standard never gives you a numbered list of documents to produce. That openness is the source of two opposite problems. Some organisations under-document and arrive at Stage 1 with a Statement of Applicability and not much else. Others over-document, producing 80 policies that nobody reads and nobody maintains. Both fail the audit, just for different reasons.
This guide gives you the actual list -the 14 documents and 12 records that ISO 27001:2022 explicitly requires, plus the practical document set most organisations add on top to satisfy Annex A. It also covers the document mistakes auditors flag most often. If you have read the ISO 27001 implementation roadmap already, this is the deeper-dive companion on the documentation workstream.
1. What Counts as a Mandatory Document
The standard uses one term -documented information -to cover two distinct things. Both are mandatory; both serve different purposes.
- Documents describe what should happen. Policies, procedures, methodologies, plans. They are reviewed and updated as the organisation changes.
- Records are evidence that something happened. Meeting minutes, audit reports, training logs, risk assessment outputs. They are retained as-is, not updated.
The auditor checks both. They read your documents to understand the design of your ISMS. They sample your records to verify the design is implemented. A perfect policy with no supporting records is design without operation -that gets flagged. Operational evidence with no underlying policy is operation without design -also flagged.
Document = "Tell me what you do." Record = "Show me you did it." If you cannot produce both for a given clause, that clause is a finding.
2. The 14 Mandatory Documents
These are explicitly required by named clauses of ISO 27001:2022. If any one is missing, that is grounds for a major nonconformity at Stage 1.
ISMS Scope
A single document defining the boundaries of the ISMS -the products, services, locations, technology, and organisational units in scope. Must reference the issues identified at 4.1 (internal/external context) and the interested parties at 4.2.
Information Security Policy
The top-level policy approved by senior management. Must state the organisation's commitment to information security, set the framework for objectives, and reference satisfaction of applicable requirements. Typically 2-4 pages.
Information Security Risk Assessment Process
The documented methodology for identifying, analysing, and evaluating information security risks. Must define your risk criteria, scoring scales, and acceptance thresholds. This is the method document -not the risk register itself.
Information Security Risk Treatment Process
Defines how risks are treated -accept, mitigate, transfer, avoid -and the workflow from identified risk to approved treatment. Must reference the Statement of Applicability and link to control selection.
Statement of Applicability (SoA)
The single most scrutinised document in an ISO 27001 audit. For each of the 93 Annex A controls: include or exclude, justification for the decision, current implementation status, and which risks the control treats. See our complete SoA guide for the structure and column-by-column build.
Information Security Objectives
Measurable objectives at relevant functions and levels. Each objective must have a target, owner, timeline, and resources. Auditors expect to see progress reviewed at management review meetings.
Evidence of Competence
Documentation showing that people performing security-relevant roles have the necessary competence -through education, training, or experience. CVs, certifications, training completion records all count.
Documented Information Required by the Standard
A meta-requirement -the standard says "documented information determined by the organisation as being necessary for the effectiveness of the ISMS." In practice this means a master document register listing all ISMS documents, their owners, version numbers, and review cycles.
Operational Planning & Control
Documentation of how planned changes, outsourced processes, and operational controls are managed. Often satisfied by a Change Management Policy and supporting procedures.
Risk Assessment Results
The output of applying the methodology -typically a risk register. Each entry: asset, threat, vulnerability, likelihood, impact, inherent risk, treatment, residual risk, owner.
Risk Treatment Results
The Risk Treatment Plan -the document that lists every treatment decision, the controls applied, owners, timelines, and status. The bridge between risk register and SoA.
Monitoring & Measurement Results
Defines what is monitored, by whom, how often, and how results are evaluated. Plus the actual measurement data. Without this, you cannot demonstrate ISMS effectiveness -which is the core of Stage 2.
Internal Audit Programme
A multi-year plan covering all ISMS clauses and applicable Annex A controls. Plus the audit procedures (planning, execution, reporting). See our internal audit guide for the execution detail.
Management Review Procedure
How management reviews the ISMS -frequency (typically annual or semi-annual), required inputs, expected outputs, attendees. The procedure document; the minutes are records.
Every organisation produces more documents than these -see Annex A controls below. But missing any of these 14 will be flagged at Stage 1.
3. The 12 Mandatory Records
Records are the operational evidence. Auditors sample them; they do not read every entry but they will test consistency, completeness, and retention.
| Record | Clause | What Auditors Sample |
|---|---|---|
| Competence evidence | 7.2 | 2-3 employee training records spanning the audit period |
| Communication records | 7.4 | Examples of internal and external security communications |
| Risk assessment results | 8.2 | Risk register entries, plus updates over the audit period |
| Risk treatment results | 8.3 | Risk Treatment Plan entries closed or progressed during period |
| Operational planning records | 8.1 | Change records, exception approvals, outsourcing reviews |
| Monitoring & measurement results | 9.1 | Metrics dashboards, KPI reports, scan results |
| Internal audit programme | 9.2 | Audit schedule covering current and upcoming cycles |
| Internal audit reports | 9.2 | 2-4 recent audit reports with findings and follow-up |
| Management review results | 9.3 | Minutes from at least one full management review |
| Nonconformity records | 10.1 | NC log, root cause analyses, corrective actions, verification |
| Corrective action results | 10.1 | Closed NCs with effectiveness evidence |
| Continual improvement evidence | 10.2 | Improvement initiatives tracked through to completion |
Documents can be written the week before Stage 1. Records cannot -they are time-stamped operational artefacts. If you have no internal audit reports because you have not yet run one, that is the audit finding regardless of how good the procedure document is.
4. Annex A Documents -The Add-On Set
The 14 mandatory documents above cover the management system clauses. Annex A controls -the 93 technical and organisational controls -typically require their own supporting documentation when implemented. Not every control needs its own policy; many are bundled.
The Annex A documents most organisations end up producing:
- Acceptable Use Policy -covers A.5.10, A.5.11, A.5.14, A.5.15 (user responsibilities, asset handling, transfer of information, access control)
- Access Control Policy -A.5.15, A.5.16, A.5.17, A.5.18 (logical access controls, identity, authentication, privileged access)
- Cryptographic Controls Policy -A.8.24 (use of cryptography)
- Information Classification Policy -A.5.12, A.5.13 (classification and labelling)
- Supplier Security Policy -A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 (supplier relationships)
- Incident Management Policy & Procedure -A.5.24 through A.5.28 (incident response lifecycle)
- Business Continuity Plan -A.5.29, A.5.30 (ICT readiness for business continuity)
- Backup Policy -A.8.13 (information backup)
- Logging & Monitoring Policy -A.8.15, A.8.16 (logging and monitoring)
- Secure Development Policy -A.8.25, A.8.26, A.8.27, A.8.28 (development lifecycle, security testing, secure coding)
- Physical Security Policy -A.7.x (only if you have physical premises in scope)
- HR Security Policy -A.6.1 through A.6.6 (screening, terms, awareness, disciplinary, post-employment)
The total document set typically ends up at 25-35 for a small-to-medium organisation. Larger organisations with multiple business units, geographies, or product lines may have 50-70. Beyond that, you are probably over-documenting.
5. Structuring the Document Set
A predictable document hierarchy makes maintenance easier and audits faster. The structure most ISO 27001 practitioners settle on:
Level 1 -Policies (the "what" and "why")
Senior-management approved. Typically 2-5 pages each. State principles and high-level rules. Do not contain step-by-step procedures. Reviewed annually.
Level 2 -Procedures (the "how")
Owner-approved. Detail the operational steps. Reference the parent policy. Reviewed when underlying processes change or annually, whichever comes first.
Level 3 -Work instructions, templates, forms
Tactical artefacts that support procedures. Form templates for change requests, risk assessment spreadsheets, incident response checklists. Updated as needed.
Level 4 -Records
Time-stamped evidence. Cannot be edited after the fact. Retained per the retention schedule.
Use a consistent naming convention like POL-SEC-001 Information Security Policy v3.2. POL = Policy, PRO = Procedure, FRM = Form, REC = Record. When an auditor asks "show me the access control policy", you find it in 10 seconds, not 10 minutes.
6. Documentation Mistakes Auditors Flag
1. Copy-pasted template documents
Free templates from the internet often contain references to controls or scenarios that do not apply to your organisation. Auditors spot this immediately when the policy mentions, say, an industrial control system you do not have. Templates are starting points, not finished documents. Every template needs editing to match your actual operations.
2. Version control gaps
Documents without version numbers, change history, or approval signatures fail the basic controlled-information test of Clause 7.5. Every document needs a version, an approver, a date, and a review cycle.
3. Policies that reference procedures that do not exist
"Refer to the Incident Response Procedure for details" -and the procedure is missing. Cross-references must be checked. A document referencing another document that does not exist is a documented-information failure.
4. Last-reviewed dates more than 12 months old
Clause 7.5.3 requires documents to be "available and suitable for use when and where needed" -which auditors interpret as up-to-date. A policy last reviewed in 2023 will be challenged in a 2026 audit.
5. The SoA missing implementation status
"Included" or "Excluded" is not enough. The SoA must show, for each included control, the current implementation status. Otherwise the auditor cannot tell which controls are claimed but not actually operating.
6. Records that do not match the documented retention period
If your Records Retention Policy says training records are kept for 3 years and the auditor finds none older than 6 months, that is either non-retention or shadow deletion. Both fail Clause 7.5.3.
7. Approval signatures from people who have left the company
A common one. The CTO approved the policy in 2024, left in 2025, and the policy still shows their name. This is a control failure in document management, even if the content is fine. Re-approve when the approver changes.
7. The Review & Update Cycle
Documents do not get written once and forgotten. The ISMS is a living system; the documentation has to reflect that. The cycle most organisations adopt:
| Document Type | Review Cycle | Trigger Events |
|---|---|---|
| Information Security Policy | Annual | Org change, scope change, major incident |
| SoA | Annual | Risk treatment changes, new controls deployed |
| Risk Assessment Methodology | Annual | Material change to risk landscape |
| Risk Register & Treatment Plan | Quarterly (live) | New risks, control changes, treatment closure |
| Operational Procedures | Annual or on-change | Process change, technology change, post-incident |
| Internal Audit Programme | Annual | Scope or org change |
| Business Continuity Plan | Annual + test-driven | After each BCP test or real incident |
Treat the review cycle as a calendar event, not a triggered process. Schedule each document for review on a fixed date each year and ride out the calendar -most teams find this far more reliable than relying on triggers, which tend to be missed.
Ready to build an audit-ready document set?
SecComply builds the full ISO 27001 documentation pack -the 14 mandatory documents, the supporting Annex A policies, and the records framework -calibrated to your scope. Aligned with our implementation roadmap and the auditor expectations you will face at Stage 1 and Stage 2.
Talk to a consultant →FAQ
ISO 27001:2022 explicitly mandates 14 documents and 12 records. The documents define what you do; the records prove you did it. Most organisations end up with 30-40 documents total once Annex A control-specific procedures are added -but only the 14 are mandatory at the clause level.
No. ISO 27001 only requires the information security policy at Clause 5.2 to exist; it does not prescribe a one-policy-per-control structure. Many organisations consolidate related controls into thematic policies (e.g. one Acceptable Use Policy covering several A.5/A.8 controls). What auditors check is whether the policy actually addresses the requirement, not how many documents you have.
A document describes what should happen -a policy, procedure, plan, or methodology. A record is evidence that it did happen -a meeting minute, training log, risk assessment output, audit report. Documents are reviewed and updated; records are kept as-is and retained for a defined period.
Yes. Clause 7.5 only requires that documented information is identifiable, controlled, and available where needed. PDF, wiki page, Notion doc, Google Doc, Confluence page -all acceptable, provided version control, approval, and access controls are in place. The format matters far less than the controlled-information lifecycle.
ISO 27001 does not prescribe a retention period -it requires you to define and document one. Common practice: management review minutes for 3 years, internal audit records for the current and previous certification cycle (6 years), training records for the duration of employment plus 2 years, incident records for at least 3 years. Define the retention schedule once and document it in a Records Retention Policy.