Operationalizing Audit Trail Review: Risk-Based and Review-by-Exception Approaches

Most companies have figured out that audit trails must exist. The hard part is reviewing them without drowning. A single chromatography data system can generate tens of thousands of audit trail entries a week. A manufacturing execution system can generate millions a month. Nobody can read all of that, and a regulator does not expect you to. What they expect is a documented, risk-based, defensible process that reliably surfaces the entries that matter and lets the rest pass.

This article is about that process. It covers the regulatory basis, how to scope review by data criticality, how to set frequency, how review-by-exception works and where it is allowed, how to document a review so an inspector can follow it, the roles involved, and the failure patterns regulators cite. If you can run this program, you can sit in an inspection and defend it.

For the design side (what an audit trail must capture, how to configure it, secure-timestamp and metadata requirements), see audit-trail-design-and-review. This article assumes the trails exist and are trustworthy, and focuses on the operational burden of reviewing them.

What audit trail review is and why it is required

An audit trail review is a documented examination of the change history of GxP-relevant electronic records, performed by a qualified person, to detect unauthorized, unexplained, or improper changes to data before that data is used to make a quality decision (for example, releasing a batch or accepting an analytical result).

The point is not bureaucratic. The audit trail is the record of who did what to the data and when. If nobody ever looks at it, a person can delete a failing injection, reprocess a result, change an integration, or back-date an entry, and the deviation will never be caught. Reviewing the audit trail is the control that makes the audit trail meaningful. An unreviewed audit trail is close to no audit trail at all from a data integrity standpoint.

The regulatory basis

FDA, 21 CFR Part 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.” It also requires that audit trail documentation be retained and “available for agency review and copying.” The regulation establishes the trail; the review obligation is reinforced elsewhere.

FDA, 21 CFR 211.68(b) (cGMP for finished pharmaceuticals) requires that input to and output from computer systems be checked for accuracy, and that records be maintained. 21 CFR 211.180(e) and 211.194 require complete records of data and their review. The agency reads the combination of these with Part 11 to require that audit trails of GMP-critical data be reviewed.

FDA Guidance, “Data Integrity and Compliance With Drug CGMP: Questions and Answers” (December 2018) is the document most often quoted. It states that audit trails that capture changes to critical data should be reviewed “with each record and before final approval of the record,” and that routine scheduled audit trail review should be based on the complexity of the system and its intended use. It explicitly ties audit trail review to the batch record review and to QC analytical data review.

EU GMP Annex 11 (Computerised Systems), clause 9 directs firms to consider, on the basis of a risk assessment, building a system-generated audit trail that captures all GMP-relevant changes and deletions, to document the reason for any change or deletion of GMP-relevant data, and to keep that audit trail available, convertible to an intelligible form, and reviewed on a regular basis. The expectation that the trail be reviewed regularly is the operational hook.

MHRA, “GXP Data Integrity Guidance and Definitions” (March 2018) devotes significant attention to audit trail review. It introduces the concept of review by exception and states that the review should be performed by the person responsible for the data (or a designate) and that QA should provide oversight. It is the clearest published articulation of the risk-based, exception-based model.

PIC/S PI 041-1, “Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments” (July 2021) mirrors and extends the MHRA position, including detail on what “review by exception” requires to be acceptable.

WHO Technical Report Series 1033, Annex 4 (2021) and EMA/ICH expectations are consistent with the above. None of these conflict. The synthesis is: review GMP-relevant audit trails, base scope and frequency on risk, do it before the data is used for a decision, and let QA oversee.

A useful mental model: the audit trail review is not a separate activity bolted on at the end. It is part of the review of the data itself. When QC reviews an HPLC result, the audit trail for that result is part of the record being reviewed, the same way the chromatogram and the integration are.

The two layers of review: record-level and periodic

Almost every workable program separates audit trail review into two layers. Conflating them is a common source of confusion in interviews and in SOPs.

Layer 1: record-level (transactional) review

This is the review of the audit trail entries tied to a specific record at the time that record is reviewed and approved. When a reviewer signs off on an analytical result or a batch record, they also look at the audit trail entries for that result or batch. This is what the FDA Q&A means by “review audit trails that capture changes to critical data with each record and before final approval.”

