Change Control

What change control actually is

Change control is the controlled process for proposing, assessing, approving, implementing, and verifying changes to anything that can affect a regulated outcome: GxP processes, equipment, facilities, materials, suppliers, methods, computerised systems, and the documents that govern them.

It's a permanent change to how something is done. Not a one-time deviation from how it's normally done (that's a planned deviation). Not a fix for something already broken (that's a CAPA). A new way of doing the thing, going forward.

Every modern quality framework treats change control as one of the load-bearing elements of the quality system. ICH Q10 lists change management as a system element alongside CAPA, deviations, and management review. ISO 13485 and EU GMP carry similar expectations. The reason they all do this is the same: most quality failures begin as well-intentioned changes nobody fully assessed before going live.

Why inspectors pay close attention to changes

If you're an inspector and you want to know how a quality system is really run, you don't ask for the SOP binder. You ask to see the last twelve change requests.

Change records show how the organization handles risk in practice. Were impacts assessed seriously? Was the approval path appropriate to the risk? Did training actually reach the people who do the work? Were related documents revised and routed? Is there evidence the change worked after go-live, or did it disappear into the system without follow-up?

Weak change control rarely shows up alone. It shows up in the next deviation, the next batch failure, the next 483 observation, because the same gap (no impact analysis, no training, no effectiveness check) is what let the trouble in.

Inspector perspective: a change request that says "low risk — no impact" with no analysis behind it tells an inspector one of two things. Either the change really was trivial and the program is good at right-sizing the work, or the change wasn't trivial and the team rushed it. The next ten changes in the log usually settle which.

What the rules and standards actually require

Change control sits in multiple regulations and standards, sometimes by that name and sometimes folded into broader quality system requirements. The references most often cited in findings:

