Data Integrity in Gene Therapy: What FDA Really Expects

Gene therapy is one of the most data-intensive categories of biologics any regulator reviews, and the same data integrity principles apply across pharma, biotech, medical devices, and the wider life sciences. A single Biologics License Application (BLA) for a viral vector or a base editing product can carry hundreds of assay datasets, manufacturing batch records, stability profiles, and clinical data packages, all of which have to hold together under a reviewer who has seen every kind of data manipulation, system misconfiguration, and documentation failure imaginable.

The gap that sinks programs is rarely a missing study. It is the integrity of the data underneath the studies: who generated it, whether it can be reconstructed, and whether the systems that produced it would let someone change a number without leaving a trace. This article walks through what inspectors actually look for, why advanced therapies are structurally harder than legacy small molecule manufacturing, and what a program that passes inspection looks like in practice, down to the procedures, roles, and acceptance criteria. The thinking here is modality-agnostic. A sterile injectable line, a medical device firmware build, or a clinical data management system faces the same questions, with gene therapy as the sharpest illustration because the consequences are the most permanent.

Why one-time therapies raise the stakes

Two features of the modality make data integrity unusually load bearing, and both have analogues elsewhere in the industry.

First, the products are often administered once. A patient receiving a one-time gene addition or editing therapeutic cannot stop taking it if a problem emerges later. The data supporting safety, identity, purity, and potency is the only protection between a manufacturing or analytical error and an irreversible clinical outcome. Reviewers know this, and they treat the supporting records accordingly. The same logic raises the stakes for an implantable device that cannot be recalled from a patient, or a vaccine lot given to millions before a stability signal appears.

Second, the analytical and manufacturing workflows are immature and instrument-heavy compared with a mature small molecule line. Potency, identity, and genomic integrity are assessed with methods that are still evolving: digital PCR (ddPCR) for vector genome titer, next generation sequencing for editing outcomes and off-target assessment, flow cytometry for transduction and immunophenotyping, and cell-based potency assays whose biology is genuinely hard. Each of these runs on instrument-specific software, much of it with weaker access controls and audit trail capability than a mature chromatography data system. The result is a long chain of hand-offs, each one a place where data can be lost, overwritten, or silently altered. Any organization adopting new instrumentation faster than its quality systems can absorb it lives with the same exposure.

There is a third factor that quietly multiplies the first two. Much of this work is split across contract development and manufacturing organizations and contract testing labs. A sponsor may own the BLA but hold none of the instruments that generated the data in it. That means the sponsor has to assure data integrity at sites it does not operate, through audits, quality agreements, and access to records it cannot see day to day. When a partner’s instrument software has a partial audit trail or a shared login, the finding lands on the sponsor’s submission. The oversight obligations here are spelled out in CDMO oversight and quality agreements and in supplier and vendor qualification, and they are not optional in this modality, they are the normal operating model.

Put those together and the inspection posture is straightforward: high consequence, immature systems, many hand-offs, and shared accountability across organizations. That is exactly the profile that draws scrutiny.

The gap between the guidance and what gets cited

FDA’s guidance “Data Integrity and Compliance With Drug CGMP: Questions and Answers” was finalized in December 2018 (the draft was issued in April 2016). It restates the ALCOA expectations that have anchored records and signatures requirements for decades: data must be Attributable, Legible, Contemporaneous, Original, and Accurate. The “plus” elements widely taught alongside it, Complete, Consistent, Enduring, and Available, come from MHRA guidance (“GXP Data Integrity Guidance and Definitions,” 2018) and PIC/S guidance (PI 041, “Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments”) and are now common vocabulary across agencies. For a fuller treatment of each attribute, see ALCOA+ in detail and the data integrity foundations article.

Every quality team has a slide on ALCOA+. What the slide does not capture is the inspector’s real question. They are not walking the floor hunting for an ALCOA violation in the abstract. They are looking for systems that allow data to be manipulated without detection, whether or not manipulation actually occurred.

That distinction matters more than almost anything else in this topic. A company can have clean data, complete records, and tidy audit trails and still receive a data integrity citation, because the system would have allowed backdating without forcing a reason, or because the electronic lab notebook does not capture edits at the field level. The finding is not the data. The finding is the control gap that makes the data untrustworthy.

This is why “we checked and the numbers are right” is not a defense. The agency is assessing whether the numbers can be proven right to a skeptical third party, using the system’s own records, without relying on the honesty of the analyst.

The regulatory anchors you should be able to name

When an inspector or interviewer presses on basis, these are the citations that carry the weight. Know them by number and by what each one actually requires.

A program that almost always runs in parallel jurisdictions should treat the US and EU requirements as a single combined bar. The 21 CFR Part 11 and EU Annex 11 article and the practical Part 11 / Annex 11 guide map the two side by side.

