The Audit Trail: What a Reviewer Is Actually Supposed to Look At

Of all the terms in data integrity, audit trail is the one that sounds most like somebody else's problem — a server log, a matter for IT. It is in fact a laboratory record, and the regulators treat reviewing it as an ordinary part of checking a result rather than as a specialist exercise. The FDA's comparison is deliberately mundane: audit trail review is similar to assessing cross-outs on paper when reviewing data.

Quick answer

What is an audit trail? The FDA defines it as a secure, computer-generated, time-stamped electronic record that allows for reconstruction of the course of events relating to the creation, modification, or deletion of an electronic record. The MHRA describes it as a form of metadata, and says it facilitates the reconstruction of the history of events relating to the record, regardless of its medium, including the who, what, when and why of the action.

Crucially, the MHRA notes that it records those life-cycle details without obscuring or overwriting the original record. An audit trail is additive. Nothing is replaced; the previous value stays.

What should be in one

PIC/S PI 041-1 gives the most concrete list. The audit trail should include the details of the user that undertook the action; what action occurred or was changed, including old and new values; when the action was taken, including date and time; why the action was taken, meaning the reason; and, in the case of changes or modifications to data, the name of any person authorising the change.

Five fields. Four of them are automatic in any modern system. The fifth — why — is typed by a person, which is why it is the one most often empty or filled with a placeholder.

The FDA translates the same requirement into an instrument example that will be familiar to anyone who has read a purity figure. The audit trail for a high performance liquid chromatography run, it says, should include the user name, the date and time of the run, the integration parameters used, and details of a reprocessing, if any — and documentation should include change justification for the reprocessing.

So the audit trail for the run that produced your purity number is supposed to record not just that a number was produced, but which integration parameters produced it, and if they were changed, the stated reason. That is the material behind reprocessing and manual integration.

Two kinds of trail

The FDA distinguishes trails that track the data from trails that track the system. Audit trails include those that track creation, modification, or deletion of data — such as processing parameters and results — and those that track actions at the record or system level, such as attempts to access the system, or to rename or delete a file.

In a footnote, the FDA names examples suited to the second category: audit trails that capture instrument operational status, instrument communication logs, and alert records.

On, locked, and not switchable

Both guidances treat the audit trail's own integrity as the first thing to establish.

The MHRA: audit trails identified by risk assessment as required should be switched on; users should not be able to amend or switch off the audit trail; and where a system administrator amends or switches off the audit trail, a record of that action should be retained.

PIC/S goes further and asks for the logging of the switch-off to be automatic. Audit trail functionalities should be enabled and locked at all times, and it should not be possible to deactivate, delete or modify the functionality. If it is possible for administrative users to do so, an automatic entry should be made in the audit trail indicating that this has occurred.

The design intent is simple. Turning off the recording is itself a recorded event. Which is also why administrator rights are kept away from the people who generate the data, a separation covered in access control in a working lab.

Not every keystroke

A common misreading is that audit trail review means reading everything the system logged. Both guidances say otherwise, and the reason is practical: an unreadable review is not a review.

The MHRA states that the relevance of data retained in audit trails should be considered by the organisation to permit robust review, and that it is not necessary for audit trail review to include every system activity — naming user log on and off, and keystrokes, as examples of what can be left out.

Its alternative is review by exception. An exception report, in the MHRA's definition, is a validated search tool that identifies and documents predetermined abnormal data or actions that require further attention or investigation by the data reviewer. PIC/S describes the same approach as focusing on anomalous or unauthorised activities, and adds a note that cuts the task down further: well-designed systems with permission settings that prevent change of parameters or data, or access restrictions that prevent changes to configuration settings, may negate the need to examine related audit trails in detail.

In other words, the better the system is locked down, the less there is to read. The review effort is inversely proportional to how much the system allows.

Who reviews it

The FDA's answer places the duty with the person already reviewing the result. Personnel responsible for record review should review the audit trails that capture changes to data associated with the record as they review the rest of the record. Not afterwards, not separately, and not by a different function.

PIC/S specifies the sequence more tightly for critical data. Critical audit trails related to each operation should be independently reviewed with all other records related to the operation, and prior to the review of the completion of the operation. This review should be performed by the originating department and, where necessary, verified by the quality unit. Non-critical audit trail reviews can be conducted during system reviews at a pre-defined frequency.

And PIC/S states the failure mode plainly: failure to adequately review audit trails may allow manipulated or erroneous data to be inadvertently accepted by the quality unit.

The MHRA adds a prerequisite that sounds obvious and is routinely the binding constraint. Reviewers should have sufficient knowledge and system access to review relevant audit trails, raw data and metadata. A reviewer who cannot open the audit trail cannot review it, however qualified they are.

How often

The FDA's rule is a hierarchy rather than an interval. If the review frequency for the data is specified in regulation, apply that same frequency to the audit trail. If it is not specified, determine the frequency using knowledge of your processes and risk assessment tools — and the risk assessment should include evaluation of data criticality, control mechanisms, and impact on product quality.

PIC/S adds the sampling design, which is the part most often missed: audit trail reviews should be both random, selected based on chance, and targeted, selected based on criticality or risk. A programme that only ever looks where it expects trouble will not find trouble anywhere else.

