Visit Website →
← Back to blog

Inspection Ready FDA Audit Trails: Map Predicate Rules, Use Hash Chains

October 1, 2026
Inspection Ready FDA Audit Trails: Map Predicate Rules, Use Hash Chains

Under 21 CFR Part 11 §11.10(e), FDA expects secure, computer-generated, time-stamped audit trails that record creation, modification, and deletion and do not obscure earlier entries. This applies to electronic records covered by a predicate rule, not to every system in your building. Inspectors will want to see the logs themselves, proof they were reviewed, and documentation showing the retention period matches the related record.

TL;DR:

  • Audit trails must be tailored to record types, with more controls on CGMP-critical data and less on routine or non-regulatory records.
  • Hash chaining and verifiable timestamps are recommended to ensure audit trail integrity during inspections.
  • Documentation should include predicate-rule mapping, risk rationale, and details for legacy systems to demonstrate compliance.
  • Review frequency and process should be integrated with record review, with evidence retained for as long as the records themselves.
  • Most failures stem from missing upfront mapping and documentation, not technical flaws, emphasizing the importance of foundational controls.
Haiphai
Streamline Your Regulatory Operations
HaiPhai helps life sciences teams identify operational bottlenecks and integrate AI into regulatory processes such as drafting and clinical site activation.
Explore HaiPhai

Table of Contents

What counts as an audit trail and which records need one

A compliant audit trail is a secure, computer-generated, time-stamped record that lets someone reconstruct who did what, when, and why, without altering or hiding what came before it. That definition covers two different categories of events, and confusing them is a common source of gaps.

  • Data-level changes: edits to values like an HPLC processing parameter, a lab result, or a batch record entry.
  • System-level events: access attempts, user permission changes, record deletions, or configuration edits.

Not every electronic system needs the same level of audit-trail control. The practical approach is to build a record inventory, map each record type against its governing predicate rule, and document a risk-based rationale for the controls you apply. A spreadsheet used for internal scheduling looks nothing like a batch release record under CGMP, and the audit-trail expectations should reflect that difference rather than applying one blanket standard everywhere.

The operative text is short, but it carries the weight of most audit-trail disputes during inspection.

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. Record changes shall not obscure previously recorded information.

That language comes directly from 21 CFR Part 11 §11.10, and it does not stand alone. Section 11.10 also requires system validation, limited access to authorized individuals, and authority checks to confirm that only qualified people can perform certain operations. An audit trail that logs changes on a system with no access controls is not defensible: anyone could make the entries the log is supposedly protecting.

Retention is the other half of the obligation. Audit-trail documentation must be kept at least as long as the electronic records it describes, and it has to be available for FDA review on request. A company that purges logs faster than it purges the underlying records has already failed this requirement, regardless of what the logs actually show.

Scope, enforcement discretion, and legacy systems

FDA has never asked every electronic system in a regulated company to meet the same Part 11 standard. FDA's Part 11 scope guidance explains that the agency intends a narrow interpretation of Part 11 and applies enforcement discretion to specific provisions, including validation, audit trails, and record retention, while still enforcing the underlying predicate rule. That distinction matters: enforcement discretion on Part 11 provisions does not remove the predicate-rule obligation to keep accurate, complete records.

Documenting your position takes three steps:

  1. Map each electronic record to its predicate rule and identify what that rule already requires.
  2. Write a risk-based rationale explaining why your audit-trail controls fit the record's regulatory weight.
  3. For legacy systems that predate current logging capability, document the chain start date, known limitations, and any compensating controls, such as manual review logs or restricted access, that cover the gap.

Skipping the documentation step is the most common inspection finding: teams often make the right decisions but never write down why.

What a defensible audit entry actually contains

An audit trail is only useful if it captures enough detail to answer an inspector's questions without follow-up. At minimum, each entry needs a user ID tied to a real individual, a date and time stamp that includes the time zone, the action taken, the record identifier, and both the original and new values when a field changes. For CGMP-critical data, a documented reason for the change adds another layer of defensibility.

  • User identity: a unique ID, never a shared login or generic account.
  • Timestamp: date, time, and time zone from a reliable, synchronized clock source.
  • Action and values: what changed, the record it affected, and the before-and-after values.
  • Reason for change: required where the underlying data is CGMP-critical.

Protecting the trail matters as much as filling it out. FDA's Part 11 scope guidance ties predicate-rule mapping to the controls a company chooses, and the practical version of that principle is storage that is append-only or tamper-evident, access controls that keep the log itself from being edited, and a system design that makes it technically difficult, not just procedurally forbidden, to disable logging. Operational metadata rounds this out: consistent record linkage across systems, a canonical way of serializing entries so the same event always produces the same record, and a time source that cannot be manipulated locally.

Who reviews audit trails and how often

Audit-trail review works best when it is folded into the record review your quality unit already performs, not treated as a separate IT task that happens somewhere else. If a predicate rule specifies a review frequency, follow it. Where no specific frequency is stated, a risk-based schedule tied to how critical the data is works better than a fixed calendar rule applied uniformly.

  • Review audit trails alongside the records they document, not on a separate schedule disconnected from record approval.
  • Give the quality unit explicit oversight where CGMP requirements apply, rather than leaving review to whoever built the system.
  • Set frequency by data criticality when no predicate rule states one: finished-product results warrant tighter review than routine scheduling data.
  • Document each review with a signature or equivalent record, and retain that documentation for as long as the underlying record is retained.