One development to watch on the EU side: in July 2025 a draft revision of Annex 11 (the first substantial rewrite since 2011) went to public consultation alongside a revised Chapter 4 and a new draft Annex 22 on artificial intelligence. The consultation closed on 7 October 2025; as of August 2026 these remain drafts, not yet in force. EMA held a further Annex 22 expert workshop on 30 June and 1 July 2026, the concept paper’s mid-2026 publication target has slipped, and a final text is now expected no earlier than 2027. The draft is longer and more prescriptive, adds cloud and outsourced IT, identity and access management, and cybersecurity as explicit expectations, and sharpens audit trail and data governance requirements. For an instrument-heavy advanced-therapy program run across CDMOs and contract labs, the direction reinforces exactly the controls this article stresses. Confirm the final published text and clause numbers before citing them, and treat the draft as a signal of inspector expectations rather than a current requirement.

The findings that recur

Drawing on published warning letters, FDA Form 483 observations, and inspection trends, the findings cluster into a handful of failure modes. None of them are exotic. They are the same failures that have generated data integrity warning letters across pharma, devices, and clinical operations for fifteen years, made worse by the instrument sprawl described above.

Partial audit trails

The obvious failure, audit trails switched off, gets caught immediately and is increasingly rare. The harder problem is partial audit trails. A system records that a result was created and that a record was deleted, but it does not capture field-level edits, or it captures that a value was “modified” with a timestamp but not the previous value.

The practical inspection standard, drawing on 21 CFR 211.68 and 21 CFR Part 11 for the recorded change and on ALCOA+ and EU Annex 11 expectation for the reason, is that the audit trail must be complete enough to reconstruct any change to raw or critical data: the old value, the new value, who made the change, when, and why. If you cannot reconstruct the prior state of a number, the system fails. For how to design and review trails so they actually meet this bar, see audit trail design and review and operationalizing audit trail review.

Instrument software for ddPCR, flow cytometry, and plate readers is the usual offender, because many of these packages were built as scientific tools first and compliant records systems second. The same gap appears in older standalone balances, pH meters, and device test rigs.

Shared or generic login credentials

Still happening. When two analysts share a login for convenience, or a workstation runs under a single generic account, every record produced is unattributable. This fails the Attributable principle outright, and it makes the data scientifically uninterpretable, because you cannot establish who performed which step or whether the person was trained and qualified for it.

Specialized instruments are especially exposed here. They often ship with a single administrative account and weak user management, and small teams under schedule pressure rationalize sharing. The fix is individual named accounts everywhere, enforced through identity and access management, with privileged functions separated from routine ones. The access control angle is covered in depth in CSV cybersecurity and access control and electronic signatures implementation.

Data transfer without verification

Raw data leaves an instrument, lands on a network share, gets imported into a LIMS or a calculation spreadsheet, and at each step the only check is that an analyst looked at the numbers and they seemed fine. That is not a control. It is an opportunity for transcription error or selective omission.

A defensible transfer either keeps the data inside a single validated system end to end, or applies an automated integrity check at each boundary: a checksum or hash comparison, a reconciliation count, or a system-to-system interface whose mapping has been verified. The transfer event should be logged on both sides. The principles here overlap heavily with data lifecycle and metadata and with the controls described in infrastructure qualification and spreadsheet validation, since spreadsheets are where most uncontrolled transfers happen.

Failing or aberrant results discarded before disposition

This is the finding that turns a 483 into a warning letter. An analyst gets a result that looks wrong, decides the instrument was off or the sample was bad, reruns, and deletes the first acquisition from the instrument software. The only record that survives is the passing one.

The agency position is unambiguous: all data, including failing and aberrant runs, must be retained and evaluated under the out-of-specification process. A decision to invalidate a result requires a documented scientific or technical justification, reviewed and approved, not a quiet deletion. The reference framework is the FDA guidance “Investigating Out-of-Specification (OOS) Test Results for Pharmaceutical Production,” now in its Revision 1 (May 2022), which supersedes the October 2006 original, reinforced by 21 CFR 211.192, and the mechanics are covered in the OOS investigation process. When a failure points at a systemic problem, it should also feed the CAPA system.

Potency assays make this temptation acute. The assays are variable, batches are precious and few, and timelines are brutal. That combination is exactly when discipline matters most and is hardest to hold.

Testing into compliance and uncontrolled reprocessing

Closely related: re-injecting, re-integrating chromatographic peaks, or re-running an analysis with different parameters until the answer passes, without documenting each attempt and its justification. In an electronic system this leaves fingerprints in the audit trail. Inspectors increasingly pull the trail and compare the number of acquisitions against the number of reported results. A mismatch is one of the fastest ways to lose credibility for an entire data set. The chromatography-specific version of this is detailed in chromatography data system integrity.

A quick map of findings to expectations

The table below summarizes the recurring findings, the underlying expectation, and the regulatory anchor. The citations are real and current as of writing.

Chain of identity and chain of custody: the data integrity layer of vein to vein

Autologous and other patient specific cell and gene therapies add a control conventional biologics never have to think about: the starting material is a named patient, not a vendor lot, and the finished product has to return to that same patient. Chain of identity (COI) confirms the product in front of the treating clinician is genuinely the material collected from this patient. Chain of custody (COC) confirms the material was never outside a controlled, monitored handoff between collection and administration. Both are usually filed under GMP or clinical operations, but they are squarely a data integrity question: the record tying a bag of cells to a patient is not supporting documentation for a safety decision, it is the safety decision. If that record cannot be trusted, no analytical result downstream matters. For the broader GMP and ATMP framework this sits inside, see GMP for cell and gene therapies: chain of identity, chain of custody, and ATMP controls.

