Why audit trail review is a recurring FDA inspection finding

FDA inspectors consistently cite audit trail deficiencies as some of the most frequent data integrity observations in pharmaceutical and medical device facilities. The citations fall into two categories: systems that do not capture complete audit trails, and systems that do capture them but where the company has no procedure for reviewing them. Both are violations. The second is, in many ways, the more avoidable one.

Having an audit trail turned on is a start. Reviewing it systematically, at defined intervals, with documented results, is what FDA actually expects.

What FDA requires for audit trails

The regulatory foundation for audit trail requirements sits in 21 CFR Part 11, which applies to electronic records and electronic signatures in FDA-regulated activities. Section 11.10(e) requires that audit trails be computer-generated, include the date and time of operator entries and actions, and cover any creation, modification, or deletion of electronic records.

The FDA Data Integrity and Compliance with Drug CGMP guidance (2018) goes further, stating that audit trail review should be performed “as part of the routine data review process,” and that the frequency of audit trail review should reflect the risk of the system and the data it contains. This means audit trail review cannot be an annual checkbox activity for high-risk systems. It must be integrated into normal operations.

For systems governed by EU GMP Annex 11, the requirements align closely. Audit trails must be available for inspection and reviewed routinely, with any anomalies investigated and documented.

What must an audit trail capture

A compliant audit trail captures, at minimum:

• The identity of the operator who made each change (user ID, not just a shared login)
• The date and time of the change, in a format that cannot be altered by the user
• The original value before the change and the new value after it
• The reason for the change, where regulations require a reason code or comment
• Any deletions, voids, or overrides, with the same level of attribution

Shared logins defeat audit trail integrity entirely. If three people use the same account, the audit trail cannot attribute an action to a specific person. FDA inspectors treat shared logins as a data integrity failure, not a minor procedural gap.

Time stamps must come from a controlled system clock. A workstation whose clock can be adjusted by the user does not provide the independent, non-alterable time records that Part 11 requires.

Risk-based frequency for audit trail review

One of the most common questions quality teams ask is how often audit trails should be reviewed. FDA’s answer, from the 2018 data integrity guidance, is that the frequency should be commensurate with the risk of the system and the criticality of the data.

A practical framework for setting review frequency:

High-risk systems include those directly involved in batch release, laboratory result management, or product disposition. Audit trail review for these systems should be integrated into each relevant record review. When a batch record is reviewed for release, the associated audit trail should be reviewed at the same time.

Medium-risk systems include those that support quality processes but do not directly control product release. Document management systems, training records platforms, and CAPA tracking systems fall here. Monthly or quarterly periodic review is typical, with targeted review whenever a specific record is under investigation.

Low-risk systems include administrative applications with no path to product quality impact. Annual review, combined with event-triggered review when incidents occur, is generally sufficient.

Whatever frequency you set, it must be documented in a procedure and followed consistently. An SOP that says “quarterly” but has no review records for 18 months is not a defense during an inspection.

Building an audit trail review procedure

An effective audit trail review SOP includes several core elements.

Scope and applicability. Which systems are covered. The SOP should reference the company’s validated system inventory so reviewers always know which applications fall under the procedure.

Roles and responsibilities. Who is responsible for initiating the review, who performs it, and who approves the results. In most organizations, the system owner or the quality unit performs the review, and a second reviewer confirms the findings.

Review criteria. What reviewers are looking for. Common criteria include: entries created or modified outside of normal business hours, repeated failed login attempts, records that show deletion without a documented reason, changes made immediately before or after a product release decision, and changes to calibration or test records close to an out-of-specification event.

Documentation requirements. How results are recorded. Many organizations use a standardized audit trail review form that captures the system reviewed, the date range, the reviewer, any anomalies found, and the disposition of each anomaly. If no anomalies were found, the form still gets completed and filed.

Escalation process. What happens when an anomaly is found. The SOP should define whether anomalies trigger a deviation, an investigation, or simply a documented explanation, depending on their nature and severity.

