21 CFR Part 11 in practice: audit trails, electronic signatures, data integrity

The first time you hear “we need to be Part 11 compliant”, it sounds like a documentation task. It is not. Part 11 translates into architecture decisions that, if you get them wrong early, you pay for with a rewrite.

I worked on systems where this mattered in practice — components for a chromatography data system at Waters, and clinical systems at Cerner. This article is about the engineering side, not about filling in forms.

What does 21 CFR Part 11 actually require?

It is the FDA regulation covering electronic records and electronic signatures. The central idea: if you replace paper and handwritten signatures with a computer system, that system must provide at least the same level of trust.

The requirements that touch code directly:

• the system is validated (you can demonstrate it does what it should);
• you can generate accurate and complete copies of records, in a form usable for inspection;
• records are protected and retrievable throughout the retention period;
• access is limited to authorised individuals;
• there is a secure, computer-generated, time-stamped audit trail;
• authority checks — who is allowed to do what.

Notice what it does not say: no specific technology. You can be compliant with very different stacks, as long as you can demonstrate the properties above.

And, more importantly, it does not apply everywhere. Part 11 covers records required by a predicate rule that you choose to keep electronically. In its 2003 Scope and Application guidance, the FDA stated its intent to exercise enforcement discretion over part of the requirements — audit trails included — and tied the decision to a justified and documented risk assessment. In practice: you do not audit everything because “Part 11 says so”, but because you determined, with an argument, what falls in scope.

The rest of this article assumes you have already done that scoping.

What does an audit trail mean in code?

This is where most teams get stuck, because a compliant audit trail is not just a log table.

It must be:

• system-generated, not user-written;
• time-stamped, recorded independently of the operator — in practice the server’s clock, not the client’s;
• recording the creation, modification and deletion of records, with who and when;
• not obscuring previously recorded information — the old value stays visible, never overwritten;
• retained at least as long as the record it belongs to.

The technical consequence is significant: you must not lose the previous value on update. Either the row is versioned, or a trigger captures the prior state before it is overwritten — the requirement is that the earlier information stays recoverable, not that the current row is never updated. “Deletion” usually becomes a logical marking. And the audit trail cannot be editable from the application — if an admin can modify it, it loses its evidentiary value.

A classic mistake: using application logs as the audit trail. Logs rotate, get lost, can be filtered, and are not structured per record. They are not the same thing.

What does a compliant electronic signature look like?

An electronic signature is not an “I agree” checkbox. The regulation requires the signature to explicitly contain:

Component	What it means in practice
Signer’s name	printed, not just an internal ID
Date and time of signing	system time stamp
Meaning of the signing	what it signifies: review, approval, responsibility, authorship

In addition, the signature must be linked to its record such that it cannot be excised, copied or transferred to another record in order to falsify something.

For signatures not based on biometrics, at least two distinct identification components are required — for example a user ID and a password. Within a single continuous session, the first signing uses both, and subsequent signings may use at least the component private to the individual. Outside a continuous session, every signing requires all components.

From an implementation standpoint, this means the “signature” is its own entity in the model, bound cryptographically or referentially to the signed content — not an approved_by column on the row.

What is data integrity (ALCOA+)?

Around Part 11 sits a set of data-integrity principles known as ALCOA+. They are not the text of the regulation, but they are the shared language inspectors use when discussing data:

• Attributable — you know who performed the action;
• Legible — it can be read and interpreted;
• Contemporaneous — recorded when it happened, not retroactively;
• Original — the primary source, not a transcription;
• Accurate — correct;
• plus: complete, consistent, enduring, available.

If you design your data model with these in mind, compliance becomes a consequence rather than a separate effort. “Contemporaneous”, for instance, immediately tells you the timestamp must come from the server, not the client.

What do teams get wrong most often?

1. Treating Part 11 as a layer added at the end. A correct audit trail changes the data model; it cannot be glued onto a schema built around destructive updates.
2. Confusing logging with the audit trail. See above — completely different purposes.
3. Signature as a boolean. Without a name, a moment and a meaning, it is not a signature.
4. Uncontrolled clocks. Timestamps from different sources, without a clear time zone, undermine the credibility of the entire series.
5. Forgetting the export. The “accurate and complete copies” requirement means you must be able to produce the data in an inspectable form — designed up front, not improvised under pressure.

Where do you start if your product falls under Part 11?

The order I found most effective:

1. Determine which records are regulated. It is rarely the whole database. Scoping cuts the work enormously.
2. Design the audit trail before features. It is a structural decision.
3. Make the signature a first-class entity in the model.
4. Control time from a single source.
5. Build the export early and test it like a real feature.

The rest — policies, training, procedures — exist and matter, but live outside the code. The part you can irreversibly get wrong as an engineer is the part above.

If you are building something in this space and want a technical conversation rather than a compliance one, I am open to it.