25.20 — Data Integrity, ALCOA+ and 21 CFR Part 11

An inspector sits down at a laboratory workstation and asks the analyst to show her the chromatography software's audit trail. The analyst has run the assay for a batch that passed and was released.

The audit trail shows something the result file does not. Before the run that produced the passing result, there were two earlier injections of the same sample, both deleted, under a project folder called "trial". The passing result was the third attempt.

Nothing about the tablets changed. What changed was the company's ability to be believed — about that batch, and about every other batch it has ever released using that system.

This is the failure mode regulators fear most, because it is the only one that makes all the other controls meaningless. If the records can be edited to say whatever is convenient, then batch records, trial data, validation reports and investigations are all theatre.

The principle: ALCOA, and the four that were added

Data integrity means the data is complete, consistent and accurate throughout its life. The working definition regulators use is an acronym you will hear daily, and every letter is a testable requirement rather than a slogan.

Attributable. You can tell who did it and when. A shared login destroys this immediately, which is why shared accounts on a GxP system are among the most common serious findings in the world.

Legible. It can be read and understood, now and in ten years. For electronic records this means readable without a piece of software nobody can install any more.

Contemporaneous. Recorded at the time the work was done. Not from memory at the end of the shift, and not on a scrap of paper transcribed later — the scrap is then the original record and the neat version is a copy.

Original. The first capture, or a certified true copy of it. If an instrument produces an electronic file, that file is the original record, and printing it and discarding the file destroys the original.

Accurate. Correct, and where errors are corrected, the original value is still visible along with who changed it and why.

Then the four that were added because inspectors kept finding gaps the first five did not close.

Complete — all of it, including repeats, failures, and the runs nobody liked. Consistent — in sequence, with dates and times that make sense across systems. Enduring — kept on durable media for the required retention period. And available — retrievable when someone asks, throughout that period.

Read those nine as system requirements and they are a specification. Attributable means individual accounts and no shared credentials. Contemporaneous means server-side timestamps the user cannot set. Original means the raw file is retained and not just the report. Complete means no hard deletes. Enduring and available mean a migration plan for the day the vendor stops supporting the product.

21 CFR Part 11, in plain terms

When companies began replacing paper with computers, an obvious legal question appeared: is an electronic record acceptable where the law requires a record, and is an electronic signature acceptable where it requires a signature? The American answer, effective 1997, is 21 CFR Part 11.

The bargain it strikes is simple. Yes, electronic records and signatures are acceptable — provided the system meets a set of controls that give the same confidence a paper record with a wet-ink signature would.

First, a distinction that decides which controls apply. A closed system is one where access is controlled by the people responsible for the records. An open system is one where it is not — records passing through a third party outside that control — and it requires additional measures such as encryption and digital signature standards. Nearly all regulated systems are operated as closed systems, including cloud-hosted ones, because access control remains with the regulated company through contracts and configuration.

The controls for records, in the order they matter to an engineer:

Validation — the system does what it is supposed to do and is shown to do it (Chapter 25.21).

Accurate copies — records can be produced in human-readable and electronic form for inspection.

Retention — records remain retrievable throughout the required period, which may be decades.

Access control — only authorised people, with authority checks so that the system knows not only who you are but what you are allowed to do and sign.

And audit trails — the requirement worth quoting almost in full because it is the one everything else leans on. A secure, computer-generated, time-stamped audit trail must record the operator entries and actions that create, modify or delete electronic records. Changes must not obscure previously recorded information. The audit trail must be retained at least as long as the record itself and be available for review and copying.

Read each phrase as a design constraint. Computer-generated means the system writes it, not the user. Secure means nobody can edit or delete it, including administrators. Must not obscure means updates are versioned rather than overwritten. And available for review means it must be readable by a human, not just present in a table — an audit trail that can only be extracted by a database query and a developer is, in practice, a finding.

For signatures, the requirements are equally concrete. A signature must be linked to its record so it cannot be copied elsewhere. The signed record must display the printed name of the signer, the date and time, and the meaning of the signature — authored, reviewed, approved. An electronic signature based on identification codes and passwords must use two distinct components, and where a person signs several records in one continuous session, the first signing uses both components and subsequent ones may use at least one. And the company must certify to the agency, once, in writing, that its electronic signatures are legally binding equivalents of handwritten ones.

One thing Part 11 does not say, despite endless confusion: it does not require electronic signatures. It applies when you choose to use electronic records or signatures in place of paper. A company can keep paper and stay outside it — which is exactly why some sites still run on paper for certain processes, and why that is a legitimate choice rather than backwardness.

