---
title: "ISO 27001 mandatory documents: the complete 2022 list"
canonical: https://www.grcmana.io/vault/iso-27001/documents
published: 2023-08-28
updated: 2026-10-20
author: "Harry West"
framework: "ISO 27001"
control: "Guide ISO 27001 mandatory documents and records"
journeyStage: fundamentals
---

# ISO 27001 mandatory documents: the complete 2022 list

## Key takeaways

ISO 27001 mandatory documents are a short list from clauses 4 to 10: scope, policy, risk processes, Statement of Applicability, treatment plan and objectives, plus records proving the ISMS runs. Annex A documents become expected only for controls your Statement of Applicability marks applicable. Enough documentation is whatever lets every sampled process be shown working.

- **Core documents** — The ISMS scope, information security policy, risk assessment and treatment processes, Statement of Applicability, risk treatment plan and security objectives, all written, approved and kept current under Clause 7.5.
- **Mandatory records** — Competence evidence, risk assessment and treatment results, monitoring results, the audit programme and its results, management review results, and nonconformity and corrective action records, produced as the ISMS operates.
- **Annex A documents** — No Annex A control is mandatory, so neither is its paperwork. Once the Statement of Applicability marks a control applicable, auditors usually expect written rules or procedures behind it.
- **How much is enough** — Clause 7.5 adds whatever your ISMS genuinely needs written down. A procedure you never follow is worse than none, because the auditor will test it and record the gap.

The Stage 1 auditor's first request is your document set. The folder you inherited holds dozens of files of uncertain status, and nobody can say which ones the standard actually requires. This guide lists the ISO 27001 mandatory documents and records clause by clause, separates them from the Annex A documents your Statement of Applicability adds, and shows how much is enough. It is written for security and compliance leads at UK firms of 25–250 people preparing for [ISO 27001:2022](https://www.grcmana.io/vault/iso-27001) certification.

The mandatory core is shorter than most template packs suggest. Most of it is records your management system produces as it runs, not documents you sit down to write.

## What are the ISO 27001 mandatory documents?

ISO 27001 mandatory documents are the documented information that clauses 4 to 10 explicitly require: the ISMS scope, the security policy, the risk assessment and treatment processes, the Statement of Applicability, the treatment plan and the objectives. Mandatory records sit alongside them, proving the system ran: competence, risk results, monitoring, audits, reviews and corrective actions.

