Audit Trails and Data Integrity: ALCOA+ in Practice

Audit trails and data integrity are two of the most scrutinized topics in any lab inspection today, yet a lot of labs are still winging it. This post breaks down what ALCOA+ actually requires, what a solid audit trail looks like in practice, and where most small and mid-size labs quietly fall short.

What ALCOA+ Actually Means (Beyond the Acronym)

You've probably seen the acronym before. ALCOA stands for Attributable, Legible, Contemporaneous, Original, and Accurate. The plus adds Complete, Consistent, Enduring, and Available. FDA, WHO, and most regulatory frameworks use some version of this as the backbone for data integrity expectations.

But here's the thing — ALCOA+ isn't a checklist you run through once a year. It's a description of what good data looks like at every step of the analytical process. Every entry, every result, every correction.

Let's translate each piece into something useful:

• Attributable: You know who recorded the data and when. No shared logins. No mystery entries.
• Legible: If it's on paper, someone other than the author can read it. If it's electronic, it renders correctly and doesn't depend on a discontinued software version.
• Contemporaneous: Data is recorded at the time of the activity — not reconstructed afterward from memory or rough notes.
• Original: You have the raw, unaltered record. A transcribed number with the original discarded doesn't cut it.
• Accurate: The record reflects what actually happened. No rounding that changes significance, no selective data exclusion without documented justification.
• Complete: All data is there, including failures, repeats, and anomalies. Cherry-picking passing runs is a serious integrity violation.
• Consistent: Timestamps, units, and identifiers are applied the same way every time, everywhere.
• Enduring: Records survive the retention period — not on a USB drive someone's dog chewed, not in a shared drive that gets purged every two years.
• Available: Authorized reviewers can access records when they need to, including during an unannounced inspection.

Why Audit Trails Are the Teeth Behind ALCOA+

ALCOA+ tells you what data integrity looks like. An audit trail is how you prove it.

An audit trail is a secure, time-stamped, chronological record of every action taken on a record — who created it, who viewed it, who changed it, and what the previous value was before any edit. It should be automatic, not something an analyst manually fills in.

Think of it like the revision history in a Google Doc, except tamper-evident and regulated. If an analyst changes a result from 98.2% to 98.6% three days after the original entry, the audit trail captures the original value, the new value, the timestamp, and the user ID. A reviewer can see the full picture.

Without a proper audit trail, you're essentially asking inspectors to take your word for it. That doesn't go well.

The Most Common Audit Trail Failures in Small Labs

I've seen labs of all sizes get tripped up on audit trails. The problems tend to cluster around a few familiar patterns.

Shared User Accounts

This is the most common and most damaging failure. When two analysts share a login, attributability goes out the window. You can't tell who made an entry, which means every data point under that account is questionable.

Fix this before anything else. Every person who touches data needs their own credential.

Paper Records With No Traceability

Paper isn't inherently non-compliant, but it has to be managed carefully. Corrections need a single line through the original entry, the corrector's initials, a date, and a reason. White-out, erasure, or overwriting is a red flag that will get flagged immediately.

A lot of labs say they do this. When you look at their notebooks, they do it maybe 60% of the time. That inconsistency is the problem.

Electronic Systems Without Audit Trail Configuration

Some labs use spreadsheets or basic software that technically supports audit trails — but nobody turned the feature on. Or the audit log exists but is stored in a location that analysts can edit. An audit trail that can be deleted or modified by the same person it's auditing isn't an audit trail.

Gaps in Raw Data Retention

Raw instrument files — chromatograms, spectral data, balance printouts — are original records. If your SOPs only require saving the final report and not the underlying data files, you have a data integrity gap. Inspectors will ask for raw data. If you can't produce it, expect a finding.

What a Reviewable Audit Trail Actually Looks Like

Let's use a concrete example.

Suppose Meridian Analytical Lab runs a potency test on a cannabis extract. Analyst Jordan runs the HPLC assay on Tuesday morning and enters a THC result of 74.3% into the LIMS. Later that afternoon, Jordan notices a calibration error and re-runs the assay. The corrected result is 71.8%.

Here's what the audit trail should capture:

1. Tuesday 09:14 — Jordan (user ID: JT04) enters THC result: 74.3%. Associated sample ID: MER-2024-0882.
2. Tuesday 14:37 — Jordan (JT04) modifies THC result from 74.3% to 71.8%. Reason entered: "Calibration curve error identified — see deviation log DEV-0441. Assay repeated per SOP-HPLC-03."
3. Tuesday 14:38 — Supervisor Lee (user ID: LK01) reviews and approves the change.

That record tells a complete, coherent story. An inspector can follow it without asking a single question. If the audit trail just showed "74.3% changed to 71.8%" with no reason and no supervisor review, you'd have a problem.

