21 CFR Part 11 Audit Trail Requirements: What Your E-Signature System Must Log

When an FDA investigator sits down to review your electronic signature system, the first thing they ask for is the audit trail. Not the SOPs, not the validation summary, not the user access list. The audit trail. And when they look at it, they're checking for something specific: can they reconstruct exactly what happened, who did it, and when, without taking anyone's word for it?

That's what 21 CFR Part 11 Section 11.10(e) is actually about. The regulatory text is short. The implementation is where organizations run into trouble.

This post covers what Part 11 requires an e-signature audit trail to capture, field by field, what those requirements mean technically, and what the most common gaps look like when FDA inspectors find them.

What Section 11.10(e) Actually Says

The full text of 21 CFR Part 11 Section 11.10(e) reads:

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. Record changes shall not obscure previously recorded information. Audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.

That's it. Fifty-seven words. But each qualifier carries a specific technical meaning that's played out in 483 observations for decades. Let's unpack the terms that matter most.

Secure

"Secure" means the audit trail cannot be modified, overwritten, or deleted by any user, including system administrators. Access controls alone don't satisfy this. If a database administrator can connect directly to the underlying database and alter audit trail records without generating a detectable footprint, the trail isn't secure regardless of what the application UI enforces.

The current technical standard for satisfying "secure" is a SHA-256 hash chain: each audit entry includes a cryptographic hash of the previous entry. Modifying any historical record breaks the chain, and the discrepancy is detectable when the chain is verified. This is why FDA inspectors increasingly ask about the technical mechanism for tamper evidence, not just whether the application prevents edits through the UI.

Computer-Generated

The system generates the audit trail entry, not the user. A text field where users type what they did doesn't satisfy this. The audit entry must be created automatically by the system at the moment the triggering action occurs. The user can add a reason-for-change comment, but the core audit data must come from the system.

Time-Stamped

Timestamps must be generated server-side, synchronized to an external time standard. A timestamp pulled from the user's local device doesn't independently record the time of the action because the device clock can be manipulated. Server-side timestamps with NTP synchronization are the standard implementation.

Independently Record

The audit trail records events separately from the data record itself. If an audit trail entry is simply an embedded field in the record that the user edits along with the data, it doesn't satisfy this requirement. The audit trail must exist as a separate, system-controlled structure that records the event independently of the user's action on the record.

Shall Not Obscure Previously Recorded Information

This clause is the one that catches the most legacy systems. When a user corrects a field, the original value must remain visible alongside the new value. Overwriting or deleting the prior entry fails this requirement entirely. Systems that show only the current state of a record, with no way to see what it looked like before a correction, are non-compliant regardless of how technically sophisticated the rest of the platform is.

The Seven Data Elements Every Audit Trail Entry Must Contain

Part 11 doesn't provide a field-by-field schema, but FDA's inspection expectations, the October 2024 final guidance on electronic systems in clinical investigations, and decades of 483 observations collectively define what a compliant audit trail entry must capture.

The reason-for-change field deserves particular attention. Part 11's regulatory text doesn't explicitly require it in the 11.10(e) language, but FDA's broader data integrity expectations make it effectively mandatory for any modification to a regulated record. ALCOA+ requires that corrections be contemporaneous, documented, and traceable. In practice, a system that allows corrections without requiring a reason-for-change will generate 483 observations during a data integrity inspection. The reason-for-change must also be mandatory, not optional. A comment box that users can leave blank doesn't satisfy the requirement.

For a deeper look at ALCOA+ data integrity requirements and how they interact with Part 11, see our post on ALCOA+ audit trail software requirements.

What Triggers an Audit Trail Entry

Section 11.10(e) applies to actions that "create, modify, or delete electronic records." In an e-signature platform, that covers more events than most teams initially expect.

Signature Events

