Document control is one of those requirements that organisations either over-engineer into a bureaucratic nightmare or under-deliver on to the point where an auditor cannot find what they need. Both failure modes are common. The right approach sits between them: a consistent, proportionate system that keeps your ISMS documentation accurate, accessible, and trustworthy — without drowning your ISMS lead in version numbers and approval workflows.
Clause 7.5 of ISO 27001 covers documented information — what you must document, how to create and update it, and how to control it throughout its lifecycle. This guide explains what the standard actually requires and how to build a document control system that works in practice.
Documented Information vs Records: An Important Distinction
Before getting into the mechanics, it helps to understand that “documented information” in ISO 27001 covers two distinct categories.
Documents are the policies, procedures, plans and guidelines that define how your ISMS operates. Your information security policy is a document. Your risk assessment methodology is a document. Your acceptable use policy is a document. Documents are living — they get created, reviewed, updated, and eventually retired.
Records are the evidence that your ISMS is operating as described. Training completion logs, audit reports, management review minutes, corrective action records, supplier assessment notes — these are records. Records are generally not updated once created; they are retained as historical evidence.
Document control applies to both, but differently. Documents need version control, approval processes, and review cycles. Records need retention periods, access controls, and disposal procedures.
Most ISMS document control problems involve documents rather than records — specifically, documents that are outdated, unapproved, or impossible to locate when an auditor asks for them.
What Clause 7.5 Actually Requires
Clause 7.5 is structured in three parts.
Clause 7.5.1 (General) establishes that your ISMS shall include documented information required by the standard and whatever additional documented information your organisation has determined is necessary. The standard specifies a number of mandatory documents — the scope statement, information security policy, risk assessment results, Statement of Applicability, and so on. Beyond those, you decide what else needs to be documented to make your ISMS function.
Clause 7.5.2 (Creating and updating) requires that when you create or update documented information, you ensure appropriate identification and description (such as a title, date, author, and reference number), appropriate format and media, and review and approval for suitability and adequacy. In plain terms: documents need to be clearly identified and need to go through an approval process before they are in active use.
Clause 7.5.3 (Control of documented information) sets out the ongoing control requirements — that documented information required by the ISMS and by the standard shall be available and suitable for use where and when needed, and adequately protected. It also requires you to address how documented information is distributed, accessed, retrieved and used; how it is stored and preserved; how changes are controlled (including version control); and how long it is retained and how it is disposed of.
That last paragraph is where most of the practical work lies.
The Document Lifecycle
Every ISMS document passes through a predictable set of stages. Your document control process should define what happens at each stage and who is responsible.
The ISMS Document Lifecycle
Every ISMS document passes through the same stages — Clause 7.5 applies at each one
Stage 1: Creation
A new document is created in response to a requirement — a new policy needed to address a risk, a procedure update required by a control, or a mandatory document identified during an ISMS gap assessment.
At creation, the document should be given:
- A unique document identifier (e.g. POL-001 for policies, PRO-001 for procedures)
- A descriptive title
- A version number — start at v0.1 for a draft, moving to v1.0 on first approval
- A creation date and author
- A document owner — the person responsible for its accuracy and review
Until a document is approved, it is a draft and should not be treated as authoritative.
Stage 2: Review and Approval
Before any document is issued for use, it must be reviewed and approved. The standard requires review and approval for suitability and adequacy — meaning the person or people approving it need to be able to assess whether it is fit for purpose, not just whether it exists.
For information security policies, approval at senior management or board level is appropriate and demonstrates the leadership commitment required by Clause 5.1. For operational procedures, approval by the relevant process owner or ISMS lead is typically sufficient.
Approval should be documented. This does not have to be a wet signature — a named approver and approval date recorded in the document header, or a version history log, or an email chain, all constitute documentary evidence of approval.
Stage 3: Issue and Distribution
Once approved, the document moves to active status and is issued to those who need it. This raises two practical questions: where does the document live, and how do people know it exists?
Your document storage approach — whether that is a shared drive, SharePoint, a document management system, or a wiki — should be defined and consistently used. The key requirements are that current versions are easily accessible to those who need them, and that outdated versions are either removed from active locations or clearly marked as superseded.
If your staff need to follow a procedure to do their jobs securely, they need to be able to find the current version without hunting through multiple folders or asking the ISMS lead.
Stage 4: Periodic Review
Documents do not stay accurate indefinitely. Policies written during implementation may not reflect the organisation as it is two years later. Procedures may reference systems that no longer exist, or fail to address risks that have emerged since they were written.
Clause 7.5.2 requires that documents remain suitable and adequate — which implies they need to be reviewed at appropriate intervals. Most organisations set a defined review cycle — typically annual for key policies, with a trigger-based review when something material changes.
When a document is reviewed, record the outcome. If no changes are needed, document that the review took place and the document remains current. If changes are needed, follow the revision process below.
Stage 5: Revision
When a document needs to change, the revision process mirrors the initial creation process. The document is updated, the version number incremented (v1.0 becomes v1.1 for a minor update, v2.0 for a significant revision), and it goes through review and approval again before the new version replaces the old one.
Maintain a version history within each document or in your document register — a brief record of what changed and when. This gives an auditor confidence that changes were deliberate and authorised, not arbitrary. It also helps your team understand why a procedure is the way it is.
Crucially, when a new version is issued, the old version must be removed from active use. An organisation where staff might be working from v1.0 and v2.0 simultaneously, without knowing which is current, does not have document control.
Stage 6: Retirement and Disposal
Documents that are no longer needed — because the policy area has been superseded, the procedure replaced, or the process discontinued — should be formally retired.
Retired documents should not be left in active document storage where they might be mistaken for current policy. Archive them in a clearly labelled location (many organisations keep a retired documents folder with the retirement date noted), or delete them. For regulatory or audit trail purposes, some organisations retain retired documents for a defined period — the length depends on your sector and any applicable legal requirements.
Version Numbering: Keep It Simple
There is no standard format for version numbers, but a simple and consistent convention is more useful than a complex one. A common approach:
- v0.1, v0.2… for drafts under development
- v1.0 for the first approved version
- v1.1, v1.2… for minor updates (corrections, clarifications, small additions)
- v2.0 for major revisions (significant structural changes, new content areas, fundamental policy shifts)
Whatever convention you adopt, apply it consistently across all ISMS documents. Inconsistency — some documents using dates as version identifiers, others using numbers, others having no version marker at all — is itself a document control finding.
The Document Register
A document register (sometimes called a master document list) is not explicitly required by ISO 27001, but it is strongly recommended as the practical mechanism for maintaining control of your document set. Without one, an auditor asking “can you show me your full set of ISMS documents” will require you to either produce a list on the spot or guide them through a file structure — neither of which looks as controlled as a maintained register.
Your document register should capture for each document:
- Document ID and title
- Document type (policy, procedure, record, plan, etc.)
- Current version number
- Date of last review and approval
- Date next review is due
- Document owner
- Storage location or link
- Status (draft, active, retired)
Review the register at each management review as a standing agenda item — it takes minutes and keeps the ISMS lead confident that nothing is overdue.
ISMS Document Register: What to Capture
A master document list is not required by the standard — but it is the most practical way to maintain control of your document set
Access Control for Documents
Clause 7.5.3 requires that documented information be adequately protected. For most ISMS documents, this means ensuring:
- Policies and procedures are accessible to those who need to follow them, but not publicly accessible in their entirety
- Sensitive documents — the risk register, certain security procedures, the asset register — have restricted access appropriate to their content
- Only authorised individuals can create or modify documents in the ISMS document set
- There is a mechanism to prevent accidental deletion or modification of records
In practice this is usually managed through folder permissions on a shared drive or document management system. The key test is whether someone could accidentally overwrite the current version of a policy, or whether an ex-employee still has access to your document storage.
What Auditors Look For
When a certification body auditor reviews your document control, they are looking for evidence that your documents are:
Current — the version in use reflects reality. If your incident response procedure still references a helpdesk system you decommissioned last year, that is a gap.
Approved — there is evidence that someone with appropriate authority signed off each document before it went into use. Undated, unversioned documents with no approval record are a common finding.
Accessible — staff who need to follow a procedure can find it. If the ISMS lead has to locate it for them during an audit, that is an accessibility problem.
Reviewed — documents have been reviewed within the stated review cycle. A policy that says “annual review” and has not been reviewed in 26 months is a gap.
Controlled — old versions are not in active circulation. If you have v1.0 and v2.0 of the same policy both accessible to staff, you do not have document control.
Common Mistakes
Treating document control as a one-time setup task. Creating a consistent naming convention and a document register at implementation is necessary. Keeping them maintained thereafter is the harder and more important part.
Version numbers that mean nothing. A document labelled “Information Security Policy v3” with no version history and no record of what changed between versions provides minimal assurance that changes were controlled. Version numbers need to be accompanied by a change record.
Approval that exists only in theory. Many organisations have a policy approval process on paper but in practice update and re-issue documents without going through it. An auditor who asks to see the approval record for a recently updated policy should be able to find it immediately.
Proliferating formats. When different people create ISMS documents in different formats, with different headers and naming conventions, the document set looks uncontrolled even when it is technically adequate. Establish a template early and use it consistently.
Confusing document control with document creation. Some organisations focus heavily on producing more documentation and less on controlling what they have. A lean, well-controlled set of 20 documents is more useful — and more impressive to an auditor — than 60 documents in various states of currency and approval.
FAQs
What is the difference between a document and a record in ISO 27001?
Documents define how your ISMS operates — they are prescriptive and get updated over time. Records provide evidence that your ISMS has operated as described — they capture what happened and are generally not modified after creation. Your risk assessment methodology is a document; the completed risk assessment showing your assessed risks and scores is a record. Your incident management procedure is a document; the incident log entry for a specific event is a record. Both require control under Clause 7.5, but the controls applied to each differ.
Can we use a wiki or intranet for ISMS document control?
Yes, provided the platform supports the control requirements: version history, access permissions, approval workflows (or a documented alternative), and the ability to distinguish current from archived documents. Many organisations use Confluence, SharePoint, or similar platforms effectively. The risk is that collaborative platforms make it easy to edit documents informally — ensure that your governance process is enforced even when the technical barrier to editing is low.
Who should approve ISMS policies?
The information security policy itself should be approved at senior management or board level — this is part of demonstrating leadership commitment under Clause 5.1. Operational procedures and work instructions can be approved at the appropriate operational level — typically the ISMS lead or the manager responsible for the relevant area. The key principle is that whoever approves a document should be able to genuinely assess whether it is suitable and adequate for its purpose.
How long should we retain ISMS records?
ISO 27001 does not specify a universal retention period. For mandatory records — such as internal audit results, management review minutes, and corrective action records — most organisations retain for at least three years to cover a full certification cycle. Records with legal or regulatory significance (incident records, data breach documentation) may have longer statutory retention requirements depending on your jurisdiction and sector. Define retention periods in your document control procedure and apply them consistently.
Does ISO 27001 require specific document formats?
No. The standard does not prescribe formats, templates, or file types. Word documents, PDFs, SharePoint pages, Confluence wikis, and plain text files are all acceptable. What matters is that documents are identifiable, appropriately approved, accessible, and controlled — not what they look like or what software was used to create them.