What the guidance layer added later

In 2003 the agency issued a scope-and-application guidance narrowing how the rule would be enforced, after industry complained that a maximal reading made every spreadsheet a regulated system. It set out enforcement discretion in specific areas and, importantly, said that decisions about audit trails, record retention and copying should be based on a justified risk assessment of the record's impact on product quality and patient safety.

In 2018 the agency issued a data integrity guidance in question-and-answer form, addressing what inspectors had actually been finding. Its practical positions are worth knowing because they answer the questions engineers ask. Audit trails should be reviewed as part of the review of the record they belong to — routinely, by someone qualified, not only when there is a suspicion. Shared login accounts are unacceptable where individual attribution is required. Blank forms must be controlled so that a discarded attempt cannot simply vanish. And a system must be evaluated for whether users can influence what is captured — an interface allowing a run to be discarded before saving is a data integrity risk by design.

Europe's equivalents are Annex 11 of the GMP guide, covering computerised systems, and the inspectorate guidance on data integrity across GxP. Annex 11 is being rewritten for the first time since 2011: a draft revision was published on 7 July 2025 with consultation closing on 7 October 2025, expanding a five-page annex into a much longer document covering cloud services, outsourced IT, supplier oversight, cyber threats and modern data flows — and it arrives alongside a new Annex 22 covering artificial intelligence. Final publication and application are expected to follow in the period after that, so anyone doing computerised systems work for a European client is currently working across both the old and the emerging text, and saying so accurately is itself valuable to a client.

The failure patterns, named

Data integrity findings repeat with such regularity that they can be listed, and every one of them is preventable by design.

Shared or generic accounts, so that no action can be attributed to a person.

Administrator privileges held by the people who perform the work, so the same person can run a test and delete the result.

Audit trails disabled, never configured, or never reviewed. Never reviewed is the most common of the three: the trail exists, and no human has ever looked at it.

Deleted or unsaved acquisitions — the "trial injection" pattern from the opening of this chapter, where samples are run unofficially and only a satisfactory result is formally recorded.

Back-dating and transcription — records completed later and dated as though contemporaneous.

Uncontrolled spreadsheets doing calculations that decide product release, with no version control, no audit trail and no validation.

System clocks that users can change, which quietly defeats every timestamp in the system.

And the largest of all, in terms of consequences: a culture where a failed result is a personal problem. If an analyst believes that reporting an out-of-specification result will be held against them, the system's technical controls are working against the incentives of the people using it, and eventually the incentives win.

The enforcement consequences are severe and specific. Data integrity findings have produced import alerts, warning letters, consent decrees and, in the most serious cases, the agency's application integrity policy, which halts review of every application from that company until the reliability of its data is established. This is the one area where a compliance problem becomes an existential one, and it is why clients react to data integrity questions with an intensity that can seem out of proportion until you understand the ladder from Chapter 25.18.

What this means for the systems you build

Translate the whole chapter into engineering requirements and it becomes a short, checkable list.

Requirement	What it means in code
Attributable	Individual accounts, no shared logins
Contemporaneous	Server time, never client-supplied
Original	Raw data retained, not just reports
Complete	Soft deletes only, nothing purged
Audit trail	Append-only, immutable, human-readable
Access control	Roles with authority checks on signing
Available	Retention, migration, readable export

Four design decisions cause most of the trouble, and all four are cheap at the start and expensive later.

Time. Every timestamp must come from a controlled source, ideally the server, synchronised, and stored with its zone. A record whose time came from a user's laptop cannot support attribution.

Deletion. A GxP system does not hard-delete. Records are marked inactive with a reason and a signer. This includes the ones your product owner insists are "just drafts" — a draft that influenced a decision is a record.

The audit trail's readability. Build the review interface at the same time as the trail itself. A trail nobody can review is the finding, and the review requirement means somebody will need to look at it every week for years.

And validated interfaces. When data moves between systems, the transfer is part of the record's integrity: it must be verified, failures must be visible rather than silent, and reconciliation must be possible. Silent data loss in an integration is a data integrity event even though no person did anything wrong.

One last piece of advice that will make you unusually effective with these clients. Do not treat Part 11 as a checklist to satisfy at the end. Treat it as an architecture: identity, immutable history, controlled time, controlled deletion, controlled export. Systems built that way pass validation quickly and cheaply. Systems built normally and then made compliant are rebuilds, and everyone involved remembers who promised otherwise.

Next: Chapter 25.21, how a computer system is actually validated — GAMP 5, the specification-and-verification chain, the risk-based approach, and how modern development practice fits inside it.