Priya Nandakumar had eleven weeks until her Stage 2 audit, a signed board resolution funding the certification effort, and — she thought — a tidy SharePoint folder called "ISMS Documents" that made her feel, on the Friday before the auditor arrived, cautiously optimistic.
By Tuesday afternoon of audit week, that optimism was gone.
Priya was the ISMS coordinator at Cascade Diagnostics, a 140-person medical device software company in Raleigh that built remote patient-monitoring dashboards for cardiology clinics. The company was chasing ISO 27001 certification because its two largest prospective customers — hospital networks with a combined contract value of roughly $2.1 million a year — had made certification a condition of signing. The lead auditor, a meticulous former NHS security manager named Owen Marsh, asked for the current Access Control Policy. Priya pulled it from the shared drive: version 3, approved four months earlier, signed by the CTO.
Then Owen asked the network engineering lead for the same document. He produced version 2 from his desktop — six months old, unsigned, referencing a "Director of IT Operations" role that no longer existed after a reorg. Then Owen asked to see what new hires were trained on during onboarding. The training deck, built by HR eighteen months prior, cited version 1 almost verbatim, including a password-rotation requirement the company had deliberately dropped in version 2 in favor of MFA and long passphrases.
Three versions. Three audiences. Zero agreement on which one was authoritative, who had approved it, or when it was last reviewed. Owen didn't need to look any further to write it up: a major nonconformity against Clause 7.5, control of documented information — specifically, failure to prevent the unintended use of obsolete documents. Cascade's Stage 2 was suspended. The re-audit, expedited at Cascade's request, cost an additional $14,000 in auditor fees and pushed the certificate six weeks past the date the hospital contract required. Cascade kept the deal, barely, by sending the CISO to personally reassure the customer's procurement team. Not every company in this position is so lucky.
This is not a rare failure mode. Document control is, by a wide margin, the most commonly cited nonconformity category in ISO 27001 audits — not because organizations lack policies, but because they lack control over which version of a policy is the real one, who is allowed to change it, and how long records of what actually happened have to be kept before they can be safely destroyed. Clause 7.5 is short. The discipline it demands is not.
Who this is for and what you'll walk away with
This article is for the person who has been handed document control almost by accident — an ISMS coordinator, a quality manager doing double duty, an IT governance lead, or a founder-CISO — and now has to design a system that an external auditor will trust on sight. You should already have drafted or be drafting your core policies (if not, start with writing an effective information security policy); this piece is about what happens to those documents after they're written. You'll leave with a working definition of documents versus records, a naming and versioning convention you can adopt today, an approval-authority model, a retention schedule template covering the document and record types every ISMS produces, and a clear picture of which nonconformities show up most often — so you can fix them before an auditor finds them.
Documented information: the term ISO 27001:2022 actually uses
If you're searching the 2022 standard for the words "documents" and "records," you'll mostly come up empty. ISO/IEC 27001:2022 collapsed both concepts into a single term: documented information. This isn't cosmetic. The standard deliberately stopped distinguishing "quality manual" from "quality record" because the distinction was a holdover from older management-system language, and because in a digital ISMS the line between a living document and a fixed record is often just a status flag, not a different storage system.
That said, the underlying concepts documents and records represent didn't disappear — they still describe two very different management disciplines, and any auditor worth their certificate will expect you to handle them differently even though the standard uses one word for both. We'll unpack that distinction in the next section. First, the clause structure itself.
Clause 7.5 has three parts, and each one answers a different question:
7.5.1 General — what documented information do you need to have, at minimum?
7.5.2 Creating and updating — when you create or change documented information, what has to happen to it?
7.5.3 Control of documented information — once it exists, how do you keep it available, protected, and under control for as long as it matters?
Read literally, 7.5.1 splits the "what" into two buckets: documented information required by the standard itself (the mandatory documents named explicitly elsewhere in Clauses 4–10 and referenced in Annex A — the scope statement, the policy, the risk assessment methodology, the Statement of Applicability, and so on) and documented information the organization itself determines is necessary for the ISMS to be effective. That second bucket is where most organizations under- or over-document: too thin, and you can't demonstrate consistency; too thick, and you generate a maintenance burden nobody has time for. If you haven't already mapped the first bucket, the ISO 27001 mandatory documents checklist is the fastest way to confirm you have the non-negotiable set covered before you spend energy on 7.5.2 and 7.5.3.
Table 1: Clause 7.5.1 — the two sources of "documented information"
Source | What it means in practice | Example |
|---|---|---|
Required by the standard | Explicitly named in the clause text of ISO 27001:2022 (Clauses 4–10) or implied by an Annex A control's normal implementation | ISMS scope, information security policy, risk assessment and treatment methodology, Statement of Applicability, risk treatment plan, internal audit results, management review minutes |
Determined necessary by the organization | Not named by the standard, but judged necessary for the ISMS to function effectively at your size, complexity, and risk profile | Access control procedure, incident response runbook, supplier due-diligence checklist, secure development standard |
Both are equally "in scope" for 7.5 | Once something is documented information under either heading, all of 7.5.2 and 7.5.3 applies to it | You can't apply lighter control to a self-determined procedure just because ISO didn't ask for it by name |
"The auditors don't care whether you call it a policy, a procedure, a runbook, or a one-pager. The moment you decide something needs to be written down and kept current, Clause 7.5 has already attached itself to it. I've seen companies get flagged for a Slack-pinned 'process' that everyone treated as gospel but nobody had ever reviewed, versioned, or approved." — Marcus Webb, Lead Auditor, Meridian Certification Body
7.5.2 decoded: creating and updating documented information
Clause 7.5.2 is where most of the mechanics of document control live, even though the clause itself is only a few lines long. It requires that whenever documented information is created or updated, the organization ensures three things: appropriate identification and description, appropriate format and media, and appropriate review and approval for suitability and adequacy.
Each of those three requirements maps to a concrete control you need to build, not a philosophy you need to hold.
Identification and description means every piece of documented information needs to carry enough metadata that someone encountering it in isolation — printed out, forwarded as an attachment, found in an old backup — can tell what it is, how current it is, and who stands behind it. The standard gives examples: a title, a date, an author (or the role/function responsible), and a reference number. In practice, this is the single control that would have prevented Cascade Diagnostics' Stage 2 failure. If all three copies of the Access Control Policy had carried a visible version number, an approval date, and an approving authority in the header, Owen Marsh would have caught the discrepancy in ten seconds instead of writing a major nonconformity.
Format and media means deciding, deliberately, what form a document takes — Word document versus PDF versus wiki page versus recorded video versus a GRC platform's structured record — and what medium it lives on, and making that choice fit the document's purpose. A password policy that only exists as an unlisted video recording is hard to search, hard to version, and hard to prove was distributed; a disaster recovery runbook that only exists as an editable wiki page with no snapshot history is hard to prove was frozen at the version actually used during last quarter's failover test.
Review and approval for suitability and adequacy is the requirement that gives documents their authority. A document isn't "controlled" the moment someone writes it — it's controlled once a designated person with the authority to do so has reviewed it and confirmed it's fit for purpose. This is also where organizations most often skip a step under deadline pressure: they publish a policy the week before an audit without running it through the approval step they defined for themselves, and then can't produce evidence that step happened.
Table 2: The minimum metadata set for controlled documents
Metadata field | Purpose | Where it typically appears |
|---|---|---|
Document title | Unambiguous identification | Header, footer, file name |
Document reference / ID | Ties the document to a register entry | Header, footer |
Version / revision number | Distinguishes current from superseded | Header, footer, file name (optional) |
Effective date | When this version became the controlled version | Header or first page |
Author / owner (role, not just name) | Accountability that survives staff turnover | Footer or metadata table |
Approver and approval date | Evidence of 7.5.2 review and approval | Approval block, signature page, or e-signature record |
Classification level | Confidentiality handling instructions (see asset management and information classification) | Header or footer |
Review cycle / next review date | Drives your review schedule | Footer or document register |
Distribution list or access group | Who is entitled to see it | Document register, not always on the document itself |
7.5.3 decoded: control of documented information
If 7.5.2 is about the moment documented information is created or changed, 7.5.3 is about everything that happens to it afterward, for the rest of its life. The clause requires that documented information be controlled to ensure it is available and suitable for use, where and when it is needed, and that it is adequately protected — specifically calling out protection from loss of confidentiality, improper use, and loss of integrity.
To make that concrete, the standard lists the activities you need to address, "as applicable": distribution, access, retrieval, and use; storage and preservation, including preservation of legibility; control of changes, such as version control; and retention and disposition. It also adds a requirement that's easy to forget: documented information of external origin — determined by the organization to be necessary for the planning and operation of the ISMS — must be identified as appropriate and controlled.
That's a lot packed into one clause, so it's worth breaking into the six operational areas an auditor will actually test:
Table 3: Clause 7.5.3 requirements mapped to operational controls
7.5.3 requirement | What an auditor will ask to see | Operational control you need |
|---|---|---|
Availability and suitability where needed | "Show me the current incident response procedure, right now, from the tool the responder actually uses." | Single source of truth, accessible without special request during an incident |
Protection from loss of confidentiality | "Who can view the risk register? How do you know?" | Access permissions tied to classification, reviewed periodically |
Protection from improper use | "How do you stop someone editing the policy without authorization?" | Locked/read-only distribution formats, edit permissions restricted to owners |
Protection from loss of integrity | "How would you know if this file had been altered outside the approval process?" | Version control, checksums or platform audit trails, restricted write access |
Distribution, access, retrieval, use | "How did the new starter in Support get this procedure?" | Defined distribution lists, onboarding hooks, searchable repository |
Storage and preservation, including legibility | "Can you open a five-year-old audit record?" | Format migration plan, backup of the document repository itself |
Control of changes (version control) | "Show me the history of changes to this document." | Version log, change log, tool-native revision history |
Retention and disposition | "How long do you keep board meeting minutes, and how do you destroy them after?" | Retention schedule, disposal procedure |
Control of externally-originated documented information | "Do you keep the current version of your cloud provider's SOC 2 report? How do you know it's current?" | External document register |
"7.5.3 is really six different disciplines wearing one clause number. I ask candidates in every audit the same trick question: 'who owns document control at your organization?' Half say IT. IT owns storage and permissions, not suitability and approval authority. Ownership has to sit with someone who can actually judge whether a policy is still adequate, which almost never lives in the infrastructure team." — Sandra Kilbride, Quality & Compliance Director, Alderbrook Logistics
Note what 7.5.3 does not require: it does not require a specific tool, a specific retention period, or a specific numbering scheme. Every example in this article — the naming conventions, the version formats, the retention years — is illustrative, built from patterns that work well in practice, not a quotation of the standard. Auditors certify that your own documented procedure for controlling documented information is being followed consistently; they don't grade you against someone else's template.
Where Clause 7.5 sits inside Clause 7: Support
It's worth stepping back from 7.5's mechanics to see where it lives, because the placement is deliberate. Clause 7, Support, groups five sub-clauses together for a reason: 7.1 Resources, 7.2 Competence, 7.3 Awareness, 7.4 Communication, and 7.5 Documented information. None of the other four function well without the fifth. Competence (7.2) is demonstrated largely through training records — themselves documented information. Awareness (7.3) campaigns rely on controlled, current communication materials, not whatever version happens to survive in someone's inbox. Communication (7.4) about security incidents, policy changes, or audit findings is only trustworthy if the underlying documents being communicated about are themselves under control. If you haven't already worked through the other four sub-clauses, the Clause 7 Support overview covers resources, competence, and awareness in the depth this piece doesn't, and reading it alongside this article gives you the full picture of why document control so often surfaces as the root cause behind competence and awareness findings too — a training record can't prove competence against a policy version nobody can locate.
This is also why document control tends to be one of the first ISMS functions worth stabilizing, even before some Annex A controls are fully mature. A gap in, say, network segmentation is contained to one technical domain. A gap in document control quietly undermines the evidence trail for nearly everything else the ISMS does, because almost every other clause and control ultimately proves itself through some form of documented information.
Multi-framework document control: what SOC 2 and HIPAA expect
Very few organizations building an ISMS are doing so in a single-framework vacuum. If Cascade Diagnostics' hospital customers require ISO 27001, they very likely also expect alignment with HIPAA's security and privacy safeguards somewhere in the vendor relationship, and if NorthPeak Financial sells into US enterprise accounts, a SOC 2 report alongside ISO 27001 certification is often requested in the same procurement cycle. The good news is that the document control discipline built for Clause 7.5 does most of the heavy lifting for both — the frameworks use different vocabulary for closely related expectations, not fundamentally different practices.
SOC 2's common criteria expect documented policies, evidenced change management, and controlled access to sensitive documentation — conceptually the same ground as 7.5.2 and 7.5.3, examined through a different lens and a different reporting period. HIPAA's Security Rule documentation standard goes further than ISO 27001 in one specific respect worth knowing if you're in a healthcare-adjacent business like Cascade: it sets an explicit minimum retention period (six years from creation or last effective date, whichever is later) for security-rule-related documentation, a number ISO 27001 itself never mandates. Building your ISO 27001 retention schedule with that HIPAA figure in mind — rather than discovering the mismatch later — is a good example of using ISO 27001's flexibility on retention periods to your advantage instead of picking a number in isolation and hoping it holds up under a different framework's scrutiny.
Table 4: Document control vocabulary across frameworks
Concept | ISO 27001:2022 term | SOC 2 framing | HIPAA framing |
|---|---|---|---|
Living governance document | Documented information (document) | Documented policies and procedures (CC criteria) | Policies and procedures (Security Rule) |
Evidence of an event or decision | Documented information (record) | Evidence artifacts / control evidence | Documentation of actions, activities, assessments |
Version and change tracking | Control of changes (7.5.3) | Change management criteria | Not separately named, implied by documentation standard |
Retention | Retention and disposition (7.5.3), period self-determined | Typically aligned to audit period plus a defined look-back | Six years from creation or last effective date (explicit minimum) |
Approval evidence | Review and approval for suitability/adequacy (7.5.2) | Management review and sign-off evidence | Periodic review evidenced under the documentation standard |
None of this means ISO 27001 certification satisfies HIPAA or SOC 2 obligations on its own — each framework still needs its own assessment — but a single, well-run document control system, built once to the more demanding of your applicable retention and evidence requirements, is usually enough to serve all of them without duplicating effort. If your document set is still using ad hoc templates rather than a consistent structure across policies, procedures, and records, the ISO 27001 documentation templates guide is the natural next stop for turning the naming, versioning, and metadata pillars in this article into ready-to-use document skeletons.
Documents vs. records: the distinction that changes how you manage each one
ISO 27001:2022 uses one term — documented information — for what earlier management-system thinking split into two categories. That vocabulary change doesn't mean the underlying difference stopped mattering; it means the standard trusts you to apply the right discipline to each without being told which label to use. Get this distinction wrong and you'll either over-version things that should never change, or leave living documents uncontrolled because you filed them as "done."
A document is living, prospective, and instructive. It tells people what to do, and it's expected to change as the organization, the threat landscape, or the technology changes. Policies, procedures, standards, and the ISMS scope statement are documents. A document that hasn't been revised in three years isn't necessarily a good sign — it might mean nothing changed, but more often it means nobody's looking.
A record is fixed, retrospective, and evidentiary. It captures something that happened — a decision, a result, an event — at a specific point in time, and it is not supposed to be edited afterward. Meeting minutes, completed risk assessments, internal audit reports, training attendance logs, incident tickets, access-review sign-offs, and management review outputs are records. If someone "corrects" a record after the fact without a documented correction process, they haven't updated it — they've falsified it.
If this distinction, or terms like "documented information," "control owner," or "disposition" still feel slippery in conversation with colleagues, our ISO 27001 terminology and glossary guide is worth keeping open in a second tab — document control is one of the areas of the standard where imprecise vocabulary causes the most avoidable confusion during an audit interview.
Table 5: Documents vs. records at a glance
Attribute | Documents | Records |
|---|---|---|
Nature | Living, prospective, instructive | Fixed, retrospective, evidentiary |
Expected to change? | Yes — revised on a schedule or trigger | No — locked once finalized |
Primary control need | Version control, review, approval | Integrity, retention, retrievability |
Typical review cadence | Annual or trigger-based (e.g., after a major incident, reorg, or system change) | Not reviewed for currency — reviewed only for retention/disposal eligibility |
Who "owns" it | A role responsible for keeping it accurate | A role responsible for keeping it intact and retrievable |
Example | Access Control Policy, Incident Response Procedure | Signed risk acceptance form, completed internal audit checklist, access review sign-off |
Failure mode if mismanaged | Obsolete version used in practice | Evidence missing, altered, or destroyed too early/late |
Relevant Annex A anchor | 5.37 Documented operating procedures | 5.33 Protection of records |
Annex A control 5.33, Protection of records, is the clearest signal in the standard that records deserve separate treatment: it specifically calls for records to be protected from loss, destruction, falsification, unauthorized access, and unauthorized release, and for retention, storage, handling, and disposition to be managed in line with legal, regulatory, contractual, and business requirements. Nothing in Annex A carries an equivalent, named control for "protection of documents" — because documents are protected primarily through the mechanisms in 7.5.2 and 7.5.3, while records need their own retention and integrity discipline layered on top.
Building a document-control procedure: the four pillars
A document-control procedure doesn't need to be long, but it needs to answer four questions unambiguously enough that two different employees, asked separately, would describe the same process: How do we name things? How do we version things? Who has to approve what? What metadata is mandatory? Get these four right and you've addressed the bulk of 7.5.2 and a good share of 7.5.3.
Pillar 1: naming conventions
A naming convention exists so a file's name alone — before anyone opens it — tells you what it is, what category it belongs to, and roughly how current it is. The trap most organizations fall into is over-engineering the convention until nobody follows it, or under-specifying it until every department invents its own.
Table 6: A practical document naming convention
Component | Format | Example |
|---|---|---|
Category prefix | 2–4 letter code for document type | POL (policy), PROC (procedure), STD (standard), REG (register), FORM (form) |
Short subject | Hyphenated plain-English subject | access-control, incident-response, supplier-due-diligence |
Version | v-major.minor | v2.1 |
Status suffix (optional, drafts only) | -DRAFT while unapproved | POL-access-control-v3.0-DRAFT |
Full example |
| |
Full example (record, not versioned the same way) | Category-Subject-Date/ID |
|
The rule worth enforcing above all others: only one file name pattern exists per document, and old versions are never renamed to "v1_FINAL_FINAL2" style ad hoc labels. If your convention can't survive a document going through six revisions, it's the wrong convention.
Pillar 2: versioning
Version numbers should communicate the size of a change, not just its sequence. A two-tier major.minor scheme does this cleanly: minor version increments (v2.0 → v2.1) for wording clarifications, formatting fixes, or small non-substantive edits that don't change what the document requires anyone to do; major version increments (v2.1 → v3.0) for changes that alter obligations, scope, ownership, or approach — anything that would require re-training or re-communication.
Table 7: Version numbering decision guide
Change type | Version bump | Re-approval required? | Re-distribution required? |
|---|---|---|---|
Typo, grammar, formatting fix | Minor (e.g., v2.0 → v2.1) | Owner sign-off sufficient in most schemes | No |
Clarifying existing requirement without changing intent | Minor | Owner sign-off; approver notified | Optional, log the change |
New or changed requirement, changed scope, changed owner/role | Major (e.g., v2.1 → v3.0) | Full approval workflow re-run | Yes — active notification, not just re-posting |
Annual review with no changes found | No version change; update "last reviewed" date only | Reviewer confirmation logged | No |
Complete rewrite / replaces a retired document | Reset to v1.0 with a note referencing the superseded document's final version | Full approval workflow | Yes |
Whatever scheme you choose, write it down as part of the procedure itself — the scheme is documented information too, and an auditor will ask you to explain it once and then check that every document register entry actually follows it.
Pillar 3: approval authority
Approval authority answers "who is allowed to say this document is now the controlled version?" It should be a role, not a name — because names change jobs and roles don't — and it should scale with the document's weight. A one-line procedural clarification shouldn't need the same sign-off as a rewrite of the risk acceptance criteria.
Table 8: A sample approval authority matrix
Document type | Drafts / proposes | Reviews for adequacy | Approves (final authority) | Typical cycle time |
|---|---|---|---|---|
Information security policy (top-level) | ISMS coordinator / CISO | Leadership team | CEO or designated top management (per Clause 5 leadership requirements) | 2–4 weeks |
Functional policy (access control, acceptable use) | Control owner | ISMS coordinator + relevant department head | CISO or delegated authority | 1–2 weeks |
Operating procedure / runbook | Process owner | Team lead | Control owner | 3–10 business days |
Risk assessment methodology | Risk owner / ISMS coordinator | Risk committee | CISO or ISMS Steering Committee | 2–3 weeks |
Statement of Applicability | ISMS coordinator | Control owners (per control) | Top management | 2–4 weeks |
Form/template (non-policy) | Process owner | Peer review | Process owner (self-approve permitted) | 1–3 business days |
The matrix itself needs to live somewhere controlled — ironically, it's a document about documents, and it's subject to the same 7.5.2 review-and-approval requirement as everything else it governs.
"The fastest way to fail an approval-authority test is to let 'whoever's in the room' sign off on a policy. I once watched a company's HR generalist approve a cryptography standard because the actual owner was on vacation and the deadline was tight. The content might have been fine. The evidence of appropriate authority wasn't, and that's what got cited." — Tom Falkirk, IT Governance Lead, Brightwell Insurance
Pillar 4: metadata, headers, and footers
The metadata fields in Table 2 aren't useful sitting in a spreadsheet somewhere — they need to be physically present on the document itself, visible to anyone who opens it without context. The standard layout that works across most organizations places document title, reference number, and classification level in the header; version number, effective date, and page count ("Page X of Y") in the footer; and a one-page approval block on either the cover page or the final page listing the author, reviewer(s), approver, and each of their approval dates.
For records rather than documents, the metadata need is different: instead of a version and review date, a record needs a clear "finalized" marker (a signature, an e-signature timestamp, or a locked/read-only file status) and a retention classification that tells anyone handling it how long it must be kept and under what disposal rule — covered in full later in this piece.
Access and distribution control
Control of documented information isn't only about preventing the wrong version from circulating — it's equally about preventing the right version from reaching people who shouldn't have it, and about proving both of those things happened by design rather than by luck.
Distribution control starts with a simple classification-driven rule: not every controlled document should be visible to every employee, and the ISMS should not treat "posted somewhere on the intranet" as equivalent to "distributed." A risk register with named vulnerabilities and financial exposure figures, a supplier contract with commercial terms, or an incident report naming affected individuals all warrant tighter access than a general acceptable-use policy that every employee needs to read on day one. This ties directly back into how you classified the asset in the first place — if you haven't yet built out your classification scheme, asset management controls 5.9 through 5.14 is the article that covers labelling and handling rules in depth.
Table 9: Access control matrix by document type
Document/record type | Default access | Edit rights | Distribution method |
|---|---|---|---|
Information security policy (top-level) | All employees (read) | Owner + approver only | Onboarding pack, intranet, signed acknowledgment |
Functional procedures (e.g., access control, incident response) | Relevant team + management | Process owner | Team wiki/DMS folder, linked from onboarding |
Risk register | ISMS team, risk owners, senior leadership | Risk owner or ISMS coordinator | Restricted DMS/GRC folder, no general distribution |
Statement of Applicability | ISMS team, auditors (on request), senior leadership | ISMS coordinator | Controlled repository, shared with certification body under audit |
Supplier contracts and DPAs | Procurement, legal, relevant control owner | Legal/procurement only | Contract management system |
Internal audit reports | ISMS team, auditee management, senior leadership | Internal audit lead only, post-issue read-only | Restricted folder or GRC module |
Incident records | Incident responders, ISMS coordinator, affected system owner | Locked after closure | Ticketing system / incident register |
HR records (screening, disciplinary) | HR only, plus named individual (self) | HR only | HRIS, not general shared drive |
Two access-control failure patterns show up again and again in audits: documents left in a "public" or "everyone" permission group by default because nobody actively restricted them, and documents restricted so tightly that the people who need them during an actual incident can't reach them without submitting a ticket. Both are control of documented information failures — the first breaches confidentiality, the second breaches availability, and 7.5.3 explicitly requires both.
"I ask incident responders during tabletop exercises to pull up the current incident response runbook from their actual laptop, mid-exercise, with no advance notice. About a third of the time, someone can't get to it — wrong permissions, expired link, or it's only on a manager's machine. That's not a documentation problem. That's an availability failure under 7.5.3, and it's the kind of gap that costs real minutes during a real breach." — Elena Cho, ISMS Manager, Cascade Diagnostics
Change control and version history
Version control is named explicitly in Clause 7.5.3 as an example of what "control of changes" means in practice, and it's the mechanism auditors probe hardest, because it's the easiest thing to fake with a single Word document and hardest to fake with a genuine history. A version number on a header proves nothing by itself; what proves control is a change log that shows every prior version, what changed, who changed it, who approved the change, and when it took effect.
The lifecycle below is the same regardless of whether you run it through a DMS, a GRC platform, or a disciplined shared-drive convention — only the tooling that enforces each step changes.
flowchart LR
A[Create / Draft] --> B[Review]
B --> C{Approved?}
C -- No, revise --> B
C -- Yes --> D[Approve & Version]
D --> E[Publish]
E --> F[Distribute / Communicate]
F --> G[Control Changes<br/>Version History]
G --> H[Retain]
H --> I[Dispose / Archive]
G -.triggered by review cycle or event.-> AEach arrow in that diagram should correspond to something you can point to as evidence. "Create/Draft" should show a draft marker or DRAFT suffix. "Review" should show reviewer comments or sign-off, separate from final approval. "Approve & Version" should show the approval block populated and the version number incremented per your own scheme. "Distribute/Communicate" should show more than a file sitting in a folder — an email, a wiki notification, a training session, or a GRC platform's read-receipt log. "Control Changes" is the ongoing state a document lives in between reviews, where the version history accumulates. "Retain" and "Dispose" apply differently to documents (retain the current version, and often the last one or two prior versions, then let older ones age out) than to records (retain per schedule, then destroy on a fixed trigger) — both are covered next.
Table 10: Version history log template
Version | Date | Change summary | Changed by | Reviewed by | Approved by | Approval date |
|---|---|---|---|---|---|---|
v1.0 | 2024-02-11 | Initial issue | J. Alvarez | — | R. Nkomo (CISO) | 2024-02-14 |
v1.1 | 2024-08-03 | Clarified MFA exception process wording | J. Alvarez | S. Patel | R. Nkomo (CISO) | 2024-08-05 |
v2.0 | 2025-03-22 | Added cloud console privileged-access requirement following control 8.2 review | P. Nandakumar | Access Control WG | R. Nkomo (CISO) | 2025-03-28 |
v2.1 | 2025-11-14 | Annual review — no substantive change, formatting only | P. Nandakumar | — | Control owner | 2025-11-14 |
The version history log is itself documented information and needs the same discipline applied to it that it's tracking — most DMS and GRC tools generate this automatically from edit metadata, which is one of the strongest arguments for moving off a plain shared drive once your document set grows past a few dozen controlled files.
The retention schedule: how long to keep what
Clause 7.5.3 requires that you address retention and disposition — it does not hand you a table of years. Retention periods are properly set by looking at three inputs together: legal and regulatory requirements that apply to your sector and jurisdiction (data protection law, sector regulation, employment law, tax and corporate law), contractual commitments to customers or partners, and your own business need for the information to remain useful as evidence or reference. ISO 27001 wants you to have made this decision deliberately and documented it — not to have adopted any particular number.
The table below is an illustrative starting point built from patterns seen across many ISMS implementations, not a legal retention schedule. Confirm every period against your own counsel or compliance function before adopting it, especially anywhere personal data, financial records, or sector-specific regulation is involved — an ISO 27001 retention schedule should support obligations under frameworks like HIPAA or a customer's SOC 2-driven requirements, not override them.
Table 11: Illustrative retention schedule by document/record type
Document/record type | Category | Illustrative minimum retention | Trigger to start the clock | Rationale |
|---|---|---|---|---|
ISMS scope statement | Document (current + superseded) | Life of certification + 3 years after retirement | Version superseded | Historical scope evidence for surveillance audits |
Information security policy | Document | Current version + last 2 superseded versions | New version approved | Demonstrates continuity of governance |
Statement of Applicability | Document/record hybrid | Every certification-cycle version, 6 years after superseded | Recertification or major revision | Evidence of applicability decisions over time |
Risk register (point-in-time snapshots) | Record | 6 years from snapshot date | Each formal review/update | Evidence of ongoing risk management |
Risk treatment plan | Record | 6 years from closure of last action | Plan closed or superseded | Evidence treatment was executed |
Internal audit reports | Record | 6 years from issue date | Audit closed | Certification body and recertification evidence |
Management review minutes | Record | 6 years from meeting date | Meeting concluded | Evidence of top management oversight |
Corrective action records | Record | 6 years from closure | Action closed | Nonconformity trend analysis, recertification evidence |
Training and awareness records | Record | Duration of employment + 3 years | Training completed | Evidence of competence (Clause 7) |
Access review / recertification logs | Record | 3 years from review date | Review completed | Evidence of least-privilege enforcement |
Incident records | Record | 6 years from closure (longer if litigation/regulatory hold applies) | Incident closed | Legal exposure, pattern analysis, regulatory reporting |
Supplier due-diligence and contracts | Record | Life of contract + 6 years | Contract termination | Contractual dispute window, supply-chain audits |
Background screening records | Record | Duration of employment + 1 year, per local law | Employment ends | Employment law compliance, varies by jurisdiction |
Disciplinary records | Record | Per local employment law (often 2–6 years) | Case closed | Employment law compliance |
Physical/visitor access logs | Record | 1–3 years | Log period closed | Physical security investigation window |
Backup and system logs (security-relevant) | Record | Per logging/monitoring policy, commonly 1 year minimum, longer for regulated data | Log generated | Incident investigation, regulatory requirement |
Certificates and audit evidence packages | Record | Full certification cycle (3 years) + prior cycle | Certificate issued/renewed | Recertification comparison |
Where retention periods conflict — for example, a data minimization principle under privacy law pushing toward shorter retention, against a litigation-hold obligation pushing toward longer retention — document the conflict and the resolution rather than silently picking one. That resolution note is, itself, useful evidence during an audit.
Retention scheduling and secure disposal is a big enough topic on its own that this article can only give it the treatment it needs at a summary level; a dedicated deep dive on records retention and secure disposal mechanics — legal hold processes, cross-border retention conflicts, and disposal verification in outsourced storage — is on our backlog as a future companion piece, and worth checking for directly if your organization's retention picture is more complex than the table above can capture.
"The retention schedule is the document people build last and regret not building first. We had a client facing a data subject access request who couldn't say definitively whether a two-year-old support ticket had been deleted, retained, or simply lost — because nobody had ever decided which of the three was supposed to happen. That ambiguity is worse for a regulator than a shorter retention period would have been." — Anika Voss, Records Manager, Solvane Pharma
Disposition and secure disposal
Retention has an end point by design — "disposition" is the deliberate act of deciding, at the end of a retention period, whether a document or record is destroyed, archived permanently, or transferred (for instance, to a successor system during a platform migration). Disposition should never be something that just happens because a storage quota was hit or an employee cleaned out a folder before leaving; it should follow the same rigor as creation and approval, just running in reverse.
Secure disposal matters because a record's confidentiality obligations don't expire when its retention period does — if anything, disposal is often the single highest-risk moment in a record's life, because it's when information moves from "controlled and monitored" to "gone," and getting that step wrong (an unencrypted drive sold on secondary markets, a filing cabinet emptied into unshredded recycling) creates the same exposure as a breach. This is exactly the territory Annex A control 8.10, Information deletion, and control 7.10, Storage media, address for digital and physical media respectively, and it overlaps with 7.14, Secure disposal or re-use of equipment, whenever the media itself (not just the file) is being retired.
Table 12: Disposal method by media and sensitivity
Media / format | Disposal method | Sensitivity trigger for higher assurance |
|---|---|---|
Paper records (general) | Cross-cut shredding, certificate of destruction for bulk disposal | PII, financial data, health data → witnessed/certified destruction |
Paper records (highly sensitive) | On-site shredding with chain-of-custody log | Board minutes, legal privilege material, regulator correspondence |
Local hard drives / endpoints | Cryptographic erasure or physical destruction, logged in asset disposal register | Devices that ever held production data or credentials |
Cloud-hosted documents/records | Platform-native secure delete + confirmation of backup purge cycle | Regulated data subject to a documented deletion SLA |
Backup tapes/media reaching end of retention | Physical destruction or verified overwrite, logged | Any backup containing personal or financial data |
Removable media (USB, external drives) | Physical destruction preferred over wipe-and-reuse for sensitive data | Any device that left organizational premises |
SaaS/DMS platform records | Scheduled deletion job tied to retention schedule, with deletion log retained separately | High-volume records where manual deletion isn't feasible |
Two practical rules keep disposal defensible: log the disposal event itself (what was destroyed, when, by what method, authorized by whom) as a short-lived record that outlives the thing it describes, and never let disposal be silent — a document register or retention tracker should show "disposed [date], per schedule, method X" rather than simply going blank.
External-origin documented information
Clause 7.5.3 closes with a requirement that's easy to miss because it sits at the end of a long list: documented information of external origin, determined by the organization to be necessary for the planning and operation of the ISMS, has to be identified and controlled. This covers a wider set of material than most first-time implementers expect — supplier SOC 2 or ISO 27001 certificates, regulatory guidance documents, applicable legislation and standards you've referenced in your risk assessment, customer security questionnaires and their responses, cloud provider shared-responsibility documentation, and vendor security whitepapers your architecture decisions rely on.
The control need here isn't to rewrite or approve someone else's document — you don't own it and shouldn't pretend to — it's to know which external documents you're depending on, confirm you're holding the current version, and re-check that periodically. A supplier's SOC 2 report from three annual cycles ago sitting uncommented in a shared folder is functionally the same failure as an internal policy nobody reviewed: documented information being relied upon without confirmation it's still current or suitable.
Table 13: External document register — example structure
External document | Source | Relevance to ISMS | Current version confirmed | Next check-in |
|---|---|---|---|---|
Cloud provider SOC 2 Type II report | Primary IaaS vendor | Underpins reliance on vendor's control environment for supplier relationship security | 2025 report, confirmed 2026-01 | 2026-Q4 (annual reissue) |
Applicable data protection legislation | Jurisdiction's regulator | Basis for privacy-related risk treatment | Confirmed against regulator site 2026-02 | On legislative change or annually |
Key SaaS vendor's penetration test summary | Payroll processor | Supplier due-diligence evidence | Confirmed 2025-09 | Next contract renewal |
Industry sector guidance (e.g., healthcare data handling guidance) | Sector regulator/association | Informs retention and handling decisions relevant to records such as those under HIPAA-adjacent obligations | Confirmed 2025-11 | Annual |
Customer-mandated security addendum | Enterprise customer contract | Defines contractual security obligations feeding the SoA | Confirmed at contract signature | On renewal or amendment |
Treat the external document register itself as documented information subject to 7.5.2 — it should have an owner, a review cadence, and evidence that someone actually reconfirmed currency rather than just recording the date the row was first created.
Choosing your tooling: shared drive, wiki, DMS, or GRC platform
The standard is deliberately silent on tooling — nothing in Clause 7.5 mandates a document management system — but the tool you choose determines how much of the discipline above happens automatically versus how much depends on human diligence holding under deadline pressure. Smaller organizations often start on a shared drive or wiki and outgrow it exactly at the point their document set crosses from "a handful of policies" to "a full ISMS with dozens of documents and hundreds of records."
Table 14: Tooling comparison for document and records control
Approach | Version control | Approval workflow | Access control granularity | Audit trail | Retention/disposal automation | Best fit |
|---|---|---|---|---|---|---|
Shared drive (folder structure + naming convention) | Manual, relies entirely on discipline | Manual (email or signature sheet) | Folder-level, often coarse | Minimal — file metadata only | None, manual tracking required | Very small orgs, early-stage ISMS, tight budget |
Wiki (Confluence-style) | Native page history, decent | Often bolt-on (approval plugin or manual sign-off note) | Space/page-level permissions | Good — full edit history | Weak — needs manual archival process | Mid-size orgs prioritizing ease of editing and searchability |
Dedicated DMS (SharePoint with governance, or a document-management platform) | Strong native versioning | Configurable workflows | Strong, often field/library-level | Strong, exportable | Retention labels/policies often built-in | Orgs with meaningful document volume and IT support to configure it |
GRC platform (compliance-specific) | Strong, tied to control/evidence mapping | Strong, often maps directly to control ownership | Strong, role-based by design | Strongest — built for audit export | Often includes retention scheduling as a feature | Orgs pursuing multiple frameworks (ISO 27001, SOC 2) simultaneously, or scaling past one auditor cycle |
The honest trade-off: a shared drive costs nothing extra and is the fastest to start, but it puts 100% of the control burden on human process discipline — which is exactly what failed at Cascade Diagnostics in the opening story. A GRC platform costs real money and configuration time, but it enforces the process even when people are rushed, which is when document control failures actually happen. Most organizations land somewhere in the middle: a wiki or DMS for living documents, and a lighter structured register (sometimes inside the same GRC tool used for the risk register) for records retention tracking.
"We migrated from a shared drive to a GRC platform six months before our second surveillance audit, mostly because I was tired of manually rebuilding version history logs from file metadata every time an auditor asked. The tool didn't make our documents better — the content was already fine — but it made proving control effortless instead of a two-day scramble." — Ravi Deshmukh, Document Control Specialist, NorthPeak Financial
Common mistakes: why document control is the #1 audit finding category
Across the certification audits I've supported or reviewed over the years, document control and records management issues surface as findings — minor or major — more often than any other single clause. Not because the requirement is complex, but because it's easy to satisfy on the surface (a folder full of policies looks fine) while failing underneath (nobody can say which policy is current, who approved it, or what happens to the evidence it generates). The following patterns account for the large majority of what I've seen written up.
Table 15: The recurring document-control findings and how to fix them
Common finding | Why it happens | Fix |
|---|---|---|
Multiple versions of the same policy in active use | No single source of truth; local copies saved and edited independently | Publish from one controlled location; disable local editable copies for consumption; enforce via the naming/versioning pillars above |
Policy references a role or system that no longer exists | Review cycle missed after a reorg or system change | Trigger-based reviews tied to organizational change events, not just calendar dates |
No evidence of approval | Approval happened verbally or over chat, never logged | Mandatory approval block populated before publication; no publish without it |
Records altered after finalization | No "lock" mechanism; records treated like editable documents | Read-only/locked status on finalized records; correction process (not silent edit) for genuine errors |
Retention period undefined or inconsistent across departments | Retention schedule built late or only for regulatory records, not ISMS records | Single retention schedule covering all ISMS document/record types, reviewed against legal/regulatory input |
Disposal happens with no log | Cleanup treated as housekeeping, not a controlled activity | Disposal log as its own short-retention record, tied to the retention schedule trigger |
External documents (supplier certs, contracts) untracked | Treated as "someone else's document," out of scope | External document register, owned and reviewed like any other control |
Distribution assumed rather than evidenced | Document "published" but never confirmed read/received | Acknowledgment tracking (e-signature, LMS completion, or read receipt) for policies requiring acknowledgment |
Access too broad or too narrow | Default permissions never revisited after initial setup | Periodic access review of the document repository itself, same discipline as any other access review |
Training materials drift from current policy | Training built once, policy updated since, nobody reconciled them | Tie training content review to the same trigger as the policy's own review cycle |
If there's one takeaway from this list, it's that almost none of these findings are about the quality of the writing in a policy. They're about the evidence trail around it — who touched it, when, with what authority, and what happened to the record of that. An auditor reading a beautifully written access control policy that can't produce an approval date will write the same nonconformity as one reading a rougher policy that can.
Case studies
Case study 1: Cascade Diagnostics — from major nonconformity to clean recertification
The opening story didn't end with the suspended Stage 2 audit. Priya Nandakumar's response, once the immediate crisis passed, was structural rather than cosmetic. Cascade retired its "ISMS Documents" catch-all folder entirely and moved to a mid-tier DMS with library-level permissions and native version history. Every existing policy was re-issued at v1.0 under the new naming convention, with the approval-authority matrix (Table 8 above, adapted for Cascade's org chart) enforced through the platform's workflow feature rather than trusted to memory. The training deck was rebuilt with an explicit dependency note: "content mirrors Access Control Policy v[current] — do not revise independently." The re-audit, five weeks later, closed the major nonconformity with zero repeat findings and only one minor observation (an external document register that existed but hadn't yet been populated for two newly onboarded suppliers). Cascade signed both hospital contracts within the quarter, and the CISO now cites the document-control rebuild, not the original policy set, as the actual deliverable that saved the deal.
Case study 2: NorthPeak Financial — eliminating a recurring finding across two audit cycles
NorthPeak Financial, a 300-person fintech processing merchant payment data, had passed initial certification but picked up document-control findings in both of its first two annual surveillance audits — different specific documents each time, but the same underlying pattern: procedures maintained by individual team leads on personal drives, inconsistently versioned, with approval evidenced only by email threads that were later deleted per the team's own inbox retention habits (an irony not lost on the auditor). Document Control Specialist Ravi Deshmukh led a consolidation into a GRC platform already in use for the risk register, mapping every controlled document to a control owner with workflow-enforced approval. The result across the third surveillance audit: zero document-control findings, the first clean cycle in the company's certification history, and — as a secondary benefit Ravi hadn't fully anticipated — a 40% reduction in the time it took to assemble evidence packages for the audit itself, because version history and approval trails were exportable directly from the platform instead of reconstructed by hand.
Case study 3: Alderbrook Logistics — a records retention gap that nearly became a regulatory problem
Alderbrook Logistics, a regional freight and warehousing company handling customer shipment data, had a document control procedure that was, on paper, adequate — but its records retention schedule had never been extended to cover incident records specifically, only "general business records" at a vague three-year default. When a data exposure incident from four years earlier resurfaced during a customer's due-diligence review ahead of a contract renewal, Alderbrook discovered the original incident record, including root-cause analysis and remediation evidence, had been deleted under the generic three-year rule — a year before it could have demonstrated the issue was fully resolved. Quality and Compliance Director Sandra Kilbride used the gap as the catalyst to rebuild the retention schedule with incident records carrying an explicit six-year minimum (aligned with the pattern in Table 11), closing what she now describes as "the single riskiest blind spot in our entire ISMS" — a retention period that was technically documented but had never actually been checked against the kind of record it needed to cover.
The strategic close: document control as a trust signal, not paperwork
It's tempting to treat Clause 7.5 as the administrative tax you pay to get to the parts of ISO 27001 that feel like "real security" — access control, cryptography, incident response. That framing undersells what document control actually buys an organization. A customer's security questionnaire, a regulator's inquiry, a breach investigation, and an internal dispute over who approved a risky exception all resolve faster — and more favorably — when an organization can produce, on demand, the exact version of the exact policy that was in force on the exact date in question, along with proof of who approved it and who saw it. That capability is a competitive differentiator in sales conversations with security-conscious buyers, not merely an audit-survival tactic, and it's precisely what frameworks adjacent to ISO 27001 — SOC 2's documentation and change-management criteria, HIPAA's requirements around retained records of security decisions — are also testing for, even when they use different words to ask.
Certification bodies flag document control disproportionately not because they're pedantic about paperwork, but because a management system that can't reliably control its own documented information is signaling something deeper: that the organization's stated controls and its actual practice may have quietly drifted apart, with nobody positioned to notice. Fixing that gap is one of the highest-leverage moves available in an ISMS build, because the fix (a naming convention, a versioning scheme, an approval matrix, a retention schedule) is comparatively cheap and mechanical, while the trust it buys — with auditors, customers, and your own future self during an incident — compounds every year the ISMS operates.
If you're building this discipline from scratch, don't try to design a perfect system before you've populated your first document register — start with the mandatory document set, apply the four pillars, and let the retention schedule and tooling decisions follow once you can see the real shape of what you're managing. Explore PentesterWorld's mandatory documents checklist to confirm your baseline, review the information security policy template as a starting structure for the highest-authority document in your set, and use the internal audit report template to see, firsthand, the kind of records format an auditor expects you to be able to produce quickly. If you're earlier in the journey and haven't yet nailed down which documents you actually need, the Complete ISO 27001 Implementation Guide walks the full build sequence, and the ISO 27001 Glossary of Terms is worth bookmarking the first time "documented information" and "record" start to blur together in conversation.
Document control won't win you the deal by itself. But an auditor, a regulator, or an enterprise procurement team who asks a hard question and gets a fast, precise, well-evidenced answer will trust everything else you tell them a little more — and that trust is the actual asset Clause 7.5 is quietly building.