It also asks for the method itself to be written down: the regulated user should establish a procedure describing in detail how to review audit trails, what to look for and how to perform searches, and the review activity should be documented and recorded.

Two subtleties worth knowing

Timestamps can be truthful and still mislead. PIC/S notes that audit trail entries should be recorded in true time and reflect the actual time of activities, and that systems recording the same time for a number of sequential interactions, or which only make an entry once all interactions have been completed, may not comply. Its own illustration is the recording of four raw materials added to a mixing vessel: if the order of addition is a critical process parameter, each addition should be recorded individually with its own timestamp; if it is not, the four can be a single timestamped activity.

The MHRA explains the mechanism behind that. In a transactional system, the metadata — username, date, time — are not captured in the system audit trail until the user saves the transaction to durable storage. The timestamp records the save, not the act. Which is why it also recommends that the combination of multiple unit operations into a single transaction should be avoided and the interval before saving minimised.

An audit trail is not change control. PIC/S appends a one-line caution that prevents a common conflation: an audit trail should not be confused with a change control system, where changes need to be appropriately controlled and approved under the quality system. The trail records what happened. Change control decides what is allowed to happen.

When there is no audit trail at all

Older instruments exist, and both guidances deal with them rather than pretending otherwise.

The MHRA: where relevant audit trail functionality does not exist, as in legacy systems, an alternative control may be achieved — for example by defining the process in a standard operating procedure and using log books — and alternative controls should be proven to be effective. Continued use of the legacy system may be justified by documented evidence that a compliant solution is being sought and that mitigation measures temporarily support its continued use.

PIC/S permits the same with a condition: if no electronic audit trail system exists, a paper-based record to demonstrate changes to data may be acceptable until a fully audit-trailed system becomes available, where it achieves equivalence to an integrated audit trail.

Both make the allowance temporary by design. The acceptable answer is a documented bridge, not a permanent arrangement.

What to ask, and what to conclude

• Ask whether reprocessing happened, not whether the system has an audit trail. Nearly all modern systems have one; what matters is whether anything in it needed explaining.
• Read the why field as the informative one. The automatic fields say what the software did. The reason field is the only place a human accounted for it.
• Treat a locked-down system as a smaller review burden, not a bigger one. PIC/S says permission settings that prevent changes can remove the need for detailed trail review.
• Do not expect audit trails in a certificate of analysis. A certificate is a summary; the trail sits behind it, as described in the nine words that decide whether a record counts.
• Where a figure is decisive for your work, confirm it by a second measurement principle. It is the only form of verification available to a purchaser — see how much quantification methods actually agree.

Key takeaways

• An audit trail is metadata that records the who, what, when and why of changes, without obscuring or overwriting the original record.
• PIC/S asks for five fields: user, action including old and new values, date and time, reason, and the authoriser of any change.
• The FDA's HPLC example specifies user name, date and time of run, integration parameters used, and details of any reprocessing with a change justification.
• Audit trail functionality should be enabled and locked; if an administrator can switch it off, that act should itself be logged automatically.
• Review need not cover every system activity — log on and off and keystrokes are named as excludable — and review by exception is an accepted approach.
• The FDA places audit trail review with the person reviewing the record, at the same time as the rest of the record.
• PIC/S requires reviews to be both random and targeted, and to follow a documented procedure saying what to look for.
• A timestamp may record when a transaction was saved rather than when the activity occurred.
• An audit trail is not a change control system; it records events rather than authorising them.

Frequently asked questions

Can an audit trail be searched and exported?

PIC/S says it should be: if possible, the audit trail should retain the dynamic functionalities found in the computerised system, giving search functionality and the ability to export data, such as to a spreadsheet, as examples. It also expects the trail to be printable in a meaningful format.

Does a paper record have an audit trail?

In effect, yes — the corrections. The MHRA's definition covers records either paper or electronic, and PIC/S sets out the paper equivalent: the original entry must remain readable and not obscured, overwriting is not permitted, the reason for a critical correction should be recorded, and the change should be initialled and dated.

Why does time zone come up?

Because contemporaneity cannot be demonstrated without it across sites. PIC/S notes that where global systems are used it may be necessary for date and time records to include the time zone; the MHRA asks for synchronised clocks and for the time zone to be specified where data is used across multiple sites.

Is an aborted injection supposed to appear?

Yes. The FDA states that aborted or incomplete injections should be captured in audit trails and should be investigated and justified — the point taken up in reprocessing and manual integration.

Does any of this apply outside GMP?

Not as a requirement. These are GMP and GxP documents and research-grade material falls outside them, a boundary set out in what research use only means. As a description of what a defensible electronic record looks like, they are the clearest text available.

Sources

• US Food and Drug Administration. Data Integrity and Compliance With Drug CGMP: Questions and Answers — Guidance for Industry. December 2018. FDA guidance
• Medicines and Healthcare products Regulatory Agency. GXP Data Integrity Guidance and Definitions. Revision 1, March 2018. MHRA guidance
• Pharmaceutical Inspection Co-operation Scheme. PI 041-1: Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. Adopted 1 June 2021; entry into force 1 July 2021. PIC/S guidance

All quoted text is taken from the published guidance documents linked above.

This article describes record-keeping and documentation practice only. It contains no usage instructions, no dosing information and no protocols of any kind.

For laboratory and in-vitro research use only. Not for human or veterinary use.