ICH Q10 turns change approval into a before-and-after quality test
The pharmaceutical quality-system model connects a proposed change to risk-based evaluation before implementation and a check afterward that objectives were achieved without harming product quality.
Editorial figure by RegQuality Review. Source context: International Council for Harmonisation.
Change control is a lifecycle system, not a commercial-batch form
The direct answer in ICH Q10 is that change management belongs across the product lifecycle. The model covers pharmaceutical development, technology transfer, commercial manufacturing, and product discontinuation, while recognizing that the formality of the system can differ by stage. That architecture matters because knowledge and risk move with a product: a development decision can shape the control strategy, a transfer can expose process assumptions, and a commercial signal can create learning that belongs in future products and platforms.
ICH Q10 identifies monitoring, corrective and preventive action, and innovation as potential drivers of change. A maintained record should therefore preserve why the change entered the system, the product and process knowledge available at that point, the lifecycle stage, the affected controls and filings, and the accountable functions. A change number and approval date alone cannot show whether the proposal was evaluated in its actual scientific and regulatory context.
The pre-implementation decision is risk based and multidisciplinary
The guideline calls for the level of effort and formality to be commensurate with risk. That is not permission to skip the decision record for a supposedly small change. It is a direction to scale the evidence, expertise, testing, approval, and oversight to the potential effect on product quality. The organization should be able to show the risk question it asked, the basis for its classification, the current understanding it used, and why the selected controls are proportionate.
ICH Q10 also describes evaluation by expert teams with appropriate knowledge and expertise. The assessment should consider the marketing authorization, including whether the change remains within an approved design space where relevant, as well as the current product and process understanding. Prospective evaluation criteria make that review testable: they define what evidence will support approval, what must be resolved before execution, and what outcome will later count as success.
Closure requires evidence after implementation
A strong change record does not end when tasks are marked complete. ICH Q10 says an evaluation after implementation should confirm that the change objectives were achieved and that there was no deleterious effect on product quality. That creates a before-and-after control: the proposal states an intended result and anticipated risks; the post-implementation review compares observed evidence with those criteria and records the disposition.
The evidence will vary with the change. It may include validation or qualification results, batch and process monitoring, stability signals, deviations, complaints, laboratory trends, data-integrity checks, regulatory commitments, or performance over a defined observation period. The system should preserve exceptions and inconclusive results rather than forcing a clean closure. Where evidence does not support the original conclusion, the record needs an accountable follow-up path into investigation, CAPA, further monitoring, reversal, or another controlled change.
What a regulated buyer should test in a change platform
A useful demonstration follows one representative change from its originating signal through scope, knowledge review, risk classification, expert assessment, regulatory-impact review, prospective criteria, implementation, effectiveness evidence, and final approval. Reviewers should introduce a conflicting result and inspect how the platform handles reassessment, overdue evidence, linked deviations, version history, electronic signatures, access, audit trail, and export. They should also test whether a product, process, site, method, specification, supplier, computerized system, and filing can be related without collapsing distinct responsibilities.
Technology can route and retain this evidence, but it cannot supply scientific judgment, decide regulatory applicability, or establish that the data are reliable. ICH Q10 is a harmonised model, not a product specification, and it expressly says it is not intended to create new expectations beyond current regional GMP. Buyers should map the model to applicable law, approved dossiers, regional guidance, internal procedures, and the actual lifecycle stage before treating a configured workflow as compliant.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
RegQuality Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.