Why this is structurally harder than a vendor lot

A conventional biologic starting material carries a vendor certificate of analysis and a lot number that means the same thing at every site that touches it. An autologous starting material carries a patient identifier that has to survive translation across systems that were not built to talk to each other: a hospital electronic health record, a courier manifest, a manufacturing execution system, and a LIMS. Every translation is a place a transcription error can happen, and unlike a vendor lot mix up, a chain of identity failure here means one patient could receive material intended for someone else. The consequence, not the mechanism, is what pushes this control above the bar applied to ordinary GMP identity testing.

What the record has to capture

1. A unique identifier assigned to the patient’s material at the point of collection, distinct from, and cross referenced to, the patient’s clinical identifier.
2. At every handoff, a two identifier verification: two independent identifiers read back and reconciled by the person accepting custody, not only the person releasing it.
3. A time stamped custody log entry at each handoff, who released, who accepted, when, and the condition of the material, temperature and container integrity, at that moment.
4. A record of any excursion, temperature, time in transit, container damage, with a documented assessment of impact before the material moves to the next step.
5. A reconciliation, before infusion or before release for administration, that walks the full chain from collection to point of use and confirms no gap or unexplained substitution exists.

Acceptance criteria

• Every handoff has a two identifier verification logged contemporaneously by the person accepting custody, not recorded later from memory.
• No custody gap: the material’s location and custodian are known and documented for the entire journey.
• Any excursion is captured and assessed for impact before the material advances, not discovered during a later review.
• The chain is reconciled end to end before infusion or release, with a named individual accountable for that reconciliation.
• Electronic and paper elements of the chain agree, and where a paper log still exists, its entries are contemporaneous, not backfilled at the end of a shift.

A worked example

Roles

Apheresis coordinator owns identifier assignment and the first verification. Courier owns condition monitoring and custody log entries in transit. Manufacturing receiving confirms identity and condition on arrival. QC and the qualified person or release authority confirm the chain is complete before release. The infusion site clinician performs the final, patient facing two identifier check immediately before administration, independent of whoever labeled the product.

Common mistakes

• Identifier verification performed by the same person who generated the label, with no independent second check.
• A paper custody log completed retrospectively at the end of a shift rather than at the moment of each handoff, so the timestamps are not contemporaneous.
• The identifier used at collection does not match, character for character, the identifier used in the manufacturing system, and no verification step catches the mismatch before the material enters the process.
• A temperature excursion during courier transport recorded on the courier’s shipping log but never carried into the manufacturing batch record or the disposition decision.
• Reconciliation performed as a paperwork step after the material is already released or infused, rather than as a gate before release.

When a discrepancy surfaces

Templates for building this out: SOP: Chain of Identity and Chain of Custody for Cell and Gene Therapy and Form: Chain of Identity / Chain of Custody Verification Log.

Viral vector lot genealogy and pedigree across the manufacturing chain

A finished drug product lot of a viral vector based gene therapy sits at the end of a long dependency chain: a plasmid lot, itself dependent on a bacterial master and working cell bank, a producer or packaging cell line vial pulled from a cell bank at a specific passage, an expansion and transfection or infection step, a vector harvest, one or more purification lots, and a fill finish lot. Comparability assessments, contamination investigations, and even a routine out of specification trace back through this genealogy, and the record connecting each stage to the next is itself GxP data, subject to the same attributability and reconstructability expectations as a laboratory result. When the genealogy record lives in a spreadsheet one person maintains by hand, the program has a single point of failure sitting underneath every disposition decision it makes.

Why this differs from ordinary batch genealogy

Small molecule and most biologics genealogy is largely linear: one active ingredient lot, one drug product lot. Viral vector genealogy is frequently many to one. A single vector harvest lot may draw from cells expanded across multiple vessels or multiple sub-lots of a working cell bank; a purification pool may combine multiple harvests; a fill finish lot may combine multiple purification lots. Every combination event is a place where the record has to capture not just that a mixing happened, but exactly which source lots, in what proportion, and confirmed to what disposition status before they were combined.

How to build and maintain the genealogy record

1. Assign a unique lot number at every stage: plasmid, cell bank vial and passage, expansion batch, vector harvest, purification pool, fill finish, drug product.
2. At every stage that consumes upstream material, record the specific parent lot number or numbers, the quantity or proportion contributed by each, and the disposition status of each parent lot at the moment it was consumed.
3. Maintain the linkage in a system with an audit trail, a LIMS, an MES, or an equivalent GxP system, not in an uncontrolled spreadsheet. Where a spreadsheet is genuinely the only option, treat it as a GxP record: version controlled, access controlled, and reviewed, the same discipline described for calculation spreadsheets in infrastructure qualification and spreadsheet validation.
4. Reconcile quantities in against quantities consumed and quantities out at each stage; an unexplained gap is a signal worth investigating before it becomes a disposition problem.
5. Review the complete genealogy chain as part of batch disposition for the final drug product lot, not only the immediate parent lot. A QA reviewer approving a DP lot should be able to answer which plasmid lot and which cell bank passage ultimately contributed to it.

