Change control risk assessment: how to make it defensible to an inspector

Most change control records contain a risk assessment. Far fewer contain one that an inspector would accept as evidence that someone actually thought about the change. The usual version is a tick box that says 'low risk', a one line justification copied from the last change, and an approval signature from the person who proposed it.

This guide sets out what the risk assessment in a change control is for, which questions it must answer, how to rate the outcome without hiding behind a scoring matrix, and how to connect it to CAPA when the change is itself a corrective action. It is written for the people who raise, assess and approve changes, not for the regulatory affairs team.

What the risk assessment is for

The purpose of a change control system, as described in ICH Q10 and the EU GMP guidance on quality risk management, is to evaluate, approve and implement changes in a way that keeps the product and the validated state under control. The risk assessment is the step that decides how much scrutiny the change gets: which functions must review it, what testing or validation is needed, whether authorities must be notified, and what monitoring follows implementation.

That makes it a decision tool, not a form. If the assessment would have come out the same whatever the change was, it is not doing its job. Inspectors test exactly this by picking two unrelated changes and comparing the assessments side by side.

Start with a precise description of the change

A risk assessment can only be as good as the description it assesses. 'Update SOP' or 'replace pump' cannot be assessed. A usable description states what is changing from what to what, where it applies (site, line, product, system), why the change is being made, and what is deliberately not changing.

• Current state and proposed state, in specific terms (part number, set point, version, supplier, location).
• Scope: which products, batches, equipment, systems and documents are touched.
• Reason: the deviation, CAPA, audit finding, supplier notice or business driver behind it.
• Timing: planned implementation date and whether any batches are in progress.
• Temporary or permanent. Temporary changes are often the least controlled and the most cited.

The impact questions that must be answered

Work through a fixed set of impact questions every time, and require a written answer to each, including 'no impact' with a reason. The list below is a practical minimum. Your own procedure should add questions that reflect your products and systems.

1. Product quality: could the change affect identity, strength, purity, stability, sterility or any critical quality attribute?
2. Process: does it touch a critical process parameter, a critical material attribute or the control strategy?
3. Validated state: does it require requalification, revalidation, cleaning validation review or method verification?
4. Regulatory: does it alter anything described in the marketing authorisation or a registration file, and who decides that?
5. Data and systems: does it affect a computerised system, its configuration, interfaces, audit trail or electronic records?
6. Documents and training: which SOPs, batch records, specifications and training matrices must change before go-live?
7. Suppliers and contract partners: do quality agreements, specifications or notification duties apply?
8. Patient and supply: could the change affect patient safety, availability or an existing commitment?
9. Other changes and deviations: is it linked to, or does it overlap with, anything open?

Rating the risk without hiding behind a matrix

Many sites use a severity, probability and detectability matrix. That is fine, as long as the rating is justified rather than calculated. A score of 6 means nothing to an inspector unless the record explains why severity was rated as it was and what evidence supports the probability.

• Rate severity by the worst credible consequence for the patient or the product, not by how inconvenient the change is.
• Base probability on evidence: similar past changes, supplier data, development or pilot results, not optimism.
• Give detectability credit only for controls that actually exist and would catch the failure before release.
• State assumptions explicitly. If the rating depends on a pilot batch passing, say so, and make that a condition of approval.
• Do not let the risk rating decide the classification alone. Some changes are major because of regulatory or validation impact even when the technical risk is low.

ICH Q9 describes the underlying principle: the level of effort, formality and documentation of a risk assessment should be proportionate to the level of risk. A trivial change deserves a short assessment. A change to a sterile process deserves a thorough one. Proportionality has to be visible in the record, not assumed.

Weak versus defensible: a worked example

When the change comes from a CAPA

A corrective or preventive action often needs a change, for example a revised SOP, a new check on a batch record or an equipment modification. Link the two records in both directions. The change control should cite the CAPA, and the CAPA should not be closed as implemented until the change is closed and effective. Inspectors regularly find CAPAs closed on the date the change was approved, long before anything was actually changed.

The risk assessment for a CAPA-driven change should also ask whether the change itself could create a new failure mode. A new verification step that is easy to skip, or a procedure that adds a handwritten transcription, can introduce the next deviation. Our guide on human error in root cause analysis explains why corrective actions that depend on people remembering something tend to fail, and how to design controls that do not.

Implementation, verification and closure

The assessment sets conditions, and the change cannot be closed until those conditions have been met. Implementation should be traceable: what was done, when, by whom, and against which version of each document. Verification checks that the change did what it was meant to do and nothing else. For changes touching data systems, confirming that the audit trail captured the configuration change is part of that check, as described in our audit trail review checklist.

• Documents effective and training complete before the change goes live, not after.
• Any validation or qualification work finished and approved before routine use.
• Affected batches in progress identified, with a documented decision on how they are handled.
• A defined effectiveness check, with a date and an owner, for anything more than a trivial change.
• Closure by QA only once every condition of approval is evidenced.

Pre-approval checklist

1. Is the change described precisely enough that someone else could implement it from the record?
2. Was every impact question answered, including the 'no impact' answers, with a reason?
3. Were the right functions consulted, and does the record show who answered what?
4. Is the risk rating justified in words, with evidence and assumptions stated?
5. Is the classification (minor, major, regulatory) consistent with the assessed impact?
6. Are conditions of approval written as concrete, checkable actions with owners and dates?
7. Is the link to any originating deviation or CAPA recorded in both directions?
8. Has a defined effectiveness check been scheduled?

Common inspection observations

• Identical risk assessment text across unrelated changes.
• Risk assessment completed by the proposer alone, with no input from affected functions.
• Changes implemented before approval, then documented retrospectively.
• Temporary changes with no end date or review.
• Regulatory impact assessed by someone without access to the registration file.
• No evidence that conditions of approval were ever checked.

If your change control records show the same weaknesses, the fix is rarely a better template. It is clearer ownership of each impact question, a short training for those who assess changes, and QA review that reads the reasoning and not only the signatures. The Change Control course on this site covers the full lifecycle, and the CAPA and root cause course covers the linked corrective actions.

Frequently asked questions