Quality Management · 7 min read
Document Control That Holds Up in an Audit: Version, Approve, Prove
Most quality systems do not fail during the audit. They fail three years earlier, in a folder called Quality that fills up with files named Procedure_final_v3_USE_THIS.docx. The management system looks fine on the surface. Then an auditor asks a plain question the shared drive cannot answer, and the gap opens up.
This is a Kanso perspective. See how Kanso runs ISO 9001 and Lean Six Sigma on one platform →
The question a shared drive cannot answer
Picture the moment. An auditor points at a work instruction taped to a machine and asks: is this the current version? Who approved it, and when? Who has read it since the last change? Show me the two revisions before this one, and what changed between them. On a shared drive, every one of those questions turns into archaeology. Someone opens the folder, squints at four files with similar names, checks the modified date, and starts guessing. Guessing in front of an auditor is how a minor finding becomes a major one.
The uncomfortable part is that the drive did nothing wrong. It stored the file. It preserved the bytes. Storage was never the job. The job is control, and control is a different thing entirely. A shared drive gives you a pile of documents. ISO 9001 asks for a register of controlled documented information with a defensible history behind each entry. Those are not the same category of object, and no amount of disciplined folder naming closes the gap.
We have watched capable quality managers lose an afternoon reconstructing an approval trail from email threads and calendar invites. The document existed. The evidence that it was controlled did not.
What clause 7.5 actually asks for
ISO 9001:2015 splits its requirement into three parts, and it pays to read them as written rather than from memory. Clause 7.5.1 covers the documented information the system requires. Clause 7.5.2 governs creating and updating it: appropriate identification and description, appropriate format and media, and review and approval for suitability and adequacy. Clause 7.5.3 governs control of documented information, so that it is available where needed and adequately protected, and it names the activities explicitly: distribution and access, storage and preservation, control of changes such as version control, and retention and disposition.
Read that list slowly, because each item is a separate obligation. Identification. Review and approval. Version control. Distribution and access control. Protection from loss of integrity. Retention and disposition. Six things. A shared drive gives you a partial answer to one of them, storage, and leaves the other five to human diligence. Human diligence is not a control. It is the thing controls exist to backstop.
The standard does not mandate software. It never says buy a system. But it describes behaviour that software delivers as a byproduct and that a folder delivers only when every person, every time, remembers to do the manual work. The failure mode is not laziness. It is entropy. Given enough people and enough deadlines, the manual version always drifts.
Where the shared drive breaks, item by item
Take version control first. On a drive, versioning is a naming convention, and naming conventions are opinions, not enforced rules. _v3 and _final and _USE_THIS coexist in the same folder because nothing stops them. There is no single current version, only a social consensus about which file people have agreed to trust this week. When that consensus is wrong, someone runs production against a superseded instruction and nobody notices until the nonconformance report lands.
Now review and approval. Approval on a drive is an email that says looks good to me, living in an inbox the auditor cannot see and the next quality manager will never inherit. There is no binding between that approval and the specific revision it blessed. Change the file after the email and the approval silently applies to content nobody signed off. The evidence and the artefact have come apart.
Then distribution and access. A drive tells you who could open a file. It does not tell you who did, and it certainly does not tell you who read the version that matters. Retention is worse still: the natural way to make an old version go away on a drive is to delete it or overwrite it, which is precisely the destruction of history that clause 7.5.3 exists to prevent. Every instinct the shared drive encourages runs against the control the standard requires.
A signature is not a scanned image at the bottom of a PDF
Here is the opinion we will defend. A scanned signature pasted into a PDF is not evidence of approval. It is a picture of a signature, and a picture proves nothing about who approved what, or when, or against which revision. It can be copied from one document to another in seconds. It carries no timestamp, no identity assertion, no link to the exact content it supposedly authorises. An auditor who understands this will treat it as decoration, and they will be right to.
What makes an approval real is the binding. A signature has to be tied to a specific person, at a specific moment, against a specific version of a specific document, in a record that cannot be quietly edited afterward. That binding is the whole point. Strip it away and you are left with an image that asserts a claim it cannot support. The distinction sounds pedantic until the day it decides whether your approval trail survives scrutiny.
This is also why we are wary of approval-by-email as a permanent system of record. Email captures a moment of assent, but it floats free of the document. The person left the company, the mailbox was archived, the file changed twice since. The approval and the thing approved need to live in the same record, locked to the same revision, or the approval is worth less than it looks.
What real document control looks like
Controlled document control has a shape, and once you have seen it the shared-drive approach looks like what it is: a filing cabinet pretending to be a management system. Every document has one identity and a version history you can read like a ledger. Major and minor revisions are distinct, so a typo fix and a substantive change to a control step are not the same event. Nothing is overwritten. Superseded versions are retained, not deleted, and you can open any of them and see exactly what it said.
Approval is a route, not an email. A change moves through named approvers, and their sign-off binds to that exact revision. The signature is drawn and captured against the version and the timestamp, not pasted in as an image that could belong to any document. Once approved, the version is locked. Editing it does not amend the approved record; it opens a new revision that has to earn its own approval. The history stays honest because the system will not let it lie.
Distribution becomes provable rather than assumed. Read-tracking records who has actually opened the current version, so when the auditor asks whether the operators have seen the revised instruction, you answer with a list instead of a hope. Review cadence is built into the document rather than living in someone's calendar: each document carries a review interval and an automatically calculated next-review date, so a procedure that is due for review announces itself instead of quietly ageing past relevance. Comments and annotations sit on the document itself, in context, so the reasoning behind a change is captured next to the change and not lost in a separate thread.
Why this belongs on the same platform as everything else
This is where Kanso does the work. Document control in Kanso is a controlled register: major and minor versioning, approval routes with named approvers, drawn e-signatures bound to a specific person and revision, read-tracking on the current version, review cadences that set the next-review date for you, a block editor for authoring, comments and annotations in context, and a folder and navigation tree so the register stays legible as it grows. The point is not any single feature. It is that the history is defensible by construction, so the answer to the auditor's question is already recorded before the question is asked.
The deeper reason to run document control here rather than in a standalone tool is what sits next to it. A procedure does not exist in isolation. It is referenced by a corrective action, exercised during an audit, and measured by the analytics engine that tracks how the system is performing. When document control lives on the same platform as CAPA, audits, and reporting, a controlled document is not a dead file. It is a node connected to the evidence that it works. A corrective action can point at the exact revision of the procedure it changed. An audit finding can reference the controlled version in force on the day.
A shared drive plus a spreadsheet is the default because it is free and already installed, and for a very small operation it can limp along. But it is a category below what clause 7.5 describes, and the gap is invisible right up until an auditor stands in front of it. Version, approve, prove. The drive can do the first badly, the second informally, and the third not at all. Real document control does all three by default, and keeps doing them long after the person who set it up has moved on. That is the difference between storing your quality system and controlling it. Built by eClips (eclips.tech).
See Kanso in action
One platform for ISO 9001 and Lean Six Sigma — with the analytics to query and model your quality data in SQL, Python, and R.
Book a walkthrough