Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Log Plug-and-play starting point Data Integrity

Log: Pre-BLA Audit Defect Log

A plug-and-play defect log for the findings a pre-BLA or pre-NDA data integrity audit produces: severity, owner, tied-to-result reference, closure date, and disposition, with the filing-gate rule for High-severity findings and a filled specimen.

Document type: Log

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use defect log for the findings a pre-BLA or pre-NDA data integrity audit produces. It is the single place every broken trace, every audit trail gap, and every undisclosed excursion found during the audit gets recorded, scored, assigned an owner, and tracked to closure before the target filing date. Pair it with the CMC data traceability matrix, which is where most rows in this log originate, and the pre-BLA CMC data integrity audit protocol that defines the audit this log tracks. Replace every <<FILL: ...>> placeholder. A filled specimen follows.

FieldEntry
Log number<<FILL: LOG-ID>>
Product / application<<FILL>>
Audit protocol reference<<FILL: pre-BLA audit protocol number and version>>
Log owner<<FILL: QA / DI SME>>
Target filing date<<FILL>>

Severity definitions and filing-gate rule

SeverityDefinitionFiling rule
HighAffects a result behind an acceptance criterion, a PPQ batch, or a registration stability lot (the 100-percent-verification population); or the original data cannot be recoveredMust be remediated, or carry a written, science-based justification approved by QA, before filing. No exception.
MediumAffects development, characterization, or risk-weighted-sample data; original data recoverableMust be remediated (re-verified, revalidated, or procedurally corrected) on a defined timeline that closes before filing.
LowAffects routine, non-load-bearing data with no direct submission claimMay close post-filing on a tracked timeline, noted as a residual item; document the rationale for deferral.

A finding’s severity is set from the result’s sampling tier in the audit protocol, not from a subjective read of “how bad it looks.” A broken trace on a 100-percent-verification result is High by definition; downgrading it requires a written rationale approved by QA, not a default judgment call.

Field table

FieldEntry
Defect IDUnique, sequential (e.g. <<FILL: DEF-2026-001>>)
Result / record affectedThe specific result, batch, or record, with its matrix row ID if applicable
Module 3 / CMC sectionThe submission section this result supports
Data typeAnalytical result / process validation / stability / multi-site or CDMO
DescriptionWhat was found, in enough detail that a reader unfamiliar with the audit understands the gap
SeverityHigh / Medium / Low, per the rule above
Root cause (if known at logging)<<FILL: or "under investigation">>
CAPA / deviation referenceLinked corrective action or deviation record
OwnerNamed individual, not a function or department
Target closure dateMust precede the target filing date for High severity
StatusOpen / In progress / Closed
QA dispositionRemediated / Justified and accepted / Deferred (Low only), with the approving QA name

The log

Defect IDResult / recordSectionData typeDescriptionSeverityRoot causeCAPA/dev refOwnerTarget closureStatusQA disposition
<<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>><<FILL>>Open<<FILL>>

Instructions for use

  1. Log every finding the same day it is identified during audit execution, regardless of how minor it appears at the time; do not wait for the audit to conclude.
  2. Set severity from the sampling tier of the affected result, per the rule above, at the time of logging; re-score only with a written, dated rationale.
  3. Assign a named owner and a target closure date at the time of logging, not after a follow-up meeting.
  4. Review the full log at every program milestone and explicitly at the pre-BLA meeting readiness check; every High-severity row must show a path to closure before the filing date is treated as real.
  5. On closure, record whether the finding was remediated (objective evidence of a fix, re-verification, or revalidation) or justified (a written, QA-approved rationale); “closed, no further action” with neither is not an acceptable disposition for High or Medium severity.
  6. Feed every closed finding’s root cause into the broader quality system; a pattern across multiple findings (for example, the same instrument or the same site recurring) is itself a signal that belongs in a CAPA, not just three separate log rows. See what is a CAPA.

Retention

Retain this log, and every referenced CAPA and deviation record, per the site’s records retention schedule, for not less than <<FILL: retention period>>, and as part of the permanent inspection file for the application. The log is not archived or closed out until every row is Closed or explicitly carried forward as a documented residual item in the audit summary report.

Summary roll-up

MetricCount
Total findings logged<<FILL>>
High severity, open<<FILL>> (must be zero at filing)
High severity, closed (remediated / justified)<<FILL>>
Medium severity, open<<FILL>>
Low severity, deferred with tracked date<<FILL>>

References

21 CFR 211.192 (investigation of discrepancies), 211.194 (laboratory records). FDA Data Integrity and Compliance With Drug CGMP, Questions and Answers (2018). ICH Q9(R1), Quality Risk Management, for the severity-to-risk basis.

Confirm the current version of each reference before issue.


Filled specimen

An excerpt from an example biologic BLA audit log, roughly six months before the target filing date.

Defect IDResult / recordSectionData typeDescriptionSeverityRoot causeCAPA/dev refOwnerTarget closureStatusQA disposition
DEF-2026-011Purity, batch DS-2409 (matrix row T-058)3.2.S.4.1Analytical3 of 9 injections in the sequence not reported, no documented reason; analyst account held admin rightsHighUnder investigation: possible undocumented trial injections during method troubleshootingINV-2026-0087R. Alvarez (Analytical)2026-09-15In progressPending
DEF-2026-014Stability chamber CH-07, 12-month pull3.2.P.8Stability18-hour excursion to 14C, not disclosed until audit found the chamber logHighPower event; chamber alarm acknowledged but not documented at the timeDEV-2026-0201K. Osei (Stability)2026-08-20ClosedJustified and accepted: impact assessment shows mean kinetic temperature within demonstrated acceptable range; disclosed in submission
DEF-2026-019Reagent lot traceability, non-critical in-process assay3.2.P.3Process validationReagent lot number not captured on 4 of 60 sampled in-process recordsLowForm field not mandatory in current templateCAPA-2026-0044J. Kim (Manufacturing)2026-11-30OpenDeferred: template correction in progress, procedural fix; not load-bearing

Two things this excerpt shows. First, DEF-2026-011 is exactly the kind of finding a pre-BLA audit exists to catch and a real inspection does not get to find first, it is High severity, has a named owner, and a target closure date that precedes the filing window. Second, DEF-2026-014 shows the log working as intended: an unrecorded excursion became a documented, assessed, disclosed item instead of a hidden one, and it closed with QA’s written justification on file, not a silent “fine, move on.”

Common inspection findings this log prevents

  • A defect found during the internal audit that was never logged, so there is no record it was ever assessed or closed.
  • A High-severity finding closed with no evidence of remediation and no QA-approved justification, just a status change to “Closed.”
  • Findings with no named owner or target date, so nothing closes before the filing date arrives.
  • A pattern of related findings (same site, same system, same instrument) tracked as isolated rows with no CAPA connecting them.

How to adapt this log

  1. Set the product, application, and audit protocol reference in the header.
  2. Confirm your severity thresholds match the sampling tiers in your audit protocol; do not use a generic severity scale disconnected from what result the finding actually affects.
  3. Keep this log as the single source of audit findings reported at every program milestone; do not let a parallel, informal tracker develop.
  4. Route every Medium and High finding into your CAPA or deviation system per your normal quality procedures, and keep the cross-reference current in this log.
  5. Confirm every regulation in the references against the current published version before issue.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.