Audit Trail Review in GxP: Scope, Frequency, Responsibility

Our services for audit trail review

The audit trail is the computer-generated, unalterable log of a system: who created, changed or deleted which record, when and why. It secures the who-when-why behind every GMP relevant record and thereby carries the attributability principle of ALCOA+. Without a review, however, it remains a dead log: only regular, knowledgeable checking turns the audit trail into a control that makes manipulation, operating errors and process weaknesses visible.

This is exactly where the authorities focus. An audit trail nobody looks at is not evidence of data integrity in an inspection; it is a finding waiting to happen.

Clarify scope?

Book an intro call

Leistungs-Wegweiser

Welche Ausgangslage beschreibt Ihr Vorhaben?

Wählen Sie die Ausgangslage. Sie erhalten einen fokussierten Startpunkt mit Vertiefungen und Kontaktweg.

Vom Erstgespräch zum Plan

Wir klären Umfang, Rollen, Risiken und regulatorischen Rahmen und schlagen einen belastbaren Fahrplan vor.

Erstgespräch vereinbaren Projektmanagement ansehen

Our approach in GxP projects: from planning through release – each step delivers evidence you can present in QA review and audit. View GxP consulting in five steps

What the regulations require

EU GMP Annex 11, section 9: Audit trails covering GMP relevant changes and deletions must be reviewed regularly. The current version of Annex 11 leaves the frequency open; the draft revision sharpens the expectation towards documented, risk-based reviews.
21 CFR Part 11, section 11.10(e): Systems need a secure, computer-generated, time-stamped audit trail. The FDA guidance on data integrity explicitly answers that audit trails should be reviewed by a knowledgeable person, for example as part of the record review before release.
MHRA GXP Data Integrity Guidance: The UK guidance anchors the risk-based review as part of the data lifecycle and names disabled or never reviewed audit trails as a typical integrity risk.

Whether your systems meet the basic requirements is clarified in a first self-assessment by our Part 11 Check and the Annex 11 Check.

What an audit trail must contain

Before a review makes sense, the audit trail itself has to be complete. From 21 CFR Part 11 section 11.10(e) for the US and EU GMP Annex 11 section 9 combined with the ALCOA+ principles, a clear minimum content per entry follows:

Who: the unique user ID of the acting person, never a group or system account.
When: a computer-generated timestamp with date and time from a synchronized, tamper-proof system clock.
What: the action (create, change, delete) and the affected record, uniquely referenced.
Old and new value: changes must not hide the original value. Part 11 states this explicitly: record changes shall not obscure previously recorded information.
Why: the reason for change where the governing regulation requires it, for example for GMP records under EU GMP Chapter 4.

On top come properties of the audit trail as a whole: it is generated automatically by the system, cannot be changed or switched off by users and remains readable and evaluable over the full retention period of the data, even after system retirement. For long-term availability the rules of our data archiving apply.

What must be reviewed and what not

The most common mistake is trying to check everything. Whoever screens every login gets fatigued and misses the relevant entries. The review concentrates on GMP relevant events:

Changes to results and raw data: changed or reprocessed results, manual reintegrations in chromatography, overwritten measurement values.
Deletions and rejections: deleted sequences, discarded runs, aborted measurements including their justification.
Method and parameter changes: changed integration parameters, recipe or limit changes between measurement and release.
Date, time and sequence anomalies: measurements outside the shift, trial runs before the actual sample, conspicuous repetition patterns.
System events: permission changes, new or deactivated accounts, configuration changes, a switched-off audit trail.

Routine entries such as successful logins or automatic backups do not belong in the individual review. Suspicious patterns within them, such as logins under someone else's ID, are covered by the periodic system review.

Risk-based frequency: two levels, two rhythms

Data related review

Before the decision that relies on the data: batch release, result approval, stability assessment. Reviewed are the audit trail entries of the affected records, in the rhythm of the release process.

System related review

Periodically according to the risk assessment of the system: permission and account changes, configuration, audit trail status. Typical intervals range between monthly and yearly, defined in the SOP and the periodic review.

The classification follows the criticality of the data and the configurability of the system. A chromatography data system with manual integration needs a tighter rhythm than a temperature logger with a fixed program. We document the risk assessment per system, methodically aligned with our approach in computer system validation (CSV).

Who reviews: roles and responsibility

The review belongs to people who can assess the data professionally. A three-level model has proven itself:

Second person in the four eyes principle: checks the data related entries as part of the record review before release. The creator of the data never reviews their own entries.
System owner or key user: performs the periodic system review, including permissions, configuration and audit trail status.
QA: defines the process, samples the reviews and assesses findings in deviation management.

The review is signed electronically in the system or on a checklist; the requirements for such signatures are described on our page about electronic signatures.

Practical tips: making the review workable day to day

From our projects, five decisions have proven essential; every review SOP should answer them before the first review starts:

