21 CFR Part 11 Compliant Software: Audit Trail, Electronic Signature, and Validation Requirements Met by Architecture

21 CFR Part 11 compliance in a QMS is not a settings toggle. It is not a checklist item checked off by a vendor’s marketing team. It is a set of specific technical and procedural requirements that a system must satisfy by design.

Those requirements live in the architecture: in how the audit trail is generated and protected, in how electronic signatures are bound to records, in how access controls are enforced at the application layer, and in the validation documentation that supports the regulated user’s obligation to validate the system before using it for FDA-required records.

This page covers how eLeaP implements each Part 11 requirement at the system architecture level.

The Structure of 21 CFR Part 11: Electronic Records and Electronic Signatures

Two Regulatory Areas, Two Separate Evaluations

21 CFR Part 11 covers two distinct areas: electronic records and electronic signatures. Each area has its own subpart, its own technical requirements, and its own FDA enforcement history.

A QMS that satisfies the electronic records requirements but implements electronic signatures that do not meet Subpart C fails Part 11 in the area most commonly scrutinized by FDA investigators. The two areas must be evaluated independently.

The central requirement under Section 11.10 is that electronic records used in place of paper records under FDA regulations must be accurate, reliable, authentic, and trustworthy. The central requirement under Subpart C is that the electronic signature constitutes a legally binding act equivalent to a wet-ink signature — and that the system enforces this technically, not just procedurally.

Audit Trail Requirements Under 21 CFR Part 11.10(e)

What § 11.10(e) Requires

Section 11.10(e) requires that persons using closed systems to create, modify, maintain, or transmit electronic records employ procedures and controls to ensure authenticity, integrity, and confidentiality. Specifically, it requires:

• Secure, computer-generated, time-stamped audit trails that independently record the date, time, and operator identity for entries and actions that create, modify, or delete electronic records
• That record changes do not obscure previously recorded information
• That audit trail documentation be retained for at least as long as the subject electronic records
• That audit trail records be available for agency review and copying

Each of these requirements maps to a specific technical characteristic. The following sections address each in turn.

Computer-Generated and Time-Stamped

The audit trail must be generated by the computer system itself — not manually entered by a user. In eLeaP, audit trail entries are generated automatically on every qualifying action:

• Record creation
• Field modification
• Status change
• Electronic signature application
• Document access
• Configuration change

No user action is required to trigger an audit trail entry. No user action can suppress one. Timestamps are generated by the server at the time the action is processed — not by the client device. This prevents timestamp manipulation through client clock adjustment. Server timestamps are maintained in UTC with offset recording, satisfying the accurate timestamping requirement across time zones.

What Each Audit Trail Entry Captures

Each audit trail entry in eLeaP captures four elements required by Section 11.10(e):

This structure satisfies Section 11.10(e)’s requirements that the audit trail independently record the date, time, and operator of each action, and that prior values are not obscured by changes.

Tamper-Evidence and Immutability

The audit trail in eLeaP is written to a separately secured, append-only audit log database layer. This is a database-layer separation hardcoded at the infrastructure level — not managed via application-level permissions.

• No user role — including the system administrator role — has write or delete access to the audit trail database
• The append-only architecture means entries can be added but never modified or removed after the fact
• The audit trail is readable and exportable by authorized personnel and FDA investigators
• The audit trail is not modifiable by any means available through the application

The database-layer separation between operational data and audit trail data is the technical implementation of Section 11.10(e)’s requirement that the audit trail be secure and computer-generated rather than subject to user manipulation. This distinction matters for validation engineers writing OQ test scripts: tamper-evidence is testable at the database layer, not solely by attempting edits through the UI.

Retention and Availability for Agency Review

Section 11.10(e) requires that audit trail documentation be retained for at least as long as the subject electronic records.

In eLeaP, audit trail entries are retained for the life of the record they document, plus any additional retention period required by the applicable regulation. For GMP batch records, audit trail retention satisfies the period required under 21 CFR Part 211.180, which specifies retention of at least one year after the expiry date of the batch.

Audit trail export for FDA review produces a formatted report of entries for specified records, specified users, or specified time periods — in a format suitable for submission to the agency.

Electronic Signature Requirements: 21 CFR Part 11.50, 11.100, and 11.200

Why Electronic Signature Compliance Is Harder Than It Looks

Electronic signature requirements under Part 11 are more frequently misimplemented than audit trail requirements. The technical bar is higher than a workflow checkbox or acknowledgment click. Sections 11.50, 11.100, and 11.200 together define:

