ISO 27001 Mandatory Documents: Documents vs Records
Search for the mandatory documents required by ISO 27001 and you will find a dozen lists. They do not agree with each other. Some run to ten items, some to thirty. Some include an ISMS manual, which the standard never mentions. At least one still says Annex A contains 114 controls, which was true of the 2013 edition and has not been true since 2022.
The disagreement is not carelessness. It comes from a distinction the standard makes and most lists do not: ISO/IEC 27001 requires two different things, and calls them both documented information.
Getting this right changes what you build, and it changes what happens in your audit. It is also the reason so many organisations arrive at a stage 2 audit with a full folder and still fail.
Trying to work out which files you actually need? The ISO 27001 Compliance Suite contains no document unless a clause requires it or an applicable control implies it — 43 files rather than a hundred and thirty, with the eight required registers as separate files. €590 excl. VAT.
The distinction the standard makes
Read clauses 4 to 10 looking at the verbs and a pattern appears. The standard asks for documented information in two modes.
“Shall be available as documented information.” Something must exist and be current. The scope statement. The policy. The Statement of Applicability. These are documents: they state what the organisation intends to do, they are approved, they are revised, and versions supersede one another.
“Shall retain documented information as evidence of…” Something must be kept as proof that an activity happened. Results of risk assessments. Evidence of competence. Evidence of the audit programme and audit results. These are records: they state what occurred, they are not revised, and a correction is a new entry that leaves the original visible.
The difference is not academic. A document proves intent. A record proves operation. An ISMS can be fully documented and still fail its audit, because the documents exist and nothing shows the processes ran.
This is the most common failure mode I saw as a Notified Body auditor, and it is structural: buying a documentation kit gets you the first category and none of the second, because the second is produced by operating, not by purchasing.
What must be available: the documents
These are the items where the standard requires documented information to exist and be current.
| # | What | Clause |
|---|---|---|
| 1 | The scope of the ISMS | 4.3 |
| 2 | The information security policy | 5.2 |
| 3 | The information security risk assessment process | 6.1.2 |
| 4 | The information security risk treatment process | 6.1.3 |
| 5 | The Statement of Applicability | 6.1.3 d) |
| 6 | The information security objectives | 6.2 |
| 7 | Documented information determined as necessary for effectiveness | 7.5.1 b) |
Seven items. Item 7 is the open one: it is the standard acknowledging that a management system needs more written down than the six named items, and leaving the extent to you. It is also the item that vendors expand into thirty policies, because it is the only place where expansion is possible.
Note what is not on this list. There is no required ISMS manual. There is no required access control policy, incident response procedure, or supplier policy as a matter of clauses 4 to 10 — those become necessary through Annex A, and only where the corresponding control is applicable to you.
Two of the seven have articles of their own: the Statement of Applicability, which is the one certification auditors read first, and the information security policy.
What must be retained: the records
These are the items where the standard requires evidence to be kept. This list is shorter than most vendors admit, and it is the one that decides whether your audit goes well.
| # | Evidence of | Clause |
|---|---|---|
| 1 | Competence of persons doing work affecting security performance | 7.2 d) |
| 2 | Results of the information security risk assessments | 8.2 |
| 3 | Results of the information security risk treatment | 8.3 |
| 4 | The results of monitoring and measurement | 9.1 |
| 5 | The audit programme and the audit results | 9.2.2 |
| 6 | The results of management reviews | 9.3.3 |
| 7 | The nature of the nonconformities and any subsequent actions taken | 10.2 f) |
| 8 | The results of any corrective action | 10.2 g) |
Eight. That is the complete set from the management system clauses.
Every one of these is a list that accumulates over time, which is why in a well-built ISMS each of them ends up as a register with one owner rather than as a document that gets revised. And every one of them is answerable with the question an auditor actually asks: show me the last four.
The Annex A layer, and why it is conditional
If you are also looking at ISO 42001, note that its Annex A is a different control set of 38 controls rather than an extension of this one — the actual mapping covers what that means in practice.
Beyond clauses 4 to 10, some Annex A controls name documented information of their own. The most commonly cited are:
- A.5.31 — legal, statutory, regulatory and contractual requirements identified and documented
- A.8.9 — configurations, including security configurations, documented
- A.5.37 — documented operating procedures
But there is a condition that most lists state weakly or not at all: an Annex A control is only applicable to you if your risk assessment or an external requirement makes it necessary. Annex A is a reference set used to check that nothing necessary was overlooked. It is not a checklist of things you must implement.
This is where the vendor lists inflate. A control that is applicable in your Statement of Applicability generates documentation obligations; a control that is legitimately excluded generates none. Two organisations with genuinely different risk profiles will have genuinely different documentation sets, and both can be certified.
Why the lists you find disagree
Now the disagreement makes sense. Three things are being conflated:
- Documents required by clauses 4 to 10. Seven items, the same for everyone.
- Records required by clauses 4 to 10. Eight items, the same for everyone.
- Documentation generated by applicable Annex A controls. Different for every organisation.
A list that mixes all three and presents them as “the mandatory documents” is not wrong so much as unusable, because you cannot tell which items apply to you and which are the vendor’s preferred structure.
There is also a commercial incentive at work. Documentation kits are priced by volume, and a longer list of mandatory documents makes a larger kit look necessary rather than padded. When you see a toolkit advertising sixty or a hundred and thirty documents, it is worth asking which of them any clause requires.
What a documentation set should and should not contain works through the same question from the buyer’s side.
The practical consequence: what an auditor asks for
Two of the eight records come from the same process: the internal audit programme and its results. Two more come from the risk assessment and its treatment.
At a stage 1 audit, the auditor reviews documentation. The seven documents above, plus the applicable Annex A material, is essentially what stage 1 examines. A purchased kit gets you through it.
At a stage 2 audit, the auditor tests whether the system operates. This is done by sampling: they pick an activity and ask for the record it produced, for a period you did not choose. The eight records above are what that sampling hits.
An ISMS that has been running for three weeks cannot produce them, however complete its documents are. This is the single most common reason a first certification attempt fails, and it is not fixable by writing more documents. It is fixable only by operating the system for long enough to leave a trail — realistically three to six months.
If you take one thing from this article, take this: when you plan your certification timeline, plan it around the records, not the documents.
A test for your own documentation set
For each document you hold, ask which of these it is:
- Required by a clause, in which case it is one of the fifteen items above.
- Required by an applicable Annex A control, in which case the Statement of Applicability should say so and the control should trace back to a risk or an obligation.
- Necessary for effectiveness under 7.5.1 b), which is a legitimate answer — a procedure that people actually follow qualifies.
- None of the above, in which case you are maintaining it for no reason, and maintenance is the real cost of documentation.
The last category is larger than most organisations expect. A management system that only accumulates procedures becomes one that people work around, which is a slower and less visible failure than the one the documentation was meant to prevent.
What good looks like
The same logic applies to an AI management system: see what an AI governance framework consists of, where the distinction between documents and records is if anything sharper.
A lean ISMS for a small organisation typically has:
- Seven documents from the clauses, of which the scope statement and the Statement of Applicability carry the most weight
- Eight registers, one per required record, each with one owner
- A procedure for each Annex A control area that is genuinely applicable, written to be followed rather than to be counted
- Modules for the records those procedures produce, so that nothing is recorded inside a procedure
That is around forty files for a full ISMS, not a hundred and thirty. The difference is not depth. It is that every file has a reason to exist that can be stated in one sentence.
One addition since 2024: the context analysis must now record a determination on climate change, which is a line rather than a document but is checked all the same.
Frequently asked questions
How many documents does ISO 27001 actually require? Seven that must be available, from clauses 4 to 10. Eight further items must be retained as records. Everything beyond those fifteen comes from an applicable Annex A control or from your own judgement under clause 7.5.1 b).
Is an ISMS manual mandatory? No. The standard never requires one. Many organisations keep one because it is a useful way to introduce the system, but no clause asks for it and no auditor can require it.
Why do published lists of mandatory documents disagree? Because they mix three different things: documents required by the clauses, records required by the clauses, and documentation generated by Annex A controls that are applicable to some organisations and not others. Only the first two are the same for everyone.
Are all 93 Annex A controls mandatory? No. Annex A is a reference set used to check that no necessary control was overlooked. A control becomes applicable when your risk assessment or an external requirement makes it necessary, and the Statement of Applicability records that decision either way.
Can I buy the mandatory documentation? You can buy the seven documents. You cannot buy the eight records, because a record proves that something happened. This is why organisations with complete documentation still fail stage 2.
How long does an ISMS need to run before certification? Long enough to produce records an auditor can sample — realistically three to six months. The documentation can be ready in weeks; the evidence cannot.
Does a bigger toolkit mean better coverage? Not on its own. Documentation kits are priced by volume, so a longer list of documents makes a larger kit look necessary. The useful test for any file is whether a clause requires it, an applicable control implies it, or you determined it necessary under 7.5.1 b).
Summary
| Documents | Records | |
|---|---|---|
| Standard’s wording | ”available as documented information" | "retain documented information as evidence of” |
| How many from clauses 4–10 | 7 | 8 |
| What they prove | Intent | Operation |
| Behaviour | Revised, versioned, approved | Not revised; corrections are new entries |
| What an auditor does with them | Reads them at stage 1 | Samples them at stage 2 |
| Can you buy them? | Yes | No |
The documents you can buy. The records you have to earn, and they take months. Any plan that treats ISO 27001 as a documentation exercise fails at exactly the point where the two are told apart.
Where to go from here
The useful test for any documentation set is whether every file in it can justify its own existence in one sentence. Most cannot, and the maintenance cost of the ones that cannot is what makes management systems collapse in year two.
The ISO 27001 Compliance Suite is built on the distinction in this article: procedures separate from the modules and registers that record their output, the eight required registers as separate files with one owner each, and no document included unless a clause requires it or an applicable Annex A control implies it. 43 files, €590 excl. VAT.
If you are starting further back, what a documentation toolkit should contain covers the whole set, the Statement of Applicability covers the one document a certification auditor reads first, and the certification cost breakdown prices the documents, the audit and the three years after it.