Audit trail review checklist: three words that appear in almost every data integrity inspection of recent years. FDA and EMA inspectors no longer ask only whether audit trails are enabled, but how they are reviewed: by whom, how often, on which events and with what documented evidence. A well-built checklist turns the review from a generic formality into a targeted control: it defines in advance what to look at in each system (CDS, LIMS, MES, SCADA, eQMS), how to classify anomalies and how to record the outcome. In this article you will find the applicable regulatory requirements, the checks to include in the checklist system by system, the criteria for setting a risk-based frequency and the mistakes auditors challenge most often.
Audit trail review checklist: what the regulations require
No regulation provides a ready-made checklist, but the requirements converge from four main sources.
The FDA guidance Data Integrity and Compliance With Drug CGMP: Questions and Answers (December 2018) addresses audit trails in questions 1.c, 7 and 8. The key principle of question 7: audit trail review belongs to the personnel already responsible for record review, exactly as cross-outs and corrections are assessed on paper. It is therefore not an IT task, but a QC, Production and QA task within routine data review.
The EU GMP Annex 11 (Computerised Systems), in clause 9, requires a risk-based evaluation of building audit trails into systems that record changes and deletions of GMP-relevant data, documentation of the reason for changes, and audit trails that are available, convertible to a readable form and regularly reviewed. The draft revision of Annex 11, released for public consultation by the European Commission from 7 July to 7 October 2025 together with the new Annex 22, strengthens precisely the controls on audit trails, electronic signatures and system security: documented review will become even more central.
The PIC/S PI 041-1 guidance (Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, 1 July 2021) is today the most operational reference for inspectorates: it links the depth and frequency of the review to data criticality and asks for evidence that anomalies are detected and managed. The MHRA 'GXP' Data Integrity Guidance and Definitions (March 2018) completes the picture with the audit trail and metadata definitions used by most of the industry.
How to build the checklist: the three essential blocks
An effective audit trail review checklist is structured in three blocks.
- System prerequisites: audit trail enabled and not switchable off by ordinary users, clock synchronisation, mandatory "reason for change" field, segregated roles and privileges (whoever generates data must not be able to administer it).
- Events to review: the filtered list of critical events for each system, defined during validation and referenced in the SOP. Reviewing "everything" is the same as reviewing nothing.
- Outcome and documentation: assessment of anomalies (is the event covered by a procedure? justified? consistent with times, roles and signatures?), opening of a deviation or investigation where needed, and documented recording of the review with date and reviewer signature.
Topics like this one — data integrity, audit trails, inspections — are the daily bread of The Pragmatic GMP, GuideGxP's free weekly newsletter: every week one GMP topic broken down into operational decisions, with no unnecessary theory. Subscribe here.
The critical events to check, system by system
The table summarises the events a checklist should catch in the most common laboratory and manufacturing systems.
| System | Critical events to review | Typical review moment |
|---|---|---|
| CDS (HPLC/GC) | Reprocessing and manual integrations, changes to methods and sequences, exclusion or deletion of injections, unjustified repeat runs | With the analytical review, before result approval |
| LIMS | Result changes after entry, status changes (review/approval), cancelled tests, changes to specifications and master data | With the batch or sample review |
| MES / SCADA | Changes to critical process parameters, manual overrides, alarms and related responses, repeated or aborted steps | With the batch record review, before release |
| eQMS / document management | Changes to approved records, workflow re-openings, administrator actions on GMP data | Scheduled periodic review |
| All systems | Repeated failed logins, unusual out-of-hours activity, activity under shared or "admin" accounts, changes to system date/time | Periodic review + by exception |
Review frequency: the risk-based approach
It is the question every QA gets asked: how often should the review be done? Question 8 of the FDA guidance gives the most concrete rule: if the review frequency for the data is already specified in CGMP regulations, the audit trail review follows that frequency. Audit trails covering changes to critical data should therefore be reviewed together with the record they belong to and before final approval — for an analytical result, with the data review; for a batch, before release. For all other audit trails, the frequency is set through a documented risk assessment, considering data criticality, existing technical controls and impact on product quality: periodic reviews (for example monthly or quarterly) are acceptable when the justification is solid and written down.
A widespread mistake is promising unsustainable frequencies in the SOP: a targeted review on filtered events that actually happens is better than a "total" review that is declared and never completed.
The mistakes inspectors challenge most often
- Review declared but not documented: the SOP exists, the evidence does not. Every review must leave a trace: electronic signature, comment or filtered report.
- No event filtering: printing thousands of log lines is not a review. Filters for "significant events" must be defined and validated.
- Optional reason for change: if the system does not force users to justify changes, the review loses most of its value.
- Non-segregated privileges: analysts with administrator rights make the audit trail itself unreliable.
- Anomalies without follow-up: an anomaly detected and not tracked in a deviation or investigation is, in an inspector's eyes, worse than one not detected at all.
GuideGxP recommendation
Start from the inventory of GxP systems and classify their audit trails by criticality; for each system define during validation the list of critical events and the corresponding filters; write an SOP that assigns the review to those who already review the records, with frequencies justified by the risk assessment; document every review and connect anomalies to the deviation system. Revisit the checklist at every relevant system change and at periodic review.
If you want an already structured path, the GuideGxP guide Data Integrity in GMP – Operational Guide to governance, audit trail review and QC laboratories contains the complete method to set up governance, checklists and audit trail review frequencies that stand up in inspections, with the operational toolkit included.
Official sources
- FDA – Data Integrity and Compliance With Drug CGMP: Questions and Answers (2018)
- PIC/S PI 041-1 – Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (2021)
- European Commission – Consultation on EudraLex Vol. 4: Chapter 4, Annex 11 and Annex 22 (2025)
- MHRA – 'GXP' Data Integrity Guidance and Definitions (2018)
