ALCOA+ and Data Integrity: How the Principle Becomes System Design

ALCOA+ is a design test, not a poster

Data integrity means more than preventing accidental deletion. The MHRA GxP data integrity guidance describes expectations across GxP sectors and discusses data criticality, inherent integrity risk, data governance, audit trails, review, retention, and validation for intended purpose. The PIC/S guidance on data management and integrity similarly frames good records as attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available.

These qualities are useful because they turn a broad compliance objective into design questions. If a record cannot be attributed to a person or system event, the workflow needs an identity control. If a change cannot be reconstructed, the audit trail or retention design needs attention. If a result is entered long after the activity without explanation, the procedure and timestamp model may be weak.

Turn each principle into a requirement

• Attributable: identify the person, system, or instrument responsible for an action. Avoid shared accounts when individual attribution matters.
• Legible: preserve records in a form people can read and interpret throughout the retention period.
• Contemporaneous: record events at the time of the activity, or document and investigate justified exceptions.
• Original: preserve the source record or a verified true copy, including relevant metadata.
• Accurate: use validated calculations, controlled inputs, review, and error handling.
• Complete and consistent: retain the full sequence, including relevant changes, repeat runs, exceptions, and decisions.
• Enduring and available: protect records from loss or silent alteration and make them retrievable for the required period.

Look beyond the application screen

A data-integrity assessment should follow the data lifecycle. Trace data from creation through processing, review, approval, export, migration, backup, restoration, archival, and disposal. Note interfaces and manual transcription points. A clean front end cannot compensate for an uncontrolled spreadsheet export, an unreviewed integration queue, or a backup that has never been restored successfully.

Evidence that supports the claim

Requirements should state the integrity need. Risk assessment should explain the impact of failure. Tests should challenge the control under realistic conditions. Procedures should assign review and escalation. Periodic review should confirm that the control still works after changes in people, process, configuration, or supplier. Keep the chain together so the conclusion is supported by more than a screenshot.

Data integrity is strongest when the normal workflow makes the right record easier to create than the wrong one.

The VLMS glossary and readiness tools can help teams organise the vocabulary, but the final requirements must come from the regulated process and its risks.