Protocol: Pre-BLA CMC Data Integrity Audit

This is a ready-to-use protocol for the data integrity audit a sponsor runs on its own CMC data package before filing a marketing application, biologic or small molecule. It is a verification exercise, not a document review: the point is to confirm the raw data behind every load-bearing result in Module 3 is complete, traceable, and defensible, and to fix what is broken while there is still time. Run it as a rehearsal of the pre-license or pre-approval inspection. Replace every <<FILL: ...>> placeholder, set your document numbers and dates, and route it through document control and approval. A filled specimen follows. Confirm each cited regulation against the current source before you rely on it; this is educational reference content, not legal or regulatory advice.

Approval page

1. Objective

To verify, against ALCOA+ and the specific claims made in <<FILL: Module 3 / equivalent CMC section>> of the application for <<FILL: PRODUCT>>, that every load-bearing analytical, process validation, and stability result is traceable to complete, unaltered raw data, generated by a trained analyst on a qualified instrument under a controlled method, and reviewed before use; to identify every gap; and to disposition each one by remediation or a documented, science-based justification before the application is filed.

2. Background and rationale

A marketing application summarizes years of data generated across multiple systems, and often multiple sites, into a document a reviewer reads in isolation from the underlying systems. The pre-license or pre-approval inspection team does not stay isolated from those systems; they go directly to the chromatography data system, the LIMS, the manufacturing execution system, and the paper and electronic batch records, and they compare what those systems hold against what the application claims. Any gap between the claim and the system is a finding, and a finding tied to data integrity carries more weight than almost any other category because it undermines confidence in the rest of the package, not just the cited result. This protocol makes that comparison a scheduled quality activity, run by people who understand both the regulatory expectation and the technical systems, instead of a discovery made for the first time by an investigator.

This protocol is written to apply across modalities. For an autologous or patient-specific cell and gene therapy program, pair it with a chain-of-identity review scoped to the specific manufacturing and administration records for each lot; a retrospective audit of development-era clinical manufacturing data for a CGT sponsor, which carries its own gap-scoring scheme suited to data generated under evolving protocol versions, is a related but separate exercise, described in the pre-BLA retrospective data integrity audit protocol.

3. Scope

In scope: every result type that supports an acceptance criterion in the specification, every process validation and process performance qualification (PPQ) dataset cited in the submission, every stability dataset supporting the proposed shelf life, and the manufacturing records tied to every batch named in the application, at every site (internal, clinical manufacturing, and contract) that generated the data. As a minimum, the population includes:

• Release and stability results supporting drug substance and drug product specifications.
• PPQ batch data, including in-process and enhanced monitoring data collected during the PPQ program.
• Process characterization and development data that justifies a critical process parameter (CPP) range or a control strategy element cited in the submission.
• Reference standard qualification data underlying any result calibrated against it.
• For combination products, the device constituent’s design verification data feeding a claim in the submission.

Out of scope: <<FILL: anything explicitly excluded, with rationale, for example non-GMP research characterization not cited anywhere in the filing>>.

4. System description and context

List every system that generated or holds data in scope, so the audit team knows exactly where to pull raw data from and what validation status to confirm before relying on it.

A system with an unconfirmed validation status or an audit trail that cannot be shown to have been on for the full period in scope is itself a finding under section 10, not an assumption to resolve later.

5. Prerequisites

• The list of every data-contributing site, including contract testing laboratories and contract manufacturers, is finalized and confirmed against the current draft of the submission.
• The method inventory (every analytical method cited in the submission, with current effective version) is compiled.
• The systems in section 4 are confirmed validated, or their validation gaps are already logged as a known finding.
• The population of results in scope (every specification-supporting result, every PPQ batch, every registration stability lot) is enumerated before sampling begins, not estimated.

6. Roles and responsibilities

7. Sampling approach

Full census of every number in a multi-thousand-page CMC section is rarely feasible. Apply this rule to every result in the population defined in section 3, and record which tier each sampled result fell into:

Any result that was reprocessed, invalidated, retested, or otherwise touched after the first analysis is pulled into full verification regardless of which tier it started in; that population is exactly where an investigator starts.

8. Execution steps, by data type

8.1 Analytical results

1. Identify the raw data source for the sampled result: CDS sequence, instrument output, plate reader file, or laboratory notebook entry.
2. Confirm the raw data file is retained and readable in its original dynamic form, not only as a flattened printout or PDF.
3. Pull the audit trail for the acquisition and confirm no post-analysis modification exists without a documented, change-controlled or deviation-justified reason.
4. Confirm the analyst who generated the result was trained on the effective method version on the test date, from the training record, not from memory or assumption.
5. Confirm the instrument was within calibration and the system was in a qualified state on the test date.
6. Confirm the method version used matches the current controlled version, or trace an approved bridging record if it does not.
7. Confirm a second-person review occurred and is dated after the analysis.
8. Record the full trace on the CMC data traceability matrix row for this result; log any broken link in the defect register (section 10).

8.2 Process validation and PPQ data

1. Confirm the PPQ protocol was approved before the first PPQ batch was executed.
2. Confirm the PPQ batches cited were consecutive, at commercial scale (or a scientifically justified equivalent), and representative of the commercial process.
3. Confirm enhanced or heightened sampling and monitoring data associated with the PPQ program is complete for every batch, with no unexplained missing data point.
4. Confirm the statistical analysis behind the PPQ conclusion is correct and that the acceptance criteria were defined before execution, not fitted to the results afterward.
5. Reconcile the executed batch records for PPQ batches against the process description in the submission line by line; log any undisclosed deviation.