Acceptance criteria

• Every DP lot traces to specific, disposition confirmed lots at every upstream stage, with no orphan link, a lot referenced with no record of its own disposition, and no unexplained substitution.
• Every pooling or splitting event names its exact source lots and their proportions, not a generic reference to prior harvests.
• The genealogy record itself is attributable, entry by entry, and time stamped at the point of the event, not reconstructed afterward from disparate logs.
• A contamination or OOS investigation on any single upstream lot can be answered against every downstream DP lot it reached, within the time your investigation procedure allows.

A worked example

A reviewer can walk this table from either direction: forward from the plasmid lot to confirm everything it touched, or backward from DP-2026-118 to confirm exactly which harvests, and in what proportion, made up the pool that became this lot.

Roles

Manufacturing science and technology, or the designated process owner, builds and maintains the genealogy record. QC confirms each stage’s disposition before it is consumed downstream. QA reviews the complete chain, not only the immediate parent lot, as part of batch disposition. Name an explicit genealogy owner in the batch record review procedure; this is exactly the kind of cross-functional record that falls through the gap when everyone is accountable for their own stage and no one is accountable for the full chain.

Common mistakes

• The genealogy maintained in a personal spreadsheet outside document control, with no audit trail on edits and no verification that it matches the underlying batch records.
• A pooled harvest lot’s individual contributing sub-lots not separately recorded, so an investigation into a single contaminated sub-lot cannot determine which finished DP lots it reached.
• Cell bank passage number captured only informally, inferred later from a freezer inventory log rather than recorded contemporaneously at the point of use.
• The genealogy reviewed only at the level of the immediate parent lot at batch disposition, so a defect several stages upstream is not caught before release.

Templates for building this out: Log: Viral Vector Lot Genealogy and Pedigree Register.

How to assess where your data integrity risk actually sits

Before you can build controls, you have to know which records carry the most risk. Spreading effort evenly across every system wastes the budget and leaves the dangerous records under-protected. A risk-based pass is the first operational step, and it is also what the 2018 Q&A, GAMP 5, and the computer software assurance thinking all push you toward.

A workable procedure runs in this sequence.

1. Inventory every computerized system that creates, processes, or stores GxP data. Instruments, LIMS, ELN, MES, historians, spreadsheets, and any cloud service. If it touches a release, stability, or submission decision, it is in scope.
2. For each system, classify the records it produces by data criticality: how directly the record drives a quality decision, and how severe the consequence of an undetected error would be. The method is laid out in data criticality and data risk.
3. For each critical record, score data integrity risk by combining criticality with the system’s vulnerability to undetected change. A record on a system with field-level audit trail, named accounts, and a verified interface is low vulnerability. The same record on a standalone instrument with a shared admin account and manual export is high.
4. Rank, then assign control depth and audit trail review frequency to match. The highest-risk records get reviewed every batch; lower-risk records get periodic review.
5. Record the assessment, the rationale, and the resulting controls so it can be defended and re-run when systems change.

Acceptance criteria for this step: an inspector can ask “show me how you decided which audit trails get reviewed every run,” and you hand over a documented, current risk assessment that traces each control back to the criticality of the record it protects. The structured methods are in CSV risk assessment methodology and DI gap assessment methodology.

What good actually looks like

A mature data integrity program is not defined by the volume of its documentation. It is defined by controls that make manipulation hard, make errors visible, and keep the full history of every data point available for review. In practice, that means a specific and observable set of behaviors.

• Instrument-to-system data transfer with automated verification: a checksum or system interface that confirms imported values match exported values, logged in both the source software and the destination audit trail. No manual retyping of critical data into spreadsheets that then drive disposition.
• Individual named accounts everywhere, with no human users sharing credentials and no routine work done under service or administrative accounts. Access is provisioned by role, reviewed periodically, and revoked promptly when people change roles or leave.
• Audit trail review built into the workflow, not bolted on. The expectation from the 2018 Q&A is that audit trails be reviewed with the same frequency and rigor as the records they support. For a release-critical result, that means a documented step confirming the trail for that batch or run was reviewed before the data was used for a decision. The mechanics live in batch record review and operationalizing audit trail review.
• OOS and out-of-trend procedures that explicitly address electronic data: what an analyst may and may not do when a computerized result is out of specification, before touching the instrument or the file. The out-of-trend angle is in out-of-trend investigations.
• System clocks synchronized and protected so contemporaneous timestamps are trustworthy and a user cannot move the clock to backdate an entry, the subject of time stamps and system clock control.
• A validated state that is maintained, not just achieved once. Software versions, configurations, and integrations change constantly in this space, so periodic review confirms the system is still in its validated state and that changes went through change control. The wider lifecycle approach is laid out in GAMP 5 and the CSV framework and the newer computer software assurance thinking, which lets teams concentrate effort on the highest-risk records rather than spreading testing thin.
• A governance layer above the individual systems, so that ownership, periodic review, risk assessment, and remediation are coordinated rather than left to each lab. That program-level view is the subject of the data governance framework and data integrity program architecture.

None of this is novel. All of it requires organizational discipline to sustain, especially at the speed these programs run.

Roles and responsibilities

