“If it isn’t documented, it didn’t happen.” You’ll hear that a lot around audits, and there’s truth in it: in an audit, your evidence is your documented information.
So most first-time implementers find a list of mandatory documents and open a blank Word file for every line. That’s the wrong move. Roughly half of the mandatory items aren’t documents at all. They’re records: evidence your ISMS produces while it runs. You write about eight or nine documents. If your documentation project is nineteen Word files, something has gone wrong.
This article gives you the complete list of what ISO 27001 requires, explains what’s a document and what’s a record, and shows what auditors expect beyond the list.
Documented information: two kinds, both mandatory
ISO 27001 hardly ever says “document” or “record”. It speaks of documented information, and clause 7.5.1 splits it into two groups: what the standard itself requires, like the scope, the policy or the Statement of Applicability, and what you determine is necessary for your ISMS to be effective, like a backup procedure.
Both are mandatory. Once you’ve decided you need a document, clause 7.5.1 requires it, and the auditor will expect it. The difference is only who decides: the standard, or you.
The verbs give the type away. Where the standard requires information to be available as documented information, as with the scope and the policy, it expects a document: something you write, approve, keep current and version. Where it requires you to retain documented information as evidence, as with audit results or competence, it expects a record: proof that something happened.
And the format is open. Documented information can be a wiki page, a ticket, a log file or even a video. No clause requires a Word file with a header and a revision table. How much you need also depends on your size, the complexity of your processes and the competence of your people. A ten-person SaaS company and a global manufacturer can both be certified against the same standard with very different amounts of paper.
The 19 mandatory documents and records
Counted in the standard’s own text, there are 16 documentation requirements in clauses 4 to 10. In practice, they become 19 items, because auditors expect the risk acceptance criteria, the risk assessment criteria and the risk treatment plan as items of their own, not buried inside the two risk processes.
Clause | Mandatory item |
|---|---|
5.2, A.5.1 | Information security policy |
4.3 | Scope of the ISMS |
6.1.2 | Risk assessment process |
6.1.3 | Risk treatment process |
6.1.2 a) | Risk acceptance criteria |
6.1.2 a) | Risk assessment criteria |
6.1.3 d) | Statement of Applicability |
6.1.3 e), 8.3 | Risk treatment plan |
6.2 | Information security objectives |
7.2 d) | Evidence of competence |
8.1 | Evidence that processes are carried out as planned |
8.2 | Results of information security risk assessments |
8.3 | Results of the information security risk treatment |
9.1 | Results of monitoring and measurement |
9.2.2 | Audit programme |
9.2.2 | Audit results |
9.3.3 | Results of management reviews |
10.2 f) | Nature of nonconformities and actions taken |
10.2 g) | Results of any corrective action |
The clearest example of a record is clause 8.1. It requires documented information to the extent necessary to have confidence that processes have been carried out as planned. You can’t write that in advance. It accumulates: meeting minutes, tickets, approvals, change logs, completed onboarding checklists. The auditor samples this evidence; nobody reads a document titled “Operational Planning and Control”.
These are the 19.
Here are all 143.
The free checklist adds the 124 documents and records auditors expect once your Annex A controls are applicable, each mapped to its clause or control, with a status column (in place, partial, missing) that turns it into your gap list.
Beyond the 19: what auditors expect
The 19 aren’t where the auditor stops. Once you declare an Annex A control applicable in your Statement of Applicability, the auditor expects the policy, procedure or record behind it. Annex A controls aren’t unconditionally mandatory, but the obligation flows through your Statement of Applicability. That’s where the other 124 items on the checklist come from: topic-specific policies, procedures, processes and records.
So read “additional” as “not required by the letter of the standard, but expected by most auditors once the related control is applicable”. It doesn’t mean optional in any casual sense.
How the pieces fit together
Most organizations structure their documentation as a hierarchy with four types, and each answers one question.
Policies define the what: all critical business data is backed up regularly and can be restored. Topic-specific policies, which many organizations call standards, define the what exactly: system backups must be performed daily. Procedures define the how: backups run daily at a set time by an assigned role. And records prove all of the above: the backup log with today’s date. Records are what the auditor samples. Nobody asks whether you believe in backups; they ask for the logs.
And processes? A process isn’t a fifth document type. Clause 4.4 requires you to establish your processes and their interactions, not to write them all down. Only two processes have a documentation duty of their own: risk assessment and risk treatment.
Creating and controlling documented information
Clause 7.5.2 covers creating and updating: every document needs an identification and description, a suitable format and medium, and a review and approval.
In practice, that’s a document header: an ID, a title, a version and an owner; the language and the template; and who created, reviewed and approved it. The revision history shows what changed in which version.
Clause 7.5.3 then requires that everything is controlled: available where and when it’s needed, and adequately protected.
It comes down to a few questions. Is it available where it’s needed? Is it protected against unauthorized disclosure, improper use or unauthorized changes? Who can read it, who can change it, and how do people find it? Is it stored so that it’s still readable years from now? Are changes controlled, so that everyone uses the current version? And how long do you keep it, and how do you dispose of it? All of this applies to documents from outside that you rely on, too, like laws, contracts or a supplier’s manual.
In practice, that’s a lifecycle: you create a document, store it with access control and versioning, people use it, outdated versions are archived, and at the end it’s securely disposed of. A document management system like SharePoint or a GRC tool takes care of much of this. And if you already control documents for ISO 9001, you don’t build a second system. You extend the one you have.
Watch the full lecture above. It’s “Clause 7.5 Documented Information” from the course, with the two kinds of documented information, the document header, the hierarchy and what you have to control.
When each document is created
You don’t write the 19 in one go. They come out of the project, step by step: the scope in Step 1, the policy and objectives in Step 4, the risk methodology with both sets of criteria in Step 6, the risk assessment results in Step 7, the Statement of Applicability and the risk treatment plan in Step 8, evidence of competence in Step 9, the audit programme, audit results and management review in Step 10, and the nonconformities and corrective actions in Step 11. The implementation roadmap shows the full order.
From the auditor’s chair
At stage 1, the 19 mandatory items are, quite literally, what you hand the certification body. The auditor uses them to understand the design of your ISMS, and the stage 1 report tells you which records will be examined in stage 2. Expect a records request, not a surprise.
At stage 2, the question changes. It’s not “why does this document exist?” It’s “show me the evidence that you do what it says.” Deviating from your own procedure is a nonconformity, even where ISO 27001 never required that procedure. So a freshly written document set with no operating history doesn’t certify.
Frequently asked questions
How many mandatory documents does ISO 27001 require?
Counted in the standard’s text, there are 16 documentation requirements in clauses 4 to 10. In practice, auditors expect 19 items, because the risk criteria and the risk treatment plan are treated as items of their own. About half of them are records, not documents.
Are the Annex A documents mandatory?
Not unconditionally. They become binding once you declare the related control applicable in your Statement of Applicability. From then on, the auditor expects the policy, procedure or record behind it.
Does documented information have to be a Word document?
No. It can be a wiki page, a ticket, a log file, a database or a video. What matters is that it’s identified, controlled, available where it’s needed and protected.
Do we need to document every process?
No. Clause 4.4 requires you to establish your processes, not to describe them all. Only risk assessment and risk treatment have a documentation duty of their own. Beyond that, write a process description where it helps, for example where a process crosses several teams.
Which documents does the auditor ask for first?
At stage 1, the 19 mandatory items: they show the design of your ISMS. At stage 2, the records: the evidence that the ISMS actually runs.
Documented information in the course.
With a template for every document.
Chapter 3 (5 lectures, 21 min) shows you what an audit-ready ISMS looks like, how to handle documented information and the 12 steps. Then every step comes with the templates of the ISO 27001 Toolkit, from the scope to the Statement of Applicability.
Clause 7.5 Documented Information
06:14
The Project Goal: An Audit-Ready ISMS
06:39
Template: Information Security Policy
POL-001
Template: ISO 27001 Project Plan
400+
Ready to see where each document comes from? Start with the implementation roadmap.