Examples of what record-level review catches:

• An injection was acquired, then deleted, then re-acquired (possible test-into-compliance).
• A result was reprocessed with different integration parameters and the original was not reported.
• A sample was re-identified or re-named.
• A method was changed mid-sequence.
• An entry has a “reason for change” that is blank or boilerplate.

Layer 2: periodic (system-level) review

This is a scheduled review of system-wide audit trail activity that is not tied to a single record: changes to system configuration, user accounts and privileges, date/time settings, audit trail enablement status, integration libraries, sequence templates, and other global events. These do not show up in any one batch record but are exactly where serious data integrity problems hide.

Examples of what periodic review catches:

• A user account was granted administrator privileges, used once, and downgraded.
• The audit trail was disabled for a period and re-enabled.
• The system clock was changed.
• A shared/generic login was used.
• A processing method in the shared library was modified.

A mature program documents both layers, who performs each, and on what trigger or frequency. See time-stamps-and-system-clock-control for why clock and time-zone events deserve specific periodic scrutiny.

Scoping the review by data criticality

You cannot review everything with the same intensity, and you should not pretend to. The defensible answer is a documented risk assessment that maps data and events to a review depth and frequency. This is the heart of “risk-based.”

Step 1: classify the data and the system

Use your data criticality and data risk assessment (see data-criticality-and-data-risk) to rank records by the consequence of an undetected, improper change. A QC release assay feeding a batch disposition decision is high criticality. A facility temperature log feeding an environmental trend is moderate. A non-GxP scheduling system is out of scope.

System complexity matters too. A spreadsheet with no audit trail (a hybrid record) is reviewed differently from a full CDS with a configurable, secure, time-stamped trail.

Step 2: identify the audit-trailed events for each system

For each in-scope system, list the categories of events the audit trail captures and rate each for data integrity risk. A simple matrix:

Step 3: decide depth per tier

• High criticality, high DI risk: reviewed at record level for every record, plus the events are configured as exceptions so they are pulled forward automatically, plus a periodic system review.
• Medium: periodic review at a defined frequency, sampling if volume is high, with a documented rationale for the sample size.
• Low / non-GxP: documented as out of scope or reviewed only on a triggered basis (deviation, investigation, audit).

Acceptance criteria for the scoping

You have done this correctly when:

• Every in-scope GxP system has a documented inventory of its audit-trailed event categories.
• Each category has an assigned review layer and frequency with a written rationale.
• The rationale ties back to data criticality, not to convenience or to what the tool happens to make easy.
• An inspector can pick any high-criticality record and you can show where its audit trail was reviewed.

The single most common audit-trail-review finding is a program that reviews what is easy to review rather than what is risky to ignore. The scoping document is your defense against that finding.

Setting review frequency

Frequency follows from the layer and the risk tier, not from a calendar habit.

Record-level review frequency is “every time the record is reviewed and approved.” There is no separate cadence. The audit trail review happens inside the data review that already happens before batch disposition or result approval. If your QC review SOP and your batch record review SOP do not mention audit trail review, that is a gap regardless of any other periodic program you run. See batch-record-review-gmp and chromatography-data-system-integrity.

Periodic (system-level) review frequency is risk-based and typically lands as:

• High-risk configurable systems (CDS, LIMS, MES): monthly to quarterly for system events, more often if exception tooling is weak.
• Moderate systems: quarterly to semi-annual.
• Lower-risk systems: annual, often folded into the periodic review of the validated system (see validation-master-plan-and-periodic-review).

Triggered reviews override the schedule. A deviation, OOS, complaint, supplier signal, or inspection finding involving a system should trigger an immediate, targeted audit trail review for the relevant window, regardless of the routine cadence.

A practical caution: do not write a frequency into an SOP that you cannot sustain. “Daily review of all CDS audit trails by QA” looks impressive and will become the finding when you cannot show evidence of it for three weeks in March. Write the frequency you can actually perform and evidence, and make it risk-justified.

Review by exception: what it is and where it is allowed

Review by exception is the only thing that makes high-volume audit trail review sustainable, and it is the part interviewers probe hardest because it is easy to do wrong.

The concept

