Building a document control system that survives an audit
Learn how to design out the four most common document-control findings: uncontrolled copies, missing approvals, version gaps, and retention failures. Built in the order an auditor checks them.
Most document-control audit findings are not clever. They are the same four gaps repeated across industries: an uncontrolled copy in a shared drive, a document nobody approved, a version that two people edited at once, and a record kept past its retention date. A document control system fixes these by design, not by reminder emails. This guide covers what to build, in the order an auditor will check it.
Start with a single source of truth
The first finding auditors write up is uncontrolled distribution: a PDF on someone's desktop, a printout on the shop floor, a copy in a supplier's inbox. Each copy is a separate risk because none of them update when the master changes.
Design this out by making one repository the master and everything else a view of it. Users read the current version through a link, not a download. When you must distribute a physical or offline copy, stamp it as a controlled copy with an issue number and a recall obligation, and log who holds it. If you cannot answer "who has copy 4 of this work instruction", you have an uncontrolled-copy finding waiting.
Versioning that leaves no gaps
Every document needs an unambiguous version identifier, a change history, and a rule for when the number increments. Auditors test this by picking a document and asking to see the version that was live on a given date. If you cannot reconstruct that, you fail.
Keep the rules simple. Draft versions and released versions must be visually distinct. Only one released version is current at a time. Superseded versions are retained but clearly marked as superseded so nobody works from them. Store the change reason against each version, because "why did this change" is a standard audit question.
Approvals with a defined route
A document without a recorded approval is the second most common finding. "Approved" means a named person, a role authorised to approve that document type, a date, and a record that cannot be edited after the fact.
Route approvals by document type and area of responsibility. A calibration procedure should not be approvable by someone outside the quality function. Build the route so a document cannot reach released status without passing through the required signatures. Manual sign-off sheets drift out of sync with the document itself, so bind the approval to the version it approved.
Retention and disposal on a schedule
Retention findings run both directions: records destroyed too early, and records kept long after their retention period with no justification. Both signal that no schedule is being enforced.
Assign a retention period to every document and record class, tie disposal to a trigger date, and log the disposal event. The log matters as much as the deletion, because an auditor wants evidence that disposal was a controlled decision, not an accident. Our QMS structures this alongside the rest of the quality system so retention is set when a document is created, not bolted on later.
How ComplyTrain supports this
ComplyTrain's QMS functionality is structured around ISO 9001, so versioning, approval routing, retention scheduling, and controlled distribution follow the clauses your auditor will reference. Data is hosted in the EU on AWS eu-central-1 (Frankfurt). Tenant data is separated using a silo model: schema-per-tenant, Cognito-pool-per-tenant, and bucket-per-tenant, so one customer's documents never share storage with another's. You can read how we map the standard on our /standards/iso-9001 page.
A short pre-audit checklist
Before an audit, confirm five things. One master exists for each document. Every released document shows a version, an approver, and an approval date. Superseded versions are retained but marked. Every controlled copy is logged with a holder. Every record has a retention period and a disposal trigger. If all five hold, the common findings above cannot land.
See how these controls work in practice on the /product/qms page, then book a walkthrough with our team to map your current document set onto the system.