• ICH Q10 §3.2.3 — Change Management System: the canonical pharmaceutical-quality-system reference. Risk-based evaluation, expert review, post-implementation evaluation, and management of regulatory commitments arising from the change.
• ICH Q9(R1) (Step 4, January 2023; EU GMP adoption effective July 2023): quality risk management principles apply to the impact assessment that drives change scope and depth. The R1 revision strengthens expectations on subjectivity and bias in risk assessment.
• ICH Q12: technical and regulatory considerations for pharmaceutical product lifecycle management. Introduces Established Conditions (what's registered) and Post-Approval Change Management Protocols.
• 21 CFR §211.100: written procedures for production and process control, including any changes.
• 21 CFR Part 820 — QMSR (effective February 2, 2026): incorporates ISO 13485:2016 by reference, including §7.3.9 (Control of design and development changes) and §4.2.4 (Control of documents). Under the former QSR (in force through February 1, 2026), §820.30(i) governed design changes and §820.40(b) governed document changes.
• EU GMP Chapter 1 §1.4(xvii): quality system element calling for a formal change management system.
• EU GMP Annex 15 §3 — Qualification and Validation: change control as part of the qualification and validation framework; defines when re-validation is needed.
• EU GMP Annex 11 §10: periodic evaluation of computerised systems including change management; supports §11.10(k) expectations on systems documentation.
• ISO 13485 §4.1.4: changes to the QMS shall be evaluated for their effect.
• ISO 13485 §7.3.9: design and development changes — identification, review, verification, validation, and approval before implementation.
• WHO TRS 1019, Annex 3: guidance on change management for pharmaceutical products.

The change request from idea to closure

A change moves through a recognizable shape, whether the system is paper or electronic:

• Initiation. Someone proposes the change with a description, a reason, and a target effective date. Could be an operator, a supervisor, an engineer, QA, regulatory, or the output of a CAPA.
• Impact assessment. The change is evaluated across quality, validation, registered scope, supplier and customer obligations, environmental health and safety, and training. ICH Q9(R1) principles apply. This is where the bulk of the thinking happens. Tick-box assessments fail at inspection.
• Classification. Based on the assessment, the change is classified (minor, major, critical, or by category aligned to the SOP). Classification drives the approval path and the depth of validation work that follows.
• Approval routing. Reviewers and approvers from the affected functions sign off in a controlled workflow. Each signature carries its meaning (review, approve, technical accept, regulatory accept) and the date. For electronic systems, this is Part 11 §11.50 and §11.70 territory.
• Implementation tasks. The work that has to happen before the change can go live: document revisions, training-on-change, supplier notifications, validation activities, equipment changes, system configuration. Tasks have owners, due dates, and evidence.
• Effective date. The change goes live, gated on all required tasks being complete. Affected production records, batch records, or system configurations start using the new version on this date.
• Effectiveness review. A defined period after go-live, the change is reviewed against the original objective. Did it work? Any unintended effects? Risk-based — a critical change gets operating data; a minor change might be a confirmation that the new SOP is in routine use.
• Closure. The change request is formally closed by an independent approver after effectiveness is confirmed. Open changes don't close themselves; closure is its own controlled step.

What good change control programs do

The programs that hold up at inspection share a few habits:

• Risk-based classification with teeth — the classification matrix is defined and applied honestly; minor classifications aren't used to shortcut the work
• Impact assessment is actual analysis — not a checklist of yes/no questions; cross-functional input, technical reasoning visible in the record
• No implementation before approval — the system blocks the effective-date trigger until all required approvals are recorded
• Linked documents — SOPs, specs, batch records, validation protocols affected by the change are linked from the change request
• Training-on-change before effective date — training tasks generated automatically for affected personnel; effective date can be gated on completion for high-risk changes
• Validation activities tracked — re-validation or verification work is part of the change record, not a separate parallel effort
• Supplier and customer notifications — where a quality agreement requires notification, the notification is captured and the response (or absence) documented
• Effectiveness review scheduled at approval — not added later; review date and criteria defined when the change is approved
• Closure is a controlled step — an open change with all implementation tasks done is not closed; effectiveness review must be performed and signed off
• Trending — counts of open changes, average cycle time, overdue effectiveness reviews, repeat areas — all feed Management Review

How Complere supports change control

A change request that holds up at inspection has impact analysis you can read, approvals from the right people in the right order, training to the staff who do the affected work, and an honest answer to "did this actually work?" Complere is built to run that shape of change control end-to-end, in one record, with the evidence captured as the change progresses rather than reconstructed afterwards.

When someone on your team raises a change, the request carries the proposal, the impact assessment across quality and validation and registered scope, the classification it earned, the documents it affects, and the training it requires — all in one record your reviewers, approvers, and an auditor can read end-to-end without opening five other systems. Larger changes can be broken into sub-changes with dependencies so the pieces land in the order your team intends, not in whatever order they happen to finish.

Approval routes are configurable to your classification matrix, not hard-coded. Each approval captures the approver's identity, the role they're signing under, the meaning of their signature (review, approve, technical accept, regulatory accept), and the moment they signed. Signatures are bound to the change record they were applied to. Templated change categories carry their own approval routes and impact-assessment fields so the depth of work matches the classification rather than the habits of whoever raised the request.

Training-on-change is generated from the request itself, not added as a side activity. Assignments flow to the affected staff with completion tracked back to the change. Effectiveness review is a separate, controlled step — closure can't happen until the review is recorded and signed off, so high-risk changes don't quietly close out without anyone confirming they worked. Cycle time, overdue items, and effectiveness pass rate roll up to dashboards your quality lead and your management review meeting can use.

Every action on the change request and its sub-changes is captured with who did it, when, and what they changed. The history can't be quietly edited or deleted. Your data stays in your own dedicated space and never mixes with another customer's.

For changes that affect the Complere platform itself, your team starts from the Vendor Validation Package rather than re-validating from scratch — the impact of a platform update scopes against the pre-built URS, IQ/OQ/PQ evidence, and traceability matrix you already hold.

What stays with your team is the program around the platform: deciding your classification thresholds, training your staff on what a real impact assessment looks like, and verifying at periodic review that the changes you've shipped are the changes your records show.

Terms related to change control

Change control connects to many other quality concepts. Explore related terms to build a complete picture.

• CAPA — CAPA actions often result in changes
• Document Control — document revisions tied to changes
• Training Management — training-on-change is highly inspected
• Risk Management — ICH Q9(R1) drives impact assessment
• Validation — many changes trigger re-validation
• Deviation — planned deviations vs changes
• Management Review — change metrics feed MR
• Change Control Module