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
Report Plug-and-play starting point Data Integrity

Report: Retrospective Data Review After a Data Integrity Finding

A plug-and-play report structure for the retrospective data review FDA expects after a data integrity finding: the affected population, the review methodology, the reliability criteria, a decision rule, the disposition of affected batches, and the product-in-distribution and field-action assessment, with a worked filled specimen.

Document type: Report

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 report structure for the retrospective data review that a data integrity finding demands. When audit trails were misconfigured, results were deleted, or integration was manipulated, the question is not only “is the system fixed going forward” but “what is the status of every decision that relied on the affected data.” Replace each <<FILL: ...>> placeholder with your own specifics. A worked filled specimen follows. This is educational structure to adapt, not legal advice; verify each cited regulation against the current source.

Document control header

FieldEntry
Report titleRetrospective Data Review, <<FILL: system / data type>>
Report number<<FILL: RR-ID>>
Triggering finding<<FILL: 483 observation / Warning Letter finding / internal finding reference>>
System(s) in scope<<FILL: system name(s) and ID(s)>>
Author<<FILL: role>>
RetentionPer the records retention schedule, not less than <<FILL: retention period>>

1. Summary

State plainly what failed, over what period, and what this review concluded about the reliability of the affected data and the disposition of affected product. <<FILL: two to four sentences a reviewer can read first and understand the outcome>>

2. Background and trigger

<<FILL: the finding that triggered this review, when and how the failure was identified, and the immediate control put in place>>. Reference the parent response (<<FILL: response reference>>) and the corrective action that fixed the system going forward.

3. Affected population

Define the population precisely, because a defensible review states a denominator. Identify every result, batch, or record that relied on the affected system during the affected period.

FieldEntry
Affected period<<FILL: from date>> to <<FILL: to date>>, <<FILL: N>> months
How the period was bounded<<FILL: e.g. validation record, config change history, audit trail of the setting itself>>
Total records / batches in scope<<FILL: number>>
Data type(s)<<FILL: e.g. release-supporting assay results, stability, in-process>>
Records still in distribution (if product)<<FILL: number and lots>>

4. Review methodology

State the approach and justify the sampling decision. Where the integrity of the control itself is in question, a 100 percent review is usually the defensible choice rather than a sample, because a sample assumes the very reliability under question.

  • Review scope: <<FILL: 100 percent of the population, or a justified sample with the justification>>.
  • Reliability criteria (what makes a result trustworthy despite the failure): <<FILL: e.g. independent confirmatory data from a second instrument; raw data still intact in the file system; results consistent with stability and in-process data; corroborating paper record>>.
  • Independence: <<FILL: who performed the review and how they were independent of the original work>>.
  • Method: <<FILL: how each record was examined, what was compared against what>>.

5. Decision rule

State, before presenting results, exactly how each record is dispositioned, so the outcome follows a rule rather than a case-by-case judgment.

<<FILL: e.g. A result is judged reliable only if at least two independent reliability criteria are met. Any result where reliability cannot be established is escalated to a formal investigation and a batch release-status review. Any result found unreliable that supported a release triggers a batch disposition review and a field-action assessment.>>

6. Results against the decision rule

OutcomeCountPercent
Reliable (criteria met)<<FILL>><<FILL>>
Reliability not established (escalated)<<FILL>><<FILL>>
Unreliable (confirmed)<<FILL>><<FILL>>
Total<<FILL>>100

<<FILL: narrative of what the numbers show, including any pattern in the unreliable set>>

7. Product impact and field-action assessment

For any unreliable result that supported a release, assess whether affected product remains in distribution and whether a field action is warranted.

FieldEntry
Lots with unreliable supporting data<<FILL: list>>
In distribution now<<FILL: yes/no, quantity>>
Patient risk assessment<<FILL: reference to the assessment>>
Field action decision<<FILL: none / field alert report (21 CFR 314.81 for drugs) / biological product deviation report / voluntary recall>>, with the basis
Regulatory notification<<FILL: what was reported, to whom, when>>

8. Deviations and investigations opened

ReferenceForStatus
<<FILL: DEV/INV number>><<FILL: which records>><<FILL>>

9. Conclusion

<<FILL: the defensible statement of what the affected data can and cannot support, what product action follows, and what remains open>>. State uncertainty honestly; an openly stated limitation survives review better than an overclaim.

10. Approvals

RoleNameSignatureDate
Author<<FILL>>
QA reviewer<<FILL>>
Quality Head<<FILL>>

References

FDA guidance “Data Integrity and Compliance With Drug CGMP” (2018) and MHRA “GXP Data Integrity” (2018), which frame the ALCOA expectations behind this review. 21 CFR 211.192 (production record review), 211.194 (complete laboratory records), 211.180(c) (records readily available for authorized inspection). 21 CFR 314.81 (field alert reports for drugs); the biological product deviation reporting requirements for biologics. PIC/S PI 041, on data governance and the assessment of affected data after an integrity failure.

Confirm the current version and clause numbers before you rely on them.

Filled specimen (summary and results)

Illustrative; replace with your own. A chromatography data system ran with a disabled audit trail for an estimated 14 months and produced release-supporting results for 220 batches.

  • Population: 220 batches, release-supporting assay results, period bounded by the configuration change history and the audit trail of the setting itself.
  • Methodology: 100 percent review of all 220, not a sample, because the integrity of the control itself was in question. Reliability criteria: independent confirmatory data from a second instrument, raw data intact in the file system, and results consistent with stability and in-process data. Review performed by a QC team independent of the original analysts.
  • Decision rule: reliable only if at least two criteria met; reliability-not-established escalated to formal investigation and a release-status review.
OutcomeCountPercent
Reliable (criteria met)21497.3
Reliability not established (escalated)52.3
Unreliable (confirmed)10.4

The single unreliable result supported one lot still partly in distribution; a patient risk assessment was completed, a field alert report filed, and the lot placed under a disposition review. Stating the population (220), the review basis (100 percent, with a reason), the reliability criteria, and the decision rule is what makes this defensible, and it is far stronger than a bare “we reviewed historical data.”

Common inspection findings this report prevents

  • A data integrity finding with no retrospective look at the historical data it could have affected.
  • A retrospective review with no stated population, so the denominator and coverage are unknowable.
  • A sampled review where the integrity of the control itself was in question, so the sample assumed the reliability under review.
  • Reliable and unreliable results asserted with no decision rule and no independent confirmatory basis.
  • Unreliable results that supported a release with no assessment of product in distribution or field action.

How to adapt this report

  1. Set your report number and the triggering finding in the header.
  2. Choose 100 percent review by default when the control itself failed; justify any sampling explicitly.
  3. Define your reliability criteria from what independent evidence actually exists for your data type (a second instrument, an intact raw file, a corroborating paper record).
  4. State the decision rule before the results so the disposition follows a rule, not a case-by-case call.
  5. Pair this report with the commitment register and the response package so the retrospective review is tracked to closure like any other commitment.
  6. Confirm every regulation in the references against the current published version before you rely on it.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.