The list of ISO 27001 mandatory documents is shorter than the template packs sold to you for the purpose, and it fits on half a page. An ISMS manual is not on it.
Even so, a certification audit rarely looks like someone counting documents. Picture the table at the stage two audit. The drive holds policies, neatly formatted, each with a version number and an approval date. The auditor opens two of them. Then he asks when the access rights were last reviewed, who signed off on the result and where that is written down.
That question tells you whether an ISMS project holds up. The number of documents makes no difference here. What counts is whether anything on record shows that someone did something.
What ISO 27001 requires as a document
ISO/IEC 27001:2022 requires a document in a few clearly named places:
- the scope of the ISMS (clause 4.3)
- the information security policy (5.2)
- the information security risk assessment process and the risk treatment process (6.1.2 and 6.1.3)
- the Statement of Applicability together with the risk treatment plan (6.1.3)
- the information security objectives (6.2)
That is the list. On top of it comes the clause that governs everything else. 7.5.1 names two sources of documented information: the information the standard itself requires, and the information the organisation determines to be necessary for the effectiveness of its ISMS. The second part is room to decide, not a specification. In the same clause the standard holds that the appropriate extent differs with the size of the organisation, its activities, the complexity of its processes and the competence of the people involved.
In plain terms: a fiduciary firm at one site and an industrial company with production in two countries may document to different depths, and both meet the standard. Anyone selling you a fixed template pack as an obligation is selling you an interpretation.
One document on the list deserves its own mention: the Statement of Applicability. The Statement is the hinge between your risk assessment and the controls from Annex A. For each control it records whether it applies and why, and if it does not apply, why not. In the audit it is the entry point, because every sample can be drawn from there. Take it from a template and leave someone else's justifications in place, and you achieve the opposite: a document that creates checkpoints nobody in the house can speak to. A Statement of Applicability in which some controls do not apply, with a justification that holds, stands up better in the audit than one in which everything has supposedly been implemented.
The two subclauses that follow are usually overestimated. 7.5.2 and 7.5.3 require a document to be identifiable, meaning it carries a title, a date and a version, to come in a usable format, to be reviewed for suitability before approval, and to make clear who may access it and how long it is kept. In an SME that is half a page plus the settings in your file storage, not a project of its own.
Document or record: where the ISO 27001 mandatory documents end
The larger part of the documentation requirements are not documents. They are records, in the language of the standard retained documented information, and they only come into being once the management system runs. The standard requires them in eight places:
- evidence of competence of the people involved (7.2)
- evidence that the planned processes were carried out as planned (8.1)
- the results of the risk assessment (8.2)
- the results of the risk treatment (8.3)
- the results of monitoring and measurement (9.1)
- the audit programme and the audit results (9.2)
- the results of the management review (9.3)
- nonconformities, the actions taken and the results of corrective action (10.2)
A policy you can write in a morning. A record you cannot. It is either there, because someone reviewed the access rights in March and wrote down the result, or it is missing. There is no honest way to produce it after the fact.
A usable record is unspectacular. For an access rights review, four entries are enough: when it took place, who did it, what came up and what was decided. That is a row in a table or an email with a date, not a formatted document with a cover page. A ten page policy on access management does not answer that question.
This is where a project team loses months. Writing documents for six months and then going into the audit does not work, because a good part of the requirements needs a history. The internal audit has to have taken place. The management review has to have a result that someone wrote down. The risk assessment needs results with dates. In our experience that is a more common reason for a finding in the audit than a missing policy.
Why the stack still grows to template pack size
Three reasons, and none of them is in the standard.
The first is Annex A. The controls there are a reference list from which the Statement of Applicability selects and justifies what applies and what does not. Some of the controls do call for a rule, an instruction or a record in their own wording. For the rest that is not the case. One policy per control is a convention of template packs sold by volume, not a requirement of the standard.
The second is sequence. Write documents before the scope is settled and you write them twice. The scope decides which sites, systems and processes are meant at all, and with that, which rules apply to whom. If it only lands in the third month, by then you hold documents governing things that end up outside it.
The third is the tool. An ISMS tool is useful once you know what you want to manage. Before that it is a vessel that fills with placeholders, and it creates work instead of saving it. The licence is the smaller item here, as we described in our piece on ISO 27001 costs. The expensive part is the time that goes into maintaining a system nobody uses in daily operations.
What your customer reads and what they do not
In the Swiss mid-market it is usually a buyer who puts the document question on the table, not the standard. A supplier questionnaire asks for the certificate, and anyone looking closely reads the scope line on it. That line tells them which part of your company was audited. A certificate whose scope excludes the department working for them does not answer their question.
Almost nobody asks for your policies. What the customer wants to know is whether someone at your end is responsible, how you handle incidents and whether your statements can be checked. Those are the same records the auditor wants to see. Treat information security in an SME as an operation and you serve both sides with the same work.
What you may leave out
In our experience the deletion list is the fastest lever in an ISMS project, because it removes effort without breaking a requirement:
- Templates on topics your scope does not include. A software development policy in a house that develops no software is no evidence of care, it opens a source of findings in the audit.
- The policy per control. Several rules fit into one document when they concern the same people.
- English templates translated into a German nobody in the company reads. A document nobody follows produces exactly the finding you wanted to avoid.
- The document about the control of documents, as long as 7.5.2 and 7.5.3 are met on half a page.
What belongs in the budget instead is the time for the records: the access rights review, the internal audit, the management review, the follow-up on findings. Those items rarely appear in document offers, although they carry the larger part of the work.
Who keeps the records
A document titled responsibility matrix appears nowhere in the standard. Records it requires in eight places, and those only come into being when someone has an appointment in the calendar with their name next to it.
That is the constraint behind the whole document question. A template pack can be bought, a responsibility cannot. Without one, what happens to the pack is what we see regularly: someone introduces it in the first year, in the second nobody maintains it, and at the surveillance audit it shows that every version number dates from the month of certification.
The more useful first question is therefore not which documents are missing, but who writes down at the end of the quarter what happened. That is what we take care of when we support an ISMS build to ISO 27001: scope and responsibility first, then the short list of documents, and from the start a rhythm that produces records. If you want to keep the path there lean, you will find the sequence in our piece on the pragmatic ISMS build.
If you are unsure which records already accrue at your end with nobody writing them down, look at it with us once, in a structured way. A first conversation is free of obligation and costs you half an hour.
And in case someone asks tomorrow about the last access rights review: do you find the record, or the policy that demands it?
Frequently asked questions
Which documents does ISO 27001 strictly require?
The standard names the scope of the ISMS (4.3), the information security policy (5.2), the risk assessment and risk treatment processes (6.1.2 and 6.1.3), the Statement of Applicability with the risk treatment plan (6.1.3) and the information security objectives (6.2). Everything beyond that, your organisation determines itself.
Does every Annex A control need its own policy?
No. Annex A is a reference list from which the Statement of Applicability selects and justifies. Some controls call for a rule or a record in their own wording, the rest do not. One policy per control is a convention of template packs, not a requirement of the standard.
What is the difference between a document and a record?
A document sets out how you intend to work and can be written in a morning. A record shows that you did it, and it only comes into being in daily operations. The standard requires records in eight places, among them the internal audit, the management review and corrective actions.
