Data Integrity and Compliance
TL;DR
An audit trail is a secure, computer-generated, time-stamped log of every action that creates, changes, or deletes an electronic record. Each entry shows who acted, when, and what the record said before. For FDA-regulated work, section 11.10(e) of 21 CFR Part 11 lists audit trails among the controls for electronic records.
An audit trail is a secure, computer-generated, time-stamped log of every action that creates, modifies, or deletes an electronic record, kept so the history of that record can be reconstructed later. That wording is close to the definition in FDA's 2018 data integrity guidance. A good entry tells you who did something, when they did it, what the record said before, and why it changed.
The term was borrowed from financial auditing. It entered US lab regulation in 1997, when 21 CFR Part 11 listed "secure, computer-generated, time-stamped audit trails" among the controls for closed systems in section 11.10(e). In Europe and the UK the same expectation sits in section 9 of EU GMP Annex 11 and in the MHRA's 2018 GxP data integrity guidance, scaled by risk assessment.
People often use the term interchangeably with version history, and the two do overlap. Version history keeps earlier copies of a document so you can open or restore them. The audit trail records what was done to the record around those copies: edits, signatures, status changes, deletions. And an audit is the inspection that reads it, which is a different thing again.
On paper you already know the answer. It is the single line through a wrong number, with your initials, the date and a few words of reason written beside it. 21 CFR 58.130(e) makes that a rule for GLP studies: a change to a data entry must not obscure the original, must give the reason for the change, and must be dated and signed at the time it is made. It applies the same rule to automated data collection systems.
An electronic system has to capture the same things without anyone having to remember. Say a postdoc records 2.5 mL of Tris buffer from lot 4471B on Monday, then realizes on Wednesday that the bottle on the bench was lot 4471C. When she corrects it, the log gains one new line holding:
Nobody can edit that line afterwards, and 4471B stays readable in the log. Inventory works the same way. An aliquot moved from position A3 to B7 in a freezer box gets its own entry, and so does a sample set to Quarantined after a failed QC check.
The quickest way to find out is to list where your regulated data lives: the ELN, the inventory spreadsheet, the instrument software, the shared drive of Excel analysis files. Then ask four questions of each. Does it record changes automatically? Can a user switch that off? Does it keep the old value as well as the new one? Can you export the log in a form someone else can read?
Shared drives and spreadsheets fail most of these, because a file that has been saved over keeps no trace of what it held before. Instrument PCs are the other usual gap. Missing or disabled audit trails come up again and again in FDA warning letters, and the familiar case is a standalone chromatography workstation where anyone could delete a run and inject again, with no record that the first run ever existed.
In IGOR, each notebook entry in the electronic lab notebook has a Document Version History and a review history and audit trail that can be opened at any time. Revising a locked entry creates a copy with the suffix _R1 or _R2, and the documented reason for the revision is recorded in the audit trail. Items in inventory carry a Sample History that records every action with the user and a timestamp. Users can correct their own mistakes, such as a wrong amount used, but a correction never changes or deletes the original entry. It is added as a new entry next to the original, with the user and time, and the original is marked so anyone reading the history can see that a correction follows. The Sample History itself cannot be edited or deleted. That keeps every record attributable and the original readable, which is what Part 11 and ALCOA+ expect of an audit trail.
Mostly QA, and regulators expect the review to be routine. FDA's 2018 guidance expects the people who review CGMP records to review the related audit trails as part of that work, at the same frequency as the data review when the regulations set one. The MHRA guidance asks for a documented, risk-based audit trail review as part of routine data review.
In practice the review is how a QA lead tells a harmless change from a problem. If a potency value moved between the draft report and the final report, the audit trail shows whether someone fixed a transcription error or whether there is a deviation to write up. So the review fits best on a step that already exists, such as notebook witnessing or report sign-off, with an SOP that defines which events the reviewer looks at. In IGOR, the witnesses assigned to a notebook entry can open its review history and audit trail at any time. Every login is rarely worth reading. Every change to a reportable result usually is.
Keeping and reviewing an audit trail is a regulatory obligation only for records covered by FDA predicate rules, such as studies conducted under GLP or manufacturing under GMP. An academic group with no regulated work has no legal duty to keep one. But the log still answers questions every lab runs into, like which reagent lot went into the assay that drifted, or who edited the shared plate layout the night before the run.
Yes. Section 11.10(e) of 21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails for closed systems. FDA's 2003 scope and application guidance announced enforcement discretion on that specific requirement, but predicate rules such as GLP still require changes to be documented, and FDA's 2018 data integrity guidance expects audit trails to be reviewed as part of CGMP record review.
At the same frequency as the data they relate to, when the regulations set one, for example before batch release. That is FDA's position in the 2018 data integrity guidance. Where no frequency is set, the lab decides one based on risk, weighing how critical the data is and what other controls are in place. The MHRA guidance takes a similar risk-based view and allows validated exception reports to focus the review.
They should not be able to in any system used for regulated work, and the MHRA 2018 guidance says so directly. If administrators have a switch that turns the audit trail off, lock that setting down by procedure and check it during validation.
Version history stores earlier copies of a record so they can be viewed or restored, while an audit trail logs the actions taken on the record, including who acted and when. Most electronic records need both.
This page is a general overview for lab scientists. It is not formal compliance or legal advice, and the requirements that apply to your lab depend on your regulated activities, your predicate rules, and your own validated processes.