Introduction
Teams preparing for certification usually ask the same first question: what are the ISO 27001 required documents? The standard itself is surprisingly restrained — it explicitly mandates only a short list of documents and records. But certification auditors also expect documentation for every Annex A control you have declared applicable, which is where most of the real writing lives. Conflating the two lists causes both failure modes: teams that under-document and get findings, and teams that produce 200 policies nobody follows.
The demand for clarity keeps growing. The ISO Survey counts well over 70,000 valid ISO 27001 certificates worldwide, and the number has risen sharply as enterprise customers push the requirement down their supply chains. Meanwhile IBM's Cost of a Data Breach Report puts the global average breach above 4.4 million dollars — the business case behind every one of these documents.
This checklist covers the mandatory documents clause by clause, the commonly expected Annex A procedures, and how auditors actually verify them.
Why ISO 27001 Documentation Matters
ISO 27001:2022 uses one phrase throughout: "documented information shall be available." Wherever that phrase appears, a document or record is mandatory — no document, no certificate. Everything else is governed by clause 7.5.1(b): the organization must document whatever it determines is necessary for the effectiveness of its ISMS. Auditors interpret that through your Statement of Applicability: if you declared a control applicable, they expect to see how it operates, and for most controls that means a written procedure plus records proving it runs.
ISO 27001 Required Documents by Clause
1. Scope of the ISMS (Clause 4.3)
A statement of what the ISMS covers — locations, business units, systems, and interfaces — and a justification for anything excluded. Auditors probe the boundaries hard: a scope that excludes the platform your customers actually use will not survive stage 1.
2. Information Security Policy (Clause 5.2)
The top-level policy, approved by leadership, communicated internally, and available to interested parties. Keep it short — one or two pages of commitments and direction. The detail belongs in topic-specific policies underneath it.
3. Risk Assessment Process and Results (Clauses 6.1.2 and 8.2)
You need two things: a documented methodology (how you identify, analyze, and evaluate risk, including your criteria for acceptance) and the results of actually running it. The methodology is written once; the results are records produced at planned intervals and after significant change.
4. Risk Treatment Plan and Results (Clauses 6.1.3 and 8.3)
The plan that maps each unacceptable risk to a treatment option and owner, plus records of treatment results. Auditors trace individual risks from assessment through treatment to residual acceptance — the chain must be unbroken.
5. Statement of Applicability (Clause 6.1.3 d)
The SoA lists every Annex A control, whether it is applicable, the justification either way, and the implementation status. It is the single most-referenced document in any audit: expect the auditor to sample controls from it and ask to see each one operating.
6. Information Security Objectives (Clause 6.2)
Documented, measurable objectives with owners, resources, and timelines — plus evidence you monitor them. "Improve security" is not an objective; "close 95% of critical vulnerabilities within 14 days by Q4" is.
7. Evidence of Competence (Clause 7.2)
Records showing that people doing ISMS work are competent: training records, certifications, role descriptions. A spreadsheet of completed security training with dates satisfies this for most organizations.
8. Operational Planning and Control (Clause 8.1)
Documentation that operational processes are planned and controlled — in practice, this is where your operational SOPs live: change management, onboarding and offboarding, backup execution, and similar routine procedures.
9. Internal Audit Programme and Results (Clause 9.2)
A documented audit programme (frequency, methods, responsibilities, criteria) and the results of each audit. First-time certifications fail here more than anywhere else: you need at least one full internal audit cycle completed before the certification audit.
10. Management Review Results (Clause 9.3)
Minutes or records of management reviews covering the required inputs — audit results, nonconformities, risk status, objective performance — and the decisions taken. A calendar invite is not a record; documented outputs are.
11. Nonconformities and Corrective Actions (Clause 10.1)
Records of each nonconformity, the action taken, and the evaluation of whether the correction worked. An empty nonconformity log does not impress auditors; it suggests you are not looking.
Annex A Procedures Auditors Expect to See
Beyond the mandatory list, most organizations declaring typical controls applicable will need documented procedures for: access control and privileged access management, incident management and response, backup and restoration (with test records), secure development, supplier and vendor security, asset management and acceptable use, cryptography and key management, logging and monitoring, vulnerability and patch management, physical security, data classification and handling, and business continuity for ICT readiness. None of these is individually named as mandatory by the standard — but try passing an audit with incident management declared applicable and no written incident procedure.
How Auditors Actually Check Your Documents
Auditors rarely read policies end to end. They sample: pick a control from the SoA, read the procedure, then ask for records proving the procedure ran — the last restore test, the offboarding ticket for a recent leaver, the review log for privileged accounts. The document tells them what should happen; the records tell them whether it does. A perfect policy with no operating evidence is a finding, not a pass.
Version and document control gets checked too. Every document needs an owner, a version number, an approval, and a review date — and the version people can find must be the current one. Clause 7.5.3 requires control over distribution and access, so a folder of stale duplicates is itself a nonconformity.
Step-by-Step: Building Your ISO 27001 Document Set
- Define scope first. Every other document inherits its boundaries from clause 4.3 — write it before anything else.
- Run the risk assessment before writing policies. The SoA and your procedures should follow from your actual risks, not from a template pack's table of contents.
- Draft the SoA as your master index. For each applicable control, note which policy or SOP covers it. Gaps in that column are your writing backlog.
- Write procedures at operating altitude. The person doing the backup restore or the access review should be able to follow the document without asking anyone.
- Generate records from day one. Start the nonconformity log, training records, and review minutes immediately — auditors want months of evidence, not a binder created last week.
- Complete one internal audit and one management review before booking the certification audit. Both are mandatory records you cannot backfill honestly.
Common Mistakes to Avoid
Buying a 200-document template pack. Auditors spot unmodified boilerplate instantly — a policy referencing roles your company does not have is worse than a shorter, genuine one.
Treating the SoA as a formality. It is the audit's roadmap. Justifications like "not applicable — we do not do development" get tested against reality.
Documents without records. Every procedure needs the operating evidence to match. Plan the record before you publish the procedure.
No document control. Unversioned, ownerless files in three different folders will generate findings regardless of how good the content is.
Writing for the auditor instead of the team. Documentation that only exists for certification decays within a year. Write what your team will actually use, and the audit takes care of itself.
How AI Accelerates SOP Creation
WorkProcedures compliance projects generate the full ISO 27001 document set — scope statement, policies, risk process, SoA-aligned procedures, and the operational SOPs behind Annex A controls — from plain-language descriptions of how your organization actually works. Compliance tracking with acknowledgements gives you the distribution and awareness evidence auditors ask for.
Conclusion
ISO 27001 requires fewer documents than most teams fear and more operating evidence than most teams expect. Work clause by clause, let the SoA drive the procedure list, and build records from the start. Visit WorkProcedures to build your ISO 27001 SOPs today.