Most GMP computerised systems now generate an audit trail. Far fewer sites can show that anyone reads it. 'Audit trail enabled but not reviewed' is one of the most common data integrity observations in EU and PIC/S inspections, and it usually comes with a second one: the review that does exist is a signature on a printout, with no evidence of what was actually examined.
This guide gives you a working checklist for audit trail review: what to review, how often, what a red flag looks like, and how to record the review so that an inspector can see it was real.
What the regulations expect
EU GMP Annex 11 section 9 expects, based on a risk assessment, that a system records all GMP-relevant changes and deletions, that the reason for a change or deletion is documented, and that audit trails are available, convertible to a generally intelligible form, and regularly reviewed. Section 12 adds that access to systems is restricted to authorised people, which is what makes an audit trail attributable in the first place.
PIC/S guidance on data management and integrity (PI 041-1) and the MHRA GXP data integrity guidance go further. They expect the review of audit trails to be part of the routine review of the data, carried out by people who understand the process and the system, and proportionate to the risk of the data. In practice, inspectors read this as: critical data must have its audit trail reviewed before the result is used for a GMP decision such as batch release.
Decide what to review first: a risk-based scope
Reviewing every entry in every audit trail is neither possible nor expected. Start from the data and decide which audit trail events could change a GMP decision. Typical high-risk systems are chromatography data systems, LIMS, electronic batch records, environmental monitoring systems and any system where results can be reprocessed or reintegrated.
- Critical data: results used for release, stability, or in-process decisions. Review the relevant audit trail entries with every result, before approval.
- Supporting data: data that informs but does not decide, such as some equipment logs. Review at a defined periodic frequency.
- System administration events: user creation and deletion, role and privilege changes, configuration and method changes, time and date changes, audit trail settings. Review periodically, typically monthly or quarterly depending on risk.
The audit trail review checklist
Use these questions for a data-level review. Not every item applies to every system; remove those that do not and record why in the review procedure, not in each review.
- Were any results, sequences or injections deleted, cancelled or aborted? Is each one explained and was the explanation recorded at the time?
- Was data reprocessed or reintegrated? Is there a documented, justified reason, and does the reported result use the approved processing method?
- Were any integration parameters, methods or calculations changed manually for this sample set and not for the others?
- Were any results generated but not reported, for example trial or test injections of samples before the official run?
- Do the dates and times of acquisition, processing and approval make sense, with no entries out of sequence or outside working hours without explanation?
- Were any changes made by a user other than the analyst, or by a shared or administrator account?
- Was the system date or time changed during the period?
- Were any audit trail settings switched off, or were there gaps in the audit trail?
- Does every change have a reason recorded, and is the reason specific rather than 'correction' or 'error'?
- Does the reported result match the raw data and the final processed data in the system, not just the printed report?
For the periodic system-level review, add: new or deleted user accounts and whether they match joiners and leavers, privilege changes, accounts with administrator rights who also generate data, repeated failed log-ins, configuration changes and whether each had a change control.
Red flags that need an investigation
- Injections or runs immediately before the official sequence that are not reported: a sign of 'testing into compliance'.
- Repeated reintegration of the same peak until the result passes.
- Deleted or overwritten files, especially close to a failing result.
- Results acquired before the sample was logged in or before the method was approved.
- Activity on a user account while the user was on leave or after they left.
- System clock changes, or disabled audit trail functions, with no change control.
- Reasons for change that are generic, identical across many entries, or added long after the change.
Finding one of these does not by itself mean data was falsified, but it must be raised as a deviation and investigated. An audit trail review that never finds anything over months, on a busy system, is itself a signal to an inspector that the review is not looking.
How to record the review
The most common weakness is not the review itself but the record of it. An inspector will ask what was reviewed, by whom, against which criteria, and what was found. A signature alone answers none of these.
Where the system allows it, use saved audit trail filters or reports so the same criteria are applied every time, and keep the filter definition under change control. A review performed in the system, with an electronic signature that records what was reviewed, is stronger than a printout.
Who should review, and how often
- Data-level review: a trained second person independent of the work, usually the result reviewer, before the result is approved.
- System-level review: QA or the system owner, at a frequency set by risk and written into the procedure, for example monthly for a chromatography data system.
- Reviewers need training on the specific system, because audit trail views and terminology differ between vendors.
- Administrators should not review their own administration activity.
Common gaps found at inspection
- Audit trail functionality available but switched off, or never validated.
- Audit trail review required by the SOP but no evidence of what was reviewed.
- Review performed after batch release instead of before.
- Hybrid systems where the paper printout is reviewed and the electronic audit trail is not.
- Shared logins, making the audit trail unattributable regardless of review.
- No defined frequency or scope for system-level review.
Audit trail review is the control that turns an audit trail from a technical feature into evidence of integrity. A short, risk-based checklist applied consistently, with a record of what was looked at, is what inspectors want to see.
Frequently asked questions
How often should audit trails be reviewed in GMP?
Audit trails behind critical data should be reviewed with each result, before it is used for a GMP decision such as release. System-level audit trails (users, configuration, time changes) are reviewed periodically at a risk-based frequency defined in a procedure, often monthly or quarterly.
What should an audit trail review include?
Deletions, aborted or unreported runs, reprocessing and manual integration, method and parameter changes, changes by other users or shared accounts, date and time changes, gaps in the audit trail, and whether each change has a specific recorded reason.
Who should perform audit trail review?
A trained person independent of the work for data-level review, usually the second-person result reviewer. QA or the system owner for periodic system-level review. Administrators should not review their own administrative actions.
Is signing 'audit trail reviewed' enough?
No. The record should show which system and data were reviewed, against which criteria, by whom, when, and what was found. A signature with no scope is a common inspection observation.