ISO 27001 mandatory documents: the complete 2022 list

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 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 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:

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.

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 covers how to draw that boundary.

One recent change touches the context clauses. ISO/IEC 27001:2022 Amendment 1, 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.

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.

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.

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 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 will show which of these documents exist and which only look as if they do. The ISO 27001 implementation roadmap sets out when each one gets written, and the certification process guide shows where each one is tested.

Frequently asked questions