What is an audit trail, exactly — this requirement that comes up in every GMP inspection of computerised systems? In short, it is the secure, time-stamped electronic record that documents who created, modified or deleted a piece of data, and when. But reducing it to a software feature is the mistake that leads to findings: the audit trail is first and foremost a data integrity control, and regulators expect it to be properly configured, protected and — above all — reviewed with judgement. In this guide we look at what Annex 11, 21 CFR Part 11 and PIC/S require, and how to set up a management approach you can defend in an audit.
What is an audit trail under GMP regulations
The most frequently cited definition comes from the FDA's data integrity guidance: an audit trail is 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. Three elements of this definition deserve attention:
- Secure: ordinary users must not be able to disable, alter or delete it. If the system administrator is also the person generating the data, independence is compromised.
- System-generated: a manually kept logbook is not an audit trail. The recording must happen automatically, without operator intervention.
- Reconstruction: the goal is not to accumulate logs, but to allow a reviewer (or an inspector) to answer the question "what happened to this data, who touched it, and why?".
In practice it helps to distinguish two levels: the system audit trail, which records events such as logins, configuration changes and user management, and the data audit trail, which tracks the creation, modification and deletion of GMP-relevant records (an analytical result, a process parameter, a weighing). Inspectors and reviewers focus on the second, but the first is what demonstrates the system itself is under control.
The audit trail is therefore the technical safeguard of the ALCOA+ principles: it makes data attributable (who), contemporaneous (when), original and accurate, and preserves its complete history. Without a working audit trail, demonstrating the data integrity of a GxP system becomes practically impossible.
What Annex 11, Part 11 and PIC/S require
The main regulatory references converge on the same concepts, with nuances worth knowing when you write the internal procedure or respond to an observation.
| Reference | Key requirement | Point of attention |
|---|---|---|
| EU GMP Annex 11, clause 9 | Consider, based on a risk assessment, building in a record of all GMP-relevant changes and deletions; the reason for changes and deletions must be documented | Audit trails need to be available, convertible to a generally intelligible form and regularly reviewed |
| FDA 21 CFR Part 11, §11.10(e) | Secure, computer-generated, time-stamped audit trails to record the date and time of operator entries and actions that create, modify or delete electronic records | Record changes must not obscure previously recorded information |
| PIC/S PI 041-1 (2021) | Good data management practices: audit trail review is an integral part of data review, following a risk-based approach | This is the operational reference used by PIC/S inspectorates worldwide |
Keep in mind that the European framework is evolving: the draft revision of Annex 11, published for consultation in July 2025, makes the requirements on audit trails and their review more explicit and more stringent than the 2011 text. Anyone setting up a procedure today should already be looking at where the revision is heading.
Topics like this move faster than SOPs can keep up. With The Pragmatic GMP, our free weekly newsletter, you get regulatory updates on data integrity and GMP already translated into practical actions: subscribe and stay one step ahead of your next inspection.
How to manage the audit trail in practice
An audit trail that is compliant on paper but unmanageable in practice is the most common problem in laboratories and production areas. These are the steps for a sustainable approach:
- Inventory systems and critical data. Start from your GxP system inventory and identify, for each system, which data impact product quality and patient safety: that is where the audit trail must be watched first.
- Verify the configuration. During validation, verify that the audit trail is enabled, cannot be switched off by users, is complete (who, what, when, why) and that recording the reason for change is enforced where required.
- Define roles and segregation. Administrator privileges must be separated from operational activities; the list of users and profiles must be kept current and periodically reviewed.
- Set the frequency and depth of the review. Frequency is justified by risk: for critical data the FDA recommends reviewing the audit trail together with the record, before final approval (for example at batch release or approval of the analytical result); for everything else, define a documented periodicity.
- Document the review and manage anomalies. Who reviewed, what was checked, what was found: if suspicious changes or unusual patterns emerge, open a deviation and investigate through the standard process.
- Ensure retention and readability over time. The audit trail follows the retention period of the data it refers to: it must be included in backups, survive migrations and remain readable even after system retirement.
One final point that is often overlooked: in hybrid systems, where electronic data coexists with signed printouts, the printout does not replace the audit trail. If the system generates dynamic data, the review must be performed on the original electronic data — audit trail included.
The most common findings in inspections
- Audit trail disabled, or able to be switched on and off by ordinary users — often discovered during the inspection itself.
- Shared accounts that make it impossible to attribute actions to a person: the audit trail exists, but it is useless.
- "Signature-only" reviews: the SOP requires the review, but nobody can say what is actually checked and there is no evidence of any anomaly ever detected.
- System clocks that are unsynchronised or user-adjustable, undermining the reliability of the time stamp.
- Audit trail excluded from backups or lost at system retirement, in conflict with data retention requirements.
GuideGxP recommendation
Do not write your audit trail SOP starting from the software: start from the data. First define which data are critical and which decisions they support, then ask what the audit trail must tell you to defend those decisions in an inspection. A targeted review of a few meaningful events (changes to results, deletions, reintegrations, actions performed with elevated privileges) is worth more than a formal review of thousands of rows. And remember: every anomaly found and managed is a point in your favour, not against you — it shows the control system works.
If you want a ready-made, step-by-step method to set up the review in your laboratory or production area, our guide Audit Trail Review Step-by-Step – The Definitive Operational Guide for QC and Production includes risk criteria, frequencies, examples of events to check and audit-ready documentation templates.
