Version history and document control answer different questions
A revision log answers one question: what changed between revision 9 and revision 10, and who approved it. Document control answers a different one: which revision was in use, where, on a given date, and whether you can prove it. The first is a property of a file. The second is a property of a site, and no log supplies it on its own.
The gap between those two questions is where document-control observations come from. Not "no procedure". A procedure that exists in three versions in three places, each with a different idea of which one is current, while the system that holds it reports a clean history. This post covers what the rules require of a document (none of them asks for a version history), where control breaks while the log stays tidy, and what you can check on one procedure this afternoon. The document control term is the short version.
What the rules require of a document, in plain terms
None of the GMP texts asks for a "version history". Read together, they require six things: that the right people approve a document, that it has a defined effective date, that it is the version in use where the work happens, that superseded and blank copies are controlled, that it is reviewed while it is in force, and that it can be produced, with its history, for as long as the records it governed must be kept.
| Requirement | Where it sits | What it comes to (paraphrased; full text linked below) |
|---|---|---|
| Approval by the quality unit | 21 CFR §211.22(c) | The quality unit approves or rejects all procedures or specifications that affect identity, strength, quality and purity |
| Drafted, reviewed, approved, changes included | §211.100(a) | Written production and process control procedures, including any changes, drafted, reviewed and approved by the appropriate units and by the quality unit |
| Followed as written; deviations recorded | §211.100(b) | Procedures followed and documented at the time of performance; any deviation recorded and justified |
| Master records prepared, dated, signed, independently checked | §211.186(a) | One person prepares, dates and signs; a second person independently checks, dates and signs; the preparation itself follows a written procedure |
| Each batch record an accurate reproduction of the master | §211.188(a) | Checked for accuracy, dated and signed |
| Readily available; true copies acceptable | §211.180(c), (d) | Available for inspection through the retention period; records retrievable electronically from another location count; true copies acceptable |
| Approved, signed, dated; unique; effective date defined | EU GMP Chapter 4 §4.3 | Documents containing instructions approved, signed and dated by authorised persons; unambiguous; uniquely identifiable; the effective date defined |
| Master documents, official copies, hybrids | Chapter 4 §4.1, §4.2 | Relationships and controls for master documents and official copies stated, for hybrid and homogeneous systems; reproducing a working document from a master must not introduce error |
| Regularly reviewed, kept up to date | Chapter 4 §4.5 | Documents within the quality management system regularly reviewed and kept up-to-date |
| Obsolete documents; versions at the point of use | ISO 13485:2016 §4.2.4, the device rule via 21 CFR §820.10 | Current revision status identified; relevant versions available at points of use; obsolete documents identified and their unintended use prevented; at least one copy of an obsolete document retained |
| Blank forms and templates | FDA Data Integrity Q&A, Q6 | Blank forms (worksheets, notebooks, master production records) controlled by the quality unit or another document-control method; numbered sets issued and reconciled; incomplete or erroneous forms kept with a written justification |
| System documentation under Part 11 | 21 CFR §11.10(k) | Controls over distribution, access and use of documentation for system operation and maintenance; revision and change control that maintains an audit trail |
Two details carry most of the weight. §211.100(a) says "including any changes": a revision goes through the same approval as the original, not a lighter one. And the only text that names an effective date at all is Chapter 4 §4.3, which treats it as a separate thing from approval. Approval means the document is right. The effective date means people must now follow it. Most failures sit between those two dates.
(Chapter 4 is being revised alongside Annex 11; the Commission published draft texts for consultation in July 2025. The requirements above are from the version in force.)
Where control breaks while the log stays clean
Seven mechanisms. Each one leaves the revision history looking fine on screen, because the history is recording the file and the failure is happening somewhere else.
1. Approval and effective date collapse into one
The signature date becomes the effective date by default, so the document is in force before the training, the form updates and the print run that make following it possible. Or the reverse: approval sits for weeks with no effective date, and two versions are simultaneously "current" depending on who you ask. Chapter 4 asks for the effective date to be defined. Defined means chosen, usually after the training in failure 5 has been done.
2. The printed copy has no owner
A controlled system distributes the effective version; a printer distributes whatever was on screen at the time. Once a copy is on paper, the system cannot recall it. Sites that manage this treat every print as an issued copy: numbered where it matters, logged against a person and a location, and reconciled when the revision changes. Sites that don't have a laminate in a holder that outlives three revisions. A PDF saved to a desktop is the same failure in a different medium.
3. The working copy on the shared drive
The controlled document is in the system; the version people actually open is SOP-0210_v10_FINAL_use-this-one.docx on a shared drive, because that is where the team edits. Every site has one of these drives. The fork is invisible to the document system and to its audit trail, and it is where the uncontrolled edit lives: the step someone "corrected" in the working copy that never went back through §211.100(a).
4. The procedure moved and its form did not
Procedures reference forms, logbooks, templates and worksheets. Revise the procedure, add a step, and the form it prints onto still has the old fields, so operators record the new step in the margin. FDA's data-integrity Q&A puts blank forms squarely under document control: controlled issue, numbered sets, reconciliation, and erroneous forms kept with a justification. A revision whose impact assessment lists only the SOP has missed half the change.
5. Effective before trained
The new revision is effective 1 June. Training completion on the line is 65% on 1 June, and the untrained third sign batch records against the new revision number while following what they remember of the old one. Nothing in the document system flags this, because training lives somewhere else. The training-effectiveness post covers this seam from the other side; the point here is that a revision's effective date is only defensible if it sits after the training on it.
6. Periodic review that reads the date, not the document
Chapter 4 §4.5 asks for documents to be regularly reviewed and kept up to date. In practice a two-year review becomes a signature that re-approves the document unchanged, with no record of what was checked: whether the referenced forms still exist, whether the equipment named still exists, whether a deviation in the last two years pointed at this procedure. A periodic review with no possible outcome other than "no change" is not a review.
7. The revision history says "general update"
The one line the rules do ask for, the change itself, is the one most often left blank. "Updated per change control CC-0341" with no summary, or "general update" with no change record at all. §211.100(a) makes the change subject to approval, and an approver cannot approve what the record doesn't describe. When the change came out of a deviation or a CAPA, the chain from event to revised procedure breaks here, at the document end.
The questions a document has to answer, as of a date
An inspection does not test the document system from the front. It arrives at a document from a batch record, a deviation or a complaint, and works backwards from a date. Six questions, in the order they get asked:
- Pick a record. A batch record, an investigation, a cleaning log. Note the procedure number and revision it cites.
- Ask for that revision as of that date. Not the current one. If the system can only show "current", the site is already explaining.
- Ask what was on the floor. Walk to where the work happened and read what is in the holder, the binder, the terminal.
- Ask who did the work and what they were trained on. The training record for that person, that revision, dated before the work.
- Ask for the previous revision and its withdrawal. When revision 9 was superseded, what happened to its copies?
- Ask for the change. What changed between 9 and 10, why, who approved it, and whether the form that goes with it changed too.
Each of the seven mechanisms above breaks one of those answers. You do not need a perfect answer to all six for every document. You need to be able to give them for any document that gets picked, which is a different level of control from a clean log.
The control points a document needs
Written as the properties of one document at any moment in its life. The list is the same whether the system is paper, electronic or hybrid.
| Control point | What "in place" looks like | What fails when it's missing |
|---|---|---|
| Unique identity and revision | One ID, one revision number, on every page of every copy | Two documents with the same title; a copy with no revision on it |
| Approval by authorised roles | Named roles, signed and dated, the quality unit among them; the same route for every change | Author-approved revisions; changes made "under" the previous approval |
| Defined effective date | Set deliberately, after training and form and print readiness, distinct from the approval date | Effective-on-signature; two versions simultaneously current |
| Single source at the point of use | Where the work happens, only the effective version is reachable, on screen or as a controlled copy | Laminates, desktop PDFs, shared-drive working copies |
| Superseded copies withdrawn, revision retained readable | Old copies recalled and reconciled; the superseded revision kept legible for the batches that used it | Old copies in circulation; or the reverse, the superseded revision destroyed and unproducible |
| Controlled issue of prints, forms and blanks | Each print or blank form issued to a person, logged, numbered where appropriate, reconciled at revision or on completion | Unofficial notebooks; forms from the previous revision; a print count nobody can state |
| Linked forms and references | The revision's impact assessment names every form, template and referenced procedure that changes with it | The SOP moves, the form doesn't |
| Training before effectiveness | The revision carries the list of who must be trained; the effective date follows completion | Effective before trained |
| A stated reason for every revision | The revision history says what changed and why, and cites the change record or deviation that drove it | "General update" |
| Periodic review with an outcome | A dated review recording what was checked and a decision: confirm, revise or retire | Signature-only review |
| Retrievable through retention, with history | The document, its revisions, approvals and the history of changes producible for as long as the records it governed | Migrations that keep the current file and lose the history |
The last row is the one that bites during system changes. §211.180 ties retention to the batch (at least a year past expiry) and Chapter 4 §4.11 sets a longer floor in the EU. The procedure that governed those records has to be producible, in the revision that was in force, for the same period. A migration that carries the current revision forward and archives the rest as a folder of PDFs has met the letter of retention and lost the ability to answer question 2.
Download the SOP template if you need the controlled shape those rows describe: purpose, scope, responsibilities, the revision table, and a place for the reason a change was made. A blank that already has those fields is not document control. It is the starting file control has to sit on.
Hybrid systems: name the master, name the copy
Chapter 4 §4.1 is unusually direct about hybrids. Where a document exists partly in electronic form and partly on paper, the site should state the relationships and control measures for master documents, official copies, data handling and records. It says the same for homogeneous systems, but hybrids are where it goes wrong, because each medium assumes the other one is in control.
The practical version of §4.1 is a short table in the document-control procedure: for each document type, which is the master (electronic or paper), what counts as an official copy, how copies are issued, how they are withdrawn, and how the electronic record and the paper copy point at each other (a print identifier on the paper, a print log in the system). If that table doesn't exist, the site has two document systems that each believe the other one holds the control.
Check one procedure you used last week
Pick a procedure that was used on the floor last week and test it with the document in hand, not with the document system's dashboard.
- Which revision is effective today, and since when? Is that date after the training on it?
- Walk to where it is used. What revision is in the holder, the binder, or on the terminal? Is it the same one?
- How many printed or downloaded copies of the previous revision exist, and where are they? Can you say from a log, or only from memory?
- Name the forms and templates this procedure references. Did each one change when the procedure last changed, or is one of them still from an earlier revision?
- Who performed this procedure last week? Show their training on this revision, dated before the work.
- Read the revision history. Does it say what changed and why, and does it cite the change record?
- When is the next periodic review due, and what did the last one check, specifically?
- Show revision N-2, with its approvals, as it stood on a date two years ago.
Questions 3 and 8 are where most sites stop. Both can only be answered if the controls were in place at the time: a log of issued copies, a history that survived the last system change. That is why version history still fails. Control cannot be added to a file after the fact.
How Complere keeps the approved version in use
One version is current, and it's the only one people reach. Where the work happens, the effective revision is what opens; earlier revisions stay readable for the batches that used them, marked as superseded, without competing for the operator's attention.
Effective when the approvals are complete, not before. A revision carries no effective date until every required approver has signed, so "approved" and "in force" cannot drift apart by accident.
Every printed or downloaded copy leaves a mark. Controlled prints and downloads are logged, with who took them and when, so "how many copies of revision 9 are out there?" has an answer that isn't a guess.
Change, training and the procedure stay tied together. The revision links to the change that drove it and to the training it requires, so the reason for a change and the evidence that people were trained on it are read from the document, not reconstructed from three systems.
What changed is shown, not described. Reviewers see the difference between two revisions side by side, old value against new, and every edit, approval and status change carries who, when and what it was before.
What a procedure says, who approves it and when it takes effect are still the quality unit's decisions. The system's job is narrower and mechanical: keep the approved revision as the one in use, and keep the history attached to it.
