Audit trails and why reviewers ask for them

An audit trail is a record of the changes made to other records. In a computerized system, it is a log the system writes automatically, showing who created, modified or deleted a piece of data, when they did it, what the value was before and after, and, where the system asks for one, why. On paper, the equivalent is the single-line correction with initials, date and reason that leaves the original entry readable beside the new one.

The final result on a report says nothing about how it was reached. The audit trail does. That is why reviewers, auditors and inspectors ask for it, and why the regulations treat it as part of the record rather than an optional extra.

What a useful audit trail captures

The requirements in 21 CFR Part 11 and in Annex 11 of the EU GMP guidelines agree on the essentials. Entries are generated by the system, not typed by the user. They carry a time stamp from a clock the user cannot change. They identify the individual user, which is only possible if users have their own accounts. They record the old value as well as the new, so that a change does not hide what was there before. They cannot be edited or switched off by the people whose actions they record. And they are kept for as long as the records they describe.

A reason for change is not always captured automatically, but for data that affects a decision it should be. “Typo” and “correction” tell a reviewer very little. A reason that names the error and the source of the right value, such as the balance printout that shows the weight actually recorded, tells them what they need to know.

Why the final result is not enough

Consider a chromatography run. The instrument records a detector signal, and software integrates the peaks to calculate how much of each component is present. The integration depends on settings such as where the baseline is drawn and which peaks are counted. Different reasonable settings give different numbers. If an analyst reprocesses the same data several times with different settings and reports only one result, the report looks the same as one produced on the first attempt. Only the audit trail shows that the data was reprocessed, how many times, with what settings, and which result was chosen.

The same applies to injections run before the official sequence, results that were deleted, sample identities changed after the run, or instrument clocks altered. Each can turn a failing result into a passing one without any visible trace on the final report. Data integrity guidance from the FDA, the MHRA and PIC/S describes these patterns, sometimes called testing into compliance, as the reason why the review of a result has to include a review of how it was produced.

Reviewing an audit trail

Audit trails are only useful if someone reads them. Annex 11 says they should be regularly reviewed, and the FDA’s data integrity guidance recommends that audit trails capturing changes to critical data be reviewed with each record before it is approved. In practice a reviewer looks for a few specific things: data modified or deleted after acquisition, repeated processing of the same data, runs or injections that do not appear in the reported results, changes made by someone other than the analyst, changes made long after the work, and gaps or clock changes in the time sequence.

Most of what a reviewer finds will have an ordinary explanation. A sample identity mistyped and corrected at once, a run stopped because of a pressure fault and repeated, a reprocessing done under an approved procedure. The point of the review is not to assume bad faith but to confirm that each change has a documented reason that holds up. A review that finds nothing to ask about on every record for a year is worth checking too, because it may mean the audit trail is not being read.

When the system cannot provide one

Older instruments and standalone software sometimes have no audit trail, or one that can be turned off. Laboratories in that position are expected to assess the risk and put compensating controls in place: restricting who can access the system, saving raw data to a protected location as soon as it is acquired, keeping a paper log of runs and processing, and replacing or upgrading the system when practical. A spreadsheet used for calculations raises the same issue, since an ordinary spreadsheet records nothing about who changed a cell or what it held before.

For anyone receiving results from a laboratory, asking whether the systems that produced them have audit trails enabled and reviewed is a reasonable question. A laboratory accredited to ISO/IEC 17025 is expected to protect the integrity of its data and should be able to answer it plainly.