Data Integrity for QA Teams: ALCOA++ and Audit Trail Guide

The hardest question an assessor asks in a laboratory is usually this: “Did you record this result exactly as you are showing it to me, or was it corrected afterwards?” It is not enough for a result to be correct; you must be able to prove that it is correct and that it has not changed since it was produced. Data integrity is precisely this question of provability.

The concept originated in the pharmaceutical sector, but it is now firmly on the agenda of accredited testing and calibration laboratories. ISO/IEC 17025 explicitly requires records to be protected and amendments to be traceable, and accreditation assessments increasingly ask who touched the data. This article sets out the ALCOA++ principles and how an audit trail should be designed, written for QA teams.

From ALCOA to ALCOA++: How the Framework Evolved

The ALCOA acronym was introduced by the US FDA in the early 1990s and defined five essential attributes of a record. Four further principles were added over time, producing ALCOA+. Most recently a tenth principle — Traceable — was added, giving the ALCOA++ framework. The revision of EU GMP Chapter 4 is expected to place these ten principles into binding text.

For laboratories the practical meaning is this: “we have a record” is no longer sufficient. Who the record belongs to, when it was created, whether it was subsequently changed and, if so, what changed and why — each must be demonstrable.

The ALCOA++ principles and what they mean in a laboratory

Attributable: Every record must be tied to a person. A shared “lab” account breaches this principle outright.
Legible: Records must be readable and permanent. A pencil-written worksheet or a value obscured with correction fluid is not acceptable.
Contemporaneous: Records must be made at the time of the activity. Batch entry at the end of the day is one of the most frequently cited findings.
Original: Raw data must be preserved. Instrument output should not be deleted in favour of a summary table.
Accurate: The record must reflect reality, with defined verification and review steps.
Complete: Repeat analyses, failed attempts and cancelled records are part of the data set — you cannot keep only the “good” results.
Consistent: Date and time formats, units and sequencing must follow the same logic across all records.
Enduring: Records must survive intact for the full retention period. A sticky note or a spreadsheet in a personal folder is not an enduring record.
Available: Records must be retrievable within a reasonable time during an assessment. A record that exists but cannot be found is, in practice, a record that does not exist.
Traceable: The tenth principle. Every change to data or metadata must be reconstructable in sequence, with attribution and timestamps, without obscuring the original.

A critical distinction: data integrity is not about protecting data but about making it accountable. Backups protect data from loss; an audit trail tells the story of the data. One does not substitute for the other.

What an Audit Trail Is — and What It Is Not

An audit trail is a time-ordered, tamper-evident record of the actions performed on a record. A well-designed audit trail answers four questions: who, when, what and why.

The most common misconception in the field is that system logs serve as an audit trail. A server log says “this user signed in at this time”; an audit trail says “this user changed the pH result of sample 8 from 7.2 to 7.4 at 14:32, reason: instrument calibration drift”. It is the second that an assessor is looking for.

What an audit trail must contain

Old and new values together: The previous value must not be deleted; a system that stores only the latest state provides no traceability.
User identity: The individual performing the action must be identifiable; shared accounts render an audit trail meaningless.
Time information: Taken from the server clock and not alterable by the user.
Reason for change: For result data in particular, a reason field should be mandatory.
Immutability: Audit trail entries must not be editable or deletable by users — administrators included.
Reviewability: The trail must be filterable and reportable so that the QA team can review it periodically.

Keeping an audit trail is not enough — it must be reviewed

In many laboratories an audit trail exists but nobody looks at it. The expectation of the framework, however, is that the trail is reviewed regularly. A monthly QA review covering at least result changes and cancelled records catches nonconformities early and answers the assessment question “who reviews the trail?”

The review itself must also be recorded: who reviewed which period, when, and whether anything was found. Without that record, the statement “we review it regularly” carries no weight during an assessment.

Habits That Undermine Data Integrity

The findings most frequently raised during assessments