Every signing action must generate an audit entry. This includes the initial signature, any countersignature, a signature rejection or declination, and a signature revocation if the workflow allows it. The audit entry for a signing event must capture the signature meaning (approval, review, authorship) as required by Section 11.50, the user ID, and the timestamp. If a signer is prompted for two-component authentication before signing, the system must log whether that authentication succeeded or failed and at what time.

Record Corrections

Any modification to a record after it's been created triggers an audit requirement. The system must capture the original value, the new value, who made the change, when, and why. The original value cannot be deleted or overwritten. It must remain accessible in the audit trail.

Access and Authentication Events

Successful logins, failed login attempts, password changes, account lockouts, and session terminations all belong in the audit trail. Failed login attempts are specifically worth noting because FDA inspectors look at them to detect credential-sharing patterns. A user who logs in successfully from two IP addresses simultaneously, or who shows a string of failed attempts followed by a successful login at an implausible time, is a data integrity flag.

Administrator Actions

This is the most common gap in practice. If system administrators can perform actions (user provisioning, permission changes, system configuration changes, direct database access) that don't appear in the same audit trail reviewed by QA, the trail is incomplete. FDA inspectors routinely ask for administrator access logs alongside the standard audit trail. A discrepancy between the two, or the absence of admin-level logging entirely, is a 483. Every privileged action must generate an audit entry in the same system that logs user actions.

User Account Changes

Creating a new user account, changing a user's role or permissions, deactivating an account, and resetting a password all require audit entries. These events are important for demonstrating that system access was controlled throughout the period under inspection. A gap between when a staff member left the organization and when their account was deactivated, visible in the audit trail, is a finding about access management controls.

The Signature-Specific Audit Requirements Under Subpart C

The e-signature components of an audit trail have additional requirements beyond what 11.10(e) specifies for electronic records generally. Section 11.50 requires that signed electronic records contain the printed name of the signer, the date and time of signing, and the meaning associated with the signature.

This information must appear on the face of the signed record, not just in the audit trail. But the audit trail must also capture it as an independent, system-generated record. The two serve different purposes: the manifestation on the record is what the signer and reviewer see as part of the document, while the audit trail entry is what an FDA investigator reviews to verify the signature event independently.

Section 11.70 requires that electronic signatures be linked to their respective electronic records to ensure signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record. In audit trail terms, this means there must be a documented, cryptographically verifiable link between each signature event and the specific version of the record it was applied to. If the record is modified after signing, the audit trail must capture that modification as a separate event, and the signed version of the record must remain available separately from the current version.

Retention and Availability Requirements

Section 11.10(e) specifies that audit trail documentation must be retained "for a period at least as long as that required for the subject electronic records." Part 11 doesn't set the retention period itself. That comes from the predicate rule: the underlying FDA regulation requiring the record in the first place.

For clinical trial records, this typically means at least two years post-approval for IND records under 21 CFR 312.57, and 25 years for EU trial records under CTR 536/2014 Article 58. For GMP batch records under 21 CFR 211.180, it's at least one year past the drug product expiry date. The practical implication: your audit trail storage must be architected to survive for the same period as the records it covers, remain readable, and remain searchable for on-demand export.

The regulation also requires that audit trails "shall be available for agency review and copying." This means you must be able to export the complete audit trail for a specified period on demand during an inspection. Platforms that can only display audit data through their own interface, with no exportable format, create a practical problem: the investigator needs to review the trail in a format they can save, annotate, and take with them.

What FDA Inspectors Look for in Practice

FDA investigators who arrive to review electronic records typically request several things in the first hours: the audit trail for specific records or a specified time period, a filtered view showing all actions by a specific user, a list of all administrator-level actions, and any failed authentication attempts during the period under review.

The patterns that generate observations:

