How to Manage a Change Control
Make a change deliberately — assessed, approved, and verified — not quietly.
What a how-to is not
A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.
Change control is how a regulated operation makes a change on purpose: assessed for impact, approved before implementation, and verified afterward. The failure modes are simple and common — implementing before approval, and missing the regulatory or validation impact of a change that looked small.
- 1
Describe the change and the rationale
State exactly what is changing (from what, to what) and why. A vague change description produces a vague impact assessment; be specific about scope.
- 2
Assess the impact
Determine what the change touches — product quality, validated state, specifications, the regulatory filing, other systems and documents. The impact assessment is where a "small" change reveals its real reach.
- 3
Risk-assess the change
Apply quality risk management (ICH Q9) proportionate to the impact. A change that touches product quality or the validated state earns more scrutiny than a like-for-like swap.
- 4
Define actions and approvals
List what must happen before and after the change — revalidation, document updates, training, regulatory notification — and route it for the required approvals. Approval precedes implementation, always.
- 5
Implement only after approval
Execute the change only once it is approved and the pre-implementation actions are complete. Implementing first and documenting later is the most common — and most damaging — change-control failure.
- 6
Verify, notify, and close
Confirm the change achieved its intent without adverse effect, complete the post-change actions, notify affected parties (including sponsors or customers where required), and close with the evidence traceable.
- !Implementing the change before it is approved.
- !Missing the regulatory-filing or validation impact of a change that looked minor.
- !No notification to affected sponsors, customers, or downstream systems.
- !Closing without verifying the change actually did what it was meant to.
How to Manage a Change Control: frequently asked questions
Common questions on manage a change control.
What is the difference between a change control and a deviation?
A change control is planned — you decide to change something and manage it before it happens. A deviation is unplanned — something departed from the approved way after the fact. Change control is proactive and prospective; deviation handling is reactive.
Why must approval come before implementation?
Because the whole point of change control is to assess and control impact before it reaches product or the validated state. Implementing first turns a controlled change into an unassessed one — and, if it affected quality, into a deviation. "Implement then document" is the classic finding.
What impact does a change assessment need to cover?
Everything the change could touch — product quality, the validated state, specifications, the regulatory filing, linked documents and systems, and training. The value of the assessment is that it surfaces the reach of a change that looked small on the form.
When does a change require regulatory notification?
When it affects a commitment in the marketing authorisation or filing — a process, specification, site, or method the regulator approved. Reporting categories (from prior-approval to notification) depend on the change’s significance; frameworks like ICH Q12 help classify what needs what.