Change Control × Computerized System Validation
A validated system is a claim about the past; change control is what keeps the claim true. In this overlap the impact assessment becomes the validation programme's front line — and cloud updates arrive with no proposer at all.
What this page does not claim
An intersection covers what happens only where two axes overlap. It does not restate what either parent page says, and it is not a substitute for reading them.
WHAT ONLY EXISTS IN THE OVERLAP
- Qualification evidence describes the system as it was on a date. The only thing connecting that date to today is an unbroken chain of assessed, tested, documented changes — one undocumented alteration and the site can no longer demonstrate that the system in production is the system that was validated.
- Software change breaks the change-control template. The impact of a physical change is visible in walls and pipework; the impact of a configuration toggle can reach every record the system holds, and the assessor cannot see that reach without understanding the system's architecture.
- Cloud inverted the direction of change. SaaS vendors ship releases on their schedule, not the site's — change control must absorb changes it did not propose and cannot decline, which is a different discipline from approving changes it originated.
- The eQMS is both instrument and object: a change to the eQMS is routed by approval workflows running on the eQMS being changed. Its configuration is executable procedure — alter a routing rule and you have altered who may approve everything else.
- ICH Q12's lesson transfers from products to systems: pre-defining which elements bear GxP weight is what makes proportionate change assessment possible. A site that never established which configurations matter must treat every change as if it might.
The validated state is a claim change control must keep true
What a validation package actually proves is narrow and dated: on the day testing concluded, this system, in this configuration, met these requirements. Everything after that day rests on a different mechanism entirely. The validated state is not preserved by the original evidence — it is preserved by the change record, which must show that every alteration since qualification was identified, assessed for impact, verified in proportion to its risk, and approved before use. Annex 11 and Part 11 both assume this chain without ceremony: a system whose configuration has drifted from its validated baseline through unrecorded change is, for regulatory purposes, an unvalidated system wearing old credentials.
The hard judgement in every software change is regression scope — what else could this have touched, and how much re-testing does that warrant? GAMP 5's risk-based framing gives the structure: assessment depth follows the change's proximity to GxP-critical functions, and the categories of change behave differently. An infrastructure patch, a configuration change, and a code customization have different blast radii and demand different evidence. The trap has a name in every deviation system: "like-for-like". A vendor patch described as maintenance can swap the library that performs a calculation; a database update can change how timestamps are stored. Like-for-like is a conclusion the assessment is supposed to reach, not a category that excuses the assessment.
Change without a proposer
Change control was designed around an internal proposal: someone wants to change something, and the system decides whether they may. A multi-tenant SaaS platform breaks the shape. The vendor releases on its own cadence, to all customers at once, and the site's choice is not whether the change happens but whether the site is ready when it does. The quality system needs an intake for external change that mirrors what it does for internal proposals: vendor release notes treated as the raw material of an impact assessment, notification periods and sandbox access negotiated into the quality agreement before they are needed, and a standing decision about what the site does when a release lands that it has not finished assessing.
The assessable surface also shifts. The site cannot re-verify the vendor's codebase, so its own testing concentrates on what it controls and depends on: a regression suite covering the site's critical workflows and its own configurations, executed against each release in a non-production environment, with a documented acceptance decision before the change reaches production use. What fills the gap between that suite and the vendor's code is supplier assurance — and this is where the intersection quietly borrows from supplier quality: "the vendor tested it" is a claim about another company's quality system, and relying on it is only defensible if the vendor assessment established that the claim deserves reliance. A site that skipped the supplier audit and skips its own regression testing has no evidence at either end.
The eQMS: the system that carries its own change record
The eQMS gives this intersection a self-referential edge no other system has. The change request for a modification to the eQMS is itself a record in the eQMS, routed by the approval workflow being potentially modified. That is manageable — but only if the site has recognised that the eQMS's configuration is not administrative decoration. Approval matrices, workflow routings, e-signature meanings, mandatory fields, and record lifecycles are the site's procedures rendered executable: the configured workflow is the SOP, in the only form that actually constrains behaviour. Validating an eQMS is largely validating that configuration, which makes configuration changes the highest-value target of the change process — a routing change is a change to who may approve, and a field made optional is a change to what must be recorded.
The characteristic failure is configuration drift under an administration process invisible to quality. A role added through a helpdesk ticket, a workflow shortened to clear a backlog, a validation rule relaxed during an incident and never restored — each is a de facto procedural change that no one version-controlled, individually reasonable and collectively corrosive. Mature sites close the gap from both ends: configuration changes go through the same change discipline as any validated-system change, and a periodic configuration review reconciles the live settings against the validated specification, treating every unexplained difference as exactly what it is — an unassessed change discovered late.
Proportionality needs pre-decided anchors
ICH Q12 solved a problem for products that this intersection has for systems: when everything might matter, every change is either over-processed or under-assessed by guesswork. Its answer — identify in advance the established conditions, the elements that carry regulatory weight, and scale change management around them — translates directly. A validation package that explicitly marks which configurations, calculations, interfaces, and workflows are GxP-critical gives every future impact assessment its anchor: a change touching the marked set gets the full apparatus; a change provably outside it gets proportionate handling with the reasoning recorded. Without that map, assessment quality depends on whoever happens to be assessing, and the map in their head retires when they do.
ICH Q10 supplies the other half: change management is a pharmaceutical-quality-system element with a lifecycle, not a gate with a rubber stamp. That means effectiveness review for system changes — did the change achieve its intent without collateral effect, monitored over a defined period rather than assumed at closure — and it means feeding what post-implementation monitoring finds back into the risk assessment that scoped the next change. The eQMS makes this measurable in a way paper never did: change cycle times, emergency-change rates, changes reopened after closure, and configuration-drift findings are all lying in its tables, waiting to be read as the health metrics of the change system itself.
Derived from the 5 standards SPEQ maps to this intersection, across 4 regulatory bodies: FDA, EMA, ICH, ISPE.
FREQUENTLY ASKED
Does every software change require revalidation?
Every change requires assessment; only some require significant re-testing; almost none require repeating the original validation wholesale. The governing idea is that the validated state is maintained through the change process, not re-earned after each change: the impact assessment determines what the change could affect, verification is scaled to that reach and to the GxP-criticality of what it touches, and the documented chain of assessed changes is what lets the site claim the production system is still the validated one. Full revalidation is the remedy reserved for changes that undermine the basis of the original qualification — a platform migration, a major version replacement — or for the discovery that the chain itself is broken.
How should a site handle cloud vendor updates it cannot refuse?
By moving the control points to the places the site still owns. Before the subscription: a supplier assessment that establishes whether the vendor's release discipline deserves reliance, and contract terms securing advance notification, release notes, and a test environment. In steady state: a maintained regression suite covering the site's critical workflows and configurations, executed against each release before or promptly upon deployment, with a recorded acceptance decision. After each release: verification that site configurations survived, and a route into the deviation system if something did not. The site cannot control the vendor's cadence; it can control whether any release reaches GxP use unassessed — and that is the compliance claim that matters.
Are configuration changes real changes, or just administration?
In a configured system, configuration is behaviour — so a configuration change is as real as a code change and frequently more consequential. An approval routing decides who authorizes; a mandatory field decides what is recorded; a workflow state decides what can be skipped; an e-signature setting decides what a signature means. All of that was, or should have been, part of what validation verified, which makes altering it a change to the validated state by definition. The test for whether something is "just administration" is whether it can alter any GxP-relevant behaviour or record — and the honest answer for most settings in an eQMS or LIMS is yes. Sites that route configuration through change control stop having that argument record by record.
What does ICH Q12 have to do with computerized systems?
Nothing by scope, everything by structure. Q12 is a product-lifecycle guideline; it does not regulate software. But it solved the generalizable problem this intersection struggles with: proportionate change management is impossible until you have pre-declared which elements carry regulatory weight. Applied to a validated system, that means the validation package should identify the GxP-critical configurations, calculations, interfaces, and workflows explicitly — so that every subsequent impact assessment starts from an agreed map instead of an individual's recollection, and so that proportionate handling of low-impact changes is a defensible policy rather than quiet corner-cutting. The vocabulary is borrowed; the discipline it names is native to CSV.