Change control software for pharma should connect a proposed change to its affected products, documents, regulatory assessments, implementation tasks and closure evidence. For document changes, the important question is whether the new revision can be used for the specified activity, site and product. An approved document and an authorized implementation are separate decisions.
This guide helps quality, regulatory and document-control teams define that workflow and evaluate the software supporting it. The principal scope is pharmaceutical GMP, with US drug examples and an EU human-medicinal GMP system-control reference. Investigational products, biologics and other markets need their applicable regulatory assessment; the example below does not assign a filing category to a real product.
Use the record and demonstration cases below when configuring an existing system or evaluating a replacement. They are proposed operating controls, not a mandatory regulatory form.
Primary regulatory sources and document revisions were checked on October 6, 2026. The fictional Meridian example tests decision logic; it is not an executed software trial or a regulatory classification for a customer product.
Start with four decisions the system must keep separate
| Decision | What it authorizes | Evidence to retain | Typical accountable function |
|---|---|---|---|
| Approve the change plan | Proceed with defined preparation and evidence generation | Scope, risk assessment, reviewers, planned tasks and restrictions | Quality with affected functions |
| Approve the document revision | Accept the specified content and its intended use | Exact revision, approvals and resolved comments | Document owner and authorized approvers |
| Authorize implementation | Use the change for a defined activity, product, site or market | Readiness evidence and satisfied applicable hold points | Authorized operational and quality roles, informed by regulatory decisions |
| Close and evaluate the change | Confirm completed scope and handle remaining effectiveness work | Implementation results, discrepancies, evaluation or controlled follow-up | Quality and change owner |
A workflow can combine some approval steps when appropriate, but the decisions must remain understandable. A green document status should not silently lift a product-distribution restriction. Likewise, a future effectiveness check need not be falsely marked complete merely because initial implementation is authorized.
FDA's April 2009 ICH Q10 guidance recommends risk-proportionate change evaluation, appropriate expertise, consideration of marketing authorization and an evaluation after implementation. It is a pharmaceutical quality-system model, not a requirement to buy a particular software module. FDA Q10, section 3.2.3
Describe what changes, beyond the document filename
“Update SOP-240” is too little information for meaningful review. Capture the old instruction, proposed instruction and reason for the difference. Identify whether the document describes an actual process change, corrects an error, reflects a previously authorized change or only improves presentation.
For example, correcting a misspelled department name is different from changing a hold time, sampling instruction or acceptance criterion. The number of edited characters does not determine the impact. A one-character change to a unit or inequality can alter how a procedure is performed.
Make the record specific enough to establish the affected population:
- Product, strength, dosage form and lifecycle stage, where relevant.
- Site, process, equipment, material or computerized system.
- Exact document identifiers and revisions, including related forms and specifications.
- Markets, applications, commitments and outsourced activities potentially affected.
- Proposed timing, reason and whether the change is permanent or temporary.
If a field is unknown, assign discovery work before treating it as “none.” A global procedure with an incomplete site list is not ready for a global effectivity decision.
For production and process-control procedures within its scope, 21 CFR 211.100 requires appropriate drafting, review and approval, including changes, and requires procedures to be followed and documented. The same section addresses recording and justifying deviations; a retrospective record should not disguise an already executed deviation as a prospective approval. 21 CFR 211.100
Route review according to the actual change
Keep the useful distinction between change types without creating dozens of nearly identical forms. The initial screen should identify which specialist decisions are needed and why.
| Change type | Questions that change the review route | Evidence or linked record |
|---|---|---|
| Manufacturing process | Does the instruction change an operating parameter, control strategy or validated process? | Technical assessment, validation impact, affected master and executed records |
| Analytical method or specification | Are method performance, acceptance criteria, stability testing or filed details affected? | Laboratory assessment, method evidence and regulatory comparison |
| Equipment or facility | Does the change affect qualified operation, cleaning, maintenance or environmental controls? | Engineering assessment and qualification or verification plan |
| Supplier or material | Which products and contracts depend on the changed source or material? | Supplier qualification, specification and quality-agreement assessment |
| Labeling or packaging | Which approved text, artwork, presentation or market configuration changes? | Labeling assessment, approved artwork and implementation restrictions |
| Computerized system | Does intended use, configuration, data flow, access or retained evidence change? | System impact assessment, targeted verification and release record |
| Document presentation | Could wording, layout, units, references or readability change interpretation? | Before-and-after comparison and justified review scope |
These are starting questions, not automatic filing classifications. A reviewer may find that the initially selected change type is incomplete. The system should allow reassessment, additional reviewers and revised scope without erasing the earlier decision trail.
When a manufacturing change could affect a validated process, use the FDA process-validation guide to frame the additional evidence question. Document approval alone cannot answer whether the changed process remains suitable for its intended operation.
For computerized systems used in EU human-medicinal GMP activities, Annex 11 section 10 calls for changes, including configuration changes, to follow a defined controlled procedure. Changing the workflow that approves documents can therefore need its own system-change assessment. EU GMP Annex 11, January 2011 revision
Use a change record that connects evidence to decisions
Copy this structure into your approved change process or demonstration script. Add record identifiers and links to retained evidence; a link to a mutable working folder alone may not identify what was reviewed.
| Record field | Enter or attach | Owner to assign | Completion condition |
|---|---|---|---|
| Change identity and rationale | Unique ID; current and proposed state; business or quality reason | Change owner | Difference is specific enough to assess |
| Scope | Products, sites, processes, systems, parties and known exclusions | Change owner with subject experts | Affected population confirmed or explicit unresolved discovery task |
| Document impact | Source revisions; proposed revisions; dependent forms, instructions and references | Document control | Each dependency has an action or supported no-change conclusion |
| Quality risk | Potential failure, consequence, controls and remaining uncertainty | Quality and technical experts | Review effort and acceptance criteria justified |
| Regulatory assessment | Application and market context; exact evidence assessed; decision and rationale | Regulatory affairs | Authorized decision for each relevant scope; unknowns remain visible |
| Implementation restrictions | Restricted action, affected population, release authority and evidence needed | Quality, operations and regulatory | No ambiguous “hold” without specifying what it blocks |
| Preparation tasks | Document approval, qualification, verification, communication, training or supplier work as applicable | Named task owners | Outputs accepted against predefined criteria |
| Effective-use authorization | Exact revision, site/activity applicability, authorized start condition | Authorized release role | All mandatory prerequisites satisfied for that scope |
| Implementation evidence | Actual execution, first-use or deployment evidence; discrepancies | Operations or system owner | Result matches authorized plan, or differences are assessed |
| Closure and effectiveness | Result, remaining actions, evaluation method, owner and due trigger | Change owner and quality | Closure rules met without misrepresenting deferred work |
For each gate record Pass, Fail, Unknown or Not applicable, plus the evidence reference, reviewer and decision date. Use Pass when the criterion is met by accepted evidence, Fail when evidence shows it is not met, and Unknown when required information is absent or inconclusive. Not applicable needs a recorded scope rationale accepted by the appropriate reviewer.
For a proposed release, Fail or Unknown on a mandatory prerequisite blocks the affected activity. An average score must not override the block. Optional improvements can remain open under the approved procedure when they do not undermine that release decision. These status rules are a suggested workflow design, not terminology prescribed by FDA.
Make regulatory restrictions precise enough to operate
A yes/no “regulatory impact” field does not explain what operations may do next. Keep a decision for each relevant application and market, showing the current approved or filed basis, proposed difference, assessment owner and required regulatory action.
Separate preparation, manufacturing, testing, document use and distribution when the applicable requirement distinguishes them. For an approved NDA, 21 CFR 314.70 includes changes requiring approval before distribution, certain changes submitted at least 30 days before distribution, specified changes that may permit distribution upon receipt, and changes reported annually. The exact category and conditions matter; “submission sent” is not a universal release signal. 21 CFR 314.70
Biological-product changes have a separate framework in 21 CFR 601.12. Do not configure an NDA decision list as the automatic rule for every product, or apply postapproval categories to an IND without assessing the correct pathway. 21 CFR 601.12
The software should preserve the regulatory conclusion and its source evidence, rather than generate a categorical answer from “SOP change.” If assessment is performed in another system, store the controlled reference, relevant version and decision status, with ownership for updates. A successful integration should be able to show when the referenced assessment changed.
For a deeper assessment framework, see regulatory impact assessment in change control. This guide focuses on how the resulting decision governs document effectivity and implementation.
Worked example: approved method, unresolved release
Consider fictional manufacturer Meridian and change CC-240. It proposes a new sample-preparation instruction for a commercial drug. Laboratory method M-240 revision 7 will replace revision 6. The change also affects worksheet F-240, a training assignment and a source document used in the regulatory dossier.
The example assumes qualified regulatory staff have separately assessed the product. It does not infer the reporting category from the type of method change.
| Gate | Initial evidence and status | Decision or next action |
|---|---|---|
| Technical method assessment | Accepted report LAB-240 supports the defined change: Pass | Continue preparation within approved scope |
| Method document approval | M-240 revision 7 approved: Pass | Content approval recorded; effective use still gated |
| Worksheet dependency | F-240 still contains revision 6's instruction: Fail | Correct and approve dependent worksheet before affected use |
| Role readiness | Required analyst preparation evidenced for Site A; Site B evidence missing: Pass for A, Unknown for B | Maintain site-specific readiness; no global completion claim |
| Regulatory decision | US decision RA-240 authorizes a defined route with a distribution hold pending specified evidence: hold open | Retain restriction on affected distribution |
| Other market | Application context not yet confirmed: Unknown | Assign regional assessment; do not copy US conclusion |
| Implementation authorization | Mandatory document dependency failed: Fail | Revision 7 remains unavailable for routine affected use |
First resolve the worksheet mismatch. Document control approves F-240 revision 3 against M-240 revision 7, and the affected Site A roles complete the required preparation. Quality can then assess authorization for the specific Site A activity, subject to the approved plan and any activity-specific restrictions. This does not by itself release affected product for distribution.
Later, the designated regulatory reviewer accepts the evidence required to clear the US distribution hold, and the relevant quality and operational release steps are completed. The US scope may now proceed under the recorded authorization. The other market remains unresolved. If physical segregation or system controls cannot reliably maintain that distinction, the proposed partial release is not operationally supportable.
Keep a small scope ledger so the partial decision is executable. Immediately after the worksheet correction and Site A readiness review—but before the US distribution hold is cleared—the fictional ledger reads:
| Requested action | Evidence available | Disposition |
|---|---|---|
| Use method revision 7 for the defined Site A activity | Corrected worksheet and role readiness; authorized owner has accepted all prerequisites for this activity | Permitted within that recorded scope |
| Use revision 7 at Site B | Required role-readiness evidence missing | Hold Site B's affected use; Site A's result cannot be copied |
| Distribute affected US product | Required regulatory hold still open | Hold distribution even if laboratory work is authorized |
| Distribute in the other market | Application context and assessment unresolved | Hold that market's affected distribution pending assessment |
Ask the demonstrator to repeat all four requests after clearing only the US hold. The Site B and other-market rows should remain unresolved until their own conditions change. If one global “complete” flag releases every row, the workflow has failed this example's scope requirement. Retain the decision history and test the boundary again after correction.
Record the actual first-use evidence, affected batches or tests and any discrepancies. Define how the team will evaluate whether the change achieved its objective. If the procedure permits a separate effectiveness record, keep its owner, due trigger and relationship to CC-240 visible; closing implementation must not imply effectiveness was already demonstrated.
Now change one assumption: the method is shared by an additional product omitted from the initial scope. Reopen impact assessment before relying on the old release decision for that product. Existing evidence may remain useful, but its applicability must be established. The software needs controlled scope revision, not merely another completed task.
Keep CAPA, deviations and document records connected
A CAPA can initiate a process or document change, while the change record controls implementation. A deviation can reveal that an instruction was already used incorrectly or changed without authorization. Preserve the distinction between explaining the event, correcting its effects and approving a future controlled change.
Link the originating record to the change and link the change to its resulting documents, validation evidence and effectiveness evaluation. Do not duplicate the entire CAPA investigation in every related document. Instead, keep stable references and enough context to understand why the change was necessary.
A new revision also does not rewrite history. Retain the evidence showing which version governed earlier work, and assess any records affected by the original issue through the applicable process. If a source document changes after a submission package was assembled, determine whether that package needs action; silently replacing its underlying source would obscure what was submitted. The QMS data and submission readiness guide explains that handoff in more detail.
Evaluate electronic controls and implementation burden
Part 11 applicability depends on the records and their regulatory use, not the software's marketing category. For applicable closed systems, section 11.10 addresses controls including validation, record protection and retrieval, access and audit trails. Electronic signatures bring additional requirements. A vendor statement alone does not establish that your configured workflow, procedures and use comply. 21 CFR Part 11
Before choosing software, identify who maintains routing rules, product and market relationships, integrations and permissions. Ask how a reviewer retrieves the exact assessment underlying an old release, and what happens when an upstream record is withdrawn. Test authorized and unauthorized actions, not only the happy path.
For implementation planning, separate the supplier's standard functionality from configuration, migration, validation support, training and ongoing administration. A team with few changes and one site may reasonably prioritize a controlled, understandable workflow over extensive cross-system automation. A multi-site portfolio may need stronger dependency and restriction handling. Neither choice is justified by feature count alone.
Demonstrate the release boundary before buying
Ask each shortlisted supplier to execute the same cases using the intended configuration. Record what happened, the evidence produced and any manual step; these are proposed buyer exercises, not results from a product test.
| Demo case | Expected decision | Evidence to inspect |
|---|---|---|
| All mandatory prerequisites accepted for one defined scope | Authorized role can release that scope | Revision, scope, decision time, approver and accepted evidence |
| Document approved but dependent worksheet failed | Routine affected use remains blocked | Visible failed dependency and controlled correction path |
| Market assessment blank | Unknown remains unresolved | No default “no impact” or copied market clearance |
| One market cleared, another held | Restriction remains enforceable for held scope | Operational controls and downstream status, not only dashboard color |
| Source assessment revised after approval | Affected decision is reassessed under defined rules | Change history, notification and review responsibility |
| Unauthorized user attempts release | Attempt does not grant release | Permissions behavior and applicable retained event evidence |
| Export the closed change | Reader can reconstruct the approved and implemented states | Readable records, linked evidence and retained approval context |
If a supplier demonstrates a workaround, decide whether your team can operate and verify it reliably. A manual control may be appropriate; an undocumented dependency on someone remembering to send an email is not a complete demonstration.
Use the failed and unknown cases before polishing dashboards. They expose whether the system supports the decisions your procedure requires. Bring one representative change, its affected document set and its unresolved restrictions to an Assyro workflow discussion to assess the regulatory-document handoff and identify what must remain in your quality process.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.