Define the filters in the operating or system owner SOP: Which filters, queries or reports in the system are used for the review belongs documented in the operating SOP of the system or the system owner SOP. Only then is the review reproducible and independent of whichever view each reviewer assembles by clicking around. Ideal: predefined, validated filter sets per system role.
Set the interval and justify it against the regulations: The review interval is derived per system from the risk assessment and checked against the applicable regulations: Annex 11 requires regular review, the FDA expects the data related review within the record review before release, the MHRA demands risk-based frequencies. The result including its justification goes into the SOP, not just into the system owner's head.
Define the documentation type: Decide upfront how the review is evidenced: electronic signature with a review status in the system, a checklist in document management or a review report. The evidence names the period, the reviewed data areas, the filters used, findings and the assessment.
Clarify the permissions needed for the review: The reviewer needs read access to the complete audit trail including export or report functions, but no change or administrator rights. Without a dedicated review role profile, practice often ends in a dilemma: either the reviewer cannot see everything, or they receive overly powerful rights. The role concept therefore belongs in the system configuration and the system owner SOP.
Plan the orphan data check: Orphan data means records created outside the reported workflow that appear in no evaluation: single and test injections, aborted runs, measurements in local folders or under test projects. The orphan data check reconciles whether all raw data generated by the system was either reported or discarded with a documented justification. It uncovers exactly the data a mere look at the audit trail of the reported result never shows.

Typical red flags during audit trail review

Every reviewer should know these patterns, because they keep appearing in inspection reports:

Test injections or trial runs immediately before the actual measurement, looking like a preview of the result.
Repeated measurements of the same sample until a result within specification appears, without a deviation report.
Result or parameter changes shortly before release, especially changed integration parameters for the same analyte.
Activities under someone else's user ID, outside shift hours or from unexpected workstations.
Gaps in sequence numbers or timestamps, backdated entries, conspicuous jumps of the system clock.
An audit trail that was temporarily disabled or a changed audit trail configuration.
Orphan data from the orphan data check that appears in no report and was never discarded with a justification.

Every red flag is initially a task to investigate, not a verdict: many patterns have harmless explanations. What matters is that the reviewer recognizes them, documents them and has them assessed through deviation management.

Typical findings from audits and inspections

The audit trail exists, but since system go-live no review was ever performed or documented.
The SOP demands a review "regularly" without naming frequency, scope or responsible roles.
The audit trail can be disabled in the system, and nobody checks whether it is active.
Reviews are signed off wholesale although the system offers no filters or reports for a meaningful review.
Result changes between measurement and release are first noticed by the inspector, not by the internal review.
For legacy systems without an audit trail, risk assessment and compensating controls are missing.

What you get

We take the audit trail review from a paper claim to lived practice.

System inventory with risk assessment: which systems need which review at which rhythm
Review concept and SOP with scope, frequency, roles and escalation paths, DE and EN
System specific review checklists and filter configurations, for example for chromatography data systems and LIMS
Assessment of legacy systems and definition of compensating controls
Reviewer training with real case examples from inspections
Integration into periodic review and the Data Integrity Check

FAQ: Audit Trail Review

Does every audit trail have to be reviewed in full?

No. Authorities expect a risk-based review: the focus is on changes to and deletions of GMP relevant data, such as changed results, reintegrations in chromatography or modified method parameters. Routine entries such as successful logins do not need to be checked one by one, but suspicious patterns within them do.

How often does an audit trail review have to take place?

Batch or result related audit trail entries are reviewed before the decision that relies on them, meaning before batch release or result approval. System level entries such as permission changes, configuration changes or a disabled audit trail are reviewed periodically; the frequency follows the risk assessment of the system, with typical intervals between monthly and yearly.

Who is allowed to perform the audit trail review?

A knowledgeable person who can assess the data professionally and who did not create the data. In practice the review is often done by the second person in the four eyes principle; QA keeps oversight of the process and samples. Responsibility must be assigned unambiguously in an SOP.

What if a legacy system has no usable audit trail?

First assess and document the risk. As an interim measure, compensating controls help: restricted permissions, paper based four eyes checks and regular data reconciliation. In the medium term authorities expect an upgrade or a system replacement; this expectation is clearly stated in the FDA and MHRA guidances.

What is an orphan data check?

The orphan data check looks for orphaned data: raw data created by the system that does not appear in any reported result, such as test injections, aborted runs or measurements stored in local folders and test projects. It verifies that all generated data was either reported or discarded with a documented justification. The check complements the audit trail review because the audit trail of the reported result never shows this data.

Does the audit trail review itself have to be documented?

Yes. Without evidence the review counts as not performed in an audit. Common approaches are a checklist or a signature in the system that records the reviewed period, the reviewed data areas, findings and the assessment. Ideally the system supports the review with filters and a dedicated review status.

Does Annex 11 require a regular audit trail review?

Yes. Annex 11 section 9 requires audit trails to be reviewed regularly where they record GMP relevant changes and deletions. The draft Annex 11 revision further sharpens this expectation towards risk-based, documented reviews. 21 CFR Part 11 requires a secure, computer-generated audit trail in section 11.10(e), and the FDA data integrity guidance expects it to be reviewed.