Data integrity fails most often in the seams between roles, so name the owner of each control explicitly. A typical RACI looks like this.

R = responsible, A = accountable, C = consulted, I = informed. The last three rows extend the RACI to the chain of identity, vector genealogy, and CMC flexibility content covered further down. The point of writing it down is that when an inspector asks “who is allowed to invalidate a result,” there is one answer, not three. Clear GxP roles and responsibilities and a real training program make the RACI live rather than theoretical.

A worked example: vector genome titer by ddPCR

Consider a concrete path. A ddPCR run measures vector genome titer for a lot of viral vector that will be used for clinical or commercial supply. The instrument produces raw amplitude data, the software calls positive and negative droplets against a threshold, and a concentration is calculated and reported into the LIMS, where it is compared against the release specification.

The integrity-critical decisions are not at the end, they are buried in the middle. Who set the threshold, and is the threshold setting captured in the audit trail or buried in an unversioned analysis template? If the first analysis gave a borderline result and the threshold was adjusted, is the original analysis retained with a justification, or was it overwritten? When the concentration moved from the instrument software into the LIMS, was it transcribed by hand or transferred through a verified interface? Can a reviewer, months later, open the audit trail and reconstruct every reportable result this lot ever produced, including any that were not reported?

A program that passes will answer all four cleanly. The threshold and any change to it are captured and attributable. Every analysis is retained. The transfer is verified and logged. The reviewer can reconstruct the full history. A program that fails usually fails on the second and third questions: the borderline analysis quietly disappeared, and the number was retyped into a spreadsheet with no trace.

What the audit trail should look like

Here is a simplified extract of an audit trail entry that passes. Note that it captures the old value, the new value, the actor, the time, and the reason.

The reviewer can see that the threshold was changed once, why, by whom, and that the first calculated result was not silently discarded. If instead the trail showed three acquisitions and only one reported result with no explanation for the other two, that is the gap an inspector pulls on.

Acceptance criteria for the run

You know this run is defensible when all of the following are true.

• Every acquisition the instrument performed is accounted for, reported or explained.
• The threshold and any change to it appear in the audit trail with a reason and an attributable user.
• The reported titer in the LIMS matches the instrument value, with the transfer verified, not retyped.
• A documented second-person review confirms the audit trail was reviewed before the result was used for disposition.
• No result was invalidated without an approved OOS or atypical-result justification.

The lesson generalizes to flow cytometry gating, sequencing pipeline parameters, potency assay curve fitting, and far beyond cell and gene therapy: chromatographic integration on a small molecule line, automated visual inspection on a device, or query resolution in a clinical database. The judgment calls in the analysis are where integrity is won or lost, and they are exactly the steps that weakly controlled software fails to capture.

Extending the same discipline to potency and replication competent virus testing

The ddPCR titer example generalizes directly to two assay types that carry even more weight: the potency assay behind the clinical dosing claim, and, for retroviral and lentiviral vector products, the replication competent virus (RCV) assay that acts as a dedicated patient safety release gate.

Potency data review should confirm the reference standard lot used and that its own qualification data are current and attributable, that curve fitting or parallelism parameters, and any manual override of an automated fit, are captured in the audit trail with a stated reason, and that a borderline or rejected fit was retained and explained rather than silently rerun until it passed. The assay validation depth behind this is covered in comparability and potency assays for biologics and cell and gene therapies; the data integrity layer on top of that validated method is the same discipline as the ddPCR example: every analysis retained, every parameter change attributable, every transfer into the reportable result verified.

RCV testing carries a different risk profile, because a false negative is a safety event, not a specification miss. Data review should confirm every replicate result is retained, including negatives, that positive and negative assay controls met their acceptance criteria before any sample result is accepted as valid, and that an equivocal or reactive RCV signal triggers the escalation and investigation procedure rather than a repeat of the assay in hopes of a cleaner result. Repeating an RCV assay with no documented, approved justification is one of the more serious findings available in this modality, because it reads as testing into compliance on a safety gate rather than a routine release parameter.

Acceptance criteria for either assay type: every acquisition or replicate is accounted for, reported or explained; a documented, approved justification exists for any exclusion; the transfer of the result into the disposition record is verified, not retyped; and a second person review confirms the audit trail was checked before the result supported a release or safety decision.

Common mistakes: a potency curve refit with adjusted weighting or exclusion and no audit trail reason; an RCV assay control failure overridden without a documented investigation specific to that run; a reactive RCV result addressed by rerunning the same sample rather than escalating per the safety procedure.

Templates for building this out: Work Instruction: Vector Copy Number, Potency, and Replication Competent Virus Assay Data Review and SOP: Result Invalidation for Cell and Gene Therapy Potency and Release Assays.

How an inspector actually tests this

Understanding the inspection mechanics changes how you prepare. Inspectors rarely take a quality system at face value. They trace.

A common technique is to pick a single reported result, often a release-critical one such as a potency or titer value in the BLA, and follow it backward through every system it touched. They will ask to see the raw acquisition on the instrument, the analysis that produced the reported number, the audit trail around that analysis, the transfer record into the LIMS, and the disposition decision that used it. At any point in that chain where the story breaks, the original cannot be produced, the audit trail does not reconcile, the transfer was manual and unverified, the credibility of that result collapses, and the doubt spreads outward to every result produced the same way.

