Pharmaceutical document version control connects a uniquely identified revision to its approval, permitted use and retained history. It should let a user determine which instruction applies to a specific activity, site and time, while letting a reviewer reconstruct what was used previously.
A filename ending in “final” does not establish that relationship. Neither does the largest revision number or most recent upload. An approved revision may be waiting for its effective date while a newer draft remains under review.
This procedure creates a revision register and release record for controlled instructions. It is a documentary workflow with a fictional test fixture, not a demonstration of a specific EDMS. Confirm your system's actual states, permissions and configuration before using it. Primary sources were checked October 6, 2026.
1. Define the document and its permitted use
Choose one document family, such as manufacturing procedures or laboratory instructions. Record the process owner, document controller and authorized approval roles. Identify applicable sites, activities, products and any other condition that changes which instruction governs the work.
Obtain the current approved instruction, change-control procedure, approval requirements, distribution arrangements and retention rules. Include connected systems that hold links or copies. Stop if two systems both claim to own the effective version without an agreed relationship.
For applicable US drug production/process-control procedures, 21 CFR 211.100 addresses drafting, reviewing and approving procedures and changes, following them and documenting deviations. It does not prescribe one universal revision-number format. 21 CFR 211.100.
For human-medicines GMP documentation within its scope, EU Chapter 4 addresses identifiable approved instructions, defined effective dates and document controls. The Commission's current index lists the January 2011 revision; this article uses that adopted text. Chapter 4, revision 1, sections 4.1–4.5, current EudraLex index.
These examples do not establish a single lifecycle for every clinical, regulatory, quality or manufacturing document. Apply the relevant record requirements and your approved procedure.
2. Separate identity, revision and lifecycle state
Give the logical document a stable identifier. Assign a distinct identifier to each controlled revision. Keep working edits distinguishable from released revisions, using the system's supported mechanism and your procedure.
Treat revision labels as identifiers, not evidence of authority. “10” may be later than “9” in a defined scheme, but string sorting can produce a different order. “2.1” might mean a minor revision in one organization and a working draft in another. Do not infer those meanings from the characters alone.
Define lifecycle states in terms of behavior:
| Example state | Meaning in this procedure | Permitted use |
|---|---|---|
| Draft | Content is being prepared or changed | Authoring/review preparation; not operational instruction |
| In review | An identified revision is under review | Review actions within the controlled process |
| Approved, not effective | Required approval exists; release conditions remain | Preparatory access as authorized; not yet the operative instruction |
| Effective | Release conditions are satisfied for the defined scope/time | Authorized operational use |
| Superseded | Another revision replaced its operational applicability | Historical retrieval; not routine current instruction |
| Withdrawn | Use has been stopped under a recorded decision | Restricted historical/reference access as defined |
Your product may use different labels or combine states. Write the mapping before configuring it. An “approved” flag that immediately enables use is not equivalent to an approved-but-future-effective state.
Keep operational selection separate from historical retrieval. A superseded revision can remain accessible to an authorized investigator without appearing as the instruction for today's activity. Do not delete the old revision merely to make current search results look tidy.
3. Create the revision register
Use the EDMS's authoritative register where available. The table below describes the information needed; it is not a recommendation to maintain an uncontrolled duplicate alongside the system.
| Field | Required meaning |
|---|---|
| Document ID | Stable identity of the instruction family |
| Revision ID | Exact controlled content identity |
| Change reference and reason | Why the revision exists and its controlled change record |
| Scope | Site/activity/product conditions that determine applicability |
| Lifecycle state | Defined behavior, not an unexplained status label |
| Approval reference | Decision tied to this exact revision and required actors |
| Effective start | Authorized start timestamp or defined date convention |
| Effective end/replacement | When applicability ends and which revision or decision replaces it |
| Dependencies | Required readiness actions and their closure evidence |
| Distribution/retention references | Where controlled copies and historical evidence are managed |
Specify time zones and boundary conventions. In the fixture below, start is inclusive and end is exclusive. If your procedure uses calendar dates, define the applicable local day and transition behavior. “Effective October 1” is ambiguous across sites unless the meaning is controlled.
For a given document and operational scope, the selection rule in this example is: choose the uniquely authorized revision whose applicability interval contains the activity time and whose release conditions are satisfied. If none qualifies, stop and resolve the gap. If multiple revisions qualify, stop and resolve the conflict. Do not choose the newest to conceal an overlap.
Concurrent revisions can be legitimate for different sites or products. Represent that difference in the applicability rule. The problem is unresolved competing authority for the same activity, not the mere existence of two retained revisions.
4. Prepare and approve a change without rewriting history
Create the proposed revision from an identified source. Record the change reason, affected sections and relevant dependencies. Review the actual content difference as well as the revision metadata. Renaming a file is not a content review.
Assess downstream effects: related instructions, forms, training or qualification, system settings, external recipients and work already in progress. Determine which changes require a separate impact assessment or regulatory decision. The document controller should not invent those decisions from the label “minor change.”
Use the prescribed approval route. For example, applicable master production and control records have specific preparation and independent-check requirements under 21 CFR 211.186; do not replace those requirements with a generic one-click document approval. 21 CFR 211.186.
Lock the approval to the exact revision evaluated. If content changes during or after review, follow the approved rule for reassessment and renewed approval. Preserve the previous review's identity instead of silently moving its signature to the edited text.
Also distinguish revising an instruction from correcting a completed record. A completed batch record should continue to show which instruction governed the activity. Replacing every historical reference with today's version would obscure that history.
5. Release the revision with a complete transition record
Use this worksheet for each release. Enter the result, evidence reference, owner and date for every row. Required failed or unknown rows prevent release of the affected scope.
| Release check | Evidence that resolves it |
|---|---|
| Exact revision approved | Approval identifies the content/version being released |
| Scope and timing authorized | Applicable sites/activities and unambiguous transition time are recorded |
| Required dependencies closed | Designated owner accepts the readiness evidence specified by the change |
| Previous applicability ends correctly | Replacement interval has no unintended gap or overlap |
| In-progress work addressed | Approved transition rule states what happens to work already started |
| Controlled copies updated | Distribution record identifies affected locations and retrieval/replacement actions |
| Connected routes verified | Relevant links, search, exports and interfaces return the intended revision/state |
| Historical evidence retained | Prior content and associated context remain retrievable as required |
Readiness is more than sending a notification. Where the change requires training or qualification before use, obtain the defined evidence. A generic “read” receipt should not be assumed to establish competence. Where no training is needed, record the authorized assessment rather than creating an automatic training burden for every punctuation edit.
Decide the transition for work in progress before the change takes effect. Depending on the process and approved change, work might continue under a specifically permitted earlier instruction, move at a defined step or be held for assessment. This article supplies no universal rule that a batch must switch midway or always finish under its starting revision.
For controlled paper copies, identify holders or locations, copy identifiers where used and the process for replacing or withdrawing superseded material. A watermark saying “uncontrolled when printed” does not itself manage a paper instruction intentionally used to execute controlled work.
6. Run a timing and version-conflict exercise
Create synthetic document SOP-17 for Site North, activity A. The following dates and records are fictional. Assume required approval and readiness evidence exists for revision R2 and, at its scheduled transition, R3. R4 is an unfinished draft.
| Revision | State/applicability in the fixture | Start UTC | End UTC |
|---|---|---|---|
| R2 | Authorized operational interval | September 1, 2026, 00:00 | October 1, 2026, 00:00 |
| R3 | Approved; becomes effective at the scheduled transition | October 1, 2026, 00:00 | No scheduled end |
| R4 | Draft; never eligible for operational selection | None | None |
At September 30, 23:59 UTC, the rule selects R2. At exactly October 1, 00:00 UTC, it selects R3. R4 is not selected even if it has the newest file timestamp or largest label.
Test these changed conditions separately:
| Changed condition | Expected outcome | Recovery action |
|---|---|---|
| R2 has no recorded end and overlaps R3 | Conflict; do not silently pick R3 | Resolve the authorized supersession boundary |
| R3 effective start is missing | Unknown applicability; do not infer it from approval time | Obtain the controlled release decision |
| R3 approval references different content | Release failure | Reconcile the revision and required approval |
| R3 required readiness remains open at transition | No authorized release under this plan | Hold affected use and obtain an approved transition decision |
| User requests Site South with no applicable scope record | No matching instruction | Resolve site applicability before use |
| Search returns a cached R2 as current after transition | Distribution/control failure | Correct the affected retrieval route and retest |
The missing-readiness case does not automatically extend R2. Its interval already ended under the fixture. Continuing R2 would require an explicit authorized change to the transition plan, including impact assessment where applicable.
Now distinguish two requests made on October 2. An operator starting activity A at Site North needs R3, assuming its release conditions were met. An authorized reviewer investigating work performed on September 30 needs the identified historical R2 record. Returning R2 for that historical request is correct; presenting it as today's operative instruction is not. Record both the request's purpose and the activity time in the exercise so the test does not incorrectly reject legitimate historical retrieval.
For a separate site, add an explicit applicability record before choosing a revision. If Site South is authorized to continue R2 for its own defined activity and interval, concurrent North R3 and South R2 can be valid. That is a scoped decision, not an exception allowing ambiguous competing revisions for Site North.
Capture test inputs, system/configuration, expected selection, observed selection and evidence. Include ordinary operational users and historical-review users; they have different purposes. These results are a documentary exercise until your team executes the checks in its actual system.
7. Verify what users receive and retain the decision
Check the common ways people reach the document: current-document view, saved links, search, preview, controlled print/export and connected systems. A correct central register does not establish that every cached rendition or distributed copy matches it.
For each relevant route, verify the exact ID/revision, state and permitted use. A stable “current instruction” link may intentionally resolve to the effective revision, while an evidence reference in a completed record should identify the historical version. Make those two link behaviors distinguishable and test them.
If an incorrect revision was used, preserve the evidence and assess the affected activity under the quality process. Correct the failed selection or distribution mechanism and examine neighboring documents using it. Do not simply replace the file and lose the ability to determine what happened.
Retain the release record, supersession relationship, prior revisions and necessary context under the applicable retention rules. A new revision does not reset or erase the obligations attached to the old records. Periodic document review should assess whether instructions remain appropriate; a review with no content change can be recorded without inventing a new technical revision if the approved procedure allows it.
The resulting control should answer two questions reliably: what may be used for this activity now, and what was authorized for the earlier activity being reviewed? For the broader process, see the QMS document-control guide. Assyro publishes this guide. If evaluating a regulatory-document workflow with Assyro, bring the revision register and transition case to a discussion to establish the required behavior before accepting product claims.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.

