ISO 27001 clauses
Write down what helps, then keep it under control.
Clause 7.5 is less about which documents you hold and more about how you look after them. It covers the documents the standard names, the ones you decide your ISMS needs, and the rules for creating, changing, storing and finally destroying each of them. Done well, it is a few lightweight habits. Done badly, it buries a small team in paper.
Back to ISO 27001 services01 · Two sources
Your document set has two parents
Some items the standard names outright. The rest are your call, and the call is part of the requirement.
Named by the standard
A fixed floor
Clauses 4 to 10 each point to information that must exist in documented form: scope, policy, risk method and results, the Statement of Applicability, audit and review results and more. Our mandatory documents guide lists them clause by clause, so we do not repeat the list here.
Decided by you
A judgement you must make
Clause 7.5.1 also expects whatever further documented information your organisation judges necessary for the ISMS to work. That is not a blank cheque for more paper. It is a duty to think about where a written procedure or record genuinely prevents mistakes.
An auditor may ask why a process has no written procedure. A good answer names the people who run it, their competence and the record that proves it ran.
What should push you to write something down
- Size and spreadTen people in one room share knowledge by talking. Two hundred across three cities need it written.
- ComplexityA process with many steps, hand-offs or systems fails quietly without a runbook.
- CompetenceExperienced operators need less instruction than new joiners or contractors on rotation.
- ConsequenceWhere a slip would expose customer data or stop a service, a written step and a record are cheap insurance.
- ProofIf you will later need to show that something happened, a record has to be created at the time.
02 · Creating and updating
Three things every controlled item carries
Clause 7.5.2 boils down to: know what it is, keep it in a usable form, and have someone accountable approve it.
- Identity
- A title, owner, version and date, or an equivalent the system stamps automatically. A reader should know at a glance whether they hold the current copy.
- Fit format
- Language, medium and layout that suit the reader. A diagram can beat ten paragraphs; a ticket template can beat a procedure.
- Review and approval
- Someone with authority confirms it is suitable and adequate before it is used, and again when it changes. In a wiki or repository, an approval workflow or merge review is enough.
The format is yours to choose. Version history in a document suite, pull requests in a repository and approval fields in a governance, risk and compliance (GRC) tool are all valid ways to meet this clause. What an auditor checks is whether the controls actually operate, so pick the mechanism your team already uses every day.
03 · Control over its life
Controlling an item from release to disposal
Clause 7.5.3 asks that documented information is available where needed and adequately protected. In practice that means six decisions.
| Stage | What control means in practice | Evidence an auditor can see |
|---|---|---|
| Distribution | People who need it can find it; superseded copies are withdrawn or clearly marked | One published location, links rather than attachments |
| Access | Read and edit rights follow role; records cannot be edited after the fact | Permission settings, locked or read-only record stores |
| Storage and preservation | Kept somewhere backed up, legible and searchable for as long as needed | Backup scope covering the document store, export formats |
| Change control | Changes are reviewed, approved and traceable to a version | Version history, change log, approval trail |
| Retention | Each record type has a defined keep period based on law, contract and audit need | A short retention schedule, applied in the tool |
| Disposal | Expired records are destroyed or archived on purpose, not by accident | Disposal log or automated deletion rule |
Documents of external origin count too: a cloud provider's security whitepaper, a regulator's direction, a customer's contractual security schedule. Identify the ones your ISMS relies on and keep track of which version you are working from.
The standard does not fix a retention period. Your schedule should be driven by legal and contractual duties and by the certification cycle, since an auditor at recertification will want to trace evidence across the previous years.
04 · Checklist
A document-control checklist you can run in an afternoon
Walk your document store with this list before an auditor does.
- One home. Every controlled document lives in one named place, and staff know where it is.
- Owner on every item. A named role, not a person who left last year.
- Current version is obvious. Drafts and old versions cannot be mistaken for the live one.
- Approval is recorded. You can show who approved the current version and when.
- Review dates are met. Nothing is more than one review cycle overdue.
- Records are locked. Audit reports, review minutes and incident records cannot be quietly edited.
- Access matches role. Sensitive items, such as the risk register, are not open to everyone.
- Retention is written. A one-page schedule says how long each record type is kept, and why.
- Disposal leaves a trace. When records are destroyed, the action itself is logged.
- External sources tracked. The outside documents you rely on are listed with the version in use.
05 · How little is enough
How little is enough
The smallest set that lets a stranger run the ISMS and lets an auditor verify it ran.
A useful test: if your ISMS owner left tomorrow, could a competent replacement keep it running from what is written? If yes, you probably have enough. If the answer depends on someone's memory, you have too little. If the answer is buried under eighty templates nobody opens, you have too much, and the excess is now a liability, because every stale page is a potential finding.
- Start from the clauses that name documented information, then add only what applicable controls demand.
- For every further item, write one line on why it exists: the risk it reduces or the proof it provides.
- Prefer records the work creates on its own, such as tickets, merge approvals and system logs, over separate forms.
- Merge where a reader would expect to find things together.
- Retire anything nobody has opened since the last review.
Illustrative: a 25-person SaaS team
This team kept a single policy document with short topic sections, a risk register and SoA in one spreadsheet, runbooks in its engineering wiki, and records produced by its ticketing and code-review tools. The document-control procedure was half a page. Every requirement could still be traced in under a minute.
06 · Too much paper
Mistakes that come from writing too much
Over-documentation fails audits as reliably as under-documentation.
- Buying a template pack and publishing it whole. Procedures describe processes you do not run, and the auditor tests what the paper says.
- A procedure for every Annex A control. Many controls are better evidenced by a configuration or a record than by prose.
- Copies in several places. Email attachments and desktop copies drift, and someone acts on the wrong version.
- Review dates nobody can meet. Quarterly review of forty documents becomes forty overdue items by the second quarter.
- Writing records after the fact. Back-filled minutes and logs are easy to spot and damage trust in everything else.
- An ISMS manual that restates the standard. It adds pages to control without adding anything an auditor needs.
Sources: ISO/IEC 27001:2022, clause 7.5 (documented information) and its sub-clause titles, described in our own words; ISO/IEC 27001:2022 clauses 4 to 10 for where documented information is named.
Questions about documented information
Is a wiki page a controlled document?
It can be, if it has an owner, history and approval.
Most wikis keep version history automatically. Add a named owner, a way to show approval of the current version, and edit rights limited to the right people, and the page meets the same controls as a signed PDF.
What is the difference between a document and a record here?
Documents are maintained; records are kept unchanged.
The 2022 edition uses one term, documented information, for both. In practice a policy or procedure is updated over time, while a record such as an audit report proves something at a moment and should be protected from change. Our mandatory documents guide compares the two in more detail.
How long should we keep ISMS records?
As long as law, contract and the audit cycle require.
The standard leaves this to you. Set periods per record type, check them against legal and customer obligations, and make sure evidence from earlier years is still there when the recertification audit looks back across the cycle.
Do auditors care which tool we use?
No. They care whether the controls work.
A shared drive, a repository or a GRC platform are all acceptable. The auditor samples items and checks identity, approval, current version and protection. The tool only matters if it makes those checks fail.
Can we lose a certificate over document control?
Rarely alone, but it makes every other finding worse.
Weak document control usually shows up as minor findings: an outdated procedure, an unapproved change. The bigger risk is indirect. If records cannot be trusted, the auditor cannot rely on them as evidence for other clauses.
Trim the paper, keep the proof.
An ISO 27001 gap analysis reviews your document set against clause 7.5 and tells you what to keep, merge and retire.