ISO/IEC 27001:2022 Clause 7.5 documented information: keep it lean

The prospect's security questionnaire asks for your ISMS documentation. Nobody can say which version of the access control policy is current, and the approval is somewhere in a chat thread. The deal waits while someone digs through shared drives.

This guide covers ISO/IEC 27001:2022 Clause 7.5 documented information for security leaders and compliance owners at UK service providers with 25–250 staff. It shows what the clause requires, how many documents you need, what auditors sample, and how to let the platform you already run do the policing.

What is ISO/IEC 27001:2022 Clause 7.5 documented information?

Documented information is information an organisation must control and maintain, plus the medium holding it. ISO/IEC 27000:2018 defines the term, and Clause 7.5 applies it to the ISMS. It covers two layers: directive documents that state intent, such as policies and procedures, and operational records that prove what actually happened.

The wording comes from entry 3.19 of the ISO/IEC 27000:2018 terms and definitions, the overview and vocabulary standard for the ISMS family. A policy in a wiki, a training log in a spreadsheet and a signed PDF all qualify, provided you can show they are under control.

The two layers are different in kind, so it helps to name them:

• Directive documents state intent. Examples are the information security policy, the scope statement, procedures, the risk treatment plan and the Statement of Applicability (SoA).
• Operational records prove what happened. Examples are training completions, management review minutes, internal audit reports, monitoring outputs and corrective actions.

One item often does both jobs. A procedure guides staff on the day, and its version history later shows which rules applied when. Teams that treat Clause 7.5 as a policy-writing exercise forget the records layer, yet auditors sample records as readily as policies. Records need a home and a retention rule, not just a signature.

What are the ISO 27001:2022 Clause 7.5 documented information requirements?

ISO/IEC 27001:2022 Clause 7.5 documented information requirements run through three sub-clauses: 7.5.1 decides which documents exist, 7.5.2 governs how each is created and updated, and 7.5.3 governs how approved documents are distributed, protected, retained and disposed of. Together they form one lifecycle, not three separate checklists.

Read ISO 27001 clause 7.5 as a sequence, which is what most people mean by ISO 27001 document control:

1. 7.5.1 General sets the footprint: the documents the standard names, plus whatever your operation needs written down.
2. 7.5.2 Creating and updating governs birth and revision: identity, a deliberate and consistent format, and approval before use.
3. 7.5.3 Control governs life in circulation: access, storage, versioning, retention and disposal.

The order matters for effort. Build the template, version convention and approval workflow from 7.5.2, and the repository from 7.5.3, before you draft the document set from 7.5.1. Adding identity and approval trails to fifty finished documents later is a slog.

The stakes differ by sub-clause. A missing mandatory document is the fastest way to fail an audit, because there is nothing to argue about. Poor hygiene on a sampled document primes the auditor to dig harder everywhere else. A failed "show me" moment on records costs more trust than the gap behind it deserves.

How many documents does Clause 7.5.1 actually require?

Clause 7.5.1 requires the documents the standard names plus whatever your operation genuinely needs written down. At 25–50 people, a core set of roughly 25–30 documents is normal and defensible. The standard expects the footprint to scale with headcount, complexity and competence, so a 100-document template pack is not what compliance requires.

Start from the mandatory list and work outward. The standard names its non-negotiables where each requirement lives:

• Scope statement (clause 4.3).
• Information security policy (clause 5.2).
• Risk assessment method and results.
• Risk treatment plan.
• Statement of Applicability (SoA).
• Security objectives (clause 6.2).
• Operating records: competence and training evidence, monitoring results, internal audit reports, management review minutes and corrective actions.

For everything else, apply one test. Would this process go wrong, or be done inconsistently, without a written procedure? If yes, document it. If no, leave it out, and note the reasoning, because auditors ask how you decided.

Template packs invert that logic. They hand you a hundred documents written for someone else's business, which nobody on your team reads.

Every document you add is a review liability you have promised to pay.

The other cost is paper–practice divergence. An elaborate manual sits on the shelf while the team runs on informal checklists, and auditors interview the team. The gap is what gets written up.

Keep the footprint findable. Use one repository your team already runs, such as SharePoint, Confluence, Notion or an ISMS platform, with a simple register over it holding identifier, title, owner, version and review date. Give every document a named owner, because unowned documents are the ones that go stale. The inventory and register take a day or two, and they double as your gap analysis, so do them early.

What does Clause 7.5.2 require when creating and updating documents?

Clause 7.5.2 requires every ISMS document to be identifiable, consistently formatted, and reviewed and approved as suitable before use. Identification means title, reference, owner, date and version. Make the approver someone other than the author, and keep a workflow sign-off, digital signature or minuted decision as proof.

One template and a few conventions carry most of the load:

• One template. A standard header and footer with title, reference, owner, version, date and classification means every new document is born compliant.
• One version convention. Use 0.x while drafting, 1.0 on first approval, and an increment on each approved change. Keep a change table recording who changed what, when and why.
• One named owner. Only the owner edits and everyone else reads. Shared ownership is how revisions go untracked.
• Independent approval. A workflow sign-off, digital signature or minuted decision from someone other than the drafter.
• Draft and live separation. Publish a read-only PDF or locked page, so nobody works from a half-edited draft.
• Review dates that nag. Calendar reminders per owner cost nothing and close the most common gap, reviews that never happen.

Before approving a change, spend ten minutes checking what else it touches: the risk treatment plan, the asset register and neighbouring policies. Conflicting documents are a finding waiting to happen.

The bigger risk is defensibility. When a client dispute or regulatory inquiry asks which procedure was in force on a given day and who authorised it, a lost email thread does not answer.