The backward trace, as the inspector runs it. Any one broken link is where the questioning stops and deepens:

A second technique is to compare the audit trail’s count of acquisitions and analyses against the count of reported results. If an instrument shows twelve injections and the records report eight, the inspector wants the other four explained with documented justification. Silence here is read as testing into compliance.

A third is to interview the analysts. Inspectors ask people to walk through what they do when a result looks wrong, and they listen for the gap between the written procedure and the lived practice. If the procedure says retain and investigate but the analyst describes deleting and rerunning, the procedure is decoration. This is why training is a data integrity control, not a separate exercise: a training program that does not change behavior at the bench leaves the real risk untouched.

The practical implication is that you should pressure-test your own program the same way. Before an inspection, pull a release-critical result and trace it end to end yourself. If you cannot reconstruct it cleanly, an inspector will not be able to either, and you would rather find that out first. A structured DI self-audit checklist, a mock inspection program, and broader FDA inspection readiness put this on a schedule rather than leaving it to the week before an audit.

A self-trace procedure you can run this quarter

1. Pick one release-critical result from a recent lot or study (a potency, titer, identity, or stability value).
2. Locate the raw data on the originating instrument or system. Confirm it still exists and is in its original or true-copy form, per static and dynamic records and true copies.
3. Open the audit trail around the analysis. Reconcile the number of acquisitions against the number of reported results. Account for every difference.
4. Confirm each threshold, integration, gating, or parameter decision is captured with an attributable user and, where changed, a reason.
5. Follow the value into the LIMS or report. Confirm the transfer was verified, not manual.
6. Confirm a documented second-person review of both the result and its audit trail preceded disposition.
7. Log every gap you find as a finding, route it through the CAPA system, and remediate before the real inspection. If a real integrity gap surfaces, the structured response belongs in a DI remediation program.

Handling a finding when one lands

If an inspection produces a 483 observation or a warning letter touching data integrity, the response process matters as much as the technical fix, and inspectors weigh the quality of the response heavily. A credible response does four things.

• Corrects the specific record or system cited, with evidence.
• Assesses the scope: every other record, system, and time period that the same gap could have affected. A response that fixes one instrument and ignores the five others with the same shared-login problem reads as not understanding the issue.
• Addresses root cause, often a procedure, a training gap, or a quality culture problem rather than a single technician’s error. Use formal root cause analysis techniques and avoid stopping at “human error,” as covered in human error in deviations.
• Commits to verifiable corrective and preventive actions with dates, then verifies effectiveness, per CAPA effectiveness verification.

The mechanics of writing the response are in 483 and warning letter response and FDA 483 response strategy. Recurring integrity failures are almost always a quality culture problem wearing a technical disguise, so a response that names only the technical fault rarely closes the issue for good.

Data integrity for comparability and FDA’s CMC flexibilities approach

A comparability protocol for a manufacturing change proves that product made after the change is still, for practical and clinical purposes, the same product. The scientific mechanics, the change to CQA risk mapping, the testing tier, the acceptance criteria, are covered in comparability and potency assays for biologics and cell and gene therapies. The data integrity question sits one layer under the science: every dataset the comparability conclusion rests on, the pre-change lots, the post-change lots, any lot that trended differently and was still included, has to be complete, attributable, and traceable back to its raw data, because the comparability report is only as defensible as the weakest data point feeding it. A comparability package that reports summary statistics with no path back to the underlying analytical runs reads to a reviewer exactly like a batch record with no supporting raw data behind it: unverifiable, regardless of how clean the conclusion looks.

The CMC flexibilities guidance and why it raises the stakes on this point

In May 2026, FDA’s Center for Biologics Evaluation and Research finalized a Level 2 guidance, “Chemistry, Manufacturing, and Controls Flexibilities for Developing Human Cellular and Gene Therapy Products for a Biologics License Application,” describing how the agency applies CMC flexibility under 21 CFR Part 601 to advanced therapy programs. The guidance formalizes a set of approaches many CGT sponsors had already been pursuing case by case with their review division: phase appropriate application of CGMP expectations as a product moves toward licensure, risk based comparability studies rather than a fixed testing battery applied regardless of risk, explicit use of prior knowledge, platform data, prior products using the same vector or process, published literature, to support a CMC position, a process performance qualification approach that lets a sponsor scientifically justify the number of PPQ batches needed, potentially fewer than the conventional three, and in some circumstances a single representative lot supporting a defined release strategy, use of stability data generated on clinical lots to support a commercial expiration dating period, alternative analytical methods that reduce sample volume or shorten testing time where they can be justified as equivalent, and a lifecycle approach to specification setting where acceptance criteria are revisited and adjusted as more manufacturing experience accumulates rather than fixed permanently at the first filing. For the lifecycle mechanics that specification setting and PPQ batch justification connect to, see ICH Q12 and lifecycle management and process performance qualification.

None of this reduces the underlying manufacturing or testing rigor expected; it changes how much of that rigor is demonstrated through a smaller, more targeted dataset instead of a larger, conventional one. That distinction is exactly why data integrity gets more important, not less, under this approach.

