Audit Trail Review under Annex 11 and Part 11

Almost every GMP-relevant computer system now records an audit trail. Recording is rarely the problem. Where things stall in practice is the review: who looks at these data trails, when, how and with what objective? This is precisely where formal conformity parts ways with data integrity as it is actually practised.

What the regulations require

In its section on audit trails, EU-GMP Annex 11 requires that changes to and deletions of GMP-relevant data be recorded in a traceable manner and that these audit trails be reviewed regularly. On the US side, 21 CFR Part 11, specifically section 11.10(e), requires secure, computer-generated, time-stamped audit trails that independently record the creation, modification and deletion of electronic records and are retained for as long as the record itself. Both frameworks pursue the same goal: data must remain attributable and traceable.

Recording is not reviewing

The most common misconception is that an activated audit trail already equals compliance. In fact, the authorities require the review. The data integrity guidelines of the MHRA and PIC/S (PI 041) make it clear that audit trails must be reviewed routinely, specifically wherever decisions about product quality are made. An audit trail without a review is a control that exists only on paper.

An audit trail that no one reads protects data integrity as little as a camera that no one watches.

Risk-based instead of line by line

The ambition to read every audit trail line is neither realistic nor required. What makes sense is a risk-based review that focuses on the critical events:

• Focus on GMP-relevant actions: changed results, overwritten values, aborted runs, altered integrations.
• Review by exception: the system filters out the critical events, and the human assesses them.
• Anchoring in the process: the audit trail review becomes part of the batch record review and is completed before batch release.

Who reviews, and how often

The "who" is just as important as the "what". A review loses its value when a person assesses their own actions; independence and a clear separation of duties are decisive. The frequency depends on the risk: critical, batch-related systems are reviewed with every release, others at defined intervals or event-driven in the case of deviations and grounds for suspicion.

Prerequisites in the system

A reviewable audit trail needs technical foundations: individual user accounts instead of shared logins, a synchronised and protected system time, and the ability to bring the audit trail into a readable, analysable form. Hybrid workflows, in which paper and electronic recording coexist and attribution becomes blurred, are particularly treacherous. That is why the reviewability of the audit trail belongs in the requirements (URS) and in the Computer System Validation from the outset.

The typical findings

Inspections and audits keep encountering the same patterns with audit trails: the audit trail could technically be disabled and was disabled, it was recorded but never reviewed, or shared user accounts make attribution impossible. Such findings are avoidable when recording, protection and review are considered together from the start.

What counts in the end

A good audit trail review is not an end in itself but one of the most effective controls against data manipulation and error. It must be risk-based, independent, documented and embedded in the release process. Vispact helps to set up such review concepts in a practicable way, from the system requirement to anchoring it in the quality process.