ISO 27001 templates: which documents are mandatory, and what goes in them
Search for ISO 27001 templates and you will be offered sets of eighty, a hundred and forty, sometimes two hundred documents, each presented as the complete answer. Then you open the standard and find that the number of documents it explicitly requires is closer to twenty. Both statements are true at once, and the gap between them is where most implementation projects lose several months.
The standard requires documented information in specific places. Annex A implies documents in others, indirectly, by describing controls that cannot be operated without one. Everything beyond those two categories is a choice — sometimes a good one, often the vendor’s rather than yours. A set of ninety documents in a company of forty people is not thoroughness. It is ninety documents nobody will review, and an auditor who reads two of them will find the third contradicts the first.
This article separates the three categories: what the clauses require, what the controls imply, and what you can decline to write. It is written from the reviewing side — what actually gets checked at stage 1, and what gets rejected.
Short on time? The ISO 27001 Total Kit contains the mandatory set as one policy per process rather than a folder of overlapping files, with the registers and forms that produce the records. €590 excl. VAT.
What the clauses require you to document
Clauses 4 to 10 name their documented information explicitly. This list does not change with the size of the organisation.
ISO/IEC 27001:2022 uses the phrase “documented information” and attaches it to particular requirements. Where it appears, you need something written; where it does not, you need the outcome but not necessarily a document. The clause-level requirements are short enough to hold in your head.
The scope of the ISMS, from clause 4.3, states what is in and what is out. It is the first thing a certification body reads, because everything that follows is bounded by it, and an ambiguous scope makes the whole audit ambiguous.
The information security policy, from 5.2, is the management-level statement of intent and commitment. Not the forty-page catalogue of rules — that is the topic-specific policies from Annex A 5.1, which are a different thing and frequently confused with it.
The risk assessment and risk treatment processes, from 6.1.2 and 6.1.3, have to be documented as processes: how you identify risk, what criteria you use, how you decide what is acceptable, who owns the decision. The results of applying them — the risk register and the treatment plan — are records, produced by clauses 8.2 and 8.3.
The Statement of Applicability, also from 6.1.3, lists every Annex A control with a decision and a justification. More on it below; it is the one document that cannot be bought in usable form.
Information security objectives from 6.2, evidence of competence from 7.2, the operational documentation from 8.1, monitoring and measurement results from 9.1, the internal audit programme and its results from 9.2, the management review outputs from 9.3, and the nonconformity and corrective action records from 10.2 complete the list.
That is roughly a dozen items, some of which are records rather than documents. It is the entire mandatory core, and it fits comfortably in a set of twenty files including the forms that produce the records.
Documents and records are not the same thing
The distinction matters more than it sounds, because it determines what you can write in advance and what only exists after you have done something.
A document says what you will do: the policy, the procedure, the process description. You can write it on day one, and a template genuinely helps because the structure is largely the same everywhere.
A record proves you did it: the risk assessment output, the audit report, the management review minutes, the training attendance, the corrective action closure. A template gives you the form; it cannot give you the content, and an auditor can tell the difference in seconds.
This is why toolkit size is a poor proxy for readiness. Buying a hundred documents gets you a hundred statements of intent. Certification turns on the records — the second half, which nobody can sell you — and stage 2 exists precisely to check that the two match. If the policy says quarterly access reviews and there are two reviews on file for the last two years, the policy is now evidence against you.
The practical consequence: prefer a smaller set of documents you can actually operate over a larger set you cannot. Every claim in a policy creates a record you have to produce for the rest of the certification cycle.
The standard is explicit about which items fall on each side: seven documents that must be available and eight records that must be retained, named clause by clause. The full list, and why published versions of it disagree, is worth checking against whatever toolkit you are considering.
The Annex A controls that imply a document
Annex A rarely says “document”. These controls cannot be evidenced without one.
Annex A of the 2022 edition contains 93 controls in four themes, and most of them describe an outcome rather than a document. A minority cannot realistically be demonstrated without something written, and those are the ones your document set has to cover.
Control 5.1 asks for topic-specific policies, approved and communicated — this is where access control, cryptography, secure development, acceptable use and the rest belong. Control 5.9 requires an inventory of information and other associated assets, which is a register rather than a policy. Control 5.10 covers acceptable use of information and assets, 5.14 the rules for information transfer, and 5.15 the access control rules, which we cover in detail in the access control policy article.
The supplier controls, 5.19 to 5.22, require agreed and monitored requirements, which in practice means a supplier security policy and a supplier register. Control 5.24 requires incident management planning and preparation — a documented procedure with roles, and the reason our incident response plan guide exists. Controls 5.29 and 5.30 cover continuity and ICT readiness, which is the business continuity plan. Control 5.31 requires the identification of legal, statutory, regulatory and contractual requirements, usually a register. Control 5.37 asks explicitly for documented operating procedures.
In the people theme, 6.2 requires the terms and conditions of employment to state security responsibilities and 6.6 requires confidentiality agreements. In the technological theme, the ones that reliably need writing are 8.9 configuration management, 8.13 information backup, 8.24 use of cryptography, 8.25 secure development lifecycle, and 8.32 change management.
Add those to the clause-level core and you land at somewhere between twenty-five and thirty-five documents for a typical organisation. That is the honest size of a complete ISO 27001 document set. Anything substantially larger is either a group of companies, a heavily regulated environment, or padding.
One policy per process, not one policy per control. The ISO 27001 Total Kit is built that way deliberately: each process gets one document that covers it end to end, with separate forms and registers for the records. It is why the set is around forty files rather than a hundred and thirty, and why it survives its first review cycle.
The Statement of Applicability is the document you cannot buy
Every toolkit ships a Statement of Applicability, and every one of them ships it pre-filled. That is the problem: a SoA is a record of your decisions about your risks, and one arriving pre-decided is a contradiction in terms.
The SoA lists all 93 Annex A controls and states, for each, whether it applies, why, and its implementation status. The justification is where auditors concentrate, because it is where the thinking is visible. “Applicable — required by policy” is not a justification. “Applicable — addresses risks R-04 and R-11 in the risk register” is, because it traces the control back to something specific.
Exclusions attract more scrutiny than inclusions, and only some reasons survive. That an activity does not exist in your organisation is a good reason — no in-house development, so 8.25 does not apply, provided you genuinely do not develop. That the risk is accepted at management level is acceptable if the acceptance is documented and signed by someone with authority to accept it. That the control is expensive, inconvenient, or planned for next year is not an exclusion; it is either an open treatment action or an accepted risk, and calling it an exclusion is the single most common finding on a first SoA.
Two more failures worth avoiding. An SoA that excludes a control while a policy elsewhere describes doing it — the auditor will find the contradiction, because cross-checking documents against each other is exactly what stage 1 is. And an SoA with no version history, which tells the auditor it was written once and never revisited, which in turn invites questions about everything else.
What you do not need
Some of the bulk in commercial template sets exists to make the set look complete, and you can decline it without weakening anything.
You do not need a separate policy for every Annex A control. Ninety-three controls do not imply ninety-three documents; they imply coverage. One access management policy covering identity, privilege, MFA and review is stronger than five overlapping ones, because five documents drift apart and one does not.
You do not need an ISMS manual. It was a habit inherited from older standards and the 2022 edition does not ask for one. What it usually contains — scope, context, roles, process map — belongs in the documents that already require it.
You do not need documented procedures for every operational task, only where their absence would make the outcome unreliable. Clause 7.5.1(b) leaves this to your judgement, and using it is not a shortcut; it is what the clause is for.
And you do not need the standard’s text reproduced inside your policies. Auditors know what the standard says. What they are checking is what you do about it, and a policy that paraphrases the requirement without deciding anything reads as unfinished.
What actually fails at stage 1
Stage 1 reads the documents against each other. Consistency fails before content does.
Stage 1 is a documentation review, and the findings it produces are boringly consistent across organisations.
Documents that were never adapted are the most common. The template arrives with a placeholder company name, a role that does not exist in your structure, a reference to a department you do not have, or a footer from the vendor. It signals that nobody read the document after buying it, and it invites the auditor to check the others closely.
Contradictions between documents come second. The access policy says access reviews are quarterly, the operating procedure says annually, the SoA says the control is implemented, and the last review was fourteen months ago. Each document may be individually reasonable; together they describe an ISMS that does not exist.
Then there is the policy that promises more than you do. Ambitious commitments — continuous monitoring, annual penetration tests, monthly reviews — written into a policy become the criteria you are audited against. Write what you do; raise it deliberately when you can sustain it.
Missing approval and version control is a small failure with a large consequence: a document with no owner, no approval date and no revision history cannot be shown to be under control, which is a clause 7.5.3 requirement in itself.
Records that do not exist for the periods claimed round out the list, together with a risk assessment whose results do not appear anywhere in the SoA. That last one breaks the chain the whole standard is built on: risk drives treatment, treatment drives control selection, the SoA records the selection. If those three documents cannot be read as one argument, the ISMS is a collection of files.
Keeping the set alive
Certification is a three-year cycle with surveillance audits in between, and the document set has to survive it.
Give every document a single named owner — a person, not a department, because a department cannot be asked when it last reviewed something. Set a review cadence that you will keep, annually for most and after any significant change for all of them. Record the review even when nothing changed, since “reviewed, no change required, date, owner” is evidence and silence is not.
Keep the register of documents small enough to be reviewed in a morning. This is the practical argument for the smaller set: thirty documents reviewed annually is a real process; ninety is a queue that quietly stops moving after the first year, and the surveillance auditor arrives exactly when the backlog is most visible.
The minimum viable set
For an organisation implementing ISO 27001:2022 for the first time, this is a defensible starting set. Adapt the wording, keep the coverage.
- ISMS scope — boundaries, interfaces, exclusions and their basis.
- Information security policy — the management statement, approved at the top.
- Roles and responsibilities — who owns what, including the ISMS itself.
- Risk management process — methodology, criteria, acceptance, ownership.
- Risk register and treatment plan — the output, maintained rather than produced once.
- Statement of Applicability — all 93 controls, decided and justified.
- Objectives and measurement — what you are trying to achieve and how you know.
- Asset and information inventory — the register behind control 5.9.
- Access management policy — identity, privilege, MFA, joiners and leavers, review.
- Acceptable use policy — and the transfer rules, if you keep them together.
- Supplier security policy and register — selection criteria, contractual requirements, monitoring.
- Incident management procedure — roles, categories, escalation, records, notification duties.
- Business continuity and disaster recovery plan — with the impact analysis behind it.
- Backup and cryptography policy — scope, frequency, retention, keys.
- Configuration and change management — including secure development, where it applies.
- Operating procedures — where their absence would make outcomes unreliable.
- Legal and contractual requirements register — control 5.31.
- Internal audit programme and reports — the programme is a document, the reports are records.
- Management review records — inputs, decisions, actions.
- Nonconformity and corrective action log — with closure evidence.
Twenty items, some of which are registers that live in a spreadsheet. Add the topic-specific policies your Annex A decisions actually require, and the set is complete.
If you are also in scope for NIS-2
A large share of organisations pursuing ISO 27001 in 2026 are doing it because NIS-2 arrived, and the two overlap substantially — but not completely.
An ISMS built to ISO 27001 covers most of the ten risk-management measures in Article 21(2) of Directive (EU) 2022/2555. What it does not cover on its own is the personal accountability of the management body under Article 20, the notification deadlines of Article 23 running from awareness, the depth of supply chain assessment Article 21(3) expects, and the explicit requirement for multi-factor authentication. Those are additions to an existing ISMS rather than a second system, and the mapping is worth doing on paper before anyone starts writing documents twice. Our overview of the ten Article 21 measures sets out what each one requires.
If you want to know where you stand across both, the free NIS-2 gap assessment takes ten minutes and scores you obligation by obligation.
Frequently asked questions
How many documents does ISO 27001 require? The clauses explicitly require around twelve items of documented information, some of which are records. Adding the Annex A controls that cannot be evidenced without something written brings a typical set to twenty-five to thirty-five documents. Toolkits offering eighty or more are covering every control separately rather than every process once.
Which ISO 27001 templates are mandatory? The scope, the information security policy, the risk assessment and treatment processes, the Statement of Applicability, the objectives, the internal audit programme, the management review records and the corrective action records. Everything else follows from your Annex A decisions.
Can I use free ISO 27001 templates? Yes, and many are adequate as a starting structure. The cost is in adaptation and consistency: free sets are usually assembled from different sources, so terminology, roles and review frequencies contradict each other — which is exactly what stage 1 looks for. Whatever the source, budget the time to make the set internally coherent.
Is an ISMS manual required by ISO 27001:2022? No. The 2022 edition does not require one. Its usual contents — scope, context, roles, process overview — are required elsewhere, and duplicating them into a manual creates one more document to keep aligned.
What is the difference between the information security policy and the topic-specific policies? Clause 5.2 requires one high-level policy approved by top management, stating intent and commitment. Annex A 5.1 requires topic-specific policies — access control, cryptography, backup and so on — which are operational. Merging them produces a document too detailed for the board and too vague for staff.
How long does it take to write the documentation? For a small organisation starting from a good template set, four to eight weeks of concentrated effort for the documents. The records are the constraint: certification bodies expect to see the ISMS operating, including at least one internal audit and one management review, which is what usually sets the earliest realistic audit date.
Where to go next
Two processes generate more records than any other and are worth reading on their own: the risk assessment, which everything else depends on, and the internal audit, where somebody tests whether the documents describe reality.
The documents are the visible half of ISO 27001 and the smaller half of the work. What determines whether certification goes smoothly is whether the risk assessment, the Statement of Applicability and the operating reality tell the same story.
If you would rather start from a written set than a blank page, the ISO 27001 Total Kit contains the clause-level documents, the topic-specific policies the Annex A controls imply, and the registers and forms that produce the records — organised as one document per process. €590 excl. VAT.
You may also want to read the detailed pieces on the three policies auditors read most closely: access control, incident response and business continuity.
Within the ISO 27001 set, five pieces go deeper than this overview: which documents and records the standard actually requires, how to write a Statement of Applicability that survives an audit, what belongs in the top-level information security policy, the 2024 climate change amendment that most documentation sets predate, and what the whole exercise actually costs, documentation and audit fee both.
If your organisation also builds or uses AI systems, the same management system logic extends to ISO/IEC 42001 — see what certification involves and the readiness checklist.
Sources
ISO/IEC 27001:2022 is published by ISO and must be purchased; this article describes its requirements without reproducing its text.