Data Integrity

Data Integrity and ALCOA+ in Practice

Updated 2026-11-07

Data integrity is where most regulatory findings in computerised systems actually land. The principles are easy to list and harder to live: it is one thing to recite ALCOA+, another to recognise the quiet ways each principle breaks on a real system. This article takes each principle in turn, pairs it with a failure pattern, and gives the control that prevents it, using invented examples.

For the fundamentals first, see what Computer System Validation is.

What data integrity means

It is the assurance that data is complete, consistent and accurate across its whole lifecycle — creation, processing, storage, retrieval, archiving — and that you can trust it reflects what actually happened. ALCOA is the original five principles; the ”+” adds four more.

ALCOA, principle by principle

Attributable — who did it, and when. Failure pattern: a team shares one login on a laboratory instrument, so every action is recorded as the same generic user. When something looks wrong, nobody can tell who did it. Control: individual named accounts, enforced; no shared or generic logins on GxP systems; the audit trail ties every action to a person.

Legible — readable and permanent. Failure pattern: results are recorded in a proprietary format that a future software version can no longer open, or on a printout that fades. Control: store data in a form that stays readable for its full retention period; verify readability after upgrades and migrations.

Contemporaneous — recorded at the time. Failure pattern: an analyst notes readings on a scrap of paper and types them into the system an hour later. The record’s timestamp is not when the event happened. Control: capture data directly into the system at the moment of the activity; a reliable, synchronised system clock that ordinary users cannot change.

Original — the first record, or a verified true copy. Failure pattern: the original electronic file is deleted and only a printed summary is kept, losing the underlying data and its audit trail. Control: preserve the original record (or a verified true copy that keeps its meaning and metadata); never discard dynamic data in favour of a static printout.

Accurate — correct, and reflecting reality. Failure pattern: a calculation in a spreadsheet has an error nobody validated, so every result derived from it is wrong. Control: validate calculations and configurations; review against a known result; control changes to formulas.

The ”+”: four more

Complete — nothing missing. Failure pattern: a test is run three times; only the passing result is kept. The two earlier runs — and the audit trail showing them — are gone. This is “testing into compliance”, and it is a classic finding. Control: keep all data, including repeats and failures, with the reasons; never delete inconvenient runs.

Consistent — in sequence and agreeing with itself. Failure pattern: records show a sample analysed before it was received, because two systems’ clocks disagree. Control: synchronised time across systems; checks that the sequence of events makes sense.

Enduring — lasts as long as it must. Failure pattern: data lives only on a laboratory PC that is later wiped, with no backup, well before the retention period ends. Control: defined retention; backup and verified restore; archiving that outlives the original hardware.

Available — retrievable when needed. Failure pattern: archived records exist, but no one can retrieve or read them during an inspection. Control: retrieval tested as part of validation and periodically thereafter, not assumed.

Static versus dynamic data

A recurring trap sits under “Original”. Static data is fixed — a printout or PDF. Dynamic data can be interacted with and reprocessed — a chromatogram you can re-integrate, for example. Keeping only a static printout of something that was dynamic loses information the original held. Dynamic data generally has to be preserved in a form that keeps it dynamic, which shapes how you store and migrate it.

Audit trail: the backbone

Most of these controls lean on a secure, computer-generated, time-stamped audit trail that records who changed what, when, and why — enabled, not switchable off by ordinary users, and actually reviewed. Having one is not enough; regulators expect evidence it is reviewed at a frequency driven by risk. An unreviewed audit trail is where integrity problems hide.

Why this matters for validation

Every ALCOA+ principle turns into concrete requirements in the URS and concrete tests in OQ: individual accounts, audit trail capture, clock control, retention, backup and restore, retrieval. Data integrity is not a separate activity bolted on at the end — it is designed in, specified, and tested like anything else.

Next