ISO 27001 Mandatory Documents: The Complete List for 2022 Certification

ISO 27001 certification is fundamentally evidence-based. Your certification body doesn’t assess whether your organization is "secure" — they verify that your ISMS documents a systematic approach to managing information security risk, and that the evidence supports it.

The Stage 1 audit is a documentation review. The auditor checks whether you have the required documents and whether they’re structured to meet the standard. If your documentation package is incomplete at Stage 1, you won’t proceed to Stage 2.

The most common implementation failure is organizations spending months building controls without assembling the documentation that proves those controls exist. A complete documentation list — mapped to specific clause references — prevents that.

ISO 27001:2022 explicitly requires these seven documents. Missing any one of them is a major nonconformity that blocks certification.

1. ISMS Scope Statement (Clause 4.3) Defines what the ISMS covers — which departments, systems, locations, and processes are in scope. The scope can be narrow (one product line, one office) or broad (entire organization). Auditors validate the scope against your actual operations, so it must accurately reflect reality. Start narrow if you’re pursuing certification for the first time — expanding later is easier than managing an unmanageably broad scope.

2. Information Security Policy (Clause 5.2) A high-level policy signed by senior management that commits the organization to information security objectives and continual improvement. This is not an IT policy — it’s a management commitment. Auditors check for management signature, date, and that the policy is communicated to all employees.

3. Risk Assessment Methodology (Clause 6.1.2) Documents how you identify, analyze, and evaluate information security risks. ISO 27001 is deliberately non-prescriptive — you can use asset-threat-vulnerability models, scenario-based approaches, or simplified likelihood x impact matrices. What matters is that the methodology is documented, repeatable, and produces consistent results.

4. Statement of Applicability (Clause 6.1.3d) The SoA maps each of the 93 Annex A controls to your organization — marking each as applicable or not applicable, with justification, implementation status, and references to implementing documentation. The SoA is the auditor’s primary reference at both Stage 1 and Stage 2. It must be approved by management and kept current.

5. Risk Treatment Plan (Clause 6.1.3e, 6.2, 8.3) Specifies, for each risk above your acceptance threshold: which controls will be applied, who owns implementation, and the timeline. The RTP and SoA are linked — the SoA records control decisions; the RTP records the implementation plan.

6. Security Objectives (Clause 6.2) Measurable information security objectives consistent with the policy. These must be monitored (Clause 9.1) and reviewed in management reviews (Clause 9.3). Vague objectives like "improve security" fail — auditors expect measurable targets like "reduce mean incident response time to under 4 hours."

7. Risk Assessment Report (Clause 8.2, 8.3) The output of running your risk assessment methodology — a risk register documenting identified risks, their likelihood and impact ratings, and treatment decisions. Auditors trace from this report to the RTP to the SoA to control evidence. If the chain breaks, it’s a nonconformity.

Beyond the seven core documents, ISO 27001 requires records that prove implementation. Policies describe intent; records prove execution. Missing records is the most common Stage 2 failure.

Training Records (Clause 7.2) Evidence that personnel are competent for their ISMS roles. This includes security awareness training completion, role-specific training (e.g., incident response training for the security team), and new-hire onboarding records.

Monitoring and Measurement Results (Clause 9.1) Evidence that you measure ISMS performance. This connects to your security objectives — if you committed to monitoring incident response times, you need the measurement data.

Internal Audit Program and Reports (Clause 9.2) An audit schedule covering all clauses and controls over the certification cycle, plus completed audit reports. Critical requirement: internal auditors must be independent from the area being audited. The IT manager cannot audit IT controls. For small organizations, options include training a non-IT employee, using an external consultant, or cross-auditing (IT audits HR controls; HR audits IT controls).

Management Review Outputs (Clause 9.3) Minutes from management review meetings with specific required inputs: audit results, security objective performance, nonconformity status, changes in external/internal context, and improvement opportunities. Informal meetings without documented outputs fail this requirement.

Corrective Action Records (Clause 10.2) Documented responses to nonconformities — what went wrong, root cause analysis, what was corrected, and evidence that the correction was effective. Auditors don’t expect zero nonconformities; they expect a systematic process for addressing them.

System and Activity Logs (Annex A.8.15) Logs recording user activities, exceptions, faults, and information security events. The scope of logging should be defined in your operational procedures.

While not explicitly mandated by the standard, these documents are practically required because auditors expect the evidence they contain:

• Asset Inventory — required by A.5.9 (Inventory of information and other associated assets). Lists information assets, their owners, and classification.
• Access Control Policy — supports A.5.15 (Access control) and multiple A.8 controls. Defines who gets access to what, and how access is provisioned and revoked.
• Incident Response Procedure — supports A.5.24-A.5.28 (Incident management controls). Defines how security incidents are detected, reported, assessed, and resolved.
• Business Continuity Plan — supports A.5.29-A.5.30 (ICT readiness for business continuity). Defines how the organization maintains operations during disruptions.
• Supplier Security Policy — supports A.5.19-A.5.22 (Supplier relationship controls). Defines security requirements for third-party suppliers.
• Document Control Procedure — supports Clause 7.5. Defines how ISMS documents are created, approved, distributed, and updated.

A documentation kit that only produces the seven core documents without these supporting documents produces an ISMS that passes Stage 1 but risks significant findings at Stage 2.

Want to identify which documents your organization is missing? The ISO 27001 Readiness Assessment maps your current state to specific documentation gaps.

The Statement of Applicability is the document that ties the entire ISMS together. Understanding its role prevents the most common documentation mistake: creating documents in isolation without cross-references.

For each of the 93 Annex A controls, the SoA should record:

• Control reference (e.g., A.5.1 — Policies for information security)
• Applicable / Not applicable with justification
• Implementation status (Implemented, Partially implemented, Planned, Not started)
• Implementing document reference (e.g., "See Information Security Policy v2.1")
• Risk reference (which risk from the risk register this control treats)

Auditors use the SoA as their audit roadmap. They pick a control, check the implementation status, follow the document reference, then verify the evidence exists. When the SoA says "Implemented — see Access Control Policy" but no Access Control Policy exists, that’s a nonconformity.

Controls can be legitimately excluded. A software company with no physical data centers can exclude A.7.6 (Working in secure areas). A non-development organization can exclude A.8.25-8.31 (Secure development lifecycle). But every exclusion must reference the risk assessment — blanket exclusions without justification are rejected.

Copying templates without customization. The most cited audit failure mode. Organizations purchase templates, change the company name, and submit unchanged policies. Auditors ask "walk me through how you actually implement this" — and immediately detect generic language. An Access Control Policy describing Active Directory procedures fails for a cloud-native organization.

No cross-document linking. The SoA references the Access Control Policy, which references the risk assessment, which references the scope document. Without a document index that maps these relationships, the evidence chain is invisible to auditors.

Documents exist but aren’t maintained. A policy dated 18 months ago with no revision history suggests the ISMS isn’t actively managed. ISO 27001 requires continual improvement — documents should show evidence of periodic review and updates.

Risk assessment disconnected from controls. When auditors ask "why did you implement A.8.7 (Protection against malware)?" the answer must reference a specific risk from your risk register. Controls implemented because of "best practice" without a documented risk justification fail the evidence chain.

Policies without records. Having an Incident Response Procedure without any incident records (even if no incidents occurred — document that fact) leaves auditors questioning whether the procedure is actually followed.