• What a compliant electronic signature must contain
• How it must be bound to its record
• What identification components it must require at the time of signing

A system that provides a signature workflow but does not meet all three sections fails Part 11’s electronic signature requirements.

§ 11.50: Required Signature Components

Section 11.50 requires that signed electronic records contain information that clearly indicates:

• The printed name of the signer
• The date and time when the signature was executed
• The meaning associated with the signature — such as review, approval, responsibility, or authorship

In eLeaP, the signature record embedded in every signed document and workflow step contains:

• The signer’s full name as registered in the user account
• The server-generated timestamp of the signature action
• The meaning of the signature as configured in the workflow

The signature meaning is not free-text entered by the signer. It is a predefined term from the workflow configuration — such as ‘Approved,’ ‘Reviewed,’ or ‘Released.’ This ensures that meaning is consistent across all uses of the same signature type and cannot be altered by the signer at the time of signing.

§ 11.100: Uniqueness and Non-Reuse of Electronic Signatures

Section 11.100(a) requires that each electronic signature be unique to one individual and not be reused by or reassigned to anyone else. Section 11.100(b) requires that organizations verify the identity of individuals before their electronic signature is established and that this verification be documented.

In eLeaP:

• Each user account is associated with a single individual
• Account credentials — the unique identifier and password — are not shared, reassigned, or transferred
• User provisioning procedures include identity verification before account creation and documentation of that verification

Section 11.100(c) requires the regulated organization — not individual users — to submit a formal certification to the FDA stating that its electronic signatures are the legally binding equivalent of traditional handwritten signatures. eLeaP’s user provisioning workflows are designed to support the regulated user’s fulfilment of this corporate obligation, including documentation that supports the certification submission.

§ 11.200: Two Identification Components at Time of Signing

Section 11.200(a)(1) requires that electronic signatures not based on biometrics employ at least two distinct identification components — such as an identification code and a password.

Section 11.200(a)(2) creates a limited exception: for signing events that are not the first in a single continuous session, only one component is required. eLeaP does not use this exception.

In eLeaP, every electronic signature event — regardless of session context — requires both the user’s unique identification code and a password confirmation. The password confirmation is a re-authentication event, not a session token validation. The user must actively enter credentials at each signature point.

This consistent two-component requirement simplifies validation documentation by eliminating the need to define and test session boundary conditions. There are no session state variables to validate because the rule has no exceptions within eLeaP’s implementation.

§ 11.70: Cryptographic Binding of Signature to Record

Section 11.70 requires that electronic signatures be linked to their respective records to ensure signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. While the regulation specifies the required outcome, the technical method for achieving it is a design decision. eLeaP achieves it through cryptographic hashing.

The cryptographic binding works as follows:

• A cryptographic hash of the record content is computed at the time of signing
• The hash is stored as part of the signature record
• Any subsequent modification to the record content after signature produces a hash mismatch
• The mismatch is detectable by the system and flagged in the audit trail
• A record that has been modified after signing cannot present a valid signature state
• The modification invalidates the signature and requires re-signing, with both the modification and re-signing events captured in the audit trail

Cryptographic binding is applied to every electronic signature in the system, on every record type, without exception. It is not a feature that must be enabled per workflow.

Access Control Requirements Under 21 CFR Part 11.10(d) and 11.10(g)

What the Regulation Requires

Section 11.10(d) requires limiting system access to authorized individuals. Section 11.10(g) requires authority checks to ensure that only authorized individuals can:

• Use the system
• Electronically sign a record
• Access operation or computer system input or output devices
• Alter a record
• Perform the operation at hand

The operative word in Section 11.10(g) is ‘ensure.’ Authority checks must be enforced by the system, not by procedural expectation. A written procedure telling users not to perform an unauthorized action does not satisfy Section 11.10(g).

Three-Level Access Control Architecture in eLeaP

The authority check at Level 3 is enforced at the application layer. A user cannot approve a record they are not authorized to approve, regardless of whether a supervisor instructs them to. Procedural permission does not override system enforcement.

Access Review and Change Capture

Periodic access review is supported by a system report showing all active user accounts, assigned roles, and access permissions at the time of the report. This report is available on demand for internal access reviews and FDA inspection access control verification.

Changes to user access — role changes, account deactivation, and new account provisioning — are captured in the audit trail with the identity of the administrator who made the change and the server-generated timestamp.

