What Is Data Integrity in GxP?

Why regulators care about data integrity

Regulators care about data integrity because every GMP decision — batch release, deviation closure, validation sign-off — depends on records you can trust. When data is incomplete, inconsistent, or inaccurate, you cannot demonstrate that a product was manufactured correctly or that a system is validated. Patient safety, product quality, and compliance all fail at the same point: the record.

Trustworthy records are not optional paperwork. They are the evidence chain linking what happened on the plant to what quality and regulators can verify months or years later. FDA's 2018 data integrity guidance frames the expectation simply: data integrity is the completeness, consistency, and accuracy of data.

ALCOA+ — Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available — is how inspectors translate that definition into review questions. Data integrity connects directly to computer system validation (What is CSV?), risk-based assurance (What is CSA?), and electronic records controls under 21 CFR Part 11.

What Does Data Integrity Mean?

FDA defines data integrity as the completeness, consistency, and accuracy of data. Completeness means all required data is present — no unexplained blanks, missing injections, or selective reporting of only passing results. Consistency means the same fact appears the same way across systems, shifts, and review documents; a yield in the MES that disagrees with the historian and the paper log is a integrity failure even if each record exists in isolation.

Accuracy means data reflects what actually happened. A reading transcribed incorrectly, a backdated timestamp, or a result changed after test completion without documented justification breaks accuracy and undermines every downstream decision.

These expectations apply throughout the data lifecycle: creation, processing, modification, transfer, storage, retrieval, and retention. A weighing step on the shop floor, a critical parameter in a historian, a batch step in an MES, and a validation protocol result in a document repository are all in scope.

Practical pharma examples include: operator identity linked to every electronic batch step; chromatography raw data that cannot be overwritten without an audit trail entry; calibration records showing when an instrument was last verified; and validation evidence where executed results match the protocol without unexplained post-test edits.

ALCOA+ Principles Explained

ALCOA is the foundation; ALCOA+ extends it for the full lifecycle. The table below maps each principle to a GMP manufacturing example and a validation example — the same lens GXPLearn uses in Module 21 batch record review and Module 22 incident investigation.

Metadata, Electronic Records and Audit Trails

Metadata is data that describes other data — user identity, timestamps, instrument ID, software version, and change history. In electronic GMP systems, metadata often matters as much as the primary value. A result without its audit context cannot be reconstructed during an investigation.

Electronic records are text, graphics, data, audio, or pictorial information created, modified, maintained, archived, retrieved, or distributed by a computer system. When they substitute for paper under 21 CFR Part 11, controls for identification, validation, audit trails, and retention apply. EU Annex 11 sets parallel expectations for computerised systems in GMP.

An audit trail is a secure, computer-generated, time-stamped record that allows reconstruction of the course of events relating to creation, modification, or deletion of an electronic record. FDA expects audit trails for GMP-critical data — not buried IT logs nobody reviews.

Examples by system type: batch records (who changed a step completion time); historians (parameter limit edits and alarm acknowledgements); MES (recipe overrides and electronic sign-offs); automation (PLC setpoint changes and mode switches); validation evidence (post-test edits to protocol results). Reviewers examine whether trails are enabled for critical data, capture before-and-after values with user and timestamp, are reviewed under quality oversight, and whether configuration changes that could disable trails are themselves audited.

Why Audit Trails Matter

Audit trails answer three questions in every data integrity review: who changed the data, when was it changed, and what were the previous and new values. Without reconstruction capability, a company cannot demonstrate that records were not altered to achieve a passing result.

Audit trail review is quality oversight — not an IT archive exercise. QA and data owners should assess trails for unexplained edits, changes after batch release, modifications during investigations, and patterns suggesting testing into compliance.

In GXPLearn Module 22, investigators trace a shared QC analyst account (QCUSER) through chromatography audit trails, finding attribution failures and post-hoc edits — the same failure modes FDA highlights when criticising inadequate trail review.