Instead of a human reading every audit trail entry, the system (or a validated tool/query) is configured to flag only entries that meet pre-defined criteria of interest, and the human reviews the flagged exceptions. The non-exception entries are not individually read by a person; the system has applied a deterministic rule to all of them, and the human reviews the output of that rule.

The MHRA 2018 guidance and PIC/S PI 041-1 both explicitly permit this, with conditions. In substance, the MHRA position is that review by exception is acceptable only when the exception review is itself performed and documented and the exception process has been validated or verified and demonstrated to be effective.

The non-negotiable conditions

Review by exception is acceptable only if all of the following are true. Memorize these; they are the exact things an inspector checks.

1. The exception rules are documented and risk-justified. You must be able to show what triggers an exception and why those triggers cover the data integrity risks. “Show me deletes, aborts, reprocessing, method changes, manual overrides, blank reasons” is a defensible starting set; “show me whatever the vendor’s default report shows” is not.

2. The tool that generates the exceptions is validated. The query, report, script, or system function that decides what counts as an exception is itself a GxP function. If it misses a real exception, your whole review misses it. It must be specified, tested, and shown to detect the events it claims to detect. See validating-scripts-low-code-analytics and csv-risk-assessment-methodology. Negative testing matters: prove the tool flags a planted deletion, not just that it runs.

3. The non-flagged population is bounded and trustworthy. You must be confident that the events you are not reading individually genuinely carry low risk. If a category of risky event is not in your exception rules, it is invisible. A periodic full or sampled review of the non-exception population is a common safeguard to confirm the rules are not leaking.

4. The review of exceptions is documented and dispositioned. Each flagged exception gets reviewed, and the reviewer records the conclusion: explained and acceptable, or escalated to a deviation/investigation.

5. Change control protects the rules. If someone can silently change what counts as an exception, the control is hollow. Exception rule sets live under change control like any other validated configuration. See change-control-validated-systems.

Where review by exception is NOT acceptable as a substitute

Exception review supplements, it does not replace, the record-level review tied to record approval for high-criticality data. The FDA Q&A expectation that critical-data audit trails be reviewed “with each record and before final approval” stands. Exception tooling is how you make that practical (it surfaces the few entries worth a human’s attention for that record), not a way to skip looking at the record’s history entirely.

Also, you cannot use exception review to launder a system whose audit trail is itself untrustworthy. If the trail can be turned off, edited, or is not secure and time-stamped, no review process fixes it. Fix the trail first (see audit-trail-design-and-review).

A worked example: CDS record-level review by exception

Consider a QC lab releasing an HPLC assay result for batch disposition. The CDS produces an audit trail with thousands of entries per sequence. Here is a concrete, sustainable approach.

Exception rule set (configured and validated):

What the reviewer sees and does:

The validated exception report for this batch returns three flagged entries:

Documentation of the review (see the documentation section below) records: the exception report ID and version, the batch/sequence reviewed, that the report executed against the full audit trail for that sequence, the three exceptions and their dispositions, the one escalation with the deviation number, the reviewer name, date, and signature, and a statement that no other exception categories were triggered.

This is defensible. A human did not read 6,000 entries. A validated rule read all 6,000 and pulled the seven categories that carry risk; the human reviewed the three hits and acted on the one problem. That is exactly what risk-based review by exception is supposed to look like.

Documenting the review so it survives an inspection

An audit trail review that is not documented did not happen. This is where otherwise-good programs fail, because the reviewing happened informally and left no trace.

What the review record must contain

For both record-level and periodic reviews, capture:

• What was reviewed: system, record/batch/sequence identifier or time window, and the scope (which event categories, which exception rule set and version).
• How it was reviewed: review-by-exception report ID and version, or “full manual review,” and a statement that the tool ran against the complete population.
• When: date of review, and the data period covered.
• Who: reviewer name, role, and signature (electronic or wet), plus QA oversight signature where required.
• Findings and disposition: exceptions found, each with a conclusion (acceptable with rationale, or escalated). If none found, an explicit “no exceptions / no anomalies” statement, not a blank.
• Escalations: deviation/investigation numbers for anything raised, so the thread is traceable.
• Independence statement: confirmation that the reviewer is not the person who generated the data (or, where unavoidable in a small lab, how independence was otherwise achieved).

