Audit Trail Review Procedure: A Risk-Based SOP for GxP Systems

An audit trail is a regulatory requirement in its own right (21 CFR Part 11 §11.10(e), EU GMP Annex 11 clause 9), but having one turned on is not the same as satisfying data-integrity expectations. FDA, EMA and PIC/S inspectors distinguish between a system that captures an audit trail and an organisation that actually reviews it — and it is the review, not the capture, that most GxP data-integrity 483s and deficiency letters turn on. This guide covers how to design a documented, risk-based audit trail review procedure: which trails need routine review, how often, who is allowed to perform the review, what makes a review “documented” rather than just “done,” and how to handle systems where a full, line-by-line review genuinely is not practical.

The regulatory basis

Three overlapping sources establish the expectation, none of which prescribe a single universal cadence:

• 21 CFR Part 11, §11.10(e) requires “use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records” — the requirement to have the trail, not a review schedule for it.
• EU GMP Annex 11, clause 9 (Eudralex Volume 4, revision 1, operative since 30 June 2011) is the clause that actually mandates review: audit trails “need to be available and convertible to a generally intelligible form and regularly reviewed,” and clause 9 frames the audit trail itself as risk-based — “consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions.”
• FDA’s “Data Integrity and Compliance With Drug CGMP: Questions and Answers” (final guidance, December 2018) is the most concrete of the three on frequency. Its guidance: review frequency should match “the frequency with which the CGMP regulations expect you to review the underlying data” — for example, 21 CFR 211.188(b) after each significant production step, or 211.22 before batch release — and “where CGMP regulations do not specify a frequency… you should determine frequency using knowledge of your processes and risk assessment tools.” The same guidance offers a useful mental model for anyone new to this: “audit trail review is similar to assessing cross-outs on paper when reviewing data.”

PIC/S’s PI 041-1, “Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments” (1 July 2021) sits alongside these and is widely treated as the most detailed harmonised reference specifically on audit trail review mechanics. The specifics below attributed to PI 041-1 are reported via secondary industry summaries, not independently re-verified against the primary PDF text this session (it did not parse cleanly for direct quotation) — treat the framework as directionally reliable, not verbatim. The reported framework: critical audit trails — ones tied to the operation being released or reported — are expected to be reviewed by an independent reviewer before that operation is signed off (e.g. before batch release), while lower-risk, non-critical audit trails can be reviewed on a periodic schedule rather than per-event.

Which audit trails actually need routine review

Not every system on a GxP CSV inventory generates a “critical” audit trail in the sense the guidance above means. A practical way to scope this, consistent with the risk-based framing in Annex 11 clause 9 and FDA’s CGMP-frequency principle:

• Critical / release-linked — trails tied directly to a batch-release, reportable-result, or submission decision: a chromatography data system’s integration parameters and reprocessing history, a LIMS result that will appear on a Certificate of Analysis, an EDC field that feeds a case report form. These get review before the linked decision, not just on a calendar.
• Routine / periodic — trails on systems that support the quality system but don’t individually gate a release decision: an electronic lab notebook, a document-management system, a training-records system. Periodic (monthly, quarterly) sampling review is generally defensible if the risk assessment documents why.
• Low-risk / exception-driven — trails you review only when a discrepancy, deviation or complaint gives a reason to look, with that trigger and scope documented in the deviation record itself rather than a standing schedule.

This is the same tiering logic behind review-by-exception for chromatography data systems — a CDS is usually the clearest real-world example of the “critical” tier, precisely because its audit trail is what tells an inspector whether a reported result reflects every injection that was actually run.

What “documented review” actually requires

A review that exists only as “someone looked at the screen” does not satisfy an inspector, and does not survive a data-integrity investigation if something later goes wrong. A documented review needs, at minimum:

• What was reviewed — the specific system, date range, record or batch the review covered, not “the audit trail” generically.
• Who performed it, with a signature or equivalent electronic authentication, and a record of when.
• What was found — explicitly, including a statement that no anomalies were found, not just silence where a finding would have gone.
• What was done about any finding — a cross-reference to a deviation, CAPA, or investigation record if the review surfaced something, per the same corrective-action expectation that governs any other GxP finding.

