GMP
Audit-Trail Review in GMP: What Should the Reviewer Actually Look For?
Having an audit trail is not the same as reviewing it. A practical look at the checks a GMP reviewer can apply to audit-trail evidence, and how to record what the review concluded.
A GMP reviewer who is handed an audit trail has a different job from someone confirming that one exists. The reviewer's question is not "is there a log?" but "does this history let me understand what happened to this record, and do I accept the explanation?"
This article offers practical reviewer checks. It is not a validation protocol, a complete regulatory checklist, or a determination that any particular system or process is compliant. Your organisation's own risk assessment, approved procedures, and quality system should guide how you apply them, subject to the requirements that apply to you.
Existence is not review
An audit trail is a record of actions taken on an electronic record, and when. Whether it also shows who acted, and shows it reliably, is something a reviewer should verify rather than assume. Its value depends on someone looking at it with a clear question in mind.
In the United States, 21 CFR 11.10(e) describes secure, computer-generated, time-stamped audit trails that record operator entries and actions that create, modify, or delete electronic records. It also says record changes must not obscure previously recorded information. Section 11.10 sets out controls for closed systems, and whether Part 11 applies to a given record depends on the circumstances, so that determination needs to be made rather than assumed.
That wording is about the audit trail's characteristics. It does not tell a reviewer how to read one. That part is practice, and the checks below are suggested practice, not regulatory text.
Start with scope
Before opening the audit trail, decide what you are reviewing and why:
- System and record: which record or record type is under review?
- Review period: which events fall within the review?
- Relevant events: creation, modification, deletion, status changes, approvals?
- Risk: how much would an undetected change matter to product quality or patient safety?
- Responsible role: who performs the review, and is that person independent of the work being reviewed where your procedure requires it?
Your approved procedure should define the review frequency and depth. This article does not state a universal frequency, because the sources checked for it do not establish one.
Practical reviewer checks
1. Attribution and authorisation
Can each action be tied to an identifiable person? Was that person authorised to perform that action on that record at that time? Access limits and authority checks sit in the same section of 21 CFR 11.10, and a reviewer can reasonably use them as context. Shared logins or unexplained generic accounts are worth escalating.
2. Changes and deletions with preserved history
Where a value changed, can you see the earlier value as well as the new one? A change that hides what was there before leaves the reviewer unable to judge it. Deletions deserve particular attention: what was removed, by whom, and why?
3. Timestamps and event sequence
Do the times make sense together? An approval stamped before the entry it approves, or edits clustered just after a deadline, may have a simple explanation. The reviewer's job is to notice the pattern and ask.
4. Stated reasons and supporting context
Is there a reason for the change, and does it match what the surrounding records show? A reason such as "updated" says little. A reason that points to a deviation, an investigation, or a documented correction gives the reviewer something to verify.
5. Unusual patterns that need an explanation
Repeated edits to the same field, activity outside normal working patterns, or many corrections by one person are prompts for a question, not conclusions. Avoid deciding what a pattern means before you have asked.
A fictional example
Imagine a reviewer examining a batch-related electronic record. The audit trail shows a result changed from one value to another by a named, authorised analyst. The original value is still visible. The stated reason refers to a transcription error and cites a documented correction in the laboratory notebook, which the reviewer can see.
Now imagine a second entry on a different record. The result changed, the original value is visible, but the reason reads only "correction" and no supporting record can be found.
Both entries show a change. The first has an explanation the reviewer can verify. The second has an unresolved gap. That does not mean something improper happened, and the reviewer should not assume it did. It means the review is not finished until someone with the right knowledge explains the entry.
Record what the review concluded
A review that leaves no trace is hard to defend later. Consider recording:
- the system, record scope, and review period;
- what was examined and how;
- observations, including those that were explained and those that were not;
- the rationale for the reviewer's conclusion;
- any follow-up or escalation, and who owns the next decision.
These are proposed practice aids. They do not replace your procedure, and completing them does not guarantee compliance or inspection outcomes.
From one review to ongoing control
A single review tells you about one period. The real question for a quality system is whether this kind of review happens consistently, produces decisions, and drives follow-up. That is the difference between point-in-time confidence and ongoing control.
To explore that idea further, see ongoing control beyond validation. For the wider picture of how connected quality processes fit together, see the quality systems overview.