Data integrity

Data integrity is the degree to which a set of records, throughout its life cycle, is complete, consistent and accurate. It is not the same as data quality (which is about whether the value is correct) and it is not the same as data security (which is about whether the value is protected from disclosure). It is about whether the record you are looking at today is genuinely what was generated when the underlying event happened, by whom it claims it was generated, and without unrecorded change since.

Regulators care because the GMP regime rests on records. A pharmaceutical batch is safe to release because the batch record says the steps were performed, the materials were the right materials, the in-process tests passed, and the finished product met specification. If any of those records can be edited later without trace, or if any of them was filled in retrospectively from memory, the underlying logic of GMP collapses. The ALCOA principles are the test the regulator applies to find out whether the logic still holds.

ALCOA was coined by Stan Woollen at the FDA in the 1990s as a teaching device for FDA Office of Compliance investigators auditing electronic systems. The original five letters were Attributable, Legible, Contemporaneous, Original, Accurate. They were the criteria an investigator should apply to any record encountered during an inspection to decide whether it was trustworthy.

ALCOA+ extends the original five with four further attributes — Complete, Consistent, Enduring, Available — that were added in MHRA and PIC/S guidance during the 2010s to close gaps the original five did not explicitly address. The combined nine-letter framework now appears in essentially every major regulator's data-integrity guidance: FDA (2018), MHRA (2018), PIC/S PI 041 (2021), WHO TRS 1033 Annex 4 (2021).

Attributable

Every entry must be traceable to the person who made it, and to the time it was made. On paper this is the initials and date next to the entry. On electronic systems this is the logged-in user, the system time, and the immutable record of which user_id wrote this row. Shared logins, generic logins ('operator1', 'admin'), or after-the-fact attribution all break this principle. FDA Warning Letters citing shared credentials are routine — see almost any data-integrity citation since 2014.

Legible

The record must be readable, throughout its required retention period. On paper this means non-fading ink, no scratching out, no over-writing with correction fluid. On electronic systems this means the rendering format must remain readable as software changes — typically a PDF/A archival render, plus the underlying database content in an open format. Image scans of paper records must be at sufficient resolution to read every entry, including margin notes.

Contemporaneous

The record must be made at the time the event happens, not later. The most-cited data-integrity violation in inspection history is records written up at the end of a shift, or worse, the end of a week, from memory or from scrap-paper notes. The system clock used to timestamp electronic records must itself be controlled — synchronised to a trustworthy time source, audit-trailed when changed, and not user-settable.

Original

The record must be the first capture of the data, not a transcription. If a balance produces a printout and an operator transcribes the weight into a logbook, the printout is the original — the logbook is a copy. Both can be retained, but the original is the GMP record. For electronic systems, the database row is original; the export to a spreadsheet is a copy. 'Certified copies' are permitted in lieu of originals only when the copy has been formally verified against the original and the certification is itself a controlled record.

Accurate

The recorded value must be free from errors and edited only with documented change control. Edits to electronic records must capture the old value, the new value, the user, the time, and the reason — that is the audit trail. Edits to paper records must be single-line strike-throughs with initials, date and reason — never over-writing.

Complete

Every piece of data generated must be captured — including the failed runs, the re-tests, the discarded results. The 'testing into compliance' violation (re-running an assay until you get a pass and only recording the pass) is a Complete failure. Audit trails must be enabled and reviewed, not disabled to suppress unwanted entries.

Consistent

Records must be in chronological order, with date and time stamps in the expected sequence. A test result dated before the sample-receipt timestamp is an immediate red flag. Internal consistency — equipment ID matches the equipment that was actually qualified for that test, operator on shift matches the timestamp — must hold.

Enduring

The record must survive the full retention period — typically the longer of the product's life plus one year, or the regulator's minimum (often six years). Yellowing notebook pages and dead USB sticks are failures. Electronic systems must have a migration plan when the original software or hardware reaches end of life.

Available

The record must be retrievable for review by authorised personnel and inspectors. A record locked behind a system nobody knows how to query, or an archived tape with no working tape reader, is not available. Inspectors apply this practically: they ask to see the record and start the clock.

MHRA and PIC/S distinguish dynamic records (which retain the ability to be interrogated, re-processed, re-analysed by the user) from static records (a fixed printout or PDF). A chromatography raw data file is dynamic — the analyst can re-integrate the peaks; the chromatogram printout is static. The regulatory expectation is that dynamic records are retained in dynamic form for the full retention period, not replaced with static prints, because the static print loses the ability to detect manipulation of the raw data.

This distinction underpins one of the most common data-integrity findings in chromatography labs: records retained only as printouts, while the raw data files are over-written or stored without audit-trail review. The 2014 Ranbaxy Consent Decree and most subsequent India-pharma inspection findings turn on exactly this point.

