ICH Q7 clause 12: Validation
The 30 audit questions covering clause 12, 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 30 questions for clause 12
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.
§12 Validation
12.10 Is there a documented overall validation policy (e.g., a validation master plan)?
- Validation Master Plan (VMP) document approved by QA and management
- VMP scope covering all validation types required for the facility
- Defined roles and responsibilities for validation activities
- Validation policy SOP outlining company approach
- Timeline or schedule for ongoing validation activities
- VMP review and revision history
- Integration with change control — VMP referenced in change assessments
- Training records for personnel involved in validation activities
- No Validation Master Plan or equivalent document
- VMP outdated — does not reflect current facility or processes
- VMP missing major validation categories (e.g., computerized systems, cleaning)
- Responsibilities not clearly assigned in the VMP
- No linkage between VMP and change control system
- VMP not cross-referenced during change control impact assessments
A written validation policy (typically called a Validation Master Plan or VMP) is foundational. It must cover all validation types and identify responsible parties. The VMP should define: scope (what is validated), approach (prospective, concurrent, retrospective), organization (roles and responsibilities), documentation standards, change control linkage, and review/revision cycle. Auditors will ask to see the VMP early in inspections. Missing or outdated VMPs are a common finding.
12.11 Are critical process steps identified (e.g., via risk assessment) and validated?
- Documented identification of critical process steps with rationale
- Critical Quality Attributes (CQAs) for the API
- Critical Process Parameters (CPPs) for each critical step
- Risk assessment document (FMEA or equivalent) supporting criticality decisions
- Process flow diagram highlighting critical steps
- Development reports documenting parameter range establishment
- Validation status table showing which steps are validated and why
- Change control records when criticality designations change
- No formal identification of critical vs. non-critical steps
- All steps treated equally — either all validated or none validated
- Critical steps identified without documented rationale
- CQAs and CPPs not defined
- Critical step designation not reviewed after process changes
- Criticality assessment not revisited after post-approval process modifications
Not every step in an API process requires formal validation — only those critical to API quality and purity. Critical steps are identified through risk assessment and development data. This is a risk-based approach consistent with ICH Q9. Critical Quality Attributes (CQAs) and Critical Process Parameters (CPPs) must be identified and documented. Steps affecting CQAs are candidates for validation. Non-critical steps still require control but not full validation. Auditors will want to see the critical step identification rationale.
12.12 Is process validation completed before commercial distribution, with concurrent validation justified only where appropriate?
- Prospective validation protocols completed before commercial distribution
- Validation completion reports approved by QA prior to release
- Justification documents for any concurrent validation approach used
- QA approval records for concurrent validation exceptions
- Timeline evidence showing validation completion before distribution
- SOP defining when each validation approach is acceptable
- Regulatory notifications where concurrent validation was used
- Retrospective validation justification (rare, for established historical processes only)
- Batches distributed before validation was completed
- Concurrent validation used routinely rather than as exception
- No documented justification for non-prospective validation
- Retrospective validation used for new products
- Validation protocol not complete at time of batch release
- QA sign-off date on validation report later than first commercial batch release
Prospective validation is the default and preferred approach: complete validation before distribution. Concurrent validation (releasing batches as validation proceeds) is only acceptable in specific circumstances such as limited production (e.g., orphan drugs, clinical materials) and must be fully justified and approved. Retrospective validation (using historical data) is not appropriate for new processes. Any deviation from prospective validation requires documented justification and QA approval.
12.20 Is each validation conducted under a pre-approved written protocol specifying critical steps and acceptance criteria?
- Approved validation protocols for all validated processes
- Protocol approval signatures from QA and other required functions
- Quantitative acceptance criteria for each critical parameter
- Number of validation runs specified (typically 3 minimum)
- Sampling plan with locations, frequency, and sample size
- Test methods referenced for each acceptance criterion
- Approval date preceding validation execution date
- Protocol version control within change management
- Validation performed without a pre-approved written protocol
- Protocols approved after validation execution began
- Acceptance criteria not quantitative or not measurable
- Critical steps not clearly identified in the protocol
- Sampling plan missing or inadequate
- Protocol and report dates show execution before protocol approval
Every validation must begin with a written protocol approved before execution. The protocol must specify: critical steps, acceptance criteria (quantitative where possible), validation type, number of runs, sampling plan, and test methods. QA approval of the protocol is mandatory before execution begins. The protocol serves as the plan against which the validation report demonstrates conformance. Post-hoc protocols (written after execution) are a serious deficiency.
12.21 Does each validation conclude with a report summarizing results and conclusions against the protocol?
- Validation reports cross-referenced to approved protocols
- Summary of all results against acceptance criteria
- Deviation documentation and resolution within the report
- Conclusion statement regarding process validation status
- QA approval signature on validation reports
- Cross-reference between protocol version and report version
- Recommendations for corrective actions where deficiencies identified
- Report distribution and retention per document control
- Validation completed without a final written report
- Reports missing QA approval signatures
- Deviations not documented or addressed in the report
- Report conclusions not supported by the actual data
- Protocol changes during execution not documented in the report
- Report approval date significantly after validation completion
The validation report documents the outcome of executing the protocol. It must: (1) cross-reference the protocol, (2) summarize all results against acceptance criteria, (3) document deviations with their resolutions, (4) draw conclusions about process suitability, and (5) recommend corrective actions if needed. QA approval of the report is required. The report is the formal record demonstrating that the process is validated and ready for routine production.
12.22 Are deviations from the validation protocol documented and assessed?
- Deviation log within validation reports
- Impact assessment for each deviation
- QA evaluation and approval of deviation dispositions
- Additional validation runs where deviations required them
- Protocol amendments with justification and approval
- Root cause analysis for significant deviations
- Corrective actions implemented before process use
- Trending of validation deviations across multiple studies
- Validation deviations not documented in reports
- Deviations dismissed without impact assessment
- Multiple deviations in a single validation not triggering additional runs
- No QA evaluation of deviation significance
- Validation declared successful despite unresolved deviations
- Deviation classification as minor without documented impact assessment on validation conclusion
Validation deviations are common and acceptable if properly documented and assessed. Each deviation must include: description, impact assessment, justification, and QA evaluation. Deviations that indicate process problems may require additional runs or protocol amendments. Auditors will scrutinize deviation handling — deviations that are dismissed without investigation are a significant finding. The key question is: does the deviation compromise the conclusion that the process is validated?
12.23 Is the validation report reviewed and approved by the quality unit?
- QA approval signatures on all validation reports
- Dated approval preceding commercial production start
- QA review checklist or criteria for validation report approval
- Training records for QA personnel who approve validation reports
- Linkage between validation approval and production authorization
- Process change control references validation approval status
- Validation status tracking in quality system
- QA oversight of ongoing validation status
- Validation reports without QA approval signatures
- Commercial production initiated before QA approval of validation
- QA approval delegated to non-QA personnel
- Validation approval dates after production batches were manufactured
- No tracking of validation status by quality unit
- Validation status not tracked in a central register accessible to production and QA
QA approval is the final gate before a validated process can be used commercially. QA must review the complete report, verify that all acceptance criteria were met (or deviations properly addressed), and formally approve the validated status. No batches should be produced for distribution until QA has approved the validation report. The approval should be a dated signature, not implicit or informal approval.
12.30 Is equipment qualified through an appropriate DQ/IQ/OQ/PQ sequence before process validation?
- DQ documentation for major equipment (user requirements vs. design specifications)
- IQ protocols and reports with installation verification checklists
- OQ protocols and reports demonstrating operation across ranges
- PQ protocols and reports with simulated or actual production runs
- Qualification status database or tracking system
- Requalification records after modifications or relocations
- Linkage between qualification and process validation activities
- Traceability from user requirements through to performance qualification
- Equipment in use without completed IQ/OQ/PQ
- Process validation performed before equipment qualification complete
- Missing qualification phases (e.g., OQ skipped)
- Qualification documents not linked to specific equipment assets
- No requalification after significant equipment modifications
- Requalification not triggered after critical equipment component replacement
Equipment qualification is the foundation that must precede process validation. The four-phase approach (DQ/IQ/OQ/PQ) is standard: DQ verifies design suitability (often done during equipment selection), IQ verifies correct installation, OQ verifies operation across specified ranges, PQ verifies sustained performance under simulated or actual production conditions. Each phase has its own protocol and report. Auditors will trace qualification from new equipment purchase through to commercial use, verifying the full sequence was performed.
12.40 Is prospective validation used as the default approach for new or modified processes?
- Prospective validation protocols for new or significantly changed processes
- Validation executed at commercial scale, not pilot
- Validation completed before commercial distribution
- Process parameters demonstrated within defined ranges across validation runs
- API quality attributes meeting specification across all runs
- Critical step validation with focus on quality-impacting operations
- Validation results demonstrating consistent API quality
- QA-approved validation reports before routine production
- Pilot-scale data used as if it were commercial validation
- Validation performed after commercial distribution began
- Non-critical steps validated while critical steps not validated
- Validation runs not executed under routine production conditions
- Process parameters in validation differ from intended commercial parameters
- Validation protocol acceptance criteria set at specification limits rather than tighter process capability limits
Prospective validation establishes that a new or modified process is capable before commercial use. It's conducted on commercial-scale equipment using the intended process. The protocol is written first, then executed, then reported. This provides the highest confidence that the process is reproducible and capable. For APIs, prospective validation is the default expectation — alternatives require specific justification.
12.41 Where concurrent validation is used, is it justified and limited to appropriate circumstances?
- Justification document for use of concurrent validation approach
- QA approval of concurrent validation strategy
- Each batch meeting specification independently
- Individual batch release records during validation period
- Accumulating validation data evaluated after each batch
- Protocol defining when concurrent validation is complete
- Documentation showing circumstances meet the exception criteria
- Transition to prospective validation approach once sufficient data exists
- Concurrent validation used for new products without exception justification
- Batches released before meeting specifications individually
- No QA approval of concurrent validation strategy
- Concurrent validation used as routine approach rather than exception
- No transition to standard validation after sufficient data accumulates
- Concurrent validation batches released before validation interim review
Concurrent validation allows batch-by-batch release while validation is ongoing. It's intended for specific circumstances: orphan drugs, low-volume APIs, or after minor process modifications. Each batch must meet specification on its own — you can't release a batch based on averaged data. QA must justify the use of concurrent validation and approve each batch's release. Concurrent validation is NOT a way to skip prospective validation for new processes.
12.42 Where retrospective validation is used, is it limited to established, stable processes with adequate historical data?
- Retrospective validation report with historical batch data analysis
- Documentation that process has been stable (no significant changes)
- Defined CQAs and CPPs for the established process
- Statistical analysis of historical data showing process capability
- In-process control data from historical batches
- Records showing no unexplained failures in the historical period
- Justification for retrospective approach over prospective
- QA approval of retrospective validation conclusions
- Retrospective validation used for new or recently changed processes
- Insufficient historical data (too few batches)
- Historical data shows variability or failures not addressed
- Significant changes in the historical period not acknowledged
- CQAs and CPPs not defined before retrospective analysis
- Retrospective data set selectively excludes outlier batches without documented rationale
Retrospective validation uses historical batch data to demonstrate that an established process is validated. It's only acceptable for processes that have been stable and well-controlled historically. Requirements: no significant changes, defined CQAs and CPPs, established in-process controls, no unexplained failures. Typically 10-30 consecutive batches of historical data are analyzed. Retrospective validation is NOT appropriate for new processes or as a substitute for prospective validation.
12.43 Is the number of validation batches sufficient and scientifically justified?
- Validation protocol specifying number of runs and rationale
- At least 3 consecutive successful batches for traditional validation
- Statistical justification where fewer batches are used with enhanced testing
- Bracketing or matrix design documentation where applicable
- Additional runs performed when initial batches showed variability
- Written rationale for run selection
- Consistency demonstrated across all validation runs
- QA approval of the selected validation design
- Fewer than 3 batches used without scientific justification
- Validation runs not consecutive — gaps raising concerns about process stability
- Initial batches failed but later batches used for validation without addressing causes
- Number of runs not justified in the protocol
- Matrix or bracketing approach used without statistical support
- Validation runs interrupted by equipment downtime treated as single continuous runs
Three consecutive successful batches is the traditional minimum, but modern validation allows flexibility with scientific justification. Alternative approaches include: bracketing (validating at extremes of ranges), matrix design (systematic combinations of variables), or reduced batches with enhanced statistical analysis. Whatever approach is chosen must be documented with rationale. The three-batch rule is a minimum — more batches may be needed for complex processes or when initial batches show variability.
12.44 Are critical process parameters identified and controlled during validation?
- Documented list of Critical Process Parameters (CPPs) for each process
- Defined operating ranges for each CPP
- Development studies supporting CPP identification
- Risk assessment (FMEA or similar) identifying CPPs
- Validation data showing consistent operation within CPP ranges
- Master batch records specifying CPP ranges and control methods
- Distinction between CPPs and non-critical parameters documented
- CPP monitoring data during validation runs
- No formal identification of CPPs
- CPPs identified without development data support
- Operating ranges too narrow (operational risk) or too wide (quality risk)
- Validation did not demonstrate operation across full CPP range
- Master batch records do not specify CPP control requirements
- CPP ranges established from development data without verification at commercial scale
CPPs are the parameters that must be controlled to ensure API quality. Examples: reaction temperature, pH, addition rate, agitation speed, crystallization temperature, drying time/temperature. CPPs are identified through development studies and risk assessment. Each CPP must have a defined operating range. Validation demonstrates that the process consistently produces acceptable API when operating within these ranges. CPPs differ from non-critical parameters which don't directly affect CQAs.
12.45 Do validation studies challenge the process at worst-case (edge-of-range) conditions where appropriate?
- Identification of worst case conditions for validation
- Scientific justification for worst case parameter selection
- Validation runs executed at worst case conditions
- Demonstration of API quality under worst case conditions
- Cleaning validation under worst case soiling conditions
- Bracketing validation designs capturing worst case
- Risk assessment supporting worst case selection
- Protocol documentation of worst case rationale
- Worst case conditions not evaluated in validation
- Worst case selection without scientific justification
- Validation conducted only at nominal conditions despite known variability
- Cleaning validation without worst case residue or bioburden
- Worst case parameters misidentified (insufficient challenge)
- Worst case parameter combinations not tested together in a single validation run
Worst case testing challenges the process at the edges of acceptable operation. Examples: highest/lowest acceptable reaction temperatures, shortest/longest acceptable reaction times, highest impurity load in raw materials. If the process works under worst case conditions, routine production should easily maintain quality. Worst case selection must be based on process understanding — choosing the wrong parameters provides false assurance. This is particularly important for cleaning validation and sterilization processes.
12.50 Are at least three consecutive successful runs (or a justified alternative) used for prospective and concurrent validation?
- Process validation program document
- At least 3 consecutive successful batches per validation study
- Justification for additional batches where applicable
- Complete validation report for each validation batch
- Consistency demonstrated across all validation runs
- Failed validation batches investigated and handled per procedure
- Statistical analysis of validation data
- Validation status tracking for all validated processes
- Validation declared complete with fewer than 3 successful batches
- Non-consecutive batches counted toward validation
- Failed batches excluded from validation count without investigation
- No consideration of process complexity in batch count decision
- Inconsistent results across validation batches not investigated
- Revalidation triggered by change control but deferred indefinitely without risk assessment
- Process revalidation not triggered after equipment major overhaul affecting critical process parameters
Three consecutive successful batches is the minimum baseline for prospective and concurrent validation. 'Consecutive' means no intervening failed batches. 'Successful' means meeting all acceptance criteria. Complex processes (multi-step syntheses, long processing times, high variability) may require additional runs. The rationale for the number of runs should be documented in the protocol. Validation failures restart the count — you can't count 3 successful runs if there was a failure in between without investigation.
12.51 Where validation results show significant variability, are additional runs performed?
- Statistical analysis of validation data identifying variability
- Investigation of significant variability observed during validation
- Additional batches executed when variability warranted investigation
- Root cause analysis for variability
- Process modifications or additional controls implemented
- Before/after comparison when controls added
- QA evaluation of whether variability affects process reliability
- Documentation of variability acceptance decisions
- Validation declared complete despite visible variability trends
- Variability not statistically analyzed
- Root cause of variability not investigated
- Additional batches not added when variability suggested need
- Process with capability near specification limits not triggering review
- Periodic revalidation schedule not linked to Annual Product Quality Review findings
Variability within acceptance criteria may still indicate a process that's not reliably in control. If validation batches show different levels of impurities, yields, or quality attributes (even while all passing), investigation is warranted. Additional batches may be needed to demonstrate that the process is genuinely consistent. This clause protects against declaring validation 'successful' when data actually shows a process with hidden variability that could eventually lead to failures.
12.52 Is enhanced in-process and final testing performed during validation against defined acceptance criteria?
- Enhanced sampling plan specifying additional in-process testing
- In-process data throughout validation runs showing CPP compliance
- Final API testing meeting all specifications for each validation batch
- CQA data demonstrating consistency across validation batches
- Statistical comparison of validation data to development data
- Additional analytical testing beyond routine release panel
- Extended sampling at critical points in the process
- Validation report documenting both in-process and final data
- Validation sampling identical to routine production (no enhanced testing)
- In-process data not reviewed during validation assessment
- Final API testing showing results at or beyond specification limits
- CQA data not specifically tracked during validation
- No comparison of validation data to development baseline
- Continuous process verification data not statistically evaluated for trend shifts
Validation testing goes beyond routine in-process controls. Enhanced sampling and testing during validation documents that: (1) CPPs are maintained throughout the process, (2) intermediate quality is consistent, (3) final API meets all specifications. This enhanced data set supports the validation conclusion and provides the baseline against which routine production is compared. Validation without enhanced testing is essentially routine production with a pretty name.
12.60 Are validated systems periodically evaluated to confirm they remain in a validated state?
- Periodic validation review procedure with defined frequency
- Annual or scheduled validation status reports
- Review of changes, deviations, complaints during period
- Trending data analysis for validated parameters
- Risk-based review frequency justification
- Linkage with Annual Product Quality Review (clause 2.50)
- Actions taken when review identified issues
- Documentation of review conclusions and recommendations
- No periodic review of validation status
- Periodic review is only a paperwork exercise without real data analysis
- No integration between validation review and APQR
- Review frequency not risk-based
- Accumulated changes not formally evaluated for validation impact
- Cleaning agents not qualified for compatibility with equipment materials of construction
Validation is not a one-time event. Periodic review (typically annually) confirms that validated processes, equipment, and systems continue to operate as validated. The review must consider: accumulated changes, monitoring trends, deviations, complaints, out-of-specifications. Risk-based frequency allows more frequent review for critical systems. This clause links to Annual Product Quality Review (clause 2.50) which also evaluates process performance.
12.61 Does periodic review confirm that no significant (including cumulative) changes have invalidated the validated state?
- Periodic review assessing all changes since last validation
- Change control records integrated into validation review
- Risk assessment for cumulative change impact
- Decisions on revalidation scope (partial or full)
- Revalidation records where triggered by change review
- Links between change control system and validation status
- QA approval of validation maintenance decisions
- Documentation of rationale when no action is taken despite changes
- Accumulated changes not evaluated for validation impact
- Significant changes without revalidation or justified rationale
- Periodic review finds issues but no action taken
- No linkage between change control and validation review
- Risk assessments superficial or missing
- Dirty hold time validation data not available for maximum production campaign length
Changes accumulate over time — individually minor changes can collectively alter the validated state. Periodic review must assess cumulative change impact. Significant changes that trigger revalidation include: new raw material source, equipment replacement, process parameter modifications, facility changes, new suppliers for key materials. The decision between 'no action,' 'limited revalidation,' and 'full revalidation' requires risk assessment. Change control process (Section 13) feeds this evaluation.
12.70 Are cleaning procedures validated to demonstrate effective residue removal?
- Cleaning validation protocol for each cleaning procedure
- Cleaning validation reports demonstrating residue removal
- Residue limits calculated based on scientific rationale
- Analytical methods for residue detection validated
- Cleaning procedures for each piece of equipment documented
- Risk assessment prioritizing cleaning validation by cross-contamination risk
- Visual inspection as part of cleaning verification
- Worst case product identification for cleaning validation
- Cleaning procedures in use without validation
- Cleaning validation limited to visual inspection only
- Residue limits not scientifically justified (e.g., arbitrary values)
- Analytical methods for cleaning validation not validated
- No risk-based prioritization — all equipment treated identically
- Cleaning validation not updated after equipment or product changes
- Validation scope for changes determined without formal risk assessment methodology
Cleaning validation is mandatory for equipment used in API manufacture. The validation must demonstrate that residues (previous product, degradation products, detergents, microbial contamination) are removed to scientifically justified levels. The focus is risk-based — greatest attention to equipment with highest cross-contamination risk (e.g., shared equipment between different APIs). Cleaning validation is one of the most frequently cited topics in FDA inspections of API manufacturers.
12.71 Are cleaning residue limits established on a scientific (e.g., dose- or toxicity-based) basis?
- Residue limit calculation document with scientific rationale
- Health-based limits (PDE/ADE) where toxicological data is available
- Dose-based calculations where using traditional approach
- Safety factors applied and justified
- Worst-case scenario considered (smallest next batch, largest previous dose)
- Analytical method sensitivity supporting the limit
- Peer review or expert assessment of limit calculations
- Documentation of assumptions in the calculation
- Arbitrary residue limits (e.g., 10 ppm without calculation)
- Limits set at analytical method sensitivity rather than calculated
- No worst-case consideration (average dose used instead of smallest)
- Toxicological data available but not used for limit derivation
- Safety factors not applied or not justified
- TOC limit calculation not scientifically justified for the specific API residue
Residue limits must be scientifically derived — not arbitrary. The traditional approach uses dose-based calculation: acceptable residue = (smallest therapeutic dose of previous product × safety factor) / (largest daily dose of next product × batch size). Modern approaches per EMA/PDA use Permitted Daily Exposure (PDE) or Acceptable Daily Exposure (ADE) based on toxicological data. Health-based limits are preferred where toxicological data is available. The limit must be achievable by the cleaning procedure and verifiable by the analytical method.
12.72 Are cleaning-validation sampling methods (swab and/or rinse) shown to recover residues reliably?
- Sampling method documentation for cleaning validation
- Recovery studies for swab sampling with calculated recovery factors
- Recovery studies for rinse sampling where applicable
- Swabbing technique SOP with standardized procedure
- Sampling locations documented on equipment diagrams
- Recovery factors applied in residue calculations
- Sample stability studies if not tested immediately
- Training records for personnel performing cleaning validation sampling
- Sampling performed without recovery studies
- Recovery factors not applied to results
- Low recovery factors (<50%) accepted without justification
- Sampling locations not representative of worst-case residue areas
- Inconsistent swabbing technique between samples
- Swab recovery factor not validated for the specific equipment surface material
Cleaning validation sampling must recover residues reliably from equipment surfaces. Swab sampling is for small, accessible areas (direct surface contact). Rinse sampling is for large vessels and hard-to-reach areas (collects residues from all surfaces). Both have recovery challenges that must be quantified. Recovery studies demonstrate what percentage of known residue the sampling method recovers — this factor is applied to calculate actual residue levels from measured values. Recovery below 50% typically requires method improvement.
12.73 Are dirty and clean hold times validated, including for infrequent production?
- Dirty hold time validation data for maximum allowable time
- Clean hold time validation with microbiological and/or chemical monitoring
- Maximum hold times documented in cleaning SOPs
- Covered equipment protocols during clean hold periods
- Environmental monitoring during clean hold validation
- Risk assessment for infrequent production scenarios
- Periodic verification of hold times with aging data
- Change control when hold times are modified
- Hold times used in production but not validated
- Dirty hold time exceeded without revalidation
- Clean hold time without microbial verification
- Equipment stored open after cleaning without validation
- Hold times inconsistent between SOPs and validated data
- Visual inspection used as sole acceptance criterion for complex equipment geometries
Two hold times must be validated: (1) dirty hold time — how long can equipment sit unclean before cleaning becomes difficult, and (2) clean hold time — how long can cleaned equipment sit before it may become contaminated again. Both have practical implications for production scheduling. Dirty hold time validation simulates worst-case (longest) time and demonstrates cleaning still works. Clean hold time validation demonstrates equipment remains clean during the maximum allowable hold period.
12.74 Are validated hold times between cleaning and reuse incorporated into procedures?
- Validated hold time study reports
- Incorporation of hold times in cleaning SOPs
- Batch record provisions enforcing hold time limits
- Scheduling system that respects hold time constraints
- Deviation handling for hold time exceedances
- Training on hold time requirements
- Visual or analytical evidence of equipment cleanliness at hold time limits
- Comparison of hold time limits across similar equipment
- Hold times not documented in procedures
- Production scheduling exceeds validated hold times
- Deviations from hold times not investigated
- Operators unaware of hold time requirements
- Hold times not revalidated after process changes
- Worst-case product selection for cleaning validation not reassessed after new product introduction
Reinforces clause 12.73 with specific emphasis on incorporating validated hold times into written procedures. Hold time validation must show that: (1) residues remain removable after the dirty hold period, and (2) cleaned equipment remains within cleanliness limits during the clean hold period. Written procedures (batch records, SOPs, schedulers) must enforce these validated limits. Operational flexibility is important — validated hold times provide the envelope for production planning.
12.75 For shared equipment, is a worst-case product approach used and justified for cleaning validation?
- Worst-case product selection document with rationale
- Comparison of all products manufactured on shared equipment
- Solubility, toxicity, potency data supporting selection
- Cleaning validation performed with worst-case product
- Matrix or grouping strategy for similar products
- Documentation extending validation conclusions to other products
- Periodic reassessment of worst-case selection as product portfolio changes
- Risk assessment for new products added to shared equipment
- Worst-case selection without documented rationale
- New products added without reassessing worst-case selection
- Worst-case basis (solubility, toxicity) not scientifically supported
- Validation conclusions extended without justification
- Mismatched product groupings (e.g., different therapeutic classes)
- Bioburden limits for clean equipment hold not established or not tested
For shared equipment manufacturing multiple APIs, validating cleaning for every product-to-product combination is impractical. Worst-case product approach reduces validation scope by identifying the hardest-to-clean product. If cleaning works for the worst case, it will work for all others. Worst case is typically selected based on: (1) lowest solubility in cleaning solvent, (2) highest toxicity (lower acceptable residue), (3) highest potency, (4) most difficult to clean based on physical/chemical properties. Documentation of the selection rationale is critical.
12.76 For dedicated equipment, is any reduced (e.g., visual-clean) cleaning approach justified?
- Dedicated equipment designation documented
- Reduced cleaning validation approach justification
- Visual clean inspection procedure and criteria
- Degradation product assessment for dedicated equipment
- Cleaning agent residue testing even for dedicated equipment
- Microbiological monitoring program
- Campaign length limits for dedicated equipment
- Periodic verification of the visual clean adequacy
- Dedicated equipment with no cleaning validation at all
- Visual clean approach without considering degradation or cleaning agent residues
- No microbial monitoring on dedicated equipment
- Dedicated equipment used for multiple products without re-designation
- Reduced approach without formal justification
- Cleaning validation campaign approach not justified with supporting scientific rationale
Dedicated equipment (used for only one product) presents lower cross-contamination risk, allowing reduced cleaning validation. Visual clean inspection may replace analytical testing for product residues. However, three concerns remain: (1) degradation products that could accumulate over time, (2) cleaning agent residues that must still be removed, (3) microbial contamination that can occur regardless of dedication. The reduced approach must be formally justified and documented.
12.80 Are non-compendial analytical methods validated for the appropriate parameters (accuracy, precision, specificity, linearity)?
- Analytical method validation reports per ICH Q2
- Validation protocols with pre-defined acceptance criteria
- Accuracy data (recovery studies at multiple concentrations)
- Precision data (repeatability and intermediate precision)
- Specificity data (interference assessment)
- Linearity data across working range
- LOD/LOQ for impurity and trace methods
- Robustness studies for variable method parameters
- Ruggedness studies (different analysts, instruments, days)
- Non-compendial methods used without validation
- Validation missing parameters appropriate for the method type
- Acceptance criteria defined after data collection
- No robustness assessment for critical methods
- Validation data does not cover the specification range
- Linearity forced through origin when it should not be
Non-compendial analytical methods must be fully validated per ICH Q2 parameters. The specific parameters evaluated depend on the method type: identity tests need specificity; quantitative assays need accuracy, precision, and linearity; impurity tests need sensitivity (LOD/LOQ), specificity, and linearity. Robustness and ruggedness (reproducibility across laboratories/analysts) are increasingly expected. Validation protocols should specify acceptance criteria before execution.
12.81 Are compendial methods verified as suitable in the actual matrix rather than fully revalidated?
- Compendial method verification reports for each API matrix
- Verification protocol with pre-defined scope
- Specificity verification for the specific API
- System suitability data from verification
- Accuracy/precision verification for quantitative methods
- Justification document for verification scope
- Compendial method current edition referenced
- Distinction between 'verification' (for compendial) and 'validation' (for modified)
- Compendial methods used without any verification
- Modified compendial methods treated as verified (should be fully validated)
- Verification scope insufficient for method complexity
- Outdated pharmacopoeia editions referenced
- No documentation of verification rationale
- Intermediate precision not assessed during method validation
- Compendial method verification scope insufficient to demonstrate suitability in the specific API matrix
Pharmacopeial methods are pre-validated by the pharmacopoeia but must still be verified in the specific API matrix. Verification is a subset of full validation — typically specificity and system suitability for most methods, plus accuracy/precision for quantitative methods. The verification scope should be risk-based: simple identity tests need minimal verification, complex impurity methods need more. USP <1226> and EP 2.1.14 provide verification guidance. Modified compendial methods require full validation, not just verification.
12.82 Are analytical methods periodically reviewed for continued suitability?
- Annual analytical method review procedure
- System suitability trending reports for each method
- OOS frequency analysis by method
- Method-related deviation summary
- Annual method review reports with conclusions
- Actions taken where methods showed degraded performance
- Revalidation records triggered by periodic review
- Integration with Annual Product Quality Review
- No periodic method review program
- Method performance degradation not acted upon
- System suitability failures repeatedly ignored
- Method reviews are pro forma without real analysis
- No linkage between method review and revalidation decisions
- No procedure for evaluating impact of pharmacopeia supplement revisions on existing methods
- Method transfer acceptance criteria wider than original validation criteria
Analytical methods drift over time due to instrument aging, reference standard changes, reagent variability, and shifts in API manufacturing. Periodic review (typically annual) assesses method health by examining system suitability trends, failure rates, and analyst feedback. Methods showing degraded performance should be revalidated or replaced. This clause links to the concept of analytical method lifecycle management per USP <1220>.
12.83 Is an analytical method revalidated, to an appropriate extent, when significant changes are made?
- Change control records linked to method revalidation assessments
- Revalidation protocol and report for significant changes
- Partial revalidation records for minor changes
- Risk assessment determining revalidation scope
- Method change history showing revalidation triggers
- Documentation when change determined not to require revalidation
- QA approval of revalidation scope decisions
- Integration of method revalidation with change control system
- Method changes made without revalidation assessment
- Significant method changes with only minimal revalidation
- No documentation of revalidation scope rationale
- Change control system does not trigger method revalidation review
- Method performance degradation after change without revalidation
- Robustness not assessed for method parameters identified as critical during validation
Method revalidation is triggered by significant changes. The revalidation scope depends on the change: minor changes may require only verification of the affected parameter; significant changes may require full revalidation. Common triggers: new column supplier/type, mobile phase change, instrument model change, new reference standard lot, API process changes affecting impurity profile. Change control system must trigger method revalidation assessment, not just process revalidation.
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.