An approval that lives in a chat thread did happen. You just cannot prove it.

Two over-corrections are common. A change table that records what changed but never why leaves auditors and successors guessing at intent. A five-stage approval workflow at a 30-person firm gets bypassed within a quarter, and an unfollowed process is a worse finding than a simple one that runs. Set the template, conventions and workflow up before drafting the 7.5.1 document set. Half a day of setup then runs as habit.

How does Clause 7.5.3 control access, retention and disposal?

Clause 7.5.3 requires approved documents to stay reachable by those who need them and protected from leaks, tampering and loss. That means defined access levels, controlled storage, versioning, a retention schedule and disposal. Records must stay unaltered, and the retention schedule must also respect UK GDPR, which bars keeping personal data longer than you need it.

The controls that satisfy this are mostly configuration on a tenancy you already pay for:

• One repository, no exceptions. Publish read-only to staff, confine editing to document owners and put strong authentication on the lot. Microsoft 365 or Google Workspace does this without new tooling.
• Split roles. Whoever drafts does not approve, and each owner has a named deputy so a holiday does not stall the system.
• Visible status. Mark documents draft, in review, approved or obsolete. Superseded versions leave the live space for an archive staff cannot stumble into.
• A protected store. Encrypt at rest and in transit, and back up automatically to somewhere tamper-resistant.
• An audit trail. Switch on the platform log of who viewed, edited, approved and deleted what. It is your proof of who did what.

Backups need proof. The ICO guide to data security expects measures that let you restore access to personal data in a timely manner after an incident. A periodic test restore, filed as a record, is how you show that.

Backups without restores are a hope, not a control.

The retention schedule is the thinking-heavy part, so hold a half-day workshop with whoever owns legal and client obligations. For each record type, state how long it lives and what happens at end of life. Logs need particular care: the NCSC 10 Steps to Cyber Security: Logging and monitoring guidance recommends storing your most important logs for at least six months, because incidents can take months to detect.

Destruction needs sign-off and proof, such as a disposal log, a wiping report or a shredding certificate. Add a hold mechanism, so that scheduled deletion stops while an investigation or legal matter is open.

Three failure patterns recur under this sub-clause:

• Shadow copies. PDFs saved locally or forwarded by email quietly diverge from the live version until someone follows the wrong one.
• Author-as-approver. One person drafting, approving and publishing reads as no control at all.
• Permission debt. Leavers and role-changers keep edit or admin rights because removing access only covered the big-name systems.

An annual sweep closes most of them. Reviews happen, stray comments and tracked changes come out of published copies, and leavers' repository access is confirmed gone.

How do you control external documents under Clause 7.5?

Outside material your ISMS depends on, such as laws, regulations, client contracts and technical standards, falls under Clause 7.5.3 control. Catalogue it in an index, protect that index from casual edits, and check it for currency so you notice when an obligation changes.

Each index entry needs the obligation, its source, an owner, a last-checked date and the ISMS documents it drives. The last column is what makes the index useful. If a client contract sets a breach-notification window and is renegotiated, the incident procedure it drives surfaces for review.

Auditors look for some sign the index is maintained rather than written once. A last-checked date per line, filled in on a schedule, is usually enough.

What do auditors ask and sample under Clause 7.5?

Auditors run a retrieve-and-show test: they pick documents from your register, ask for records against the clock, and check leaver permissions. They also interview staff to see whether the written procedure matches practice. A gap between paper and practice is the classic finding under this clause.

Expect questions like these in the room:

• "Walk me through your document register. What is overdue?"
• "Pick this procedure up. Who approved this version, when, and where is the proof?"
• "How do I tell a draft from the live version?"
• "Find me the management review minutes from two cycles ago."
• "A former employee left in March. Show me their repository access today."
• "This record type expired last year. Prove it was destroyed properly."

Sampled documents get a metadata check: the front-page version matches the change table, an approver is named and the dates are plausible. Recent revisions are traced end to end, from trigger and edit through impact check and sign-off to publication.

A prepared 50-person firm answers each question in minutes, with:

• A register that matches what is inside each document.
• The mandatory set, produced on request without a search party.
• Repository permissions shown live, with owner-only edit rights.
• Audit logs and a recent access review showing leavers lost access.
• Backup job history plus at least one test-restore record.
• The retention schedule and disposal evidence for anything past end of life.

Grading depends on the pattern. Certification bodies typically treat a total breakdown, such as no retention rules, no access control on the store or records anyone can alter, as major. A lapsed review or one stray obsolete copy is minor, though minors aggregate to major where they cluster.

How do you automate Clause 7.5 on Microsoft 365 or Google Workspace?

Microsoft 365 or Google Workspace already provides what Clause 7.5 needs: required metadata fields, approval workflows, read-only publication, audit logs, permission reviews and retention rules. Configure them once and the platform enforces the rules by design, collecting evidence as a side effect instead of relying on people remembering.

Treat the register as the control plane. Each document is a record with owner, version, classification and review-due date, so "what is missing or overdue" becomes a dashboard query with automated owner reminders. Link each procedure to the risks and controls it serves, and a change to either surfaces the documents affected.

Let the platform own the discipline. Required fields mean a document without an owner or version cannot be saved. Approvals route through ticketing or the document platform, capturing proposer, approver, timestamp and rationale as a side effect. Repository permissions follow the identity platform, so a leaver's edit rights disappear with their account. The table lists each automation with what it catches and what it leaves behind.

The payoff is commercial. A lean footprint of 25–30 owned documents, plus evidence that collects itself, means an enterprise security review is answered from a dashboard rather than a hunt through shared drives.

Frequently asked questions