Most data integrity programmes fail in the same way. Someone runs a gap assessment, produces a long spreadsheet of findings, and the findings are remediated one document at a time until the budget runs out. Eighteen months later the same assessment produces a similar list.
That happens because the assessment measured documents rather than behaviour. ALCOA+ is not a documentation standard. It describes properties that data either has or does not have at the moment it is created, and documentation is only evidence about whether it does.
This is how we approach data integrity (ALCOA+) so the result holds rather than drifting back.
The principles, and which ones actually break
Attributable, legible, contemporaneous, original and accurate, extended with complete, consistent, enduring and available. The list is well known. What is less discussed is that they do not fail at equal rates, and a programme that treats them evenly spends most of its effort on the ones that were never at risk.
Legible and enduring rarely fail in a modern validated system — they were engineering problems that the platform solved. Attributable fails constantly, through shared accounts and shared workstations. Contemporaneous fails constantly, through late entry that is normal practice and undocumented. Complete fails in the one place nobody looks, which is the data that was captured and then excluded from a reportable result.
Weight the assessment accordingly. The point is to find the gaps that exist, not to demonstrate coverage of a framework.
Original data, and the question most assessments miss
Where is the original, and can you still get to it. In a laboratory this is the chromatographic raw data rather than the summary report. In a control system it is the historian value rather than the trend print. In a spreadsheet-based process it is whatever the spreadsheet was built from, which is frequently nowhere.
Two failures recur. The first is retention policy that quietly destroys originals while retaining the derived record — a historian that aggregates older data, an instrument whose raw files are purged on a shorter cycle than the batch record that cites them. The second is originals that technically exist but cannot be produced, because the software that reads them is no longer installed anywhere.
Test this by asking for something specific: produce the original raw data for a result in a batch released two years ago. The time it takes to answer is the finding.
Attributable, in a world of shared workstations
Shared accounts are the most common data integrity finding and the one with the most legitimate operational reason behind it. A control room operator wearing gloves, a production line where authentication delay has a real cost, a laboratory instrument whose software supports one login.
Pretending this does not exist produces a programme nobody follows. The workable position is proportionate: unique attribution for actions that create or change a regulated record or affect the process, with session design that makes that practical rather than obstructive. Where a legacy instrument genuinely cannot support individual accounts, the mitigation is a documented, risk-assessed compensating control — a contemporaneous logbook tying the session to a person — rather than silence.
What matters is that the position is deliberate and documented. An inspector is far more comfortable with an assessed limitation and a compensating control than with a shared account nobody has acknowledged. Where signatures are involved, 21 CFR Part 11 sets the bar they have to clear.
Audit trails: the control that exists and is never used
Almost every validated system has a complete audit trail. Very few organisations review them. An audit trail that has never been reviewed is a control on paper, and the gap between having one and using one is where the most serious findings come from.
Review has to be targeted to be real. Reviewing everything means reviewing nothing. What is worth looking at is narrow and consistent: changes to results or records after approval, changes made outside expected working patterns, repeated invalidations or re-tests clustered on one person or one instrument, modifications to configuration items that control a pass or fail decision, and signature events that do not match the shift pattern.
Define what is reviewed, how often, by whom, and what the reviewer is looking for. Then make the review produce a record, because a review with no output is indistinguishable from no review.
Spreadsheets, honestly
Spreadsheets remain in GxP processes everywhere, and the standard advice — eliminate them — is correct and rarely actionable at the pace it is given. The realistic approach is to triage.
A spreadsheet that performs a calculation contributing to a GxP decision is a validated system whether or not anyone has treated it as one, and it needs the same controls: version control, protection of formulas, attribution, and a retained original. A spreadsheet used to arrange information that is recorded properly elsewhere is a working tool and can be left alone.
Sorting the population into those two groups is usually a week of work and immediately reduces the problem, because most spreadsheets turn out to be in the second group. GxP software vs. spreadsheets covers where the line sits.
Why remediation stalls
It is not negligence and it is rarely ignorance. It is effort. If correcting a data integrity gap means a person reading every approved document to work out what the correction touches, it will be deferred for anything that looks small — and the deferrals accumulate into the same assessment finding next year.
Two things change this. Fix the per-change cost rather than the backlog, so that doing it properly stops being a judgement call. And fix documentation at the point of change rather than through a dedicated remediation project: do not reopen a system because its paperwork has drifted, revise it the next time a change gives you a legitimate reason to open it.
A full re-baseline of a validated estate is a large, unpopular initiative that is frequently abandoned halfway. The incremental route is slower on paper and finishes more often.
Measuring the state rather than the project
Data integrity is a condition, not a deliverable, so it should be measured continuously and reported like any other operational metric. Four questions, asked of a system picked at random rather than one somebody prepared, tell you more than a completed assessment.
- When was the last audit trail review, what did it look at, and what did it find?
- Can you produce the original data behind a result in a batch released two years ago?
- Which GxP-relevant configuration items can be changed without an approval, and who can change them?
- How many shared accounts exist in GxP systems today, and does each have a documented compensating control?
If any of those takes more than a few minutes, that is the gap. It was there before anyone asked. data integrity (ALCOA+) and audit readiness are the practices, and book a demo if you want an estate assessed rather than a framework mapped.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
