An audit trail is a table, and it only records what it is pointed at
Underneath every audit trail is a table: one row per event, with a user, a timestamp, the object touched and, in a good design, the value before and the value after. That table holds what the system was configured to send to it and nothing else. Switch trailing on for the deviation record but not for its comment field, and the comment has no rows. Run the investigation in a spreadsheet and the CAPA in a ticketing tool, and each system keeps its own table, with no row anywhere for the hand-off between them. Three validated systems, three trails, and the sequence an inspector asks for, from raised to closed, lives in the gaps between the tables.
Nothing in that picture is hidden or falsified. The trail has still failed its only test. This post is about why trails that exist still fail, and what a trail that survives inspection has to contain. The audit trail term covers the definition; the failure modes are below.
What the trail is for: the regulators' definitions
It helps to start from the definitions, because most failures are failures against the definition, not against some higher bar.
- 21 CFR §11.10(e) asks for a secure, computer-generated, time-stamped audit trail that independently records the date and time of operator entries and actions that create, modify or delete electronic records, where record changes do not obscure previously recorded information, retained at least as long as the record and available for review and copying.
- FDA's 2018 Data Integrity Q&A describes the audit trail as the record that allows reconstruction of the course of events relating to the creation, modification or deletion of a record, and expects trails capturing changes to critical data to be reviewed.
- EU GMP Annex 11 (§9) asks, based on risk, for a system-generated record of all GMP-relevant changes and deletions, with the reason documented, and for trails to be available, convertible to a readable form and regularly reviewed.
- PIC/S PI 041-1 adds a distinction worth keeping: a data audit trail (changes to GMP data) is not the same as a system audit trail (logins, configuration, privilege changes), and both matter. It also expects the functionality to be enabled and locked so users can't switch it off.
One test runs through all four: can a reviewer reconstruct who changed what, when, why, and what it was before, without leaving the record? Every failure below is a way that test comes back "no".
Where a digital audit trail breaks: seven mechanisms
These are ordered roughly by how early in a system's life they happen. The first three are configuration. The next three are architecture. The last is people.
1. It is not switched on. Many platforms ship with audit trailing per module, per object type, or per field, and default to off for performance. The validation package says "audit trail: yes" because the capability exists. Nobody checked which records it was enabled for. Warning letters citing an audit trail that was disabled, or never enabled for the instrument in question, are a recurring data-integrity observation.
2. It logs the event, not the value. "Result modified by JSMITH 14:02." Modified from what, to what? §11.10(e) is explicit that changes must not obscure previously recorded information. A trail with no before-value obscures it by omission. Reason-for-change is the companion failure: a free-text field that reads "update", "typo" or is blank.
3. Every change belongs to the same account. Shared logins on the floor. A generic "LAB_ADMIN". A service account that the integration uses to write results. Attributability is the first letter of ALCOA+ and the first thing an investigator tests. FDA's Q&A is direct: systems must attribute actions to individuals.
4. The trail lives in a different system from the decision. The deviation's history is in the eQMS. The decision to close it was made in a meeting recorded in a document management system. The CAPA that resulted lives in a third tool. Each trail is complete about its own fragment and silent about the chain.
5. Integrations rewrite history. An ERP sync updates a material status. A LIMS interface pushes results into the batch record. A middleware job "corrects" a field overnight. Each of these writes as a system identity, often without a reason, sometimes overwriting rather than appending. The trail is technically intact and practically unattributable.
6. Exports drop the trail. The record is complete on screen. The PDF sent to the sponsor, or the archive package, or the migration extract, carries the final values and none of the history. §11.10(b) asks for accurate and complete copies; a copy without its audit trail is neither. The same thing happens, slowly, at migration: the records move, the trail stays behind in a system that's about to be switched off.
7. Nobody reads it. The trail is on, complete, attributed, in one place, and has never been opened by a human being. It's a log. Review, with evidence that review happened, is what turns it into a control (more on that below).
Any one of these produces a record that can't explain itself. Most sites that fail have three or four at once.
The hand-off problem: where most trails break
Failures 4, 5 and 6 share a cause. Inside any single well-configured system, audit trails mostly work. They break where systems meet, and quality processes cross more seams than most teams realise.
Take a single deviation and count the boundaries it crosses:
| Step | Where it happens | The seam question |
|---|---|---|
| Raised | eQMS deviation record | Who raised it, and was the initial description ever edited? |
| Impact assessment | A spreadsheet or a risk tool | Is that assessment linked to the deviation, or attached as a PDF that carries no history? |
| Lab investigation | LIMS / CDS | Do the reprocessing and reintegration events on the raw data appear anywhere the deviation reviewer can see? |
| Root cause | A meeting; minutes in a document system | Who decided, when, and is the decision tied to the record it changed? |
| CAPA | Ticketing tool, or a second eQMS module | Is the action's history readable from the deviation, or only from the ticket? |
| Change | Change-control record | Does the change reference the deviation, and does the deviation reference the change? |
| Closure | eQMS | Who closed it, with what meaning, and can they see all of the above at closure? |
Four other seams cut across that table and are rarely owned by anyone:
- Time. The eQMS on one clock, the LIMS on another, the instrument PC set by hand. A trail is only reconstructible if the timestamps agree. Time-source control is a system-level audit-trail requirement, not an IT nicety.
- Identity. SSO makes the same person one identity across systems, which is good. Local accounts on instrument PCs and service accounts on integrations undo it. The trail attributes to whatever identity the system saw.
- Vendor releases. A SaaS platform changes what it logs, or how, in a release you didn't schedule. If the trail's behaviour isn't in your validated scope with release-by-release re-verification, you're trusting it blind. The multi-tenant audit-trail problem goes deeper on that.
- Migrations and decommissioning. Records get migrated; trails often don't, because they're bigger, messier and "not the data". Part 11 wants the trail retained as long as the record. A record without its history is a record you can no longer defend.
The design answer isn't "one system for everything". It's that wherever a process crosses a seam, the link has to be a record, not a person's memory: the deviation carries the reference to the investigation and the CAPA, the CAPA carries the reference back, and each side's trail is reachable from the other.
What a reviewable trail needs
Turning the definitions into tests you can run against your own system:
| Expectation | The test | What "fail" looks like |
|---|---|---|
| Enabled and locked | Show me the configuration, per record type, and who can change it | Per-module toggle; administrators can disable it |
| Attributable | Pick five changes; name the human behind each | Shared, generic or service accounts on GMP data |
| Before-value preserved | Pick a corrected result; show the original | "Field updated" with no prior value |
| Reason captured | Read ten reasons-for-change | Blank, "update", "typo" |
| Independent time | Compare timestamps for one event across two systems | Drift of minutes or worse; hand-set clocks |
| Readable in context | Open the trail from the record, without IT | A database export, decoded by someone else |
| Complete across seams | Walk one deviation raise-to-close | Gaps that have to be narrated |
| Survives copies and migration | Export a record; produce its history from the export | PDF of final values only |
| Reviewed, with evidence | Show me who reviewed this record's trail and when | "We review quarterly" with no record of it |
Nine rows. Download the audit trail review checklist to turn them into a form with evidence, reviewer and status columns, so the check itself leaves a trail.
Audit-trail review: the control that makes the trail count
Failure 7 deserves its own section because it's the one regulators have been most explicit about, and the one most sites still get wrong.
Who and when. FDA's 2018 Q&A: trails that capture changes to critical data should be reviewed with each record and before final approval, by the people who review the record, at a frequency justified by risk. Not IT. Not quarterly by exception. The batch reviewer reviews the batch record's trail as part of release. The QA approver reviews a deviation's trail before closing it.
What to look for. A useful review is a short set of questions, not a read of every line:
- Changes after approval or after review sign-off, and by whom.
- Deletions, aborted actions, and records that were created and removed.
- Reasons that don't explain the change.
- Timing that doesn't fit the process (results before the run ended; entries from one user on two instruments in the same minute).
- Privilege use: administrator or service-account actions on production data.
Periodic, system-level review sits on top of record-level review and looks for patterns across many records: account anomalies, unusual volumes, time-source drift, and whether the trail was available for the whole period.
Evidence. The review is only a control if it left a record: what was reviewed, by whom, when, what was found, what was done about it. MHRA calls this out; the revised Annex 11 draft (published for consultation 7 July 2025) devotes a block of subsections to audit trails and their review, and most sites will find that the review evidence is the gap.
What a broken trail costs day to day
The inspection is the visible cost. The daily cost is larger and quieter:
- QA time spent reconstructing evidence instead of reviewing quality.
- Release decisions that wait while someone reconciles three systems.
- Audits (customer and internal) that run a day longer because the story has to be told rather than shown.
- Repeat observations, because the weakness is structural and the CAPA addressed one record.
- Migration projects that discover, late, that the history can't come along.
Leadership feels this as delay. QA feels it as the same reconstruction, over and over.
Test one closed deviation
Pick a deviation that closed last quarter. Not the tidy one. Five steps, and the test is whether you can do each one from the screen in front of you.
- Open it. From that screen, can you see who raised it, who changed the description, and what it said before?
- Follow it to the investigation. Are the lab's reprocessing events visible from here, or only in the lab system?
- Follow it to the CAPA. Does the action's history read from the deviation, or do you have to switch tools?
- Find the closure. Who closed it, with what meaning, and did they review the trail first? Where is the evidence?
- Export it. Does the export carry the history?
Any step you had to narrate is a hand-off an inspector will find.
How Complere supports audit trails that hold together
One record, one history. The deviation, its investigation, the actions it produced and the change it triggered stay tied together, so walking from raise to close is reading one thread, not stitching three.
Nothing changes without leaving a mark. Every create, edit, approval and deletion carries who did it, when, what it was before and why. Corrections keep the original in view.
Every action has a person behind it. Users act under their own credentials, with the actions their role allows, so "who did this?" is answered by the record, never by asking around.
Review is a step, not a chore. A reviewer reads the history on the record itself, in plain language, and can mark that they reviewed it, so the evidence that review happened exists without a separate process.
The history comes with the record. When you produce a copy for an auditor or a sponsor, the trail travels with it, for as long as the record is kept.
Which records are critical, how often trails are reviewed and what counts as an anomaly are still your decisions. The system's job is to have the trail there, complete and readable, when you make them.