Where the review is itself electronic (a report generated and approved inside the system, rather than a separate paper or PDF log), that report becomes a GxP record in its own right and inherits the same 21 CFR Part 11 controls — access limitation, its own audit trail, retention — as the data it reviews.

Reviewer independence

The reviewer should not be the person whose own actions the trail is recording, and should not be someone reviewing their own direct reports’ work — the same conflict-of-interest logic that underlies independent audit generally (ISO 19011’s independence principle, applied here to a specific record type rather than a whole quality system). In a small lab this can be genuinely hard to staff cleanly; the practical fallback most quality systems use is a documented delegation — a second qualified person outside the immediate work unit, named in the SOP, rather than leaving “who reviews” ambiguous and defaulting to whoever is available that day.

When a full review genuinely is not practical

Some systems generate audit trail volume that makes a complete, line-by-line review a fiction rather than a control — a LIMS processing thousands of results a day, or an ELN with years of continuous entries. FDA’s and PIC/S’s own risk-based framing exists partly for this reason: the expectation is not “review every line,” it’s a documented, risk-justified sampling or exception-based approach. Two patterns hold up under inspection:

• Review by exception — the system (or a validated report built on top of it) flags a defined set of trigger conditions — changes to critical fields, deletions, actions outside normal working hours, changes made after a result was first recorded — and the human review focuses on those flagged events plus a documented periodic spot-check of the rest, rather than the full unfiltered log.
• Tiered sampling — a statistically or risk-justified percentage of records reviewed on a fixed cadence, with the sampling rationale (not just the result) written into the SOP, so an inspector can see the coverage decision was deliberate rather than a resource shortcut dressed up as a strategy.

What does not hold up: disabling or shrinking the audit trail itself to make review more tractable, or reviewing only when something has already gone wrong. Both read, correctly, as reducing the control rather than making it workable.

Building the procedure into an SOP

A working audit trail review SOP typically needs to state, per system or system category: the scope (which fields/actions are in the audit trail), the tier (critical/routine/exception-driven) and its basis, the frequency or trigger, who performs the review and their independence qualification, the documentation format, and the escalation path for a finding. This sits downstream of the system’s own computer system validation — the validation confirms the audit trail captures what it should; the review SOP is the operational control that actually uses it. For a system governed under the EU framework specifically, tie the SOP’s citations to Annex 11 and Annex 15 rather than 21 CFR Part 11 alone, since the two regimes phrase the underlying expectation slightly differently (Annex 11’s “regularly reviewed” versus Part 11’s audit-trail-capture requirement without an explicit review clause of its own).

FAQ

How often should audit trails be reviewed?

There is no single mandated interval. FDA’s December 2018 guidance ties frequency to how often the underlying CGMP regulation already expects the data itself to be reviewed — per significant production step, before batch release — and, where no such regulation-specified frequency exists, to a documented risk assessment. In practice this produces a tiered answer: near-continuous or pre-release review for critical, release-linked trails, and periodic (monthly or quarterly) review for routine ones.

Who is allowed to perform an audit trail review?

Someone independent of the record’s originator and, ideally, outside their direct reporting line — named in the SOP rather than left to whoever is available. Reviewing your own entries, or a subordinate’s, defeats the purpose of an independent check.

What counts as a documented audit trail review?

At minimum: what was reviewed (system, date range, record scope), who reviewed it and when, an explicit statement of findings (including “none found”), and, if something was found, a link to the deviation or CAPA record that followed. “It was checked” with no artifact behind it does not meet this bar.

Does every audit trail need to be reviewed before batch release?

Only the ones tied to that release decision — a critical, release-linked trail such as a chromatography or LIMS result feeding the batch’s Certificate of Analysis. Routine, non-release-linked systems can generally be reviewed on a periodic schedule instead, provided that tiering decision is documented in the risk assessment, not assumed.

What if a system generates too much audit trail data to review in full?

Move to a documented review-by-exception or risk-based sampling approach rather than skipping review altogether — define the trigger conditions (critical-field changes, deletions, off-hours activity) that get individually reviewed, plus a periodic spot-check of the remainder, and write the coverage rationale into the SOP so it reads as a deliberate control rather than an admitted gap.