ISO 27001
ISO 27001 document control and documented information
ISO 27001 document control covers the documented information the standard requires and the Annex A controls that depend on it. DocumentMS holds the policy set, statement of applicability and procedures under version control, records approval and review, and produces the access logs an auditor samples.
What ISO 27001 actually asks of your documents
ISO/IEC 27001 certifies an information security management system, not a product, and the documentation is the ISMS made visible. Clauses 7.5.1 to 7.5.3 require documented information to be identified, reviewed and approved for suitability, available where needed, adequately protected, and controlled for distribution, access, version and retention. The auditor tests the control, not the prose.
What makes this harder than ISO 9001 document control is that the document set is partly about the controls themselves. The statement of applicability lists which Annex A controls you have adopted and why; the risk assessment justifies them; and a set of policies and procedures implements them. An inconsistency between those three is the most common major non-conformity in a first certification audit — and it arises because they are maintained as separate files by separate people.
The third difficulty is evidence with a period. A surveillance audit asks whether a control operated throughout the year, not whether it operates today. That means the evidence of operation is its own record class with its own retention, distinct from the policy describing the control — a distinction most document libraries do not make.
The symptoms you will recognise
- A statement of applicability that references controls the policy set does not implement
- Policies approved by "management" with no named approver or date
- Access review evidence that exists for the current quarter but not for the audit period
- The ISMS document set held in a folder that ISMS-scope users cannot themselves access
- Version numbers in filenames, incremented inconsistently
- No record of who acknowledged the acceptable use policy, or against which version
Configuration
Folder structure
ISMS core
- ISMS scope and context
- Information security policy
- Statement of applicability
- Risk assessment and treatment plan
- Objectives and measurement
Policies (controlled)
- Acceptable use
- Access control
- Cryptography and key management
- Supplier and third-party security
- Incident response and business continuity
Procedures and standards
- Operating procedures
- Secure configuration standards
- Change management
- Secure development
Control evidence by period
- Access reviews
- Vulnerability scans and remediation
- Backup and restore test records
- Training and awareness completion
- Supplier assessments
Audit and review
- Internal audit programme and reports
- Management review minutes
- Corrective actions
- Certification body correspondence
Configuration
Metadata that makes the ISMS auditable
| Field | Type | Mandatory | Why it exists |
|---|---|---|---|
| Annex A control reference | Multi-select | Mandatory | Links every policy, procedure and piece of evidence to the controls it supports. This is what an auditor navigates by. |
| Document owner | User | Mandatory | Clause 7.5 expects identified, reviewed and approved documented information — which requires a named owner. |
| Approved by / approval date | User / date | Mandatory | Recorded by the system rather than typed into a footer, so it cannot be edited after the fact. |
| Effective date | Date | Mandatory | Establishes which version applied during the audit period, which is the period the auditor examines. |
| Next review date | Date | Mandatory | An ISMS document past its review date is a non-conformity independent of its content. |
| Classification | Single-select | Mandatory | A.5.12 requires information to be classified; the ISMS documents are themselves in scope of their own policy. |
| Audit period | Text or date range | Optional | Mandatory for evidence records. Without it, "evidence the control operated in FY25" cannot be filtered. |
Configuration
Approval chain
Step 1: Draft and classify
The owner drafts the document, records the reason for change, and tags the Annex A controls it supports. The classification field is set, because the ISMS documents fall under the classification policy they define.
Step 2: Consistency check
Where the change affects a control, the statement of applicability and risk treatment plan are checked against it. Linking documents by Annex A reference makes this a filter rather than a memory exercise.
Step 3: Approve for suitability
The approver — the ISMS manager, or top management for the policy and scope — approves in their own authenticated session with two-factor authentication. Approval sets the effective date and locks the version.
Step 4: Publish, acknowledge, schedule review
Policies requiring acknowledgement are issued to their scope and attestation recorded per named user against this version. The next review date is set before the current one lapses.
Configuration
Retention rule
What starts the clock
For documents the trigger is the date the version ceased to be effective. For evidence it is the end of the audit period the evidence relates to — which is why audit period is a metadata field rather than something inferred from the file date.
Outcomes
What changes
- An evidence request for a specific Annex A control is answered by filtering on the control reference
- The statement of applicability, risk treatment plan and policy set are linked, so an inconsistency is visible rather than latent
- Approval is a system record attached to a version, not a name typed into a document footer
- Control evidence for a past audit period survives revision of the policy that describes the control
- Policy acknowledgement is reported as a list of outstanding names, per version
- Overdue reviews surface on a report rather than in a non-conformity
FAQ
ISO 27001 document control: common questions
Does using DocumentMS make us ISO 27001 certified?
No, and any vendor claiming otherwise is misrepresenting the standard. ISO 27001 certifies a management system: your scope, your risk assessment, your controls and your evidence that they operate. DocumentMS holds and controls the documentation and provides evidence for several Annex A controls, which removes a meaningful amount of work — but the ISMS is yours and the audit is of you.
Which Annex A controls does the product itself provide evidence for?
Most directly: A.5.10 acceptable use through acknowledgement records, A.5.12–5.13 classification and labelling, A.5.15–5.18 access control and access rights through the permission model and access reviews, A.5.33 protection of records, A.8.10 information deletion, and A.8.15 logging through the immutable audit trail. It supports rather than satisfies them — the control is your process; this is the evidence that it ran.
How should we structure evidence so a surveillance audit is straightforward?
Tag every evidence record with both the Annex A control reference and the audit period it belongs to. The auditor’s question is almost always "show me that this control operated during this period", and those two fields turn it into a two-clause filter. Evidence filed only by date requires you to know which control it relates to.
Can the ISMS documents be visible to everyone in scope?
They need to be — clause 7.5.3 requires documented information to be available where needed — but not uniformly. The information security policy and acceptable use policy should reach everyone; the risk treatment plan and penetration test reports should not. Per-folder permissions with visible per-document overrides handle both without a second repository.
How does this differ from the ISO 9001 quality page?
The control discipline is identical; the document set and the evidence differ. Organisations certified to both typically run one library with separate policy branches and a shared document control procedure, which is cheaper to operate and much easier to audit than two parallel systems.
Dernière revue: 2026-09-01. See all seven use cases.