ICH Q7 clause 13: Change control
The 8 audit questions covering clause 13, each with the objective evidence to request, the nonconformities most often raised against it and what to sample. Part of the free ICH Q7 API GMP audit checklist, which holds 350 items across 18 clauses.
All 8 questions for clause 13
Open any row for its objective evidence, common nonconformities and auditor tips. You can check items off as you go. This browser remembers your progress across all 18 clauses of this checklist.
§13 Change control
13.10 Is there a formal change control system covering all types of GMP-relevant changes?
- Change control master SOP
- Change control form template
- Change control database or log
- Scope definition covering all change types
- Change control workflow diagram
- Responsibilities matrix
- Training records on change control
- Integration with other quality systems (deviations, CAPA, validation)
- Change control system missing major change categories (e.g., software, analytical methods)
- Informal changes outside the system
- Change control limited to production processes only
- No tracking of changes across the organization
- Training on change control limited to key personnel
- Change control system not integrated with supplier management for raw material source changes
Change control is the quality system that prevents uncontrolled changes from degrading product quality. The system must cover ALL types of changes — not just process changes. Raw material suppliers, analytical methods, computer software updates, equipment modifications, label changes: all must flow through the same controlled process. The system requires documentation, review, and approval before implementation.
13.11 Are there written procedures defining how changes are proposed, evaluated, approved, and implemented?
- Change control SOP with defined workflow
- Change initiation procedure
- Review criteria by change type
- QA approval required for all GMP changes
- Implementation plans included with change requests
- Post-implementation effectiveness review procedure
- Change request form template
- Training for personnel on change procedures
- Changes approved without QA involvement
- No post-implementation effectiveness review
- Changes implemented before approval
- No defined review criteria
- Informal approvals bypassing the procedure
- Changes handled differently by different functions
- No escalation procedure when QA and production disagree on change disposition
The change control procedure must define the process step-by-step: who can initiate a change, how it's documented, who reviews (subject matter experts), who approves (including mandatory QA approval), how impacts are assessed, how the change is implemented with controls, and how effectiveness is verified. Missing post-implementation verification is a common gap — changes must actually be evaluated for effectiveness, not just implemented and forgotten.
13.12 Is each change evaluated for its potential impact on API quality?
- Impact assessment template with standard areas
- Classification procedure (minor, major, critical)
- Impact assessments on completed change records
- Regulatory impact assessment for changes
- Stability impact assessment
- Validation impact assessment
- Cross-functional impact review
- Linkage to change justification document
- Impact assessments are superficial or checkbox-only
- No classification system
- Regulatory impact not assessed
- Stability impact ignored
- Impact assessment by single function (not cross-functional)
- Assessment limited to direct impact, ignoring indirect effects
- Post-implementation effectiveness review deferred beyond the next scheduled APQR
Impact assessment is the heart of change control — a thorough assessment prevents changes from unexpectedly compromising quality. Standard impact areas to assess: validation status (does the process need revalidation?), specifications (do limits need to change?), stability (does new data need to be generated?), regulatory (does this require regulatory filing updates?), other systems (does this affect cleaning validation, training, etc.?). Classification helps scale the response — simple changes get simple handling; significant changes get comprehensive review.
13.13 Are changes classified by significance, with the level of evaluation matched to the risk?
- Classification procedure with criteria
- Classification examples for each level
- Classification decisions on completed changes
- Review criteria by classification
- Validation requirements by classification
- Regulatory notification triggers by classification
- Change complexity assessment
- Classification training
- Classification used to justify skipping proper assessment
- All changes classified as minor
- No clear criteria for classification
- Classification decisions not reviewed by QA
- Critical changes misclassified as major or minor
- Classification downgrade from major to minor lacks documented scientific justification
- Validation scope for changes determined without formal risk assessment methodology
Classification is NOT about making some changes easier to implement — it's about matching the response to the risk. Minor changes (e.g., formatting changes, editorial SOP updates) need documentation and approval but not impact studies. Major changes (process parameter modifications, equipment changes) need impact assessment and possibly validation. Critical changes (new process steps, new equipment types, specification changes) need comprehensive assessment and likely regulatory filings.
13.14 Are changes reviewed and approved by the quality unit?
- QA approval signatures on all change records
- QA authority defined in procedures
- QA reviewer qualification requirements
- QA independence from the change initiators
- Electronic workflow requiring QA approval
- Audit trail showing QA review before implementation
- Cases where QA rejected or required modifications
- QA training on change review
- Changes implemented before QA approval
- QA approval delegated to non-QA personnel
- QA approval routine rubber-stamping without review
- QA unable to reject changes due to organizational pressure
- Electronic systems allowing bypass of QA approval
- No escalation procedure when QA and production disagree on change disposition
QA approval is mandatory and cannot be delegated to production or R&D. The QA reviewer must be trained, independent, and has authority to reject changes. QA approval signifies that: (1) the impact assessment is adequate, (2) supporting data (if required) is sufficient, (3) implementation plan is appropriate, and (4) the change does not compromise quality. Electronic systems must enforce QA as a required approver for all GMP changes.
13.15 Do significant changes trigger appropriate additional testing and/or revalidation?
- Validation/testing plans within change records
- Revalidation records linked to changes
- Partial validation records for moderate changes
- Verification records for minor changes
- Stability program updates triggered by changes
- Analytical method verification post-change
- Documentation of testing/validation scope rationale
- Integration between change control and validation
- Significant changes without revalidation assessment
- Validation scope disproportionate to change significance
- No integration with validation system
- Changes implemented with validation planned but not executed
- Revalidation skipped with weak justification
- Validation scope for changes determined without formal risk assessment methodology
Significant changes can invalidate prior validation. The required response depends on the change magnitude: minor changes may need only verification runs; moderate changes may need partial revalidation; major changes may need full revalidation of affected steps or entire process. Stability programs may need to be re-initiated for changes affecting stability. Analytical methods may need verification or revalidation. The scope must be justified based on scientific assessment.
13.16 Is the first batch produced after a significant change evaluated for the change's effect?
- Post-implementation batch evaluation records
- Comparison data pre- and post-change
- Effectiveness review for each change
- CAPA records for changes with unintended effects
- Metrics for change effectiveness
- Review meetings for significant changes
- Rollback procedures for failed changes
- Post-implementation review SOP
- No post-implementation evaluation of first batches
- Effectiveness review not documented
- Unintended effects not investigated or captured
- Change considered closed at implementation with no follow-up
- No mechanism to roll back failed changes
- Post-implementation effectiveness review deferred beyond the next scheduled APQR
Post-implementation evaluation closes the change control loop. The first batch after the change should be scrutinized more carefully than routine batches. Comparison to pre-change batches reveals whether the change achieved its purpose and whether any unintended consequences occurred. If problems are found, the change may need to be reversed or modified. This evaluation is critical but often overlooked.
13.17 Are dosage-form (customer) manufacturers notified of changes that could affect API quality?
- Quality agreements with change notification clauses
- Customer change notification records
- Documented change notification decisions (what to notify vs not)
- Customer acknowledgment of notifications
- Notification timeframe compliance
- Customer impact assessments received back
- List of changes notified to customers
- Periodic review of customer notification effectiveness
- No quality agreements with customers
- Quality agreements without change notification clauses
- Significant changes implemented without customer notification
- Customer notifications sent after implementation
- Customer impact assessments ignored
- Customer change notification timeframe not defined in the quality agreement
API manufacturers supply dosage form manufacturers (drug product companies). Changes to the API process can affect the drug product — even changes that keep the API within specification. The dosage form manufacturer needs to know about significant changes so they can assess impact on their own process, stability, and regulatory filings. This is typically handled through quality agreements that specify what changes trigger notification and timeframes.
Each item shows its evidence, common nonconformities and auditor tips. The clause index has the PDF of all 350 items, formatted for a clipboard.
The rest of the ICH Q7 API GMP audit checklist
350 items across 18 clauses. Back to the clause index.