ISO/IEC 27001:2022 requires documented information to be identified, approved, available where needed, protected, version-controlled, retained, and disposed of under a document control procedure, as set out in Clause 7.5. If your scope statement, policy, Statement of Applicability, risk assessment, objectives, and audit records lack an owner, a version number, or a retention rule, that gap is the first thing to fix before anything else.
TL;DR:
- Most mandatory documents require clear ownership, version control, approval, and retention rules to meet ISO standards and pass audit scrutiny.
- A well-maintained document register with key fields like owner, version, approval, and review date is essential for audit readiness and ongoing compliance.
- Extra supporting documents such as control procedures and retention schedules can streamline audit preparation but must be tailored to your organization’s size and complexity.
- Regularly verifying that staff can access current versions, records are retained properly, and external documents are tracked reduces common nonconformities during audits.
- Implementing a straightforward, role-based document control procedure helps organizations build and sustain effective evidence management aligned with ISO/IEC 27001:2022 requirements.
Table of Contents
- 1. What documented information does ISO 27001 actually require?
- 2. Documents you maintain versus records you retain
- 3. Which extra documents are worth creating, and which aren’t
- 4. How should you organize a document register and set ownership?
- 5. Common document-control nonconformities and how to close them
- 6. How do you implement a document control procedure from scratch?
- 7. What should you check before an ISO 27001 audit?
- 8. How do planning tools help scope document-control work?
- Getting the balance right between evidence and paperwork
- Where a planning tool fits into your document control rollout
- FAQ
- Sources
1. What documented information does ISO 27001 actually require?
ISO/IEC 27001:2022 does not hand you a list of named templates. It names the outcomes clauses 4 through 10 require documented evidence for, and leaves the format to you. That distinction matters because auditors check for substance, not paperwork style: a one-page scope statement satisfies the standard as well as a twenty-page one, provided the content is accurate and controlled.
The core items every certified organization needs to show, with their clause references, according to ISO/IEC 27001:2022:
- Scope of the ISMS (Clause 4.3): the boundaries of what the management system covers, including locations, business units, and exclusions.
- Information security policy (Clause 5.2): top management’s commitment, approved and communicated.
- Risk assessment and treatment process and outputs (Clauses 6.1 and 8.x): the methodology used and the results it produced.
- Statement of Applicability (Clause 6.1.3 d): every Annex A control, whether it is applied or excluded, with a justification for each exclusion.
- Information security objectives (Clause 6.2): measurable goals tied to the policy, with plans for achieving them.
- Operational records from clauses 7 through 10: evidence of competence, monitoring and measurement results, internal audit reports, management review minutes, and records of nonconformities and corrective actions.
Auditors sampling these items look for specific things. A Statement of Applicability with a control marked “not applicable” but no justification attached is a near-automatic finding. A risk assessment that lists risks but never ties them back to the SoA decisions leaves the auditor unable to trace why a control was chosen or skipped. The thread connecting policy to risk assessment to SoA to operational evidence is what auditors actually follow, more than any single document’s formatting.
2. Documents you maintain versus records you retain
ISO’s own guidance on documented information draws a sharp line between two categories that get controlled differently, as explained in the ISO guidance on documented information. A document is something you maintain: it describes intent, gets updated as circumstances change, and needs a current, approved version in circulation. A record is something you retain: it’s evidence that something happened, and once created, it should not change.
The practical distinction plays out like this:
- Documents (policies, procedures, the SoA) need version control, a defined review cycle, and an approval step before each new version replaces the last.
- Records (audit reports, management review minutes, training logs) need tamper evidence or write-once storage, plus a retention schedule that says how long to keep them and when to dispose of them.
- A policy typically goes through an annual review cycle, picking up a new version number each time it changes.
- An audit report, once signed off, gets archived as-is. Editing it after the fact defeats its purpose as evidence.
Mixing these two up is a common early mistake. Teams sometimes let an audit report get “updated” after the fact to correct a typo, which destroys its value as a point-in-time record. Others let policies sit in a shared drive with no retirement process, so three versions circulate at once and staff cite whichever one they found first.
3. Which extra documents are worth creating, and which aren’t
Beyond the mandatory items, most ISMS programs benefit from a small set of supporting documents that make Clause 7.5 compliance easier to demonstrate without turning into a maintenance burden.
The ones worth the effort for almost any organization:
- A short document control procedure describing how documents are identified, approved, and retired.
- A document register listing every controlled document and record with its owner and status.
- A retention schedule mapping record types to how long each must be kept.
- A change management procedure for tracking what triggers a document update.
- A handful of operational procedures mapped directly to the Annex A controls you actually rely on, such as access provisioning or incident response.
How many of these you need depends on your size and process complexity. A twelve-person startup with one office and no regulated data rarely needs the same procedural depth as a 500-person company running multiple business units under different contractual obligations. Staff competence matters too: a team with strong institutional knowledge can run on leaner documentation than one with high turnover, where written procedures carry more of the operational memory.
Combining documents usually beats splitting them when the audience and review cycle match. A single access control procedure that covers provisioning, review, and deprovisioning is easier to maintain than three separate documents that drift out of sync with each other. Split only when different owners or different review cadences genuinely require it.
Pro Tip: If two documents are always updated together by the same person, merge them. If you find yourself updating one without touching the other, that’s a sign they were right to stay separate.
4. How should you organize a document register and set ownership?
A document register is the single artifact auditors reach for first, and it does most of the work of satisfying Clause 7.5’s control requirements if it is built with the right fields.
At a minimum, track these fields for every entry:
- Document ID and title
- Owner (a named role, not a department)
- Version number and status (draft, approved, retired)
- Approval date and approver
- Next review date
- Classification (confidential, internal, public)
- Storage location
- Retention period (for records) or review cycle (for documents)
A simple major.minor versioning convention works well for most organizations: increment the major number for substantive content changes that need re-approval, and the minor number for typo fixes or formatting cleanup that doesn’t change meaning. Pair each version bump with a short change log entry, one paragraph explaining why the change happened, who approved it, and when. Practitioner analyses of ISMS procedural structures consistently point to a brief rationale alongside each version as more useful to auditors than a raw diff or history log, a point echoed in practitioner research on ISMS procedural architecture.
When choosing a platform to host the register and the documents themselves, check for a short list of capabilities before anything else:
- Permission tiers that separate who can view, edit, and approve.
- Version history that preserves prior versions instead of overwriting them.
- Search and navigation good enough that staff can find the current version in seconds, not minutes.
- Approval evidence captured automatically, not reconstructed after the fact from email threads.
- Immutable archival for records once they’re finalized.
Some organizations run this on a shared drive plus a spreadsheet register, which works at small scale but strains once document counts climb past a few dozen. Others use a wiki with an approval workflow bolted on, or a dedicated document management or GRC platform built for the purpose. For organizations managing large libraries of training or procedural content, tools that flag content drift automatically, such as the content drift detection platform from Continuity, can catch documents quietly going stale between formal review cycles.
Pro Tip: Assign a review date to every document the day it’s approved, not months later. A register with no next-review dates is a register that will be full of expired documents within a year.
5. Common document-control nonconformities and how to close them
Certain findings show up repeatedly in ISMS audits because they trace back to the same handful of control gaps.
- Obsolete versions still in active use. Staff reference an old policy because the current one isn’t where they expect it. Remediation: confirm the register’s storage location field matches where staff actually look, retire superseded versions from shared locations, and verify during the next internal audit that a sample of staff can locate the current version at their point of use.
- Missing justification for excluded Annex A controls. The SoA marks a control “not applicable” with no explanation. Remediation: revisit the risk assessment for each excluded control, document the rationale directly in the SoA, and have the risk owner sign off.
- No evidence of staff competence. Training happened, but nothing proves it. Remediation: capture attendance records, assessment results, or role-specific sign-offs, and store them as records with a defined retention period.
- Records deleted or altered before their retention period ends. This usually happens through default storage cleanup rules nobody checked against the retention schedule. Remediation: align storage system retention settings with the documented schedule, and spot-check that deletion rules in your platform match what’s written down.
- Uncontrolled external documents. Customer security requirements or regulatory texts get referenced but never tracked for changes. Remediation: add external documents to the register with an assigned owner responsible for noticing when the source changes.
For each of these, the verification an auditor wants is simple: show the register entry, show the approval or justification, and show that the current version in circulation matches what the register says it should be. A quick preventive habit, checking the register against reality once a quarter rather than once a year, catches most of these before an audit does.
6. How do you implement a document control procedure from scratch?
A workable document control procedure doesn’t need to be long. A two-to-four page document covering the following sections, as recommended in ISO’s guidance on documented information, is enough for most organizations:
- Purpose and scope: what kinds of documented information this procedure covers.
- Roles: who can author, review, approve, and retire documents.
- Approval tiers: which document types need executive sign-off versus manager-level approval.
- Identification: how documents are named and numbered.
- Versioning: the convention used and when a version bump triggers re-approval.
- Distribution and storage: where current versions live and how staff find them.
- Retention and disposition: how long each record type is kept and how it’s disposed of.
- External documents: how documents from outside the organization are tracked for changes.
With the procedure drafted, the rollout follows a predictable sequence:
- Assign document owners for every category before building the register, so nothing lands ownerless.
- Build the register using the fields covered earlier, starting with the mandatory items.
- Migrate existing documents into the register, mapping old files to new IDs and preserving any existing approval evidence rather than re-approving everything from scratch.
- Enforce the approval workflow going forward, no exceptions for “quick fixes.”
- Train staff on where to find current versions and how to request a change.
- Run a pilot on one department or process before rolling out organization-wide.
- Sample-check a handful of documents in an internal audit before the external audit ever happens.
On technical options, the right choice depends on document volume more than budget. A file share paired with a spreadsheet register works for small ISMS programs with a few dozen documents. A wiki with an approval workflow plugin suits mid-size teams that want searchability without a dedicated platform. A full document management system or GRC platform earns its cost once document counts, approval chains, or regulatory retention obligations get complex enough that manual tracking becomes error-prone. Whichever you choose, check permission granularity before committing: some platforms handle view and edit permissions well but fall short on capturing approval evidence automatically, which then has to be reconstructed by hand before an audit. Platforms built around permission-aware workflows, such as the approach described in ClawBase’s guidance on file access controls, illustrate what fine-grained access control for sensitive registers can look like in practice.
Migration tips worth following: never discard the old approval trail when moving a document into a new system, since that trail is exactly what an auditor wants to see for continuity. Map old file names to new register IDs in a single pass rather than piecemeal, so nothing gets orphaned.
On retention, set the period for each record type based on legal, contractual, or evidentiary need rather than guessing. Where no external requirement dictates a period, a conservative and defensible baseline is to keep core ISMS records across at least one full certification cycle, so an auditor revisiting your program can trace the history.
Pro Tip: Pilot the register on your riskiest process first, such as access control or incident response. If the register holds up there, it will hold up everywhere else.
7. What should you check before an ISO 27001 audit?
A short self-check before Stage 1 or Stage 2 catches most of the gaps auditors would otherwise find for you.
- Every register entry has a named owner, not a department or a vague title.
- Every document shows a recorded approval, with a name, role, and date attached.
- Records that should be immutable actually are, with no edit history showing changes after finalization.
- Retention periods are applied in the storage system, not just written in a schedule nobody enforces.
- Staff asked to pull up a document can find the current version at their point of use, not an old copy from a shared drive.
Auditors typically sample a bundle of connected evidence rather than checking documents in isolation. A typical request chains together the SoA, the risk assessment record behind it, the treatment plan, evidence that the treatment was implemented, monitoring results confirming it’s working, the internal audit report covering that area, and the management review minutes discussing it. Our practical guide to audit evidence types walks through how these bundles typically get assembled.
Where gaps turn up during a self-check, the remediation is usually fast: assign the missing owner, capture the missing approval retroactively with today’s date and a note explaining the gap, or correct a retention setting. Verification is just re-running the same check a week later and confirming the gap closed.
8. How do planning tools help scope document-control work?
Estimating how much documentation work an ISO 27001 program actually needs is easier with a sense of scale up front. A cost and effort calculator can translate your company size, industry, and current security maturity into an estimated number of person-days for documentation work, alongside a suggested review cadence for different document types. A maturity assessment across the four Annex A control themes highlights which domains have the thinnest documentation today, which is useful for deciding what to tackle first rather than documenting everything at once.
Our free 2-minute readiness check gives a fast first read on where your documentation gaps sit relative to a typical implementation, before you commit to building out a full register and procedure set.
Getting the balance right between evidence and paperwork
Good document control proves that critical processes are run deliberately, not that every possible activity has a form attached. I’d tie documentation effort to the processes where failure actually hurts, access control, incident response, vendor risk, and assign a real owner to each. Two heuristics have held up well: keep core ISMS records for at least one full certification cycle, and write change logs that explain why a change happened, not just what changed. A readable rationale beats a clean diff every time an auditor asks a follow-up question.
— Martin
Where a planning tool fits into your document control rollout
Scoping document control work gets easier once you know roughly how many person-days it will take and which domains need attention first. We built our ISO 27001 Cost Calculator to turn your company size, industry, and current maturity into a tailored estimate, with editable assumptions you can challenge against our published methodology rather than take on faith.
A few ways to put it to use for document control specifically:
- Run the free 2-minute check to get a fast read on which documentation areas are thinnest today.
- Use the ISO 27001 Readiness Assessment to get prioritized workstream suggestions, including which documents to build or harmonize first.
- Save and compare two estimates, one lean and one thorough, to see how documentation scope changes the overall timeline before you commit a team to it.
If you’re weighing outside help for the broader implementation, platforms exist that facilitate introductions to independent ISO 27001 consultants once you have a clearer sense of scope.
FAQ
What are the ISO requirements for document control?
Clause 7.5 requires that documented information be identified and described, reviewed and approved before use, and controlled so it stays available, protected, and fit for purpose. Controls cover distribution, storage, retention, version management, and disposition, as detailed in ISO’s guidance on documented information.
What are the mandatory documents required by ISO 27001?
The core set includes the ISMS scope, the information security policy, the risk assessment and treatment process and its outputs, the Statement of Applicability, information security objectives, and supporting records such as internal audit reports and management review minutes. ISO 27001 specifies the content these must cover rather than a fixed template, per ISO/IEC 27001:2022.
Can you explain ISO 27001 in simple terms?
ISO 27001 is an international standard that sets out how to build and run an information security management system: identifying risks to your information, choosing controls to address them, and proving those controls work through documented evidence. Document control is the part of the standard that makes sure the evidence itself stays accurate, current, and traceable.
Which is better, ISO 27001 or NIST?
The two serve different purposes: ISO 27001 is a certifiable management system standard with an external audit and certificate, while NIST frameworks are largely non-certifiable guidance documents widely used in the United States. Which fits better depends on whether you need a recognized certification for customers or regulators, or an internal risk management reference, and organizations in regulated sectors sometimes align with both.