Record reconstruction is the ultimate test: given only the electronic record and its audit trail, can an independent reviewer replay what happened? If not, data integrity controls — and often CSV status — are in question. See /glossary#audit-trail for the public glossary definition.

Common Data Integrity Failures

Shared user accounts eliminate attribution. When multiple analysts use one login, no one can prove who injected a sample or changed integration parameters. FDA explicitly treats shared logins as incompatible with attributable records.

Weak access control allows unauthorised changes — operators editing completed batch steps, or administrators disabling audit trails. Backdating records breaks contemporaneous and accurate principles. Missing audit trail review remains one of the most common 483 observations: trails exist but nobody reads them until an inspector does.

Incomplete documentation — blank fields, missing signatures, selective printouts — violates complete and consistent expectations. Unjustified data changes without reason codes or investigation drive warning letters. Testing into compliance — repeating analysis until a specification is met and retaining only the passing run — is a serious ALCOA+ breach.

In computerised systems, additional failures include disabling audit trails in production, copying results outside validated workflows, using uncontrolled spreadsheets as sources of truth, and validating systems without verifying integrity controls under operational load.

How Data Integrity Relates to CSV and CSA

Data integrity is not separate from validation — it is what validation exists to protect.

Data Integrity and CSV

Computer System Validation (CSV) provides documented evidence that a system performs as intended and produces trustworthy data. A validated LIMS, MES, or historian should enforce user access, generate audit trails, and prevent uncontrolled edits. Validation evidence itself — IQ/OQ/PQ protocols, test results, traceability to URS — is subject to data integrity. If those records cannot be trusted, the validation conclusion fails.

See What is CSV? for how specification, risk assessment, and testing build that assurance, and IQ, OQ & PQ explained for qualification layers that verify integrity controls at installation and operation.

Data Integrity and CSA

Computer Software Assurance (CSA) applies critical thinking and risk-based strategy to determine how much testing and evidence is needed — including how rigorously data integrity controls must be verified. High-risk functions (batch release data, audit trail generation) warrant deeper scrutiny; lower-risk reporting may need less.

CSA does not relax integrity requirements; it focuses effort where patient safety and product quality are most affected. See What is CSA? and CSV vs CSA comparison for how assurance strategy differs from traditional documentation depth.

Data Integrity Throughout the Validation Lifecycle

Data integrity expectations thread through every validation stage — not only at go-live. User Requirements (URS) should specify attributable access, audit trail behaviour, record retention, and electronic signature needs before design begins.

Design and risk assessment identify GMP-critical data, metadata requirements, and failure modes such as shared accounts or trail gaps — mapping controls to ALCOA+. Testing (IQ/OQ/PQ) verifies access controls, audit trail creation, time synchronisation, backup and restore, and that data cannot be altered without a trace.

Change control assesses any modification affecting data capture, trails, or retention. Periodic review confirms trails remain enabled, review procedures are followed, and retained data is still available and legible.

The Validation lifecycle explained guide expands each phase from requirements through maintained validated state; data integrity is the through-line that makes those activities meaningful for regulators and patients.

Practising Data Integrity in GXPLearn

GXPLearn turns data integrity concepts into practice through modules aligned with real QA workflows — educational first, not checklist theatre.

Module 21 — Batch Record Review: work through batch documentation with an ALCOA+ lens. Spot missing signatures, inconsistent timestamps, and incomplete entries the way a QA reviewer would before release — including contemporaneous-record issues where verification timestamps precede the activity they confirm.

Module 22 — Data Integrity Incident: investigate a chromatography scenario with shared-account attribution failures, trace audit trails, document ALCOA+ findings, and build CAPA targeting systemic controls — not generic retraining alone.

The Validation Digital Twin includes ALCOA+ quiz challenges reinforcing attributable, contemporaneous, and accurate record habits. Start at /data-integrity-training for the guided path, or open /app?mod=data-integrity-incident for the incident simulation.