What an Inspector Actually Reads in Your Audit Trail

An auditor rarely starts with the result. They start with one record, and then they ask what happened to it after it was first written.

That question is answered by the audit trail, not by the notebook entry. The entry shows what the lab says it did. The trail shows the sequence of events behind it, including the parts nobody expected anyone to read: the value that changed at 10:03, the reason field left empty, the permission granted to an account that should not have had it.

Most compliance writing describes audit trails in the abstract. This piece does the opposite. Below is a single experiment record with eight audit trail entries, followed by a walkthrough of what each one proves, what it fails to prove, and which one would generate an observation.

What an audit trail is, and what it is not

Under FDA 21 CFR Part 11, an audit trail is a secure, computer-generated, time-stamped record that independently captures the date and time of operator entries and actions that create, modify, or delete an electronic record. Three words in that sentence do most of the work.

Independently means the trail is generated by the system, not written by the person being recorded. Time-stamped means the sequence can be reconstructed. Create, modify, or delete means the trail is not a change log bolted onto the side of a record. It is the history of the record’s existence.

Part 11 also requires that record changes not obscure previously recorded information, so the prior value has to remain visible rather than being overwritten. Audit trail documentation must be retained at least as long as the record it supports, and it must be available for review and copying.

A single record, eight entries

The record below is a method qualification run. Timestamps are UTC.

The creation entry: what governed the record

The first entry does more than establish who started the record and when. It names the template version, and the template version tells a reviewer which fields were required, which units were fixed, and which acceptance criteria were in force at the time the work was done. A record built on version 4 of a template cannot be fairly assessed against version 6 of the procedure.

What the entry does not prove is that the named person was the one standing at the instrument. Attribution establishes account activity. Tying account activity to a person is a matter of access control and training records, which is why inspectors ask about both.

The attachment: deciding which file is the original

The trail shows what was attached and when. A recorded hash adds something more useful: a reviewer can later confirm the file has not changed since it entered the record.

The harder question is which artifact is the original. A PDF chromatogram is a representation of the run. Where the instrument’s native data file is the original record, the trail should show that the native file was captured, not only its printed form. This is the point where labs most often discover that what they have preserved is a picture of the data rather than the data.

A correction that holds up

The injection volume change is a well-formed entry. The prior value is visible, the person and time are recorded, and the reason is specific enough to be checked against a second record. “Transcription error, corrected against instrument log” points a reviewer somewhere. They can go to the instrument log and confirm it.

Reason-for-change is where most audit trails succeed or fail. A reason field that is present but filled with “correction” or “per SOP” gives a reviewer nothing to verify, and an unverifiable reason invites the next question rather than closing it.

The entry that generates an observation

Forty-five seconds after the injection volume changed, the assay result changed by three percentage points with no reason recorded.

Read on its own, that entry may be entirely innocent. Read by a reviewer, it starts a different exercise. They will pull every change to result fields across the study, look at whether the changes move in a consistent direction, check whether any of them were reviewed, and ask whether the associated deviation was raised. One unexplained change to a reported value becomes a question about the whole data set.

It is worth naming what actually went wrong here, because labs often misdiagnose it. This is a documentation failure, not necessarily a data failure. The result may be correct. By the time the finding is written up, though, the distinction is difficult to recover.

The signatures: meaning is part of the requirement

Part 11 expects an electronic signature to carry the printed name of the signer, the date and time, and the meaning associated with the signature. “Signed” on its own is ambiguous. “Performed by” and “reviewed and approved” are two different assertions, and a reviewer expects to see which one applies.

The countersignature then raises the question the rest of this article turns on. The supervisor approved the record. Did the approval include reading the audit trail, and is there any evidence that it did?

The administrative entry most reviews miss

A few minutes after approval, an administrator granted analysts permission to delete experiments. System administration events belong in the trail alongside data events, and a reviewer treats a privilege change as a control question: who can now delete records, who authorized that, and was the change assessed before it was made.