The [ISO/IEC 27001:2022](https://www.iso.org/standard/27001) standard folds both kinds into a single term, documented information. In practice it helps to split documented information by what each piece is for. ISO 27001 sets no document hierarchy, but auditors recognise this working model:

| Type | What it answers | Who approves it | How it changes | Example from the mandatory list |
| --- | --- | --- | --- | --- |
| Policy | What we commit to, and why | Top management | Rarely; reviewed at planned intervals | [Information security policy (Clause 5.2)](https://www.grcmana.io/vault/iso-27001/clause-5-2-policy) |
| Topic-specific policy or standard | The rules for one area | The area's owner, under the main policy | When the risk or technology changes | [Access control rules (A.5.15)](https://www.grcmana.io/vault/iso-27001/annex-a-5-15-access-control) |
| Process | What happens, in what order, with what inputs and outputs | The process owner | When the way of working changes | [Risk assessment process (Clause 6.1.2)](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) |
| Procedure | Step by step, how one task is done | The team that does the work | Often; kept close to the work | [Incident response procedure (A.5.26)](https://www.grcmana.io/vault/iso-27001/annex-a-5-26-response-to-information-security-incidents) |
| Plan | What we will do, by when, and who owns it | The accountable owner | As actions close | [Risk treatment plan (Clause 6.1.3)](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) |
| Record | Evidence of what actually happened | Nobody; it is produced, not approved | Never edited, only added to | [Internal audit results (Clause 9.2)](https://www.grcmana.io/vault/iso-27001/clause-9-2-internal-audit) |

The first five state how you intend to work, so you write, approve and update them. Records are different: the ISMS produces them as it runs, and you keep them unchanged as evidence. ISO's management-system vocabulary describes a policy as top management's formally expressed intentions and direction, and a process as connected activities that turn inputs into outputs. A procedure is narrower: the specified way to carry out one activity.

Most firms over-write procedures and under-produce records. The auditor samples the records.

There is a third category, and it is the one teams forget. Clause 7.5 also covers any documented information you decide the ISMS needs to work, beyond what the standard names. That decision is yours, which is why the right answer differs between a 40-person software firm and a 200-person insurer.

The clause-required list below is the floor. Everything else is either a consequence of your Annex A choices or a judgement about what your people need written down.

## Which documents do ISO 27001 clauses 4 to 10 require?

Clauses 4 to 10 require a core set of documents you write and keep current: the ISMS scope, the information security policy, the risk assessment process, the risk treatment process, the Statement of Applicability, the risk treatment plan and the security objectives. Clause 8.1 adds whatever operational information shows your processes run as planned.

Expect the Stage 1 auditor to read each of these before sampling anything else.

| Clause | Document | What the auditor checks |
| --- | --- | --- |
| [4.3](https://www.grcmana.io/vault/iso-27001/clause-4-3-determining-the-scope-of-the-information-security-management-system) | ISMS scope statement | Entities, services, locations and systems covered; a written case for each exclusion; approval and version |
| [5.2](https://www.grcmana.io/vault/iso-27001/clause-5-2-policy) | Information security policy | Leadership approval, the commitments the clause names, communication to staff, availability to interested parties where appropriate |
| [6.1.2](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) | Risk assessment process | Scales, criteria and an acceptance line that give comparable results every time |
| [6.1.3](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) | Risk treatment process | How treatment options are chosen and controls selected, then compared with Annex A |
| [6.1.3](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) | Statement of Applicability | Every Annex A control, whether it applies, the reason, and its implementation status |
| [6.1.3](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) | Risk treatment plan | Treatments with named owners and dates, and risk owners' approval of the plan and the residual risk |
| [6.2](https://www.grcmana.io/vault/iso-27001/clause-6-2-information-security-objectives) | Information security objectives | Measurable objectives, each with an owner, resources, a deadline and an evaluation method |
| [8.1](https://www.grcmana.io/vault/iso-27001/clause-8-1-operational-planning-and-control) | Operational planning information | Enough to give confidence that security processes ran as planned |

Three of these deserve more attention than the rest.

**The Statement of Applicability, risk register and treatment plan must tell one story.** Auditors cross-check them against each other faster than internal reviews do. A control marked "implemented" in the Statement of Applicability needs a risk it treats and a trail showing it happened.

A Statement of Applicability that disagrees with your risk register isn't a summary. It's a finding waiting to be written.

**The policy is one document, not twenty.** Clause 5.2 asks for a single information security policy owned by top management. The topic-specific policies on access, cryptography or acceptable use come from Annex A, which is a different question covered below.

**The scope is a commercial document.** Buyers read the scope wording on your certificate to learn what it covers. The [Clause 4.3 guide](https://www.grcmana.io/vault/iso-27001/clause-4-3-determining-the-scope-of-the-information-security-management-system) covers how to draw that boundary.

One recent change touches the context clauses. [ISO/IEC 27001:2022 Amendment 1](https://www.iso.org/standard/88435.html), published in 2024, asks you to determine whether climate change is a relevant issue. It does not add a named document, but we recommend recording the decision and its reasoning alongside your context analysis, so the auditor can see it was made.

## Which records does ISO 27001 require you to keep?

ISO 27001 requires records proving the ISMS operates: evidence of competence, the results of risk assessments and risk treatment, monitoring and measurement results, the internal audit programme and its results, management review results, and records of nonconformities and corrective actions. You add new records over time rather than editing old ones.

| Clause | Record | What good looks like |
| --- | --- | --- |
| [7.2](https://www.grcmana.io/vault/iso-27001/clause-7-2-competence) | Evidence of competence | A role matrix with required skills and current state, plus dated training and certification records |
| [8.2](https://www.grcmana.io/vault/iso-27001/clause-8-2-information-security-risk-assessment) | Risk assessment results | A register with dated passes on schedule and after significant change, each risk with an owner |
| [8.3](https://www.grcmana.io/vault/iso-27001/clause-8-3-information-security-risk-treatment) | Risk treatment results | Proof treatments were carried out: configuration exports, tickets, signed risk acceptances |
| [9.1](https://www.grcmana.io/vault/iso-27001/clause-9-1-monitoring-measurement-analysis-and-evaluation) | Monitoring and measurement results | A retained series of metric results, with the evaluation and decisions that followed |
| [9.2](https://www.grcmana.io/vault/iso-27001/clause-9-2-internal-audit) | Audit programme and audit results | The schedule, per-audit plans, reports and graded findings |
| [9.3](https://www.grcmana.io/vault/iso-27001/clause-9-3-management-review) | Management review results | Minutes recording decisions, owners and dates, not slides presented |
| [10.2](https://www.grcmana.io/vault/iso-27001/clause-10-2-nonconformity-and-corrective-action) | Nonconformities and corrective actions | A log covering what failed, the cause, the action, the owner and proof the fix held |

**Records are where certification is really won or lost.** Documents show the auditor what you intended; records show whether it happened, and Stage 2 is built on sampling them.

What auditors weigh is time. A risk register edited continuously over twelve months reads very differently from a perfect one last touched three weeks before the audit.

A record created the week before the audit is a document pretending to be evidence.

The strongest records are the ones nobody had to write. Ticket trails, training-platform completions, scanner exports and access review outputs exist because the work went through a system. When the auditor asks for evidence, you produce it from that system on demand instead of assembling a folder.

## Which Annex A controls usually need documents?

No Annex A control is mandatory, so no Annex A document is mandatory either. Once your Statement of Applicability marks a control as applicable, auditors usually expect written rules, procedures or records behind it. The most common are topic-specific policies, the asset inventory, access control rules, incident procedures, continuity plans and the legal register.

The table lists the documents we see requested most often when the control applies. Treat it as a checklist to test against your own Statement of Applicability, not a list to produce wholesale.

| Annex A control | Document usually expected | What makes it hold up |
| --- | --- | --- |
| [A.5.1 Policies for information security](https://www.grcmana.io/vault/iso-27001/annex-a-5-1-information-security-policy) | Topic-specific policies | Management approval, communication to the people they apply to, planned reviews |
| [A.5.9 Inventory of information and other associated assets](https://www.grcmana.io/vault/iso-27001/annex-a-5-9-inventory-of-information-and-other-associated-assets) | Asset inventory | Named owners, and a link to the risks each asset carries |
| [A.5.10 Acceptable use](https://www.grcmana.io/vault/iso-27001/annex-a-5-10-acceptable-use-of-information-and-other-associated-assets) | Acceptable use rules | Acknowledged by staff and contractors |
| [A.5.15 Access control](https://www.grcmana.io/vault/iso-27001/annex-a-5-15-access-control) | Access control rules | Matched by what the identity provider actually enforces |
| [A.5.24 Incident management planning](https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation) and [A.5.26 Response](https://www.grcmana.io/vault/iso-27001/annex-a-5-26-response-to-information-security-incidents) | Incident management procedure | Roles, escalation and a record of real or rehearsed use |
| [A.5.30 ICT readiness for business continuity](https://www.grcmana.io/vault/iso-27001/annex-a-5-30-ict-readiness-for-business-continuity) | ICT continuity plans | Recovery targets and test results |
| [A.5.31 Legal, statutory, regulatory and contractual requirements](https://www.grcmana.io/vault/iso-27001/annex-a-5-31-legal-statutory-regulatory-and-contractual-requirements) | Register of obligations | Kept current and cross-referenced to policies |
| [A.5.37 Documented operating procedures](https://www.grcmana.io/vault/iso-27001/annex-a-5-37-documented-operating-procedures) | Operating procedures | Available to the people who run the systems |
| [A.8.9 Configuration management](https://www.grcmana.io/vault/iso-27001/annex-a-8-9-configuration-management) | Standard configurations | Enforced as code or baseline, with drift detected |
| [A.8.13 Information backup](https://www.grcmana.io/vault/iso-27001/annex-a-8-13-information-backup) | Backup rules | Job history and at least one test restore |
| [A.8.15 Logging](https://www.grcmana.io/vault/iso-27001/annex-a-8-15-logging) | Logs (records) | Retained, protected and actually reviewed |
| [A.8.24 Use of cryptography](https://www.grcmana.io/vault/iso-27001/annex-a-8-24-use-of-cryptography) | Rules for cryptography | Approved methods and key management named |
| [A.8.32 Change management](https://www.grcmana.io/vault/iso-27001/annex-a-8-32-change-management) | Change procedure | Change tickets showing assessment, approval and testing |

Two rules keep this list under control.

- **Write only what the Statement of Applicability needs.** If you have justified excluding a control, you do not need its document. If a control applies, its document must describe what you really do.
- **Document the rule, not the tool.** "Production access requires multi-factor authentication and a manager's approval" survives a change of identity provider. A forty-step console walkthrough does not.

For how each of the 93 controls fits together, see the [ISO 27001 Annex A controls guide](https://www.grcmana.io/vault/iso-27001/annex-a-controls).

## How much ISO 27001 documentation is enough?

Clause 7.5 asks for the documented information the standard names, plus whatever you decide the ISMS needs to work effectively. The right extent depends on your size, activities and complexity, so a 60-person software firm needs far less than a bank. Enough means every process an auditor samples can be shown working from what you hold.

**Over-documentation is the more common failure at this size.** Template packs arrive with dozens of policies and procedures written for organisations with departments you don't have. Each one becomes a promise.

A 40-page policy nobody has read isn't evidence of control.

The risk is specific. An auditor who samples a procedure will test whether you follow it. If the document says access reviews happen monthly and your records show two a year, that gap is a nonconformity against your own rules, even though the standard never asked for monthly reviews.

Three tests decide whether a document earns its place:

1. **Does the standard or an applicable control require it?** If yes, it stays.
2. **Would a new joiner do the task wrongly without it?** If yes, it stays, written as briefly as the task allows.
3. **Does it describe what actually happens?** If not, fix the document or fix the practice before the auditor finds the difference.

Applied honestly, those tests usually leave a compact set. For a 60-person software firm with whole-organisation scope, a credible set looks like this:

- the clause-required documents from the first table, each a few pages at most;
- one information security handbook carrying the topic-specific policies, a section per topic;
- a handful of procedures for the tasks that go wrong without them: incident response, access changes, joiners and leavers, change and release, backup and restore;
- the asset inventory, the obligations register and the risk register as living registers, not documents.

Everything else is a record the systems already produce.

How you control these documents is a separate question: identifiers, versioning, approval, access, retention and disposal. The [Clause 7.5 documented information guide](https://www.grcmana.io/vault/iso-27001/clause-7-5-documented-information) covers that in depth.

## How do you keep ISO 27001 documents audit-ready?

Give every document a named owner, a version and a review date, keep them in a single register, and let the systems that do the work generate your records. The auditor's request list then becomes a set of links, and the documents stay accurate between audits instead of being refreshed the month before.

A working set-up at this scale has four parts:

- **One register.** A spreadsheet or database view listing each document, its owner, version, status and next review date is enough. Nobody expects a document-management suite at 50 people.
- **Named owners.** Each document has one person accountable for keeping it true, and an approver who is not its author.
- **Review triggers as well as dates.** An annual review is a minimum, not a method. A new cloud provider, an incident or a restructure should open a review of the documents it touches.
- **Generated evidence.** Connect the register to the systems that hold proof: the identity provider for access reviews, the ticketing tool for changes, the training platform for awareness.

That last step is where GRC Engineering pays off. When evidence is collected continuously from the systems that do the work, audit preparation shrinks from weeks of chasing to a check that the feeds are still running.

The same set answers more than the auditor. Enterprise security questionnaires ask for your policy, your scope, your incident procedure and proof of review. A document set that is current, owned and evidenced turns those questionnaires from a scramble into a reply.

If you are starting from an inherited folder, an [ISO 27001 gap analysis](https://www.grcmana.io/vault/iso-27001/gap-analysis) will show which of these documents exist and which only look as if they do. The [ISO 27001 implementation roadmap](https://www.grcmana.io/vault/iso-27001/implementation) sets out when each one gets written, and the [certification process guide](https://www.grcmana.io/vault/iso-27001/certification-process) shows where each one is tested.

## Frequently asked questions

### Can we use templates for ISO 27001 mandatory documents?

Yes, provided you rewrite them to describe your organisation. Auditors spot template language quickly: roles you don't employ, committees that never meet, review cycles nobody runs. Use a template for structure and headings, then delete anything you can't evidence. A short document that matches reality beats a long one that doesn't.

### Can ISO 27001 documents live in a wiki or GRC platform instead of Word files?

Yes. The standard leaves format and medium to you. What matters is that each document has an identity, a version history, a recorded approval and controlled edit rights. A wiki with page history and restricted editing often meets this better than shared drives full of files named "final v3".

### How often should ISO 27001 policies be reviewed?

At planned intervals you define, and whenever a significant change makes them inaccurate. Annual review is the common baseline. Record each review even when nothing changes, with the date and the reviewer, because "reviewed, no change needed" is evidence and silence is not.

### Do we need a separate document for every applicable Annex A control?

No. One document, or one system record, can address several controls. Add a reference column to the Statement of Applicability that points each applicable control to the document section or system that addresses it. The auditor can then follow the trail from control to evidence without asking you to find it.

### How long should ISO 27001 records be kept?

The standard leaves retention periods to you, so set them in a retention schedule and apply them consistently. As a working minimum, keep ISMS records for at least one full three-year certification cycle, so the recertification auditor can see the whole period. Legal and contractual obligations, such as employment or financial record rules, may require longer.

### What happens if a mandatory document is missing at Stage 1?

The Stage 1 auditor will record it as a gap to close before Stage 2. Depending on how much is missing, the certification body may delay Stage 2 until it is fixed. Closing the gap takes longer than writing the document, because it also needs approval, communication and enough operating time to produce records.