QA cannot read every entry of a high-volume automated audit trail before an inspection, and regulators do not expect it to. FDA, MHRA, PIC/S and EU guidance expect a documented review based on risk. In practice that means three things. Trails are tiered by how critical they are. GMP-relevant changes are surfaced by validated exception reports, with a periodic spot-check of everything else. Where sampling is used, the reason for it is written into the SOP. The limit is just as clear. An audit trail that is captured but never reviewed keeps turning up in enforcement, and FDA has rejected one firm’s plan to review only a subset of audit trails in a setting where review before batch release is required.
Why line-by-line review breaks down on automated trails
ISPE’s article on audit trail review describes some “audit trail” modules that produce thousands of entries a month across fragmented files. The majority of those entries are irrelevant to data integrity or quality, which makes meaningful manual review of such modules impossible. In that situation, ISPE says, companies must use risk-based sampling or invest in exception-reporting tools so that review stays focused.
Part of the volume comes from mixing two different things. GAMP 5 (Second Edition) separates data audit trails, which are tied to GxP-relevant records, from system or technical logs. ISPE’s reading is that only audit trails linked to GxP-relevant records need routine review as part of data verification. System logs serve other purposes and belong in separate, risk-based processes. Reviewing login events or configuration changes periodically helps show the system is still in a validated state. It is not a direct control on product data.
ISPE calls this distinction fundamental. A single export that mixes chromatography reprocessing events with every logon is the “huge dustbin” McDowall describes, and good search routines are needed to pull the relevant changes for one analysis out of it.
Does 21 CFR Part 11 require every audit trail entry to be reviewed?
No. Part 11 requires the audit trail to exist. The review obligation comes from elsewhere. Section 11.10(e) covers computer-generated, time-stamped audit trails. FDA’s 2018 data integrity guidance defines an audit trail as a secure, computer-generated, time-stamped electronic record that allows the creation, modification or deletion of an electronic record to be reconstructed. FDA’s 2003 scope and application guidance says the agency intends to exercise enforcement discretion on the 11.10(e) requirement, while firms must still comply with predicate rules on dates, times, sequencing of events, and changes that must not obscure earlier entries. The same guidance recommends deciding whether to apply audit trails based on predicate rule requirements, a justified and documented risk assessment, and the potential effect on product quality, safety and record integrity.
For drug manufacturing, the review duty comes through the CGMP regulations. FDA’s 2018 data integrity Q&A says people responsible for record review should review the audit trails that capture changes to data associated with a record as they review the rest of that record. It also says all production and control records, audit trails included, must be reviewed and approved by the quality unit under § 211.192. On frequency, the rule is this. Where CGMP sets a review frequency for the data, such as § 211.22 review before batch release, the audit trail follows it. Where it does not, the firm sets the frequency by risk assessment, looking at data criticality, control mechanisms and impact on product quality.
On scope, MHRA’s 2018 guidance says audit trail review does not need to cover every system activity, such as user log on and log off or keystrokes. FDA’s 2024 clinical investigations Q&A says the decision to review audit trails should rest on a risk assessment of the investigation and the systems, procedures and controls in place.
The sources disagree on one point. An inspection-readiness checklist from Klyverity argues that, in enforcement practice, Part 11’s “available for review” in 11.10(e) means reviewed on a documented schedule. McDowall, writing in LCGC in 2020, calls Annex 11’s “regularly reviewed” the first and currently only explicit regulatory requirement to review audit trail entries. The practical result is the same either way: a trail nobody reviews is a compliance gap.
How do Annex 11 audit trail expectations differ from Part 11?
Annex 11 states the review requirement explicitly. The 2011 Annex 11, still in force, says in clause 9 that firms should consider, based on a risk assessment, building in a record of all GMP-relevant changes and deletions. The reason for any change or deletion of GMP-relevant data should be documented, and audit trails need to be “available and convertible to a generally intelligible form and regularly reviewed.”
The 2025 draft of Annex 11 goes further on review. It says reviewing all entries in an audit trail may not be effective. Reviews should be targeted, based on risk and adapted to local manufacturing processes. Reviews should follow a documented procedure that says who reviews, what and when, and they should be carried out by people not directly involved in the activities being reviewed. The draft also expects review before batch release unless the risk of detecting unwarranted changes later can be justified. It is a draft not yet finalised, so treat it as the direction EU expectations are moving in, not as binding text.
| Point of comparison | 21 CFR Part 11 (with FDA guidance) | EU GMP Annex 11 (2011 in force; 2025 draft) |
|---|---|---|
| Audit trail capture | 11.10(e) time-stamped trail; FDA applies enforcement discretion, but predicate rules still apply | Clause 9: consider, based on risk, recording all GMP-relevant changes and deletions |
| Reason for change | Should be included where applicable (FDA 2024 Q&A) | Should be documented for GMP-relevant changes or deletions |
| Explicit review requirement | Comes through CGMP predicate rules, e.g. § 211.192 | “Regularly reviewed” in clause 9 |
| Review frequency | Follows predicate rule, otherwise set by risk assessment | Draft: timely, by risk; before batch release unless justified |
| Every entry? | Not every system activity needs review (MHRA) | Draft: reviewing all entries may not be effective; targeted review |
| Who reviews | Quality unit review and approval | Draft: personnel not directly involved (peer review) |
Is there a standard risk-based approach regulators accept?
No single sampling percentage or method is “regulator approved”. Guidance from different regulators does agree on the elements. MHRA says audit trails may be reviewed either as a list of relevant data or through an exception reporting process. PIC/S PI 041-1 asks firms to work out which audit trails are significant and to define review strategies based on data criticality. ISPE notes that organisations may define risk-based sampling strategies internally. CASRAI’s guide to a risk-based SOP names the two patterns that hold up under inspection: review by exception and tiered sampling, each with its rationale documented.
The clinical side says the same thing in different words. ICH E6(R3) expects review of audit trails and metadata to be planned, with its extent and nature based on risk and adjusted as experience builds. EMA expects review to be proactive and ongoing unless another approach is justified, and it recognises that technology can help with review of larger datasets.
The SCDM industry position paper adds a caution: its authors say clear regulatory guidance is still needed for risk-based audit trail review, as its lack slowed risk-based monitoring. Whether an approach is accepted therefore depends on the written justification and on applying it consistently. Choosing the “right” method does not settle it.
Three tiers of audit trail, three review cadences
CASRAI reports a framework in which critical audit trails, the ones tied to the operation being released or reported, are reviewed by an independent reviewer before sign-off. Lower-risk trails are reviewed on a periodic schedule instead of per event.
| Tier | What belongs in it | When it is reviewed | What makes it defensible |
|---|---|---|---|
| Critical / release-linked | CDS integration parameters and reprocessing history; a LIMS result going onto a Certificate of Analysis; an EDC field feeding a case report form | Before the linked decision (e.g. batch release), not only on a calendar | Predicate-rule timing, e.g. § 211.22 review before release |
| Routine / periodic | Electronic lab notebook, document management, training records | Monthly or quarterly sampling review | Risk assessment documents why periodic sampling is enough |
| Low-risk / exception-driven | Trails with no standing review schedule | Only when a deviation, discrepancy or complaint gives a reason | Trigger and scope recorded in the deviation record itself |
Placing systems into tiers is a judgement about data impact. The IQ Consortium authors put release, clinical stability and cleaning verification in the high-impact group at a minimum. They suggest that activities such as method validation may be medium or low impact, depending on a company’s risk considerations. MHRA allows reduced effort for lower-impact data when the process does not allow amendment without high-level system access or specialist software.
Sampling and summarising so the review fits before the inspection date
MHRA defines an exception report as “a validated search tool that identifies and documents predetermined ‘abnormal’ data or actions, that require further attention or investigation by the data reviewer.” In CASRAI’s description, the system or a validated report built on it flags defined triggers: changes to critical fields, deletions, actions outside normal working hours, and changes made after a result was first recorded. Human review then covers the flagged events plus a documented periodic spot-check of the rest.
McDowall adds the condition that makes this work. Review by exception becomes an option once technical controls that identify data changes are in place and validated. He also notes that technical controls reduce what has to be reviewed. If no user role can delete data, a reviewer does not need to search for deletions. Colour-coded flags, for example green for no change, yellow for modifications and red for deletions, keep the reviewer from “drowning in data”.
Risk-based sampling is the second pattern. ISPE describes records chosen by subject matter experts based on system risk, complexity, size, novelty, relevant incidents, and operational and change history. Those system audit trail reviews should be defined separately from routine second-person data verification. CASRAI’s test is whether an inspector can see from the SOP that the coverage decision was deliberate, not “a resource shortcut dressed up as a strategy.”
Summarising is the third tool, described in clinical data guidance. The SCDM paper recommends visualisations that turn large volumes of audit data into summaries, and statistical methods that find outliers. Its key risk indicator scheme marks a site green within one standard deviation of the study mean, amber within two, and red beyond two. Assuming a normal distribution, about 68% of indicators fall within one standard deviation, so targeted review covers the roughly 32% outside it. A flag starts an investigation. It does not finish one. Repeated corrections to one field at one site may be explained by enrolment, a protocol amendment or a training issue, so the context has to be checked first.
The choice between approaches comes down to volume and criticality. Full manual review fits low-volume systems whose trails are critical. Exception reporting plus tiered sampling fits high volume where most entries are routine. In both cases the rationale, the sampling basis and the escalation triggers must be on paper before the inspector asks.
Where those exception reports and filters are built as software over LIMS, CDS or EDC exports, they must be validated for their intended use.
Which events should be reviewed in full, never sampled?
Sampling cannot be allowed to hide the events a reviewer is there to catch. The following list draws on the IQ authors’ critical-changes list, CASRAI’s triggers, and MHRA and WHO controls:
- Deletion of data.
- Changes to test parameters or to data processing parameters, both on the IQ critical-changes list.
- Repeated analysis or reprocessing without justification, and changes to sample sequences or identification (IQ critical changes).
- The change history of finished product test results, and changes to critical process parameters (IQ critical changes).
- Changes made after a result was first recorded, and actions outside normal working hours, both CASRAI exception-report triggers.
- Administrator actions: users should not be able to amend or switch off the audit trail, and when an administrator does, a record of that action must be kept.
- Gaps in the timestamp sequence and missing original values, both among the most common 483 audit trail findings in Klyverity’s checklist.
- In chromatography, short or repeated injection sequences and aborted runs.
The 2025 Annex 11 draft states the aim directly. Review should detect deliberate or accidental changes to critical processes or data, including repeated activities, errors, omissions, unauthorised deviations and loss of data integrity.
Where FDA has drawn the line on subset review
In its August 2021 warning letter to Adamson Analytical Laboratories, FDA noted that the firm had committed to review only a subset of audit trails for future laboratory analyses. FDA called that response inadequate because 21 CFR 211.22 requires data review, including audit trail data, before batch release. The same firm had run HPLC and GC instruments without an activated audit trail from at least April 2018 until February 2021.
Sampling does not replace the release-linked review that a predicate rule requires. In CASRAI’s tier model, sampling belongs to the routine, periodic tier. The September 2025 warning letter to Persōn & Covey shows the other way firms fail: audit trails were not independently reviewed after analysis or at an established frequency. Klyverity’s reading of enforcement since FDA’s 2016 data integrity guidance is that firms had audit trails that logged everything and never reviewed them.
How to document the review procedure so it survives an FDA or EU GMP inspection
The SOP is inspected as closely as the trail itself. Klyverity notes that a 483 can follow even when the audit trail is technically sound, if the governing SOPs are absent, vague or not enforced. ISPE identifies SOPs that just say “review audit trail”, without criteria, as a persistent gap. They leave reviewers unsure whether the task means the regulatory data audit trail review, a system log check or a general verification.
What the procedure should state
Taken together, the sources give a minimum set of contents:
- Scope: which systems, record types and date ranges are covered, with data trails and system logs defined separately.
- The risk basis for each tier, with the reason for any data source left out of review.
- Frequency for each system, justified by risk.
- Who may review, usually QA and not the operators whose actions are being reviewed.
- What counts as a finding: shared logins, timestamp anomalies, missing entries, unexplained deletions.
- How findings are documented and escalated, and where records are kept and for how long.
- The sampling rationale and exception-report triggers, written into the procedure itself.
What each review record must show
A defensible record names the specific system, date range, record or batch covered. It also shows who reviewed it, with a signature and date, what was found (including an explicit statement when nothing was found), and a cross-reference to any deviation, CAPA or investigation. MHRA asks for the same positive statement of whether issues were found, plus the review date and the reviewer’s signature. WHO TRS 1033 asks for the conclusion to be documented, signed and dated.
Investigators check whether a review was substantive or pro forma. A record that says “no issues” with nothing showing what was checked is a credibility problem. Klyverity also notes that records should state the date range covered, not just the date the review took place. If the review is produced and approved inside the system, the report becomes a GxP record in its own right. It needs Part 11 controls: limited access, its own audit trail, and retention.
Changing the review approach is itself a controlled change
An exception report must be validated for its intended use. MHRA says custom report validation must show that the report’s steps match the data-checking SOP and that its output fits the review procedure. FDA’s 2024 Q&A expects system changes to be evaluated and validated according to risk, and documented. Adamson’s activation of instrument audit trails in February 2021 without governing procedures or change control was itself cited. Changing a trigger rule, a sampling rate or a tier assignment should therefore go through change control with a documented rationale, as the original design did.
The IQ authors note that ATR frequency may be adjusted based on documented historical performance.