Shared user accounts: Everyone using the same login on an instrument PC. This alone defeats attributability.
End-of-day batch entry: Results written on paper and typed into the system in the evening. This breaches contemporaneity and loses intermediate records.
Deleting raw data: Removing instrument output after transfer; the originality principle is violated.
Managing results in spreadsheets: Formula changes leave no trace, cell history is not retained, files can be copied. A spreadsheet is a calculation tool, not a record system.
Testing into compliance: Repeating an analysis until the desired result appears and not recording earlier attempts. This is the gravest breach of completeness.
Alterable system clocks: If a user can change the instrument or workstation clock, every time record becomes contestable.

Most of these stem from habit rather than intent. Indeed, the majority of findings raised in assessments concern lack of traceability rather than data falsification. The consequence is the same, however: the laboratory is unable to prove that its result is correct.

A Quick Pre-Assessment Checklist

Work through the following questions with your QA team. Every “no” points to a gap that may well become a finding.

Data integrity self-assessment

Do instrument workstations use individual accounts, or is there a shared login?
Are results recorded at the time of the activity, or entered in batches at day’s end?
Is raw instrument data retained, or only the transferred summary?
When a result is changed, can the previous value still be seen?
Is a reason required for the change?
Does someone review the audit trail regularly, and is that review recorded?
Do cancelled and repeated analyses remain in the system?
Can users change the system clock?
Do records remain accessible and readable throughout the retention period?

What to Watch When Moving from Paper to Digital

Digitalization does not deliver data integrity automatically; a poorly configured system can be riskier than paper. A correction on paper leaves a trace — it is struck through and initialled. A change in a spreadsheet cell leaves none.

Common mistakes during the transition

Leaving spreadsheets as an intermediate layer: From instrument to spreadsheet, then into the system. Traceability breaks at the intermediate step.
Defining permissions too loosely: Granting edit rights to everyone makes the audit trail meaningless. Permissions should match what the role actually requires.
Switching the audit trail off: Disabling logging “because it slows things down” is the most dangerous mistake of the entire transition.
Not migrating historical data: If older records become inaccessible, the retention obligation is breached.
Going live without verification: That the system performs as intended should be tested and recorded before it is put into use.

The Relationship with ISO/IEC 17025

ISO/IEC 17025:2017 does not use the term ALCOA++; its requirements, however, align closely with these principles. The standard requires technical records to contain sufficient information for each activity, original observations and derived data to be retained, amendments to records to be traceable, and data held electronically to be protected.

ALCOA++ is therefore a practical way of operationalising the record requirements of ISO/IEC 17025. Its advantage for QA teams is that it offers a concrete checklist: ask “how would we prove this?” for each of the ten principles, and the gaps in your system surface quickly.

Where Does Software Fit In?

Data integrity is a working culture, not a software feature. In a paper- and spreadsheet-based setup, however, satisfying most of the ten principles is close to impossible: attributability requires individual accounts, contemporaneity requires recording at the moment of the activity, and traceability requires an immutable change history.

How WiseLIMS supports data integrity

Individual accounts and role-based permissions: Every action is tied to a user, removing the need for shared logins.
Change history: Changes to records are stored with both old and new values; previous values are not overwritten.
Real-time recording: Results are entered as the work happens and stamped with the server clock.
Cancelled and repeated records: Repeat analyses and cancelled entries remain in the system, keeping the data set complete.
Electronic signature and report versions: Approved reports are signed, and revisions are tracked as separate versions.
Isolated database and backups: Each organisation’s data is held separately, with daily automated backups and a 10-year retention commitment.

Conclusion

Data integrity is the quietest risk a laboratory carries. Your results may well be correct and your team diligent; but if all you hold at the moment of a dispute or an assessment is a table showing the final state, proving correctness becomes difficult. The ALCOA++ framework makes that gap visible; the audit trail closes it.

To test your own system quickly, ask: “For a result changed last month, could we show the previous value, who changed it and why — in five minutes?” If the answer is no, there is a gap to close before your next assessment.