Labs preparing for an audit tend to review data entries and ignore configuration entries. Inspectors do the opposite, because configuration determines what the data entries are worth.

What the gaps say

Some of the strongest signals in an audit trail are the entries that are not there.

• A generic or shared account. One login used by several people makes every entry under it unattributable. Shared credentials are among the most frequently cited findings in laboratory record inspections, and no amount of downstream review repairs them.
• A quiet period. A trail with no entries during a shift that produced data raises the question of whether the trail was disabled or the work was recorded elsewhere first.
• A trail a user can switch off. If audit trail generation is a configurable setting available to the people whose work it records, its evidentiary value drops sharply.
• No stated time basis. Timestamps without a defined time zone, or drawn from a local clock a user can change, are hard to reconcile across sites and shifts.

Why the review matters as much as the trail

FDA’s data integrity guidance for drug CGMP points toward reviewing audit trails for critical data as part of reviewing the record itself, before approval or release, rather than as a separate periodic exercise. The practical consequence is that the review needs a record of its own. A trail that nobody has demonstrably read is a control that exists on paper.

Regulatory direction elsewhere is consistent with this. The draft revision of EU GMP Annex 11 published in July 2025, with a final version still pending as of August 2026, would extend audit trail expectations to capture record creation events rather than only changes and deletions, and treats review before release as an explicit expectation. Labs that already document their audit trail reviews will find that direction unremarkable. Labs that generate trails and never open them will not.

If your lab is not inspected yet

Plenty of research groups reading this have never hosted an inspection. Early-stage biotechs working toward IND-enabling studies, academic labs that have just taken on an industry sponsor, and device teams heading into a first submission all share the same exposure: an audit trail is retrospective evidence, and it cannot be generated after the fact.

This is where documentation kept in Word files, spreadsheets, and shared drives runs out. Those tools record content. They do not independently record who changed a value, when, from what, and why, and no procedure written on top of them supplies that. The record either has a history or it does not, and the decision about which is made years before anyone asks.

Three questions to ask about your current system

1. If a value in a two-year-old record was changed, can you produce the prior value, the person, the time, and the stated reason without asking anyone to remember?
2. Does every person who touches a record have an individual account, including reviewers, supervisors, and occasional contributors?
3. Can you export a record together with its audit trail, in a form you could hand to an auditor or a sponsor, without vendor assistance?

How ELabELN handles this

ELabELN records a tamper-evident audit trail with cryptographic hashing on every entry, and it is included in every edition rather than gated behind a compliance tier. Electronic signatures are FDA 21 CFR Part 11 compliant and carry signature meaning, so “performed by” and “reviewed and approved” are distinguishable in the record and in the export. Records and their trails export in PDF, CSV, XML, and JSON with no restrictions, which means the answer to the third question above does not depend on a support ticket.

The second question is where the pricing model becomes a compliance question rather than a budget one. Every ELabELN edition includes unlimited users, so the supervisor who countersigns, the QA reviewer who reads the trail, and the collaborator who contributes twice a year can each hold their own account. Shared logins are among the most commonly cited laboratory record failures, and rationed access is one of the reasons they persist. A system that charges for each additional reviewer creates a quiet incentive to do the thing inspectors cite.

ELabELN Standard is $495 per month commercial and $295 per month academic, with the same compliance posture as ELabELN Suite: SOC 2 Type II controls, AES-256 encryption, a dedicated cloud instance per customer, third-party penetration testing, and a 99.9% uptime SLA. The platform is designed to support GLP, GMP, GCP, ISO 13485, and ISO 17025 requirements; the lab achieves compliance through its own quality system, training, and procedures. You can compare editions and pricing directly, or read more about ELabELN for regulated R&D.

If any of the three questions above is hard to answer with confidence, that gap is worth finding on your own schedule rather than someone else’s. Related reading: how automated audit trails are implemented in a pharma ELN, electronic signatures and 21 CFR Part 11, and compliance and data integrity across research settings.