ALCOA+ in practice: what data integrity actually demands of your systems

Every quality manual quotes ALCOA+. Far fewer translate it into decisions about how systems are built and configured — which is precisely where audit findings come from. An inspector does not cite you for failing to recite the acronym; they cite you because a record could not be attributed, a timestamp did not reflect reality, or an original value was overwritten and nobody could prove otherwise.

This is a walk through each principle as a system requirement: what it demands, how it typically fails on a real shop floor, and what a system has to do to satisfy it.

Where ALCOA+ comes from

ALCOA was coined at the FDA in the 1990s as a memory aid for what a good record looks like. The "+" arrived later, through MHRA and PIC/S guidance, adding four attributes that the original five implied but did not state. The framework now sits behind FDA 21 CFR Part 11, EU GMP Annex 11 and the data-integrity guidance most regulators publish.

It applies to paper and electronic records alike. But paper fails these tests in ways that are visible and slow, while electronic systems fail them in ways that are invisible and fast — which is why system design carries so much of the burden.

The original five

Attributable — who did this, and when

Every record must trace to the person or instrument that produced it. The common failure is not fraud; it is convenience. Shared logins on a shop-floor terminal, a supervisor entering readings on behalf of an operator, a datalogger export with no indication of who pulled it.

Systemically this means individual accounts, no shared credentials, and machine-generated values attributed to the instrument rather than to whoever happened to be logged in. Where a human action carries regulatory weight, an electronic signature should be distinct from the login — a signing PIN, applied at the moment of the act, with its meaning declared.

Legible — readable, and still readable in ten years

Legibility is not only handwriting. For electronic records it means the data remains readable and interpretable for its full retention period, including the metadata that gives it meaning. A CSV of timestamps and numbers whose tag names lived only in a decommissioned SCADA system is no longer legible in any useful sense.

Contemporaneous — recorded when it happened

The record must be made at the time of the activity. This is the principle that paper-based process data almost never satisfies: an operator reads a display at 14:32, writes it on a scrap, and transcribes it into the batch record at the end of the shift. The value may be correct; the record is not contemporaneous, and the timestamp is fiction.

Capturing at the source is the only structural fix. When a process historian records the reading as the device emits it, the timestamp is the event time rather than the typing time — and the batch record can reference that value instead of a transcription of it.

Original — the first capture, preserved

The original record, or a certified true copy, must be preserved. In practice this is where "we keep the summary report" becomes a finding. If the raw event was discarded, or silently corrected, or exists only as an aggregate, the original is gone.

Write-once storage of the incoming event answers this directly: the raw data is kept as received and is not edited by the application, so any figure on a report can be traced back to what the instrument actually sent.

Accurate — correct, and demonstrably so

Accuracy covers both the value and the metadata around it. Industrial protocols carry a quality code alongside the reading for a reason: a temperature of 4.4 °C from a sensor reporting bad quality is not an accurate record of the cold room, it is an accurate record of a sensor problem. Systems that discard quality codes on ingestion destroy the very evidence that distinguishes the two.

The plus: complete, consistent, enduring, available

The four additions close the gaps the original five leave open.

• Complete — including repeat analyses, failed runs and readings that could not be decoded. A system that silently drops malformed events produces a tidy dataset and an incomplete record. Failed events should stay visible and be reprocessable once the cause is fixed.
• Consistent — records in sequence, with time stamps that agree across systems. Synchronised time is a data-integrity control, not an IT nicety; two systems drifting apart make a reconstruction of events arguable.
• Enduring — durable for the full retention period, on media and in formats that survive it. A spreadsheet on a shared drive is not enduring, whatever the retention policy says.
• Available — retrievable for review throughout that period. Data that exists but takes three weeks and a specialist to extract fails this in the only test that counts, which is an inspection.

The audit trail is where it is decided

Most of ALCOA+ collapses into one question an inspector can ask directly: can you show me everything that happened to this record?

An audit trail that answers it records not just the change but who made it, when, and what the value was before. Chaining entries with a hash, so each references the one before it, adds the property that matters most: retroactive tampering becomes detectable, because altering an old entry breaks the chain from that point on. Without that, an audit trail asserts history rather than evidencing it.

If the audit trail can be edited without trace, every other control on the list is a matter of trust rather than proof.

What this means when you specify a system

Turning the framework into requirements is more useful than quoting it. A defensible specification asks, at minimum:

1. Is the value captured at its source, with the origin timestamp and the quality code preserved?
2. Is the raw event stored write-once, and is retention explicitly configured?
3. Is every configuration and data change recorded in an audit trail with integrity verification?
4. Are accounts individual, permissions role-based, and electronic signatures distinct from login credentials?
5. Are failed or undecodable events visible and recoverable rather than dropped?
6. Can the data be retrieved, in context, by someone who is not the person who built the system?

Those questions belong in your computerised system validation under GAMP 5, not in a separate compliance review after go-live. Validating a system whose architecture cannot satisfy them is an expensive way to document a gap.

Process data and the execution record

Those requirements split along a natural line: whatever records the measurement, and whatever records the act of using it. NEO PI owns the process data: capture at the source across OPC-UA, MQTT and LoRaWAN, write-once raw events, quality codes preserved, hash-chained audit trail, and a read API that lets the batch record reference a value rather than a transcription of it. NEO EBR owns the execution record: enforced sequence, in-process controls that read from the historian, and electronic signature on the steps that carry regulatory weight.

Both sit inside a wider digital compliance posture — and if you are still early in that route, the paper-to-paperless roadmap covers the usual sequence, while environmental monitoring is often the least disruptive place to start.