21 CFR Part 11 for chamber data

Part 11 is short. The controls for closed systems fit on two pages, and most of the confusion around it comes not from the text being unclear but from people arriving with an idea of what it says before reading it.

This is a practical reading for chamber and furnace data specifically: what the rule asks of the records, which parts a system can provide, which parts only you can, and where the boundary between those actually falls.

The misreading worth clearing up first

Part 11 does not require encryption.

The relevant control, §11.10(c), asks for:

“Protection of records to enable their accurate and ready retrieval throughout the records retention period.”

That is about availability and integrity — the record must still be there, and still be trustworthy, years later. It is not about confidentiality. An encrypted database that nobody can restore satisfies it less well than a plain one with a tested backup.

This matters because “we encrypt it” is a common answer to a Part 11 question, and it answers a different question. What §11.10(c) actually pushes you toward is retention: where the records live, whether they are backed up, whether the backup has ever been restored, and whether anyone could still read them after the software that wrote them is three versions further on.

Confidentiality may still be required of you — by data protection obligations, by customer agreements, by your own security policy. Just not by this clause, and conflating the two tends to produce a system that is encrypted and unretrievable.

The split that governs everything else

Part 11 asks for a mixture of technical controls and procedural controls, and no software can supply the second kind. A vendor claiming otherwise is telling you something that cannot be true.

What a system can provide: the audit trail, the signature mechanism, access control, record integrity, the ability to produce accurate copies.

What only you can provide: the validation of that system in your environment, the training records, the written policies making individuals accountable for signatures issued under their name, and the procedures around who gets an account.

The checklist below is split on that line, because the most common cause of an uncomfortable audit is a site that bought good software and assumed it had bought the procedures with it.

Part one — what the system has to do

Audit trail — §11.10(e)

The rule asks for “secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records.”

Check that yours:

Records the old value as well as the new one. “Setpoint changed” is not an audit trail entry. “Setpoint changed from 180 °C to 185 °C” is.
Is not switchable off by the people it audits. If an operator can disable it, it is a log, not an audit trail.
Does not overwrite. The rule says audit trail records must be retained at least as long as the records they describe, and be available for review and copying. A ring buffer that discards the oldest entries does not do this.
Timestamps unambiguously. A timestamp with no timezone is not a time, and a record whose entries are in one clock while its report is in another cannot be reconciled against anything.

Signatures — §11.50 and §11.70

§11.50 requires that a signed record shows three things, and it is specific: the printed name of the signer, the date and time, and the meaning of the signature — approval, review, responsibility.

Two things worth checking, because both are commonly missed:

A user id is not a printed name. Renaming the account to a person’s full name does not fix it either; the rule asks for the printed name as an attribute of the signed record. And if the name is resolved when the document is printed rather than captured when it is signed, then editing the account later changes what a historical signature appears to say.
The signer must be able to see what they are signing. A signature applied to “the report” without the record being identified in the signature manifestation leaves a gap in the chain, and §11.70 asks that signatures be linked to their records in a way that cannot be excised or copied.

Access control — §11.10(d) and (g)

“Limiting system access to authorized individuals,” and “use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.”

The practical test is whether roles differ in what they can do, not whether different people have different passwords. If an operator account can change a tolerance band, the authority check is decorative.

Worth checking too: whether the system’s own configuration files are readable outside it. Role-based access inside an application is undermined if a credential or a setting is sitting in a file any local account can open.

Record protection and retention — §11.10(b) and (c)

§11.10(b) asks for “the ability to generate accurate and complete copies of records in both human readable and electronic form.”

Both. A PDF alone is human-readable but not the electronic record. A database alone is the reverse. If an inspector asks for a run in both forms, you need to be able to produce them.

For retention, the questions that actually matter:

Where does each record type physically live? Process data, audit trail and signatures are often in different stores. Find out which, because you cannot back up what you cannot name.
Is every one of those in your backup regime? Systems that mirror process data to an enterprise database frequently and deliberately do not mirror the audit trail, precisely because copying a tamper-evident record into a writable table weakens it. That is a defensible design — but it means the audit trail’s durability is your responsibility and “it’s synced” is not the answer.
Has a restore ever been tested? This is the one that fails in practice.

Integrity — §11.10(a) and (b)

Beyond validation, the useful question is: if a record were altered, would anyone know?

Hash-chaining, checksums or equivalent turn “the file has not been changed” from an assertion into something checkable. Where a system offers this and it is switchable, find out whether it is switched on — a tamper-evidence feature that defaults to off protects nothing on a fresh installation, and nobody will discover this at a convenient moment.

Part two — what only your procedures can do

None of these are software questions, and all of them get asked.

Validation — §11.10(a). “Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.” Validation is of your system in your environment — the software is one input to it. A vendor cannot validate your installation, and any claim that a product is “Part 11 validated” describes something that does not exist.

Training — §11.10(i). Documented evidence that the people using the system have the education, training and experience to do so.

Accountability — §11.10(j). A written policy holding individuals accountable for actions taken under their electronic signature. This is what makes a signature mean anything, and it is a document you write, not a feature you enable.

Signature certification — §11.100(c). Certification to the FDA that electronic signatures used in your organisation are the legally binding equivalent of handwritten signatures. A one-time submission, and a common gap.

Credential controls — §11.300. Uniqueness of each combination of identification code and password, periodic revision, loss management, and safeguards against unauthorised use. Partly technical, but the procedures around issuing and revoking accounts are yours.

The three things people most often get wrong

Treating the checklist as the goal. Part 11 compliance is a property of a system in use, not of a product on a shelf. Every control above can be present and the system still fail an inspection because nobody follows the procedure.

Assuming the audit trail is backed up because the data is. Covered above, and it is the single most common gap in chamber installations specifically — because the process data usually is mirrored somewhere visible, which makes it feel handled.

Confusing “the software supports this” with “this is switched on.” Tamper evidence, audit trail scope, role restrictions and signature enforcement are often configurable. The configuration is part of the validated state, and a default is not a decision.

What “Part 11 ready” should mean when a vendor says it

It should mean: the technical controls are present, and the vendor can tell you precisely which of the rule’s requirements they address and which they do not.

It should not be read as certified, validated or approved. Software cannot be Part 11 certified — there is no such certification — and a system is validated by the organisation running it. A vendor who claims otherwise has told you something useful about the vendor.

The reasonable question to ask instead: which parts of Part 11 does this product address, which does it leave to us, and where is that written down? A vendor who can answer that in specifics is a vendor who has read the rule.

ProcessView+ provides the technical controls described in part one — a hash-chained audit trail with old and new values, electronic signatures carrying name, time and meaning, role-based access, and tamper-evident data files. Demonstrating compliance also depends on your validation, procedures and documentation in your environment. We are glad to support that effort; for formal regulatory sign-off, consult your quality and regulatory professionals.