8.3 Stability data

1. Confirm the stability protocol was approved and that samples were placed at the correct, documented time zero.
2. Confirm every scheduled test point was completed on time, or within a documented, justified window, with any deviation captured.
3. Pull the continuous chamber monitoring record for the full storage duration and confirm no undocumented excursion exists; where an excursion occurred, confirm an impact assessment is on file.
4. Confirm any out-of-specification or out-of-trend stability result was investigated under the applicable procedure before the data entered the submission.

8.4 Multi-site and contract organization data

1. Confirm each contributing site is named correctly in the application and holds current GMP status appropriate to the work performed.
2. Confirm a pre-submission audit of the site was completed, with findings dispositioned, and that the quality or technical agreement states data integrity expectations explicitly.
3. Pull a risk-based sample of the site’s own raw data for results cited in the submission, following the same trace steps as section 8.1, rather than accepting a summary certificate at face value.

9. Deviation and finding handling

• Any broken trace link found during execution is logged the same day it is found, in the pre-BLA audit defect log, with the affected result, the Module 3 section it supports, and an initial severity.
• A finding on a 100-percent-verification result (section 7) is treated as High severity by default; downgrade only with a written, QA-approved rationale.
• No High-severity finding is left open at filing. It is either remediated (the underlying data reprocessed, revalidated, or otherwise corrected under change control) or carries a documented, science-based justification a reviewer would accept, citing corroborating or downstream evidence.
• Any inability to complete a review step, for example raw data that cannot be located at all, is itself logged as a finding; it does not silently drop out of the population.
• Findings are classified using the site’s standard finding-classification scheme; see audit finding classification for the approach this protocol assumes.

10. Acceptance criteria

• Every result in the population defined in section 3 has been sampled per the rule in section 7, with the tier recorded.
• Every sampled result has a completed trace, recorded in the traceability matrix, with status Intact, Partial, or Broken.
• Every Partial or Broken trace has a logged finding with a severity, an owner, and a disposition.
• Every High-severity finding is either closed with objective evidence of remediation, or carries a QA-approved written justification, before the protocol is closed.
• The summary report (section 11) is issued and approved by senior quality independent of the function that generated the audited data.

11. Summary and conclusion

On completion, the audit lead issues a summary report stating: the population reviewed and the sampling tier applied to each part of it, the number of findings by severity, the disposition of every High-severity finding, the residual risk carried into the filing, and an explicit statement of readiness to file from senior quality. <<FILL: summarize at close>>.

12. Attachments

• Attachment A: Completed CMC data traceability matrix.
• Attachment B: Completed pre-BLA audit defect log.
• Attachment C: System validation status summary (section 4, evidenced).
• Attachment D: Method inventory with effective versions.
• Attachment E: Contributing-site audit reports and quality agreement excerpts relevant to data integrity.

13. References

21 CFR 211.68 (automatic, mechanical, and electronic equipment), 211.180 (records retention), 211.194 (completeness of laboratory records). 21 CFR Part 11 (electronic records and signatures). Public Health Service Act section 351; 21 CFR Part 601 (biologics licensing); 21 CFR Part 314 (NDAs). FDA Data Integrity and Compliance With Drug CGMP, Questions and Answers (2018). FDA Compliance Program 7346.832M, Prelicense and Preapproval Inspections of CDER-Regulated Biological Product Manufacturers (issued 14 April 2026, effective 14 May 2026); FDA Compliance Program 7346.832, Preapproval Inspections (revised, issued 29 June 2026, effective 10 August 2026), for the objectives this audit rehearses. ICH Q9(R1), Quality Risk Management, for the sampling and risk basis. PIC/S PI 041, Good Practices for Data Management and Integrity.

Confirm the current version of each reference before issue.

14. Revision history

Filled specimen

An illustrative excerpt for an example biologic BLA, product and IDs replaced for the example.

Scope population (excerpt)

Execution finding (excerpt)

Summary (excerpt)

“Of 340 specification-supporting results, 65 PPQ and stability results, and a risk-weighted and statistical sample of development and routine data, two findings reached High severity at first pass. One was downgraded on confirmation the affected result was not submission-cited. One, an undocumented stability excursion, was closed by impact assessment and disclosed in the submission rather than hidden. No High-severity finding remains open. Senior quality confirms readiness to file, with the excursion disclosure carried forward as a known, dispositioned item.”

That last line is the entire point of the protocol: an investigator who finds the same excursion later finds a disclosed, assessed event, not a surprise.

Common inspection findings this protocol prevents

• An investigator finding an audit trail gap, a reintegration, or a chamber excursion that the sponsor’s own pre-submission audit never surfaced.
• A “we reviewed the data and it looks fine” conclusion with no population, no sampling record, and no severity-classified findings behind it.
• A contract site’s data relied on in the submission with no pre-submission audit or sample trace ever performed.
• A High-severity gap left open at filing with no remediation and no written justification.

How to adapt this protocol

1. Set the product, application type, and document numbers.
2. Confirm the population in section 3 against your actual, current Module 3 draft; do not sample against a stale table of contents.
3. Adjust the system list in section 4 to your actual system inventory.
4. Start the audit early enough in the readiness timeline that Section 10’s remediation work can complete before filing; see the BLA/NDA readiness timeline for a suggested schedule.
5. Confirm every regulation and compliance program citation in section 13 against the current published version before issue.