What reviewers should look for

Audit trail review is only as good as the criteria reviewers apply. Scanning through hundreds of log entries without a clear focus produces reviews that look thorough but catch nothing.

Experienced quality teams focus their review on several high-yield patterns:

Off-hours activity. Data entries or modifications at 2 AM in a facility that operates one shift are worth investigating. This does not automatically mean misconduct, but it warrants an explanation.

Deleted or voided records. Every deletion should have a reason. Deletions without reasons, or clusters of deletions around a specific product lot, are red flags.

Repeated re-testing. A pattern of out-of-specification results followed by retests that pass, without a documented investigation, suggests selective result reporting. The audit trail on a LIMS system will show every test run, not just the passing ones.

Back-dated entries. If the time-stamp of a record creation does not match the production timeline, that inconsistency needs an explanation.

Unusual user activity. A user who accesses records they have no business reason to access, or who makes changes outside their normal work scope, should be flagged.

System configuration requirements that support compliant review

The ability to perform meaningful audit trail review depends on how systems are configured in the first place. Systems that do not capture sufficient detail make compliant review impossible regardless of how thorough the procedure is.

Before deploying or accepting any regulated system, quality teams should verify that the system:

• Assigns unique user IDs and enforces individual authentication
• Prevents users from modifying or disabling their own audit trail
• Time-stamps entries using a synchronized, secured system clock
• Captures the original and new value for every field change
• Retains audit trail data for the full retention period required for the associated records
• Allows export or reporting of audit trail data in a readable format for review and inspection

A system that buries audit trail data in a format that requires vendor assistance to read is not practically usable for routine review. If an FDA inspector asks to see the audit trail for a specific batch and your team cannot produce it within minutes, that is a problem.

Audit trail review during inspections

FDA inspectors increasingly ask to observe audit trail review in real time. They want to see that the procedure exists, that it has been followed, and that the review records are current. They may also ask reviewers to demonstrate how they would identify an anomaly in a sample audit trail.

This means the people who perform audit trail reviews need training specific to the task, not just general data integrity training. They should understand what anomaly patterns look like, how to document findings, and what escalation path to follow when they find something unusual.

A useful preparation exercise is a periodic “mock audit” of your own audit trails, performed by a team member who did not create the records. This kind of internal review builds reviewer capability and surfaces configuration or procedural gaps before an inspector does.

Audit trail review for QMS platforms

Quality management system platforms that manage CAPA records, deviation reports, change control, and document approvals present a specific audit trail review challenge. These systems contain records that directly document regulatory compliance, and their audit trails can show whether quality processes were followed as intended or manipulated after the fact.

For QMS platforms, audit trail review should be integrated into the routine quality oversight process. When management review covers open CAPA aging or deviation trends, the audit trail data from the CAPA and deviation modules should be part of that review, not a separate periodic exercise.

Cloudtheapp’s QMS platform maintains a secure, computer-generated audit trail across all 60+ applications, capturing every record creation, modification, approval, and deletion with user attribution and system time-stamps. The platform supports periodic audit trail exports and includes role-based access controls that prevent users from modifying their own activity logs. Schedule a demo to see the audit trail and data integrity features in detail.

When audit trail review uncovers a problem

Finding an anomaly in an audit trail review is not a failure. It is the system working as intended. What matters is how the organization responds.

A documented anomaly that receives a thorough investigation, a plausible explanation, and appropriate corrective action demonstrates exactly the kind of quality oversight FDA wants to see. An anomaly that is ignored, or that is addressed by deleting the record, is a significantly worse outcome than if the review had never happened.

When an anomaly cannot be explained by operational factors, the investigation should escalate to determine whether any product was released based on data that may have been manipulated, and whether that product needs to be recalled or placed on hold pending further review.

Building this escalation logic into the audit trail review SOP before a problem occurs, rather than improvising in the middle of an investigation, is the difference between a well-managed data integrity program and one that creates secondary findings during an inspection.