Why fewer batches and alternative methods raise the data integrity bar

When a sponsor runs three conventional PPQ batches and a standard testing battery, a reviewer questioning any single result still has a broad base of comparable data to check it against. When a sponsor justifies a single representative PPQ lot, or an alternative method never run head to head against the compendial method on every lot, the justification itself, the risk assessment, the comparability rationale connecting the reduced dataset back to process understanding, the specific prior knowledge citations, the equivalence data supporting the alternative method, becomes the only thing standing behind the decision. There is no larger dataset to fall back on if that justification cannot be reconstructed and defended on its own. Every one of those supporting datasets has to carry full ALCOA+ integrity and a complete audit trail in its own right: attributable authorship, a version controlled and approved risk assessment rather than an email thread, retained raw data behind every prior knowledge citation used rather than a restated summary number, and a documented review trail showing who evaluated the equivalence data and when. A reviewer reconstructing a reduced testing decision years later, at a pre-license inspection or during a post-approval variation, has nothing else to check it against except that record.

What this means in practice, mapped by flexibility type

Acceptance criteria

• Every flexibility used in the CMC package has a named, approved, version controlled document supporting it, not an informal justification recovered after the fact.
• Every dataset cited as supporting evidence, prior knowledge, engineering runs, bridging data, is traceable to raw data and reviewed under the same audit trail discipline as a release test.
• Any lot or result excluded from a comparability or stability dataset has a documented, approved scientific justification, never a quiet omission.
• Specification changes carry a dated rationale tied to the manufacturing data available at the time, reconstructable without relying on institutional memory.

A worked example

A sponsor pursuing a defined release strategy justifies a single representative PPQ lot for a given unit operation, citing platform manufacturing history on the same vector system and two engineering runs performed earlier in development. A reviewer pulls the risk assessment that made this call. If it exists as an approved, dated document naming the specific engineering run data and platform history cited, with the raw data for those runs retrievable and attributable, the position holds. If the same justification exists only as a paragraph in a briefing document assembled for a regulatory meeting, with no underlying risk assessment or retrievable raw data behind the cited platform history, the position collapses under the first serious question, regardless of whether the scientific conclusion happens to be correct.

Common mistakes

• A risk assessment justifying reduced testing exists as a slide deck or an email thread rather than a controlled, reviewed, version controlled document with attributable authorship and a date.
• Prior knowledge cited by conclusion only, “consistent with platform experience”, with no retrievable dataset behind the claim.
• A lot excluded from a comparability or stability dataset with no documented justification, discovered only when someone reconciles the lot list against what was actually manufactured.
• An alternative analytical method adopted without retained bridging data connecting it to the method it replaced.

Templates for building this out: Checklist: Comparability and CMC Flexibility Data Package Integrity Review, Protocol: Post-Change Comparability Study, and Risk Assessment: Manufacturing Change Comparability.

Common mistakes and inspection-finding patterns

These are the patterns that recur across published findings. None name a company, and all of them are avoidable.

• Audit trail “review” that is a checkbox, never actually opening the trail. The signature exists, the review did not happen. Inspectors test this by asking the reviewer to walk through a specific entry.
• Shared logins justified by “the instrument software doesn’t support individual accounts.” The expectation is a procedural or technical compensating control, not a free pass. If the software genuinely cannot, the gap and its mitigation must be documented and risk-assessed.
• System clocks that users can change, so a contemporaneous timestamp is not trustworthy. Backdating becomes possible and undetectable.
• Critical data calculated in an uncontrolled spreadsheet with no validation, no protection on formula cells, and no audit trail. This is one of the most common findings of all, and it is usually invisible until someone traces a number.
• Original raw data deleted after a “true copy” is made, where the copy is not actually a verified, complete, dynamic-capable copy. A flattened PDF of a chromatogram is not a true copy of a dynamic record.
• Audit trail review scope that misses metadata: the trail captures result changes but not changes to methods, integration parameters, or sequence tables, which is where manipulation actually hides.
• Treating contract lab data as outside the program. The sponsor still owns the integrity of every number in the submission, regardless of who generated it.
• Chain of identity verification treated as a manufacturing formality rather than a data integrity control, so the verification step itself has no audit trail of who checked what and when.
• A vector lot genealogy that exists on paper but has never been challenged with a “trace this DP lot back to its plasmid lot” exercise until an inspector runs that exercise for the first time.
• A CMC flexibility position, fewer PPQ batches, an alternative method, a tightened specification, supported by a scientific narrative in a submission with no underlying, approved, retrievable risk assessment or bridging data behind it.

Interview questions you should be ready for

If you work in or near data integrity, these come up in interviews and in inspection interviews alike. Strong answers are specific.

What does ALCOA+ stand for, and which part is from which guidance? Attributable, Legible, Contemporaneous, Original, Accurate from FDA, plus Complete, Consistent, Enduring, Available from MHRA and PIC/S. Then add that the letters are a memory aid, and the real test is whether an outsider can verify your data from your own systems.

A result is out of specification. Walk me through what an analyst may and may not do. May not delete or overwrite the result, may not rerun and report only the passing value, may not adjust parameters until it passes. Must retain the original, raise the OOS, investigate per the procedure, and invalidate only with documented, approved scientific justification. Cite the FDA OOS guidance, current Revision 1 (May 2022), and 21 CFR 211.192.