System Validation Under 21 CFR Part 11.10(a): Vendor and Customer Responsibilities

What § 11.10(a) Requires

Section 11.10(a) requires validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. The validation requirement applies to the complete system: the eLeaP application, the hosting infrastructure, and the customer’s configured workflows and access controls.

Validation responsibility is apportioned between eLeaP as the vendor and the regulated user as the system owner.

What eLeaP Provides

What the Regulated User Is Responsible For

Data Integrity Under 21 CFR Part 11: ALCOA+ Framework and System Implementation

How ALCOA+ Attributes Map to eLeaP Architecture

FDA’s data integrity guidance applies ALCOA+ principles to electronic records in GxP contexts. These principles are the operational expression of the Section 11.10 requirements for accuracy, reliability, and trustworthiness. Each attribute maps to a specific system capability.

Evaluating 21 CFR Part 11 Compliant Software: Six Technical Questions

Ask These Questions. Request Documentation, Not Assertions.

A validation engineer or quality systems manager evaluating a QMS platform for Part 11 compliance should ask these six questions. Each maps directly to a Part 11 requirement and a testable system property. eLeaP’s answers to all six are yes, with supporting technical documentation available in the validation support package.

Q1. Is the audit trail generated at the server level on every qualifying action, and is the audit trail database inaccessible for modification by any user role — including system administrators? Can the vendor provide the OQ test script that demonstrated tamper-evidence during validation?

eLeaP: Yes. Audit trail entries are generated server-side on every qualifying action with no user-suppressible trigger. The audit trail is written to a separately secured, append-only database layer. No user role, including system administrator, has write or delete access. The OQ test script demonstrating tamper-evidence is included in the validation support package.

Q2. Does the electronic signature implementation require two distinct identification components — identification code and password — at every signature event, regardless of session state? Or does the implementation require the customer to define and validate session boundary conditions to determine when a single-component signature is permissible under § 11.200(a)(2)?

eLeaP: Yes, two components are required at every signature event without exception. eLeaP does not use the § 11.200(a)(2) single-session exception. The user must actively re-enter credentials at each signature point. There are no session boundary conditions to define or test.

Q3. Is each electronic signature cryptographically bound to the record version at the time of signing, such that any post-signature modification produces a detectable hash mismatch, is flagged in the audit trail, and requires re-signing?

eLeaP: Yes. A cryptographic hash of the record content is computed at the moment of signing. Any post-signature modification produces an immediate hash mismatch. The system detects this, flags a critical event in the audit trail, invalidates the signature state, and requires re-signing. Both the modification and re-signing events are captured in the audit trail.

Q4. Does the signed record contain the signer’s printed name, server-generated timestamp, and predefined signature meaning as required by § 11.50 — with the meaning drawn from a validated workflow configuration rather than free-text entry by the signer?

eLeaP: Yes. Every signed record contains the signer’s full name as registered in the user account, a server-generated timestamp, and a predefined signature meaning from the workflow configuration (e.g., ‘Approved,’ ‘Reviewed,’ ‘Released’). The signer cannot alter the meaning at the time of signing.

Q5. Does the vendor provide an IQ, OQ, and Part 11 traceability matrix as the baseline validation package? Does the vendor provide advance notification of system changes with change assessment documentation that supports the customer’s computerized system change control evaluation?

eLeaP: Yes. eLeaP provides IQ protocol and executed report, OQ protocol with test scripts covering all Part 11-relevant functions, and a traceability matrix mapping each Part 11 requirement to the system capability and OQ test that demonstrates compliance. Advance change notification and change assessment documentation are provided with each system update.

Q6. Does the access control system enforce authority checks at the application layer for record modification, electronic signature application, and workflow stage advancement — such that unauthorized actions are prevented by system logic rather than procedural expectation?

eLeaP: Yes. Authority checks are enforced at the application layer across three levels: system access, record-type access, and workflow-state authority. A user without the required role for a specific workflow action cannot perform that action, regardless of procedural instruction. System logic prevents the action; procedure does not substitute for it.

Related resources:

• 21 CFR Part 11 Compliance Checklist — plain-language introduction to Part 11 requirements
• GxP Quality Management Software — Part 11 compliance across GMP, GCP, GLP, GDP, and GPvP
• Computerized System Validation — validation requirements and support documentation
• Pharmaceutical QMS Software — Part 11 in the pharmaceutical GMP context