Our related guide on reviewing audit trails for CGMP records walks through how this looks in a quality management system built around lab results and manufacturing data.

Building audit trails that hold up to technical scrutiny

Simple timestamped logging is often not enough to survive a skeptical inspection. A practitioner analysis from ISPE argues that hash-chained logs, where each entry's hash incorporates the previous entry's hash, give a mathematically checkable guarantee that nothing was altered after the fact. A verifier endpoint that recomputes the chain and confirms it matches becomes the actual compliance artifact an inspector can be shown, rather than a claim that the system is secure.

  • Use hash chaining so any alteration to a past entry breaks the chain and is immediately detectable.
  • Run a verifier on a schedule, such as nightly, and keep its output as documented evidence.
  • Anchor timestamps to a trusted source, such as an RFC 3161 timestamping service, when internal clock integrity is a concern.
  • Document the chain start date explicitly for any legacy system migrated into a hash-chained format.

Concurrent writes are the most common engineering failure point: two processes writing to the same record at once can corrupt a naive chain unless the system uses advisory locks. Non-deterministic serialization, where the same event produces slightly different byte representations, breaks hash verification even when nothing was actually tampered with. Backfilled legacy hashes need explicit documentation of where the verifiable chain actually begins, since claiming continuity before that point misrepresents what the system can prove.

Pro Tip: Ask your vendor for a callable verifier endpoint, not just a description of the hashing method. If they cannot demonstrate it live, the tamper-evidence claim is unproven.

Hash-linked records entering a verifier

Audit trails in EDC, ePRO, eTMF, and safety systems

Clinical systems carry their own version of this requirement. FDA's guidance on electronic source data in clinical investigations treats the audit trail as one control among several that support trustworthy source data, alongside identity verification and record protection. Signatures and record locks alone do not substitute for a working audit trail.

  • Preserve every change, identify the individual who made it, timestamp it, and capture a reason where the edit affects a critical field.
  • Map controls separately for EDC, ePRO, eTMF, and safety or lab systems: each carries different risk and different predicate-rule weight.
  • Write SOPs that require documented justification for data changes, and have reviewers sign off in a way that explicitly references audit-trail review, not just data review.

Our clinical trial risk register guidance covers how audit-trail findings tie back into broader trial risk monitoring.

Getting your audit-trail program inspection ready

Assembling the right evidence ahead of time saves weeks during an actual inspection.

  1. Build a record inventory and a predicate-rule mapping document that shows the rationale behind every audit-trail decision.
  2. Gather audit-trail specifications, verifier outputs, chain-start documentation for legacy data, governing SOPs, and signed review records in one place.
  3. Show evidence of scheduled verification runs, a documented incident-handling process, and a clear line from reviewer actions to product quality or safety decisions.

Our NDA filing readiness checklist covers the same retention and documentation expectations from the regulatory submission side.

Where compliance teams get audit trails wrong

Most audit-trail failures are not technical. They start with skipping the record inventory and predicate-rule mapping, then trying to bolt on logging controls after the fact without a documented rationale for what needs protection and why.

Four-step audit trail control mapping

The second failure is treating audit-trail review as an IT handoff instead of a quality function. A log nobody in the quality unit ever reads is not a control, it is a file. And the third: teams accept a vendor's word that a system is "audit-trail compliant" without asking for a verifier they can actually run. A hash chain nobody can independently check is a claim, not evidence.

Prioritize the boring parts first: inventory, mapping, and documented review. The technical sophistication only matters once those foundations exist.

— John

How HaiPhai helps biotech teams close audit-trail gaps

Building a defensible audit-trail program often competes with regulatory drafting, site activation, and a dozen other deadlines pulling at the same compliance team. HaiPhai works as an embedded operational partner rather than a software vendor, mapping predicate rules to your actual record inventory and designing verifiable audit-trail architectures that fit your systems instead of forcing a generic template onto them.

Haiphai

  • We start with an operational diagnostic that identifies where your current logging, review, and retention practices create inspection risk.
  • Our team builds governed automation around the controls you need, rather than leaving verification to a vendor claim.
  • Engagements are structured through The operating partnership, covering diagnostic, redesign, and ongoing governance.

Schedule an AI Velocity Diagnostic through our services page to see where your audit-trail program stands against inspection expectations.

Sources

FAQ

What are audit trail requirements?

Audit trail requirements under 21 CFR Part 11 §11.10(e) call for secure, computer-generated, time-stamped records of who created, modified, or deleted an electronic record and when. The requirement applies to records governed by a predicate rule, and changes must never obscure what was previously recorded.

What are the FDA's new regulations for 2026?

FDA has not published a new audit-trail regulation for 2026, and the operative requirement remains 21 CFR Part 11 §11.10(e) alongside FDA's existing Part 11 scope guidance. Compliance teams should treat predicate-rule mapping and documented risk rationale as the current standard rather than waiting on a regulatory change.

What are the requirements for an audit trail according to CFR 21 Part 11?

Under §11.10(e), an audit trail must be secure, computer-generated, and time-stamped, independently recording the date and time of entries and actions that create, modify, or delete electronic records. Prior entries cannot be obscured, and audit-trail documentation must be retained at least as long as the related record.

What are the FDA requirements for clinical trials?

For clinical investigations, FDA's guidance on electronic source data expects audit trails that preserve changes, identify the person making them, timestamp the edit, and capture a reason for critical field changes. This applies across EDC, ePRO, eTMF, and safety systems, and signatures or record locks alone do not satisfy the expectation.