How often should audit trails be reviewed? With the same frequency and rigor as the records they support, per the 2018 Q&A. Release-critical data gets reviewed every batch or run as part of disposition; lower-risk data on a risk-based periodic schedule. Be ready to explain how you set the schedule from a data criticality assessment.

An instrument shows twelve injections but the report has eight results. What is your concern and what do you do? Possible testing into compliance. Pull the audit trail, account for every acquisition, confirm each unreported one has a documented justification, and if any are unexplained, treat it as a potential integrity issue requiring investigation and scope assessment.

What is a true copy, and when can you destroy the original? A complete and accurate copy that preserves the content and meaning, including dynamic functionality and metadata, verified against the original. You may retain the verified true copy in place of the original only where the copy genuinely preserves everything the original had, including the audit trail and dynamic behavior. See static and dynamic records and true copies.

How do you assure data integrity at a contract lab you do not operate? Quality agreement defining data integrity expectations and access rights, qualification audit with a specific data integrity focus, periodic audits, the right to review raw data and audit trails, and clarity that the finding lands on your submission regardless. See conducting a supplier audit.

What is the difference between a static and a dynamic record, and why does it matter? A static record is a fixed snapshot, like a printout. A dynamic record allows interaction, reprocessing, and reanalysis, like a chromatogram or a ddPCR data file. Dynamic records must be retained in dynamic form because the ability to reprocess is part of the data. Printing them and discarding the electronic file destroys integrity.

How do you assure chain of identity for an autologous product where the starting material is a specific patient? Assign a unique identifier at collection, require a two identifier verification by the person accepting custody at every handoff, log custody transfers contemporaneously with condition data, document an impact assessment for any excursion, and reconcile the full chain end to end before infusion, with one named individual accountable for that final reconciliation.

A viral vector lot is found contaminated after release. How do you determine which finished lots are affected? Pull the vector lot genealogy: every purification pool, harvest lot, and cell bank vial that fed the affected upstream lot, and every downstream drug product lot each of those fed into. This only works if the genealogy record captured exact parent lots and proportions at every pooling event, not a generic reference to prior material.

FDA’s CMC flexibilities guidance lets a sponsor run fewer PPQ batches and use alternative methods. Does that reduce the data integrity burden? No, it concentrates it. With fewer batches or an alternative method, there is less redundant data to fall back on, so the risk assessment, comparability rationale, and prior knowledge citations supporting that decision each have to carry full ALCOA+ integrity and a complete, reconstructable audit trail, because a reviewer questioning the decision has nothing else to check it against.

Where AI fits, and where it does not

There is real and growing interest in using machine learning to review audit trails at scale, flagging patterns a human reviewer would miss across thousands of entries: off-hours edits, repeated back-to-back changes to the same field, sequences that statistically do not match the documented process, or acquisition counts that do not reconcile with reported results. For the volume of audit trail data these programs generate, this is a genuinely useful application.

The caution is about role, not capability. An AI flag is not a data integrity finding. It is a screen. A finding exists only when a qualified reviewer investigates the flag and documents a conclusion. The model narrows where humans look; it does not replace the human judgment or the documented review that the regulations require. And the tool itself is a computerized system used in a GxP decision, so it has to be validated for its intended use, with its inputs, version, and limitations controlled like any other. That validation question is its own subject, covered in validating AI in GxP systems and building AI tools for GxP. Treating an unvalidated model’s output as fact in a release decision would itself be a data integrity problem.

For readers at different depths

If you are new to GxP, the single idea to carry away is that data integrity is about trustworthiness, not paperwork volume. The question behind every finding is whether an outsider could verify your data using your own systems, without trusting anyone’s word. Start with data integrity foundations and good documentation practices, and use the GxP and data integrity glossary to fix the vocabulary.

If you are a working practitioner, the highest-yield moves are usually unglamorous: kill shared logins, confirm your instrument audit trails capture field-level changes with prior values, eliminate manual retyping of release-critical data, and make audit trail review a documented part of disposition rather than an afterthought. A focused self-audit checklist or a structured gap assessment will surface the worst exposures fast.

If you are a senior or program-level reader, the work is to build a governance layer that treats integrity as a property of the whole system: clear data ownership, a current inventory of computerized systems and their validated state, risk-based review depth, and a remediation pipeline that closes findings before an inspector finds them. When findings do come, the response process matters as much as the fix, which is why 483 and warning letter response and broader FDA inspection readiness belong in the same program. If you are preparing for interviews specifically, pair this with GxP quality interview preparation.

The bottom line

Data integrity expectations for gene therapy are high because the consequences of unreliable data are, for a one-time treatment, effectively permanent, and the same logic scales across every regulated modality. The companies that pass inspection are not the ones with the thickest binders. They are the ones whose systems make manipulation difficult, make errors detectable, and keep the complete history of every data point available for review. They can name the regulation behind each control, hand over a current risk assessment that explains their review depth, and trace any reported result end to end without the story breaking. That is a harder thing to build than a slide deck on ALCOA+, and it is the standard worth building toward.