Where it lives

Record-level audit trail review is usually evidenced inside the batch record review or the analytical result review record (a checklist line, a signature, an attached exception report). It does not need a separate document, but the batch/result review SOP must require it and the evidence must be retrievable.

Periodic system review produces a standalone review record or report, retained per your record retention schedule. Many companies use a simple controlled form. See good-documentation-practices and document-control-fundamentals.

Sample periodic review record (filled-in skeleton)

Periodic Audit Trail Review Record System: LIMS (validated, prod). Review period: 01-May-2026 to 31-May-2026. Scope: system-level events (user/role changes, spec/limit changes, audit trail status, clock changes). Tool: ATR-Query v3.2 (validated, change-controlled). Reviewer: [name], QC Systems. Date: 03-Jun-2026. Findings:

• 2 user role changes, both tied to approved access requests (ticket #s listed). Acceptable.
• 1 specification limit change, tied to approved change control CC-2026-0142. Acceptable.
• 0 audit-trail-disable events. 0 clock changes. Disposition: No data integrity concerns. No escalations. QA oversight: [name], QA. Date: 04-Jun-2026. Signature.

Acceptance criteria for documentation

• An inspector can pull any high-criticality batch and find evidence the audit trail was reviewed before disposition.
• Periodic reviews exist for the stated frequency with no unexplained gaps.
• “No findings” reviews are positively documented, not absent.
• Exception reports referenced in reviews are versioned and the version is recorded.
• Escalations are traceable to a deviation/investigation and back.

Roles and responsibilities

Clear role assignment is itself an inspection topic. Define these in the SOP.

A subtle but important point on independence: in a small lab where the analyst is also the administrator, you cannot have someone review their own changes meaningfully. The mitigation is to route administrative actions and exception dispositions to a different qualified person, or to QA. Document how you achieve independence; “we are too small to separate” is not an acceptance criterion an inspector will accept.

Common mistakes and inspection-finding patterns

These are the recurring patterns regulators cite. None require company names to recognize; they are generic and well-published in inspection trends. See fda-warning-letters-patterns and regulatory-intelligence-483-trends.

No audit trail review at all. The classic finding: audit trail exists, is configured, and has never been reviewed by anyone. Often paired with the discovery of deleted injections that the review would have caught.

Review not performed before the decision. Audit trails reviewed (if at all) after batch release, or in a quarterly sweep, instead of before disposition for critical data. The timing matters; the FDA Q&A is explicit that critical-data trails are reviewed before final approval of the record.

Review by exception with no validated tooling. A lab claims review by exception, but the report it relies on was never validated, was modified ad hoc, or has never been negative-tested to prove it actually flags a deletion. Inspectors plant or look for an event and ask the report to find it.

Exception rules that miss the risk. The rule set flags trivial events and silently omits the high-risk ones (often method changes or “reason for change” quality). The program looks busy and proves nothing.

System-level events never reviewed. Record-level review is in place but nobody ever looks at user privilege changes, audit trail disablement, or clock changes. This is where the worst integrity problems hide, and it is a frequent citation.

Shared/generic logins defeating attribution. Audit trail says “QC1 user” for everything, so review cannot attribute actions to a person. The review finding here is really an access-control finding feeding an audit-trail-review failure. See csv-cybersecurity-access-control.

Reviewer reviews their own work. No independence; the person who acquired and could have manipulated the data is the same person signing the audit trail review.

Boilerplate “reason for change.” Reasons that are blank, “x,” “n/a,” “see analyst,” or auto-filled. A good program flags meaningless reasons as exceptions; a bad program lets them pass.

Frequency in the SOP that is not met. The SOP says monthly, the records show gaps. The SOP itself becomes the finding because it documents a commitment the company did not keep. Write what you can sustain.

Hybrid systems with no real trail. A spreadsheet or older instrument with no secure audit trail is “reviewed” by reviewing nothing. The correct treatment is enhanced procedural controls and a path to remediate. See hybrid-paper-electronic-records.

No documentation of “no findings.” Reviews were done but only the problems were recorded; clean periods look like missed reviews. Always positively document a clean review.

Interview-ready: questions and strong answers

These come up in data integrity and QC/CSV interviews and in inspector questioning. Answer concretely.

“How do you review audit trails for a high-volume CDS without reading every entry?” Review by exception, supported by a validated exception report. The report applies documented, risk-justified rules (deletes, aborts, reprocessing, manual integration, method changes, sample renames, blank reason fields) to the full audit trail for the record, and a human reviews and dispositions the flagged exceptions before the result is approved. The non-flagged population is covered by the deterministic rule plus a periodic check that the rules are not leaking.

“What makes review by exception acceptable to a regulator?” Documented and risk-justified rules; a validated exception tool that has been negative-tested to prove it detects real events; the rules under change control; each exception reviewed and dispositioned with traceable escalation; and a bounded, trustworthy non-exception population. Cite MHRA 2018 and PIC/S PI 041-1 as the basis.

“When must a critical-data audit trail be reviewed?” Before final approval of the record, as part of the data review, per the FDA 2018 data integrity Q&A. Not afterward, not only in a quarterly sweep.

“Who should perform the review, and who provides oversight?” The person responsible for the data (or an independent designate) performs it; the reviewer must not be the data generator; QA provides oversight and confirms the program is working. This is the MHRA model.

“What is the difference between record-level and periodic review?” Record-level is tied to a specific record at approval and catches manipulation of that record’s data. Periodic is a scheduled system-level review of configuration, user accounts, clock, and audit-trail status, which never appears in any one record but is where serious integrity problems hide.

“How do you set frequency?” Risk-based. Record-level: every time the record is reviewed. Periodic: monthly to annual depending on system criticality and complexity, plus triggered reviews on deviations, OOS, complaints, or inspection findings. And only commit to a frequency you can evidence.

“You claim review by exception, but how do you know the report catches everything it should?” We validated the report and negative-tested it: we created controlled test events (a deletion, a reprocess, a blank reason) and confirmed the report flagged each. The rule set is risk-justified against our data criticality assessment, and it is under change control so it cannot be silently altered.

“Show me where the audit trail for this batch was reviewed.” Point to the batch/result review record, the exception report ID and version, the dispositioned exceptions, and the reviewer signature with date. If you cannot do this on demand, your documentation has the gap an inspector is looking for.

A pragmatic build sequence

If you are standing this up from scratch or remediating it, do it in this order.

1. Inventory in-scope GxP systems and their audit-trailed event categories.
2. Risk-assess each event category against data criticality; assign review layer and frequency.
3. Confirm the trails are trustworthy (secure, time-stamped, cannot be disabled by ordinary users, attribution to individuals). Fix this first; review cannot compensate for a weak trail.
4. Define exception rules for high-volume systems and validate the tooling, including negative tests.
5. Wire record-level review into existing review SOPs (batch record review, QC result review) so it happens before disposition.
6. Stand up periodic system-level review with a controlled record and a sustainable frequency.
7. Assign roles with independence built in, and define QA oversight.
8. Train reviewers on what the exceptions mean and how to disposition and escalate. See training-program-gxp.
9. Document everything, including clean reviews.
10. Audit the program periodically for effectiveness: are reviews happening, are escalations being raised, are the exception rules still right. Feed findings into your data governance program (see data-governance-framework).

Run it for a quarter, then look at how many exceptions you actually escalated. If the answer is zero across every system and every period, either you are unusually clean or, more likely, your exception rules are not testing the right things. A review program that never finds anything is a program nobody should trust.

Related articles

• audit-trail-design-and-review - configuring the trail itself, the prerequisite to review.
• data-criticality-and-data-risk - the risk basis that drives scope and frequency.
• chromatography-data-system-integrity - the highest-volume, highest-risk review case.
• batch-record-review-gmp - where record-level review lives in practice.
• 21-cfr-part-11-eu-annex-11 and part-11-annex-11-practical-guide - the controlling regulations.
• time-stamps-and-system-clock-control - clock events that periodic review must catch.
• validating-scripts-low-code-analytics - validating the exception tooling.
• csv-cybersecurity-access-control - attribution and shared-login problems that undermine review.
• hybrid-paper-electronic-records - reviewing systems with weak or no native trail.
• data-governance-framework - where the program is owned and measured.