Audit trails and electronic signatures are the two parts of 21 CFR Part 11 that turn into product requirements. They are also the two places where a system that looks finished in a demo comes apart under a customer's quality review.
The text is specific. It names the fields a signature must show, the number of components a signature needs, and what an audit trail may never do to earlier data. Most design mistakes come from building to a general idea of "logging" and "sign-off" instead of to those sections.
This article goes section by section through what the regulation asks, how it meets modern identity systems, and what a reviewer will try to break. For Part 11's scope and the role of predicate rules, start with 21 CFR Part 11 explained.
What 11.10(e) asks of an audit trail
Section 11.10(e) requires 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. It adds three conditions:
Record changes must not obscure previously recorded information.
Audit trail documentation must be kept for at least as long as the records it covers.
It must be available for FDA review and copying.
Read each phrase as a design constraint.
Computer-generated means users do not write the entries. A comment field where someone types "changed per deviation" is useful context, but it is not the audit trail.
Independently means the trail does not depend on the user's cooperation, and the person making a change cannot suppress the entry. An administrator who can edit or delete audit entries undermines the control, even if nobody ever does.
Not obscure means the old value survives. Overwriting a field and logging "field updated" fails, because the reader cannot see what was there before.
The text names the date and time. In practice, reviewers also expect the identity of the person who acted. An entry that cannot be attributed to a person is hard to defend. Some predicate rules also expect a reason for the change, so confirm what yours require.
Audit trail versus application log
The two are often built from the same event stream. They serve different readers and need different guarantees.
| Application log | Part 11 audit trail | |
|---|---|---|
| Reader | Engineers and operators | Quality, auditors, FDA investigators |
| Content | Requests, errors, performance | Who changed which record, old value, new value, when |
| Mutability | Rotated, sampled, or dropped | Protected from alteration and deletion |
| Retention | Set by operational need | At least as long as the underlying record |
| Format | Machine-oriented | Readable alongside the record it describes |
If you do route both through one pipeline, the audit events need their own retention and access rules. The patterns in centralized logging for compliance apply, with a longer retention horizon.
The enforcement discretion caveat
The FDA's 2003 scope guidance said the agency intended to exercise enforcement discretion over 11.10(e). That does not make audit trails optional in practice. The guidance still expects predicate rule compliance and a documented risk assessment. Customers will usually want the audit trail for any record that supports a regulated decision.
The FDA's later guidance on data integrity in drug manufacturing treats audit trail review as part of reviewing the record itself. Plan for someone to read these entries, not only to store them.
What a signature must show and how it binds
Section 11.3 defines an electronic signature as data executed, adopted, or authorized by a person to be the legally binding equivalent of their handwritten signature. Two sections in Subpart B control what it looks like and how it attaches.
Signature manifestation, 11.50. A signed record must show three things:
The printed name of the signer
The date and time the signature was executed
The meaning of the signature, such as review, approval, responsibility, or authorship
These elements are subject to the same controls as the record and must appear in any human-readable form of it, on screen and in printouts or exports. A signature that appears in the application but drops out of the PDF export fails this section.
Signature linking, 11.70. Signatures must be linked to their records so they cannot be excised, copied, or transferred to falsify another record by ordinary means. A signature stored as an image, or as a flag that a later edit leaves in place, does not meet this. A common approach is to invalidate a signature when the signed content changes, so the record has to be signed again.
Subpart C: who can sign and how
General requirements, 11.100
Each electronic signature must be unique to one person and never reused by or reassigned to anyone else. Before an organization establishes a person's electronic signature, it must verify that person's identity.
The regulated company must also certify to the FDA that the electronic signatures in its system are intended to be the legally binding equivalent of handwritten signatures. That certification is submitted on paper with a traditional handwritten signature. It is the customer's task, not the vendor's.
Signature components, 11.200
A signature not based on biometrics must use at least two distinct identification components, such as an identification code and a password. The section then distinguishes two cases:
Within one continuous period of controlled access, the first signing uses all components. Later signings in the same session use at least one component that only the individual can execute.
Outside a continuous session, each signing uses all components.
These signatures must be used only by their genuine owners. They must be administered so that use by anyone else would require two or more people to collaborate. Biometric signatures must be designed so only their genuine owner can use them.
Codes and passwords, 11.300
Section 11.300 lists the controls around identification codes and passwords:
No two people share the same combination of identification code and password.
Issuances are periodically checked, recalled, or revised.
Lost, stolen, or compromised tokens and cards are deauthorized, and replacements are issued under suitable controls.
Transaction safeguards prevent unauthorized use and report attempts urgently to the security function and, as appropriate, to management.
Tokens and cards are tested initially and periodically to confirm they work and have not been altered.
How this meets SSO and MFA
Modern applications rarely hold passwords. Users authenticate through an identity provider, often with a second factor. The regulation predates this model, so the mapping is an interpretation each regulated company makes and validates. What follows is a common reading, not settled doctrine.
An authenticated session is not a signature. Logging in proves who opened the session. Signing is a separate, deliberate act with a stated meaning. Most designs therefore prompt for re-authentication at the moment of signing, which lines up with the 11.200 rule on first and subsequent signings.
With single sign-on, that prompt is usually a step-up authentication through the identity provider, rather than a password the application checks itself. Whether that satisfies the "two distinct components" language for a given setup is something the customer documents in validation. The controls in SSO as a compliance control and enforcing MFA for every user supply much of the 11.300 evidence, such as unique identities, deprovisioning, and alerts on failed attempts.
What a reviewer will try to break
A customer's quality team, or their auditor, will test these behaviors directly. Expect requests like these:
Change a signed record and show what happens to the signature.
Export a signed record and show the name, date and time, and meaning on the printout.
Show the audit trail for one record, including the value before the change.
Show who can alter or delete audit entries, and the evidence that nobody can.
Show how timestamps are generated, which clock they come from, and which time zone is displayed.
Show what happens to a departed user's past signatures and to their user ID.
Show two users who share an account. The correct answer is that none do.
Shared service accounts that can modify regulated records are a frequent finding. So are timestamps taken from the user's device rather than the server, and signature meanings that default to "approved" without the signer choosing one.
How TrustLynce helps
TrustLynce runs user access reviews that record the population, each reviewer's decision, and the remediation, which supports the 11.300 requirement to check identification codes periodically. Evidence from your identity and code systems is collected on a schedule with a timestamp and source, so you can answer a supplier assessment with records rather than screenshots.