Skip to content
Assyro AI
Document Version Control in Pharma
Compliance Systems

Document Version Control in Pharma

Guide

Control pharmaceutical document revisions from draft to effective use. Includes a revision register, release worksheet and worked overlap, timing and approval cases.

Assyro Team
11 min read

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:

Comparison table with columns Example state, Meaning in this procedure, Permitted use
Example stateMeaning in this procedurePermitted use
DraftContent is being prepared or changedAuthoring/review preparation; not operational instruction
In reviewAn identified revision is under reviewReview actions within the controlled process
Approved, not effectiveRequired approval exists; release conditions remainPreparatory access as authorized; not yet the operative instruction
EffectiveRelease conditions are satisfied for the defined scope/timeAuthorized operational use
SupersededAnother revision replaced its operational applicabilityHistorical retrieval; not routine current instruction
WithdrawnUse has been stopped under a recorded decisionRestricted 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.

Comparison table with columns Field, Required meaning
FieldRequired meaning
Document IDStable identity of the instruction family
Revision IDExact controlled content identity
Change reference and reasonWhy the revision exists and its controlled change record
ScopeSite/activity/product conditions that determine applicability
Lifecycle stateDefined behavior, not an unexplained status label
Approval referenceDecision tied to this exact revision and required actors
Effective startAuthorized start timestamp or defined date convention
Effective end/replacementWhen applicability ends and which revision or decision replaces it
DependenciesRequired readiness actions and their closure evidence
Distribution/retention referencesWhere 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.

Comparison table with columns Release check, Evidence that resolves it
Release checkEvidence that resolves it
Exact revision approvedApproval identifies the content/version being released
Scope and timing authorizedApplicable sites/activities and unambiguous transition time are recorded
Required dependencies closedDesignated owner accepts the readiness evidence specified by the change
Previous applicability ends correctlyReplacement interval has no unintended gap or overlap
In-progress work addressedApproved transition rule states what happens to work already started
Controlled copies updatedDistribution record identifies affected locations and retrieval/replacement actions
Connected routes verifiedRelevant links, search, exports and interfaces return the intended revision/state
Historical evidence retainedPrior 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.

Comparison table with columns Revision, State/applicability in the fixture, Start UTC, End UTC
RevisionState/applicability in the fixtureStart UTCEnd UTC
R2Authorized operational intervalSeptember 1, 2026, 00:00October 1, 2026, 00:00
R3Approved; becomes effective at the scheduled transitionOctober 1, 2026, 00:00No scheduled end
R4Draft; never eligible for operational selectionNoneNone

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:

Comparison table with columns Changed condition, Expected outcome, Recovery action
Changed conditionExpected outcomeRecovery action
R2 has no recorded end and overlaps R3Conflict; do not silently pick R3Resolve the authorized supersession boundary
R3 effective start is missingUnknown applicability; do not infer it from approval timeObtain the controlled release decision
R3 approval references different contentRelease failureReconcile the revision and required approval
R3 required readiness remains open at transitionNo authorized release under this planHold affected use and obtain an approved transition decision
User requests Site South with no applicable scope recordNo matching instructionResolve site applicability before use
Search returns a cached R2 as current after transitionDistribution/control failureCorrect 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.

Related articles

Demos available this week