For manufacturing-execution records (batch records, kiosk entries, deviation reports), the distinction usually means: keep the database content (dynamic) as the authoritative record, generate the PDF render (static) as the human-readable view, and tie them together via cryptographic hash so an inspector can prove they match.

An audit trail is the chronological, secure, time-stamped, computer-generated record of every create, read (where required), update and delete operation against a regulated electronic record. It records who did it, when, what the old value was, what the new value is, and — for changes — the reason. Without an audit trail, electronic records cannot satisfy Attributable, Contemporaneous, Original or Accurate.

21 CFR 11.10(e) requires audit trails on electronic records subject to Part 11. EU GMP Annex 11 ¶9 requires them for any GMP-relevant change in computerised systems. Both also require that audit trails themselves be subject to the same controls — they cannot be edited, they must be retained for the same period as the record they cover, and they must be available for inspection.

MHRA and PIC/S require periodic audit-trail review as a verification activity. The frequency is risk-based: critical records (batch records, OOS investigations, system-administration actions) reviewed every batch or every shift; lower-criticality records reviewed on a sampling basis. A system that has an audit trail but never reviews it is treated as a partial-compliance state.

The FDA's Warning Letter database since 2014 makes the failure modes obvious. The same patterns repeat across continents and product types.

1. Shared login or generic user account. 'Operator1' wrote every batch record entry. Attribution principle broken.
2. Audit trail disabled or never enabled. The system supports it; the company turned it off because it 'created too much data'.
3. Records back-dated. Entries with timestamps before the system clock would have permitted them, or entries with timestamps inconsistent with shift schedules.
4. Records re-created from notes. A batch record filled in at end of shift from operator's scrap notes — Contemporaneous principle broken even if the values are correct.
5. Failed runs deleted from chromatography software. The instrument's audit trail shows three injections; the records archive shows one. Complete principle broken.
6. Trial runs labelled 'system suitability' to mask failed assays. Re-injection until pass; only the pass kept. The textbook 'testing into compliance' finding.
7. Time zones manipulated. The instrument clock was adjusted backwards to make a result fit a shift. The Windows event log gives this away.
8. Paper records with whiteout, overwriting, or pencil entries. Original-record principle broken; intent to mask edits is the regulator's inference.
9. Backup tapes never tested. The records exist, but cannot be restored — Enduring and Available principles both broken when a restoration is attempted during inspection.

Data-integrity remediation is rarely a single-system fix. PIC/S PI 041 ¶6 frames it as a programme spanning governance (policies, accountability, training), system design (validated computerised systems with appropriate technical controls), process design (procedures that capture data contemporaneously), and assurance (audit-trail review, periodic data-integrity audits, management review).

Validating the computerised systems themselves is where GAMP 5 enters. GAMP's risk-based approach — categorise the software, scale validation effort accordingly, treat data integrity as a risk to assess and mitigate during user-requirement definition — is the de facto industry framework. ISPE's GAMP 5 Second Edition (2022) added explicit data-integrity sections that map ALCOA+ to specific validation deliverables.

For paper-based or hybrid records, remediation usually means moving to electronic with validated workflows that enforce contemporaneous capture, attributed actions, and audit-trailed change. Migration is itself a regulated activity — the data-migration plan, the verification of migrated data, and the decommissioning of the legacy records are all part of the validation deliverables.

V5 was designed against ALCOA+ from the database layer up. Each of the nine attributes maps to a specific platform control rather than to a procedure-only commitment.

• Attributable: every row written to a regulated table carries the authenticated user_id and the server-side timestamp. Shared logins are blocked by tenant policy; the kiosk requires user authentication before each critical action even when running unattended.
• Legible: human-readable rendering uses controlled templates; PDF/A archive renders are produced at record close and stored alongside the dynamic record.
• Contemporaneous: the kiosk gates progression on completion of each step in real time. Late entries are flagged and require a reason; the timestamp is always the server time, not the device time.
• Original: the database row is the original record. Exports are marked as copies and watermarked with the export user, time and source-record hash.
• Accurate: every UPDATE and DELETE against a regulated table writes an audit-trail row capturing old value, new value, user, time, and the reason field. The schema enforces this via a trigger, not application code.
• Complete: failed steps, voided dispenses, re-tests and discarded results are retained — never overwritten. Disposition (success/fail/void) is part of the record.
• Consistent: server-side validation rejects entries with timestamps out of plausible sequence; shift assignments, equipment qualification dates, and operator training currency are checked at write time.
• Enduring: regulated records are stored in tamper-evident tables with cryptographic hash chains; backups are tested on a schedule.
• Available: every record is retrievable through the audit view by record ID, by lot, by date range, by user; the inspector view bundles record + audit trail + linked evidence + render for export.