A LIMS like Aliquora captures this kind of structured audit trail automatically — user, timestamp, original value, new value, and reason — so analysts don't have to remember to document changes manually.

How to Build Data Integrity Into Daily Lab Workflows

Data integrity isn't a one-time remediation project. It's a habit that either gets built into your procedures or doesn't exist.

Here are the practical moves that actually stick:

Make contemporaneous recording the path of least resistance. If analysts have to go out of their way to record data in real time, they won't. Design your worksheets, your LIMS screens, and your bench layout so that recording happens naturally as part of the workflow — not as an afterthought.

Separate data entry from data review. The analyst who runs the test shouldn't be the only reviewer. A second set of eyes catches transcription errors and keeps everyone honest. Build this into your SOPs as a hard requirement, not a nice-to-have.

Treat all data as reportable until it's formally excluded. If a run failed because the analyst knocked the sample over, that still gets documented. The exclusion needs a reason. "Analyst error" is a valid reason. Unexplained gaps are not.

Run periodic internal audits focused on data integrity, not just method compliance. Pull a sample of records every quarter and verify that the audit trail is intact, that raw data files are present, and that any modifications were properly documented and approved. Don't wait for an external inspector to find problems.

Train for the why, not just the what. Analysts who understand why data integrity matters — that it's about protecting patient safety, product quality, and scientific credibility — tend to be more careful than analysts who just memorized the rules.

Data Integrity Across Hybrid Paper-Electronic Systems

Most small and mid-size labs don't live entirely in either world. They have electronic instruments feeding into a LIMS, plus paper bench sheets, paper logbooks, and the occasional printout stapled to a folder. This hybrid reality creates specific risks.

The main danger is transcription. Every time data moves from one medium to another — from an instrument printout to a spreadsheet, from a spreadsheet to a paper form — there's an opportunity for error and an opportunity to lose traceability to the original.

Best practices for hybrid systems:

• Scan and attach paper records to the corresponding electronic record so they're co-located
• Require a verification signature when any value is transcribed from one format to another
• Retain the original paper document; don't discard it after scanning
• Timestamp electronic entries to match the paper record, and note that it's a transcription with the source document referenced

This won't eliminate all risk, but it creates a defensible paper trail (pun intended) that an auditor can follow.

Preparing for an Audit Trail Review

When an inspector asks to review your audit trails, they're usually looking for a few specific things. Here's what to have ready.

A list of who has access to what. User roles, permissions, and access levels. Who can create records? Who can edit them? Who can approve changes? Who can delete anything at all (ideally: nobody, or almost nobody)?

Evidence that the audit trail is turned on and tamper-evident. Can you demonstrate that the audit log can't be modified by regular users? Is it stored in a location with restricted write access?

A sample of recent records with associated audit trails. Pick a few COAs and be prepared to walk through the full history — every entry, every change, every approval — from sample receipt to final result.

Your data retention policy and evidence you're following it. Where are records stored? For how long? What's the backup schedule? Who verifies backups are recoverable?

If you can walk an inspector through all of this without scrambling, you're in good shape.

Frequently Asked Questions

What is the difference between an audit trail and an audit log?

These terms are often used interchangeably, but some systems distinguish between them. An audit log is typically the raw, machine-generated record of system events. An audit trail is the organized, reviewable history of changes to a specific record or dataset. In regulatory contexts, both refer to the same core concept: a tamper-evident, time-stamped record of who did what and when.

Does ALCOA+ apply to paper-based labs?

Yes. ALCOA+ applies to all data regardless of format — paper, electronic, or hybrid. Paper records just require different controls: legible entries in permanent ink, documented corrections, controlled access to notebooks, and reliable archiving. The principles are the same; the implementation looks different.

How long do audit trails need to be retained?

Retention periods depend on your regulatory context. FDA 21 CFR Part 211 typically requires records be kept at least one year beyond the product expiration date, or two years after distribution, whichever is longer. ISO 17025 doesn't specify a fixed period but requires labs to define and follow a retention policy. Cannabis and environmental labs often follow state-specific rules. When in doubt, your QA manager should define a minimum based on the most stringent applicable requirement.

Can a spreadsheet meet audit trail requirements?

Standard spreadsheets like Excel don't generate compliant audit trails by default. Excel's change tracking is limited, can be turned off by users, and doesn't capture the right level of detail for a regulated environment. If you're using spreadsheets for raw data entry, you're likely carrying a data integrity risk. Validated LIMS software or 21 CFR Part 11-compliant systems are a much safer choice for regulated labs.

What should I do if I discover a data integrity gap during an internal audit?

Document what you found, when you found it, and its potential scope. Initiate a CAPA. Assess whether any released results were affected and, if so, whether customers or regulatory bodies need to be notified. Don't try to quietly patch it — the cover-up is always worse than the original finding. A well-documented self-identified gap with a corrective action is far better received by inspectors than a gap they find themselves.