ICH Q7 clause 11: Laboratory controls
The 33 audit questions covering clause 11, 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 33 questions for clause 11
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.
§11 Laboratory controls
11.10 Does the quality unit have independent access to adequate laboratory facilities (in-house or qualified contract)?
- Organizational chart showing QU independent from production
- Laboratory facility description and capability listing
- Contract laboratory qualification procedure and audit reports
- Written sampling plan with scientific rationale
- Contract lab quality agreements defining scope and responsibilities
- Quality unit job descriptions showing laboratory competency requirements
- Annual contract lab performance reviews
- Access control records for laboratory facilities
- QU reports to production management — lack of independence
- No contract lab qualification procedure despite outsourced testing
- Sampling plan based on convenience rather than scientific rationale
- Contract lab audit not performed or significantly overdue
- Laboratory facilities inadequate for required testing scope
- Contract laboratory results accepted without periodic comparison to in-house data
The QU must have independent access to labs — either in-house or contracted. If using contract labs, the QU must qualify them through audits and ensure they use validated methods. Independence from production is critical: QU cannot report to production management. Auditors should verify organizational charts showing QU independence, contract lab qualification records, and sampling plan documentation.
11.11 Are analytical methods scientifically sound and validated or verified as suitable?
- Analytical method validation reports per ICH Q2 parameters
- Method verification protocols and reports for compendial methods
- Method validation summary showing all parameters assessed
- Validation data supporting method performance at specification limits
- System suitability criteria defined and applied for each method
- Method transfer protocols and reports when methods are moved between labs
- Periodic method performance review data (trending of system suitability)
- Written validation/verification procedures
- Analytical methods used without validation or verification documentation
- Validation data does not cover the specification range
- No system suitability criteria defined or consistently failing system suitability
- Method transfer not performed when testing moved to a different laboratory
- Validation performed but not updated after significant method or matrix changes
- Intermediate precision not assessed during method validation
- Contract manufacturer re-qualification audits deferred without documented risk-based justification
Every analytical method used must be validated (for non-compendial methods) or verified (for compendial methods per clause 12.81). Validation must demonstrate fitness for purpose in the specific API matrix. Common validation parameters include accuracy, precision (repeatability and intermediate precision), specificity, linearity, range, detection limit, and quantitation limit per ICH Q2. Auditors should review method validation reports and verify that validation data supports the method's use at the specification limits.
11.12 Where pharmacopeial methods are used, are they verified as suitable in the actual API matrix?
- Method register listing all methods with compendial/in-house classification
- Compendial method verification reports for each API and intermediate
- Documentation of current pharmacopeia editions in use (USP, EP, JP)
- Validation reports for modified compendial methods
- In-house method validation reports where no compendial method exists
- Pharmacopeia subscription and update procedure
- Assessment of pharmacopeia updates for impact on existing methods
- Justification documents for non-compendial method choices
- Compendial methods used without product-specific verification
- Outdated pharmacopeia editions referenced in methods
- Modified compendial methods treated as verified rather than requiring full validation
- No assessment of pharmacopeia updates for impact on testing
- In-house methods used where suitable compendial methods exist without justification
- No procedure for evaluating impact of pharmacopeia supplement revisions on existing methods
- Compendial method verification scope insufficient to demonstrate suitability in the specific API matrix
- Method transfer acceptance criteria wider than original validation criteria
- Robustness not assessed for method parameters identified as critical during validation
Pharmacopeial methods carry regulatory presumption of suitability but must still be verified in the specific API matrix. Verification is less extensive than full validation but must demonstrate that the method works as intended for the specific product. Modified compendial methods require full validation since they are no longer considered compendial. Auditors should check whether the pharmacopeia edition referenced is current and whether verification data is product-specific.
11.13 Is all laboratory testing documented contemporaneously with complete supporting data?
- Laboratory records with all 9 required documentation elements
- Contemporaneous entries (data recorded at time of testing)
- Raw data (chromatograms, spectra, instrument printouts) retained and traceable
- Dual signatures (analyst and reviewer) on all lab records
- Written test procedures available at point of testing
- Sample log with unique identification for each test sample
- Instrument use logs correlating test times with instrument data files
- Periodic GDP audit results for laboratory records
- Lab results recorded from memory rather than contemporaneously
- Raw data (chromatograms, spectra) not retained or not traceable to test record
- Missing reviewer signature on analytical data
- Calculations not documented with formulas and input values
- Test method reference missing from laboratory records
- Instrument use log timestamps inconsistent with batch record timelines
Extends the GDP requirements of Section 6.15 specifically to laboratory activities. The clause mandates contemporaneous recording of all analytical data with full traceability. Every test record must include the nine listed elements. 'Raw data' means chromatograms, spectra, weighing tickets, instrument printouts — not just final results. The dual-signature requirement (analyst + reviewer) is mandatory. This clause is the laboratory counterpart of 6.52 (contemporaneous recording in production).
11.14 Are out-of-specification results investigated according to a written procedure?
- OOS investigation SOP with defined phases, timelines, and responsibilities
- Completed OOS investigation reports with root cause determination
- Phase 1 (laboratory) investigation checklist covering analyst technique, equipment, reagents
- Phase 2 (manufacturing) investigation when lab error not confirmed
- Original OOS result retained in the official record alongside any retest results
- Retest procedure with defined criteria for when retesting is permitted
- OOS trending data identifying recurring issues by method, analyst, or product
- CAPA records linked to OOS investigations
- Timeline evidence showing investigations completed within defined timeframes
- Management review of OOS trends at least quarterly
- Original OOS result deleted or replaced by retest result without documented justification
- No written OOS investigation procedure
- Repeated retesting until a passing result is obtained (testing into compliance)
- OOS investigations consistently attribute all failures to lab error without evidence
- Investigation timelines routinely exceeded without documented justification
- No trending of OOS results — patterns not identified
- OOS investigations closed without root cause determination
OOS investigation is one of the most scrutinized areas in API manufacturing inspections. The investigation must follow a written procedure and must be completed in a timely manner. Phase 1 (lab investigation) should be completed within a defined timeframe (typically 3-5 days). If a lab error is confirmed, retesting is acceptable with full documentation of the error. If no lab error is found, Phase 2 (manufacturing investigation) must be initiated. The original OOS result must NEVER be deleted or replaced — it remains part of the permanent record. 'Testing into compliance' (repeated retesting until a passing result is obtained) is a serious regulatory violation.
11.15 Does the OOS procedure define investigation phases, responsibilities, and conclusions beyond simply retesting?
- Written OOS investigation SOP covering all required elements
- Investigation template or form with structured sections
- Defined timelines for each investigation phase
- Criteria for classifying as laboratory error vs. manufacturing deviation
- Resample/retest criteria and approval requirements
- Investigation closure review by QA
- OOS investigation training records for analysts and QA personnel
- Metrics showing investigation completion rates within defined timelines
- No written OOS procedure — investigations handled ad hoc
- Procedure lacks defined phases or criteria for root cause determination
- No timeline requirements — investigations remain open indefinitely
- All OOS results consistently attributed to 'analyst error' without evidence
- Resampling performed without documented justification for discarding original sample
- Supervisor override of OOS classification without documented scientific rationale
This clause mandates a formal, documented OOS procedure that goes beyond simply repeating the test. The procedure should define: who can initiate an investigation, investigation phases (typically Phase 1: lab assessment, Phase 2: manufacturing assessment), criteria for confirming laboratory error vs. manufacturing deviation, retest/resample criteria, documentation requirements, and reporting to management. The FDA's guidance on OOS (2006) provides additional expectations. Key audit focus: verify the SOP exists, is followed consistently, and that investigations are not routinely closed as 'lab error' without supporting evidence.
11.16 Are appropriate reference standards (primary, secondary, in-house) established and controlled?
- Reference standard inventory listing all standards with source, lot, expiry, and storage location
- Certificates of analysis from pharmacopeial suppliers (USP, EP, WHO)
- In-house primary standard characterization reports (identity, purity by multiple techniques)
- Secondary standard qualification reports against primary standards
- Reference standard storage conditions monitoring records
- Usage and handling logs for reference standards
- Replacement/qualification schedule for expiring standards
- SOP for reference standard procurement, qualification, and management
- Reference standards from unqualified sources without characterization
- Expired reference standards in use without re-qualification
- No documentation of in-house primary standard characterization
- Secondary standards used without qualification against primary
- No storage condition monitoring for reference standards
- Missing reference standard inventory — unable to account for all standards
Reference standards form the measurement basis for all quantitative testing. The hierarchy is: recognized-source primary (USP, EP, WHO) > in-house primary (fully characterized) > secondary working standards (qualified against primary). Each level requires specific documentation. In-house primary standards must be characterized for identity and purity using multiple independent techniques. Secondary standards must be qualified against the primary standard before use. Auditors should review the reference standard inventory, characterization data, and usage/replacement logs.
11.17 Is each primary reference standard's source and purity documented and characterized?
- In-house primary standard characterization report with multiple identity techniques
- Purity determination by two or more independent methods (HPLC, titration, DSC)
- Mass balance calculation (assay + impurities + solvents + water ≈ 100%)
- Certificate of Analysis for the primary reference standard
- Stability data for the primary standard under defined storage conditions
- Documentation of standard material origin (batch, synthesis, purification)
- Peer review of characterization data by a second qualified scientist
- Comparison to pharmacopeial standard where partially available
- In-house primary standard established without full characterization
- Purity determined by a single method only
- No mass balance calculation — significant unaccounted fraction possible
- No stability data for the primary standard — unknown degradation risk
- Characterization data not peer-reviewed
- In-house primary standard storage conditions not validated for long-term stability
When pharmacopeial primary standards are unavailable (common for novel APIs or proprietary intermediates), the manufacturer must create and fully characterize an in-house primary standard. Characterization typically requires: mass balance (assay + impurities + residual solvents + water = ~100%), multiple orthogonal identity techniques (NMR, IR, MS), and purity determination by at least two independent methods. The characterization data must be sufficient to establish fitness for purpose as the calibration anchor for all subsequent testing.
11.18 Are secondary (working) reference standards qualified against a primary standard before use?
- Secondary standard qualification protocol with acceptance criteria
- Qualification reports showing comparison against primary standard
- Periodic requalification results per written schedule
- Approved secondary standard CoA with expiry/requalification date
- Storage condition records for secondary standards
- Usage log tracking consumption and remaining quantity
- Notification system for approaching requalification dates
- Handling and preparation SOP for secondary standards
- Secondary standards used without qualification against primary
- No requalification schedule — secondary standards used indefinitely
- Qualification criteria not defined or overly permissive
- Secondary standards stored outside defined conditions
- No usage tracking — unable to determine when standard should be replaced
- Requalification acceptance criteria wider than initial qualification criteria without justification
Secondary (working) standards are used in daily testing to preserve limited primary standard material. Each lot must be qualified against the primary before first use through comparison testing (typically assay comparison). Periodic requalification is required — the frequency should be risk-based but typically annually or when new primary standard lot is introduced. A written protocol must define qualification acceptance criteria, requalification frequency, and handling of out-of-specification qualification results.
11.19 Are reference standards stored and used under conditions that preserve their integrity?
- Reference standard storage area with controlled conditions
- Temperature monitoring records for storage location
- Receipt logs for new reference standards
- Current inventory list with status of each standard
- Usage and dispensing logs
- Disposal records for expired or degraded standards
- SOP for reference standard storage and handling
- Light protection and desiccation where required
- Reference standards stored at room temperature when refrigeration required
- No temperature monitoring of reference standard storage
- Unable to produce current inventory — standards unaccounted for
- Expired standards not segregated from current standards
- No dispensing or usage logs — consumption untracked
- Reference standard desiccant not replaced on schedule per SOP
Proper storage and handling preserve standard integrity. Storage conditions (temperature, humidity, light protection) should match supplier recommendations or be justified by stability data. Records must trace each standard from receipt through disposal. A current inventory with status (in qualification, approved, expired, quarantined) should be readily accessible. Auditors frequently request to see the reference standard storage area and inventory during inspections.
11.20 Is each API batch tested against its specification before release?
- Batch release testing records for recent batches
- API specification document listing all required tests with acceptance criteria
- Identity test results (IR, HPLC retention time, or specific identity test)
- Assay results with specification comparison
- Impurity profile including specified and unspecified impurities
- Residual solvent testing results per ICH Q3C
- Water content or loss on drying results
- Additional product-specific tests (particle size, polymorphism, endotoxins)
- QA disposition record based on test results vs. specification
- Batches released without completing all specification tests
- Identity testing not performed on every batch
- Impurity profile not compared to historical or registration data
- Residual solvent testing omitted without scientific justification
- Batches released with results outside specification limits
- No disposition record linking test results to release decision
Complete release testing of every API batch is non-negotiable. The testing program must cover identity (confirming the material is what it claims to be), assay (quantitative potency), and purity (impurity profile including related substances, residual solvents per ICH Q3C, and water content). Additional tests depend on the API: particle size for inhalation APIs, polymorphic form for bioavailability-critical APIs, endotoxins for parenteral APIs. Skip testing or reduced testing requires explicit regulatory justification (typically via parametric release).
11.21 Is an impurity profile established for each API?
- Written impurity profile document for each API showing all impurities
- Impurity identity (name, structure, CAS number, or RRT) for identified impurities
- Range data from multiple batches establishing typical impurity levels
- Classification of each impurity (process-related, degradation, inorganic, solvent)
- ICH Q3A/Q3B threshold compliance assessment
- Trend charts showing impurity levels over multiple batches
- Investigation records for batches with atypical impurity profiles
- Impurity profile update procedure when process changes occur
- No documented impurity profile for an API
- Impurity profile based on a single batch rather than representative data
- Unidentified impurities above identification threshold not investigated
- No comparison of batch impurity data against the established profile
- Impurity profile not updated after significant process changes
- New peaks in chromatograms not investigated or documented
The impurity profile is the fingerprint of the manufacturing process. It documents all known and unknown impurities with their typical ranges from the validated process. This profile serves as the baseline for detecting process drift, contamination, or degradation. For each impurity, the profile should capture: identity (by name or relative retention time), typical range (from multiple batches), and classification. ICH Q3A/Q3B provide thresholds for reporting, identification, and qualification. Deviations from the established profile may indicate process problems or cross-contamination and must be investigated.
11.22 Is each batch's impurity profile compared against historical data and the regulatory filing to detect drift?
- Batch-to-batch impurity trending charts or reports
- Comparison of current batch data against regulatory submission data
- Statistical analysis or trending of key impurity levels over time
- Investigation reports triggered by impurity profile changes
- Process validation batch data used as baseline for comparison
- Alert and action limits for impurity trending (tighter than specification)
- Annual Product Quality Review section covering impurity trends
- Documentation of process changes assessed for impurity profile impact
- No routine comparison of impurity data against historical baselines
- Gradual upward trend in impurity levels not investigated
- Regulatory submission profile not accessible for comparison
- Only specification compliance checked — no trending or statistical analysis
- Process changes made without assessing impact on impurity profile
- Statistical comparison methodology for impurity profiles not defined or validated
- Alert limits for impurity trending not established below specification limits
Active monitoring of impurity profiles is essential for detecting process drift. Each batch's impurity data should be compared against: (1) the regulatory submission profile (for registered APIs), (2) historical batch data from the validated process, and (3) process validation batch data. This comparison should use appropriate statistical or trending methods, not just specification compliance. A shift in impurity levels — even within specification — may indicate process changes that warrant investigation.
11.23 Is microbiological testing performed where appropriate to the API's intended use?
- Microbiological specifications for the API aligned with intended dosage form
- Batch release microbiological test results (bioburden, endotoxin as applicable)
- Environmental monitoring program and trend data for production areas
- Microbiology laboratory qualification records
- Method suitability testing (antimicrobial effectiveness testing) for the API matrix
- Trending of bioburden results over multiple batches
- Action and alert limits for environmental monitoring
- Investigation reports for excursions in microbiological limits
- No microbiological testing for APIs intended for sterile products
- Microbiological specifications not aligned with intended dosage form use
- No environmental monitoring for open processing steps
- Method suitability not demonstrated for the specific API matrix
- Excursions in environmental monitoring not investigated
- Bioburden recovery validation not performed for the specific API matrix
Microbiological testing requirements depend on the API's intended dosage form. APIs for non-sterile oral dosage forms need bioburden limits per pharmacopeia. APIs for sterile products (injectable, ophthalmic) require stringent bioburden and endotoxin testing. Environmental monitoring should reflect the process — open processing steps require more monitoring than closed systems. Auditors should verify that microbiological specifications align with the API's intended use and that environmental monitoring data supports the manufacturing environment's suitability.
11.40 Is an authentic Certificate of Analysis issued for each batch?
- Certificate of Analysis template with all required information fields
- Sample CoAs for recent batches with actual batch-specific data
- Verification that CoA data matches laboratory records for the batch
- CoA issuance log tracking all certificates issued
- Procedure for CoA preparation, review, and approval
- Controls preventing issuance of CoAs before testing is complete
- Expiry or retest date included on CoA where applicable
- Customer receipt acknowledgment or distribution records
- CoA data does not match actual laboratory test results for the batch
- Generic CoA issued without batch-specific testing data
- CoA issued before all testing was completed
- No procedure for CoA preparation and approval
- Missing expiry or retest date on CoA where applicable
- CoA issuance date precedes analytical testing completion date
Every batch shipped to customers must be accompanied by (or have available on request) an authentic Certificate of Analysis (CoA). 'Authentic' means the CoA reflects actual testing performed on that specific batch — not generic or copied data. The CoA must include product identification, batch number, release date, and expiry/retest date. For agents and brokers who re-issue CoAs, the chain of authenticity back to the original manufacturer must be maintained per Section 17.
11.41 Does the Certificate of Analysis include the API name, grade, batch number, and release date?
- CoAs showing all required content elements per the clause
- Numerical results for every test (not just pass/fail)
- Acceptance criteria (limits) stated for each test
- Contract laboratory identified where applicable
- Grade designation where the API has multiple grades
- Release date clearly stated
- Batch number matching other batch documentation
- Expiry or retest date included where applicable
- CoA shows only 'Complies' or 'Pass' without numerical results
- Acceptance criteria not stated on the CoA
- Contract laboratory not identified despite outsourced testing
- Missing tests that are part of the API specification
- Inconsistency between CoA batch number and shipping documents
- Batch-specific analytical data replaced with historical averages on CoA
This defines the mandatory content of a CoA. The key requirement is that actual numerical results must be reported — not just 'pass' or 'conforms.' Customers and regulators need the numerical data to evaluate trends and make informed decisions. If a contract lab performed any testing, that lab must be identified on the CoA. Auditors should compare CoA content against this checklist for a sample of recent batches.
11.42 Does the Certificate of Analysis list each test with its acceptance limits and the actual numerical results?
- CoA with individual test results including numerical values and units
- Compendial monograph reference where applicable (e.g., USP monograph number)
- Current pharmacopeia edition identified on CoA
- All specification tests represented on the CoA
- Units of measurement included for all quantitative results
- Results format consistent with specification (e.g., % w/w, ppm, CFU/g)
- Verification that CoA test results match raw laboratory data
- Customer-specific additional test requirements addressed where contracted
- Numerical results omitted — only 'Complies' or 'Within Limits' stated
- Compendial reference without specifying the edition
- Tests missing from CoA that are required by the API specification
- Units of measurement inconsistent or missing
- CoA results inconsistent with laboratory records
- Significant figures on CoA inconsistent with method capability
Reinforces the numerical results requirement. There is an alternative allowed: referencing a compendial monograph by name and number, which implicitly defines the tests, methods, and limits. However, even with this shortcut, actual numerical results should still be provided for each test. Best practice includes both the compendial reference and the numerical results. Auditors should verify that the compendial edition referenced is current.
11.43 Is the Certificate of Analysis dated and signed by an authorized person of the quality unit?
- CoAs with dated signature of authorized QA person
- List of authorized CoA signatories maintained by QA
- Electronic signature validation documentation if electronic CoAs used
- Signatory delegation procedure for absences
- Training records for CoA signatories
- Verification that signer identity is determinable from the CoA
- Audit trail for electronic CoA approval workflow
- CoA issuance only after batch release decision completed
- CoAs without a QA approval signature
- Signer not identifiable from the certificate (initials only, no name)
- Electronic CoAs issued without validated electronic signature system
- Non-QA personnel signing CoAs
- CoAs pre-signed before testing is complete
- Electronic signature validation records unavailable for audit
The CoA must bear the approval of an authorized QA person — confirming that QA reviewed the testing data and approved the batch for release. The signer must be identifiable (full name, not just initials). Electronic CoAs are acceptable if the electronic signature system is validated per clause 6.18 and 21 CFR Part 11 / EU Annex 11 requirements.
11.44 Does the Certificate of Analysis identify the original manufacturer by name and address?
- CoA showing manufacturer name, address, and contact information
- Contract manufacturer identification on CoA where applicable
- Re-issued CoAs referencing original manufacturer and original CoA
- Copy of original manufacturer's CoA maintained with re-issued certificate
- Supply chain documentation showing CoA chain of custody
- Quality agreement provisions for CoA requirements with intermediaries
- Procedure for verifying CoA authenticity from suppliers
- Audit records verifying intermediary CoA practices
- Original manufacturer not identifiable from the CoA
- Re-issued CoA without reference to original manufacturer's certificate
- Missing manufacturer address or contact information
- CoA from broker without original manufacturer data
- Supply chain with multiple intermediaries and no traceability to original source
- Contract manufacturer address on CoA is a registered-agent office rather than the manufacturing site
Full manufacturer identification ensures traceability in the supply chain. When intermediaries (brokers, traders, distributors) re-issue CoAs, the original manufacturer must still be identifiable. This prevents 'CoA laundering' where the actual source of the API becomes obscured. Re-issued CoAs must reference the original CoA. Auditors in the supply chain should verify that CoAs maintain the chain of identity back to the actual manufacturing site.
11.50 Is there an ongoing stability-monitoring programme for commercial APIs?
- Written stability program protocol defining scope, conditions, intervals, and methods
- Stability study reports for registered APIs
- Long-term stability data at recommended storage conditions
- Accelerated stability data at elevated conditions
- Stability-indicating method validation demonstrating selectivity for degradants
- Stability chambers qualified and monitored (temperature/humidity logs)
- Stability data trending and review at defined intervals
- Annual stability program assessment or summary report
- No documented ongoing stability program
- Stability testing performed only during development, not ongoing
- Non-stability-indicating methods used for stability studies
- Stability chambers not qualified or monitoring data shows excursions
- Insufficient test intervals to characterize stability profile
- No accelerated stability data for newly commercialized APIs
- Annual Product Quality Review responsibility not assigned to either party in the quality agreement
- Manufacturer field safety notice forwarding delayed beyond the timeframe defined in the quality agreement
- Intermediary CoA format implies they performed testing when only forwarding original manufacturer data
- Original manufacturer contact information omitted from re-issued CoA
An ongoing stability program is mandatory for all commercial APIs. It must include long-term testing at the recommended storage conditions and typically accelerated testing at elevated conditions. Test intervals should align with ICH Q1A guidelines (e.g., 0, 3, 6, 9, 12, 18, 24, 36 months for long-term). Methods must be stability-indicating — capable of detecting degradation products and distinguishing them from the API. Results drive expiry/retest date assignments and can trigger re-evaluation of storage conditions.
11.51 Are stability-indicating methods used that can detect and quantify degradation?
- Stability-indicating method validation reports
- Forced degradation study reports showing method selectivity
- Peak purity analysis demonstrating resolution of API from degradants
- Degradation pathways identified through stress testing
- Method selectivity data for each stressed condition (acid, base, oxidation, photolysis, heat)
- Mass balance data from forced degradation studies
- Periodic verification of stability-indicating capability
- Comparison of stressed sample chromatograms with unstressed API
- Stability methods without forced degradation selectivity data
- Methods that co-elute degradation products with the API peak
- No mass balance from degradation studies (significant material unaccounted for)
- Methods not re-validated for stability-indicating capability after process changes
- Only assay method used for stability — no impurity method
- Photolytic degradation pathway not evaluated during forced degradation study
Stability-indicating methods must be able to detect degradation and distinguish degradation products from the API peak and other impurities. Forced degradation (stress testing) under acid, base, oxidation, heat, light, and humidity conditions is the standard approach to demonstrate selectivity. Method validation for stability-indicating capability should show that the method resolves the API from all known and potential degradation products.
11.52 Are stability samples representative of commercial-scale batches?
- Stability batch selection rationale documenting representativeness
- Batch records for stability batches showing commercial-scale process
- Container-closure system description matching marketed product
- Justification document where pilot-scale batches are used
- Comparison data (impurity profile, physical properties) between stability batch and typical commercial batch
- Stability protocol specifying batch selection criteria
- Annual stability report documenting batches on study
- Container compatibility or extractables/leachables data where applicable
- Stability data from non-representative pilot batches used to support commercial expiry
- Stability samples stored in different containers than marketed product
- No documentation of batch representativeness rationale
- Stability batches from a process that has since been significantly modified
- Only one batch on stability (insufficient for trend analysis)
- Stability batch manufactured on different equipment train than typical commercial batches
Stability data is only valid if the test samples are representative of what customers actually receive. Commercial-scale batches are preferred. Pilot batches are acceptable only if they are genuinely representative (same process, same equipment type, same impurity profile). The container-closure system must match or simulate marketed packaging — stability in glass does not predict stability in HDPE drums, for example.
11.53 Is the stability container-closure system the same as, or simulating, the marketed container?
- Stability protocol specifying container-closure system requirements
- Documentation showing stability containers match marketed containers
- Equivalence justification where different containers are used
- Container specification documents for both stability and commercial containers
- MVTR (moisture vapor transmission rate) comparison data if applicable
- Oxygen permeability data comparison if applicable
- Light transmission data comparison if applicable
- Stability batch packaging records showing container-closure system used
- Stability samples in glass vials while commercial product in HDPE drums — no equivalence
- No documentation of container-closure system used for stability samples
- Commercial container changed without evaluating impact on stability data
- Stability data from more protective container used to support less protective commercial container
- No equivalence data when stability container material grade differs from commercial packaging
- MVTR comparison not performed when stability container size differs from commercial container
The stability container must faithfully represent marketing conditions. If the commercial container is an HDPE drum with PE liner, stability samples should be in the same system. If a different container must be used (e.g., smaller scale for practical reasons), it must be demonstrated that the test container is at least as protective as the commercial one. More conservative means: more permeable to moisture/oxygen, less protective from light — ensuring stability data represents worst-case conditions.
11.54 Are the first three commercial-scale batches placed on the stability programme?
- Stability program records showing first 3 commercial batches enrolled
- Stability data from the first 3 commercial batches
- Justification document if fewer than 3 batches used (with supporting historical data)
- Annual stability plan showing batch selection for ongoing monitoring
- Stability trending showing consistency across first 3 batches
- Protocol amendment records if stability plan deviates from standard approach
- Comparison of first 3 batch stability data with development/pilot data
- QA review of initial commercial stability data
- First 3 commercial batches not placed on stability
- Fewer than 3 batches used without documented justification
- Stability data from first batches shows unexpected degradation not seen in development
- No comparison between commercial and development/pilot stability profiles
- Stability program initiated late — significant time gap after batch manufacture
- Stability program enrollment delayed more than 30 days after batch manufacture
The first three commercial-scale batches must go on stability to confirm the shelf life established during development. This is an ICH Q1A requirement applied to API manufacturing. The exception (fewer than three) requires documented evidence of stability from prior studies. At minimum, one batch per year should be added to the ongoing program (clause 11.55). This creates a growing stability database that supports continued marketing.
11.55 Is at least one batch per year added to the stability programme thereafter (unless none is produced)?
- Annual stability plan showing batch selection for current year
- Stability monitoring records showing at least 1 batch per year enrolled
- Annual testing results for all batches on ongoing stability
- Stability trending report covering all batches and time points
- Risk assessment for APIs with limited stability requiring more frequent testing
- Stability program review as part of Annual Product Quality Review
- Protocol for selecting which batch to enroll when multiple batches manufactured
- Documentation when no batches manufactured in a given year
- No batches added to stability in a year when production occurred
- Annual testing not performed on time for batches on stability
- Limited stability APIs tested at standard intervals rather than more frequently
- No trending of ongoing stability data — individual data points reviewed in isolation
- Stability program not reviewed as part of APQR
- Batch selection for ongoing stability biased toward best-performing batches
The ongoing stability obligation requires at least one batch per year added to the monitoring program. This maintains the stability database and can detect long-term trends or the impact of gradual process changes. Testing frequency should be annual at minimum but more frequent for APIs with known stability concerns. The program design must be capable of detecting physical, chemical, and microbiological changes — not just assay decline.
11.56 Where a reduced stability-testing frequency is used, is it justified by accumulated data?
- Written justification for reduced stability testing with supporting data
- QA approval of reduced testing frequency
- Historical stability data demonstrating consistent stability profile
- Statistical analysis supporting reduced testing intervals
- Periodic review of reduced testing justification (typically during APQR)
- Trigger criteria for returning to full testing schedule (e.g., process change, OOS)
- Stability program SOP provision for reduced testing with approval criteria
- Risk assessment supporting the proposed reduced approach
- Reduced testing without documented justification
- Justification based on insufficient historical data (e.g., only 2 years)
- No QA approval for reduced testing decision
- Process or packaging change occurred without reassessing reduced testing justification
- No periodic review of the continued appropriateness of reduced testing
- Statistical power of the reduced testing plan not evaluated
Reduced testing is permitted but requires formal justification based on accumulated stability data demonstrating consistent, predictable stability behavior. This is a risk-based approach: APIs with years of stable data may have fewer time points or fewer batches per year. The justification must be documented, QA-approved, and reviewed periodically. Any process or packaging change resets the justification and may require return to full testing.
11.60 Do externally supplied intermediates carry an expiry or retest date as appropriate?
- Intermediate specification including retest or expiry date assignment
- Stability data supporting the assigned date
- Policy document defining when expiry vs. retest dating is applied
- Label showing expiry or retest date on intermediate containers
- Re-evaluation testing records for intermediates past retest date
- Customer notification of dating system used (expiry vs. retest)
- Procedure for handling intermediates that exceed their assigned date
- Documentation of expiry/retest date assignment rationale
- Intermediates shipped without expiry or retest dates
- Dating not supported by stability data
- No re-evaluation testing performed for intermediates past retest date
- Expiry date used but material continued in use past expiry without justification
- Intermediate retest evaluation limited to appearance and identity without full specification testing
- No documented procedure for handling intermediates discovered past their retest date
Intermediates shipped externally must have either an expiry date (after which the material cannot be used) or a retest date (after which the material must be re-tested before use). Internal intermediates commonly use retest dates. The choice between expiry and retest should be risk-based — APIs with known instability should use expiry dates. Stability data must support whichever dating system is chosen.
11.61 Are expiry and retest dates supported by stability data?
- Stability data report supporting assigned expiry/retest date
- Pilot-to-commercial stability data comparison where preliminary dates used
- Retest date extension documentation with supporting long-term data
- Statistical analysis of stability data (e.g., regression analysis per ICH Q1E)
- Assessment of transport condition impact on stability
- QA approval of expiry/retest date assignments and extensions
- Stability data covering the full proposed shelf life period
- Distribution condition studies or simulated transport data
- Expiry/retest dates not supported by stability data
- Preliminary dates from pilot data used beyond initial period without confirmation
- Retest date extended without additional supporting stability data
- No consideration of transport conditions in stability assessment
- Expiry/retest date assignment without QA approval
- Retest date extension granted based solely on accelerated data extrapolation
The expiry or retest date must be supported by stability data — not arbitrarily assigned. Preliminary dates from pilot data are acceptable initially but must be confirmed with commercial-scale data. Retest date extension is allowed when long-term stability data supports it, but the extension must be formally documented. Transport conditions (temperature excursions during shipping) should be factored into the overall stability assessment, not just storage conditions.
11.62 Where preliminary dates are based on pilot or accelerated data, is the basis documented and later confirmed?
- Pilot-scale stability data used for initial dating
- Representativeness assessment comparing pilot and commercial processes
- Plan to generate commercial-scale stability data to confirm pilot-derived dates
- Comparison of pilot and commercial batch impurity profiles
- Risk assessment for differences between pilot and commercial processes
- Timeline for commercial stability data to replace preliminary dating
- QA approval of preliminary dating based on pilot data
- Stability commitment filed with regulatory authorities where applicable
- Preliminary dating from non-representative pilot batches
- No plan to confirm preliminary dates with commercial stability data
- Significant process differences between pilot and commercial not assessed
- Preliminary dates used for extended periods without confirmation
- No quantitative comparison of pilot and commercial batch impurity profiles
- Scale-dependent parameters not identified in the representativeness assessment
For new APIs going commercial for the first time, pilot-scale stability data can support initial dating. The pilot process must be genuinely representative — same synthetic route, similar equipment type, comparable impurity profile. If the commercial process differs significantly (e.g., different crystallization conditions, different drying method), pilot stability data may not be predictive and additional commercial-scale stability data should be generated promptly.
11.63 Are retest-date extensions supported by long-term stability data and documented?
- Stability data from multiple batches covering the full proposed extended retest period
- Statistical analysis supporting retest date extension
- QA review and approval documentation for the extension
- Assessment of all batches on stability for consistency through extended period
- Documentation that storage conditions and containers match commercial conditions
- Updated specification or label reflecting extended retest date
- Regulatory notification or filing where required by market authorizations
- Periodic review of extension appropriateness (e.g., during APQR)
- Retest date extended without supporting stability data
- Extension based on data from fewer than 3 batches
- Data does not cover the full proposed extension period (extrapolation only)
- Extension granted despite out-of-trend results in stability data
- No QA approval of the extension
- Extension approved despite individual batch showing out-of-trend degradation at extended time points
Retest date extensions are a commercial benefit but must be supported by actual long-term stability data — not extrapolation alone. The data must be from a sufficient number of batches (typically at least 3) tested through the full proposed retest period. QA must review and approve each extension. If any batch shows out-of-trend results at the extended time points, the extension should be reconsidered. Storage conditions and packaging used to generate the extension data must match actual commercial conditions.
11.70 Are reserve (retention) samples retained for each API batch?
- Written SOP for reserve sample program
- Reserve sample storage area with conditions matching commercial storage
- Reserve sample inventory listing all retained batches
- Sample identification labels with batch number, date, and expiry/retest date
- Temperature monitoring records for reserve sample storage area
- Access control records for reserve sample area
- Reserve sample retrieval and testing records (when used for investigations)
- Disposal records for samples past their retention period
- No reserve samples retained for API batches
- Reserve samples stored under different conditions than commercial product
- Reserve sample inventory incomplete or not maintained
- Unable to locate reserve samples for recently distributed batches
- No procedure for reserve sample retention, access, or disposal
- Reserve sample area accessible to unauthorized personnel during off-hours
Reserve (retention) samples provide the manufacturer's ability to investigate future quality complaints or regulatory inquiries. They must be stored under the same conditions as the marketed product — if the API is stored at 2-8°C, the reserve samples must also be refrigerated. Retention begins from the date of manufacture completion. The reserve sample program should be documented in an SOP covering identification, storage, access, and tracking.
11.71 Are reserve samples of sufficient quantity to permit at least two full analyses?
- Sample quantity calculation showing sufficiency for two full analyses
- Reserve sample containers with all required labeling (name, batch, date, conditions)
- Specification or monograph used to determine 'full analysis' sample requirements
- Sampling SOP section addressing reserve sample quantity and labeling
- Periodic check that reserve samples remain sufficient (no unexpected usage)
- Sample container integrity checks
- Photographic evidence of properly labeled reserve sample containers
- Reserve sample request and retrieval log
- Reserve sample quantity insufficient for even one full analysis
- Reserve sample containers missing required labeling elements
- Reserve samples already partially consumed without documentation
- No calculation demonstrating sample sufficiency
- Containers damaged or showing signs of degradation
- Reserve sample quantity calculation not updated when specification panel expands
The 'two full analyses' requirement ensures that if one analysis yields an inconclusive result, a confirmatory analysis can be performed. 'Full analysis' means all tests in the specification or pharmacopeial monograph — not just a subset. For large-volume APIs this is straightforward, but for high-potency or expensive APIs where quantities are limited, the sample quantity must be carefully calculated based on the analytical methods' sample requirements. Container labeling must include the four mandatory elements.
11.72 Are reserve samples retained for one year past expiry or three years after distribution, whichever is longer?
- Retention schedule for reserve samples aligned with the dual retention rule
- Tracking of 'completely distributed' dates for each batch
- Reserve sample inventory showing retention dates for each batch
- Storage conditions matching API specification for all reserve samples
- Disposal log showing samples destroyed only after retention period elapsed
- Periodic inventory audit confirming all required samples are retained
- Documentation of the retention calculation method (which rule applies to each batch)
- Storage condition monitoring records for reserve sample area
- Reserve samples destroyed before retention period elapsed
- No tracking of distribution completion date — unable to calculate retention trigger
- Reserve samples stored under non-compliant conditions
- No disposal log — unable to demonstrate proper retention was maintained
- Retention policy only considers one rule (expiry OR distribution) but not both
- Reserve sample storage temperature excursion not investigated for impact on sample integrity
Reserve sample retention follows the same dual-rule as batch records (clause 6.14): 1 year post-expiry OR 3 years post-complete distribution, whichever is longer. For retest-dated APIs, the 3-year-post-distribution rule applies. 'Completely distributed' means when the last portion of the batch leaves the manufacturer's control — this date must be tracked. Storage conditions must match the API specification (not just room temperature). Auditors should verify that reserve sample retention periods are properly calculated and that samples are actually retained per the requirement.
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.