• Timestamp gaps or compression. If a user appears to have signed twenty documents in two minutes, or if timestamps show actions occurring in a sequence that's physically impossible given the system's processing requirements, investigators flag it. These patterns suggest backdated entries or batch processing of records that should have been signed individually and contemporaneously.
• Shared credentials visible in the trail. If the same user ID appears in audit entries from two different IP addresses at the same time, or if a single user ID account shows signing activity that spans more shifts than one person could work, the uniqueness requirement under Section 11.300 is violated.
• Missing administrator actions. If investigators can see configuration changes in system settings that don't appear in the audit trail, or if the audit trail shows no privileged user activity despite the system clearly having been administered, the trail is incomplete.
• No evidence of periodic review. Part 11 doesn't specify a mandatory review frequency, but FDA expects organizations to have a written SOP defining review intervals and documentation that those reviews occurred. Investigators ask for review records, not just the trail itself.
• Reason-for-change fields left blank or absent. If the system allows corrections to regulated records without requiring a reason, or if reasons appear in a non-mandatory comment field that users frequently skip, the investigator will note it.

For a complete inspection readiness checklist and more detail on what FDA investigators ask for, see our guide on FDA inspection readiness and audit trail requirements.

What Happens When the Audit Trail Fails

An inadequate audit trail doesn't just generate a 483 observation. In serious cases, it calls the validity of every electronic record and signature in the system into question. FDA can't accept data that can't be verified as accurate, complete, and trustworthy. When audit trail deficiencies are severe enough, the agency has rejected entire datasets in marketing applications and required paper reconstruction of records that should have been captured electronically.

The fix is rarely as simple as turning on a feature. Systems whose audit trails were built wrong at the architectural level, where the trail isn't computer-generated, where timestamps come from client devices, where administrator actions bypass logging, don't become compliant through configuration. They need to be replaced or supplemented with validated controls.

That's why audit trail architecture is a buying decision, not a configuration decision. A platform whose audit trail is structurally sound satisfies these requirements without organizational workarounds. A platform that treats audit trails as a reporting feature layered on top of a general-purpose signing workflow creates an ongoing compliance liability.

Evaluating Whether Your Current System Meets These Requirements

If you're assessing an existing platform, or evaluating a new one, these are the questions that get directly at the 11.10(e) requirements:

• Who generates audit trail entries, the system or the user? The answer must be the system, automatically, at the moment the triggering action occurs.
• Where are timestamps generated? Server-side, with NTP synchronization to an external time standard. If the answer is the client browser or the user's device, the timestamps don't satisfy "independently record."
• What is the tamper-evidence mechanism for the audit trail itself?SHA-256 hash chains are the current standard. If the answer is "database permissions prevent edits," that doesn't satisfy "secure" because privileged users can bypass application permissions.
• Do administrator actions appear in the same audit trail as user actions? If admin actions go to a separate log that isn't part of the standard QA review, the trail is incomplete.
• Is reason-for-change mandatory on corrections? Not optional, not a comment field, mandatory. And does the system preserve the original value alongside the correction?
• Can the audit trail be exported on demand? The export must be filterable by user, date range, and action type, and must be producible quickly enough to be useful during an inspection.
• What validation documentation covers the audit trail specifically? IQ/OQ/PQ protocols for an e-signature system should include specific test cases verifying audit trail completeness, immutability, and timestamp accuracy. If the vendor's validation package doesn't address these controls with executed test results, the audit trail's compliance is unverified.

For more on what IQ/OQ/PQ validation for an e-signature system should cover, see our guide on Part 11 e-signature validation step by step.

The Audit Trail as Signature Validity Evidence

Part 11's audit trail requirements aren't primarily about record-keeping for its own sake. They're about signature validity. An electronic signature is only as trustworthy as the system that generated it. If you can't demonstrate that a signature was applied by the named individual, at the stated time, to the specific version of the record on file, the signature's legal and regulatory validity is in question.

That's the standard FDA holds electronic signatures to. Not whether the signature looks right on the document, but whether the audit trail can prove it. A compliant audit trail is the evidence base for every signature in your system.

For details on Certivo's audit trail architecture and how it maps to each of these Part 11 requirements, visit our compliance overview. If you're reviewing your current SOPs for audit trail review procedures, our guide on electronic signature SOPs for FDA Part 11 covers what a compliant audit trail review procedure needs to include.