21 CFR Part 11 Audit Trail Requirements: A Practical Guide

An audit trail is not simply a downloadable activity log. Under 21 CFR Part 11, the regulated organisation needs records that make relevant operator actions attributable, time-sequenced, reviewable, and available for the required retention period.

This guide focuses on practical audit-trail design. For the regulatory framework around electronic records and signatures, see the FDA 21 CFR Part 11 electronic signatures guide.

What § 11.10(e) requires

For closed systems, § 11.10(e) calls for secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Changes must not obscure information recorded previously. Audit-trail documentation must be retained at least as long as the subject record and be available for FDA review and copying.

The 2003 FDA Scope and Application guidance describes enforcement discretion for the audit-trail provisions in § 11.10(e), § 11.10(k)(2), and the corresponding requirements in § 11.30. Part 11 remains in effect, other applicable Part 11 controls still apply, and records must continue to meet predicate-rule requirements. FDA recommends basing the decision and extent of audit trails on a justified risk assessment that considers predicate rules, record integrity, product quality, and safety.

Which events should be captured

The event model should reflect the regulated process, not only login activity. Depending on intended use, capture:

• creation, modification, deletion, or versioning of a record;
• document upload and replacement;
• approval, rejection, cancellation, and delegation;
• signature request, authentication, execution, and failure;
• signer identity and role;
• signing meaning, such as review or approval;
• workflow and recipient changes;
• permission and account changes;
• administrative configuration;
• API submission, callback, retry, and error;
• export, archive, restoration, and retention actions.

For each event, record who acted, what happened, which record was affected, when it happened, and the resulting status. Where a value changes, retain enough information to understand the previous and new state.

Preserve chronology and context

Audit evidence should use a consistent time source and make time-zone treatment clear. A displayed local time can help users, but the underlying event record should support reliable sequencing across systems and regions.

An event should also retain context: record identifier, transaction or envelope identifier, user identifier, authentication method, action type, and outcome. Avoid relying solely on a person’s display name, which may change or be duplicated.

Prevent ordinary alteration

Users whose actions are being recorded should not be able to rewrite their audit history. Administrative access to logs should be restricted, monitored, and separated from routine business roles where appropriate.

Test whether:

• a record change creates a new audit event;
• the original value remains visible;
• deleted or cancelled transactions remain traceable;
• administrators cannot silently edit history;
• exports preserve event order and identifiers;
• restored records retain their associated evidence.

Retain and retrieve the evidence

The audit trail should remain associated with the subject record for the required retention period. Retention should account for the relevant predicate rule, legal holds, investigation needs, and system migration.

During inspection or internal review, teams should be able to produce accurate and complete records in a human-readable format and, where needed, an electronic format suitable for review and copying. Test retrieval before an inspection, including older records and records migrated from a previous system.

Establish an audit-trail review process

Collecting data is not the same as reviewing it. Define:

• which processes require routine review;
• which events trigger an exception review;
• who performs and approves the review;
• how suspected unauthorised activity is escalated;
• how findings link to deviations or corrective actions;
• how review evidence is documented.

Risk-based filters can focus attention on failed authentication, out-of-sequence actions, post-approval changes, unusual administrative activity, and repeated integration errors. Audit-trail tests should be traceable to the broader 21 CFR Part 11 software validation checklist, including negative paths and record restoration.

Connect audit trails to signatures

The audit trail supports, but does not replace, the signed record. The record should display the signer’s name, signing time, and signature meaning, while the signature must remain linked to the record. For the detailed requirements, read 21 CFR Part 11 electronic signature identity and record linking.

How eSign.AI supports audit evidence

eSign.AI captures signer and document events, signing status, timestamps, authentication context, and completion evidence within an electronic-signature workflow. It can also exchange status and evidence with connected business systems.

Organisations should configure the workflow to match their intended use, validate the relevant controls, define audit-review procedures, and ensure that records and evidence are retained for the required period. The platform supports the evidence layer; it does not replace the organisation’s Part 11 assessment or quality system.

Sources and further reading

• 21 CFR § 11.10 — Controls for closed systems
• FDA Guidance: Part 11 Scope and Application