21 CFR Part 11 for developers: the audit trail and e-signature checks that end up on FDA 483s

If you build software that a pharmaceutical, biotech or medical device company uses to make, test or release product, sooner or later someone will ask: "Is it Part 11 compliant?"

Most developers hear that as a paperwork question. It is not. 21 CFR Part 11 is FDA's rule for electronic records and electronic signatures, and when an FDA investigator walks into a manufacturing facility, the gaps they write up are very often software behaviour: who could change a record, whether the change left a trace, and whether a signature means anything.

This post is the developer's version: what the rule asks for, how it shows up in an inspection, and what to build.

What Part 11 actually covers

Part 11 applies when a regulated company keeps a required record electronically instead of on paper, or signs it electronically. Batch records, lab results, deviation reports, training records, complaint files: if a regulation requires the record, and your system holds it, your system is in scope.

The core controls in 21 CFR 11.10 read like a feature list:

• Validation of the system to ensure accuracy, reliability and consistent intended performance (11.10(a)).
• Accurate and complete copies of records in human-readable and electronic form for inspection (11.10(b)).
• Record protection for the full retention period (11.10(c)).
• Access limited to authorized individuals (11.10(d)).
• Secure, computer-generated, time-stamped audit trails that record the date and time of entries and actions that create, modify or delete records, without obscuring the previous value (11.10(e)).
• Operational and authority checks, so steps happen in the allowed order and only permitted users can sign, alter or approve (11.10(f) and (g)).

Electronic signatures add their own rules: the signed record must show the signer's printed name, the date and time, and the meaning of the signature, such as review, approval or authorship (11.50). The signature must be linked to its record so it cannot be copied onto another one (11.70). A non-biometric signature needs at least two distinct components, such as a user ID and a password (11.200).

How it shows up in an inspection

Investigators rarely cite "Part 11" in the abstract. They cite what they saw. If you have read Form 483 observations, a few patterns repeat:

• Shared logins. Analysts on a lab instrument PC all use one account, so no audit trail can show who did what.
• Audit trail switched off or never reviewed. The feature exists, but it is disabled, or nobody looks at it before a batch is released.
• Admin rights for everyone. Users who generate data can also delete it, change the system clock or edit methods.
• Deleted or "trial" injections. Results were run, discarded and re-run until they passed, and the system let that happen without a record.
• Signatures without meaning. An approval that does not say what was approved, or a signature that can be applied to a record the signer never opened.

On drug manufacturing inspections these usually get written up under the predicate rules, for example 21 CFR 211.68 (controls over computerized systems) and 211.194 (complete laboratory records), rather than under Part 11 itself. The underlying failure is the same: the software allowed a record to change without a trustworthy trace.

If you want to see how often this comes up, the Form 483 reports database explains how to search observations by CFR section, and what an FDA Form 483 is covers how observations are written.

What to build

Here is the checklist I would hand an engineering team starting a GxP product.

1. Identity, not accounts. One person, one login. No shared or generic users. Tie every session to a named individual, enforce password rules and session timeouts, and log failed sign-in attempts.

2. Roles that separate duties. The person who creates data should not be able to delete it or approve it. Keep system administration (clock, configuration, user management) away from the people whose work it governs.

3. An append-only audit trail. For every create, update and delete on a regulated record, write who, what, when (server time, with time zone), the old value, the new value and, where your users require it, the reason. Make the trail immutable from the application. Store it with the record for at least as long as the record is kept.

4. Make the audit trail reviewable. This is the part most products miss. An audit trail nobody can read is not a control. Give reviewers a filtered view: changes to this batch, changes after approval, deletions, out-of-hours edits. The audit trail tests used in computerized system validation are a good list of what a reviewer will try.

5. Signatures with meaning and binding. Show name, date, time and meaning on the signed record and on any printout. Re-authenticate at the moment of signing. Bind the signature to a hash or version of the record so a later edit invalidates it visibly.

6. Don't let the clock move. Use server time from a controlled source. If a user can change the time on the box that stamps the record, the time stamp proves nothing.

7. Exports that keep context. "Accurate and complete copies" means an export includes the metadata and the audit trail, not just the final value.

8. Validation you can show. Keep requirements, risk assessment and test evidence for each release. FDA's move toward computer software assurance puts the effort on risk-based, critical-thinking testing rather than screenshots of everything, which is good news for teams with automated tests. The CSA vs CSV comparison covers the shift.

What about AI features?

If your product now drafts deviation summaries or flags anomalies with a model, the same rules apply to whatever ends up in the record. The model's output needs an author, a reviewer and a trace of what the human changed before signing. Treat the AI suggestion as an unsigned draft and the human approval as the regulated act. There is a longer discussion of whether LLM-based quality systems can pass a Part 11 audit.

The short version

Part 11 is not a certificate you buy. It is a set of behaviours your software either has or does not: named users, separated roles, an audit trail people can actually review, signatures that mean something, and a clock nobody can touch. Build those in from the first sprint and the compliance conversation with your customers gets much shorter.

I work on Atlas Compliance, which tracks FDA inspections and Form 483 observations for pharma and medical device quality teams. If you build for that market, the FDA inspection directory is free to browse.