21 CFR Part 11 for temperature monitoring: a clause-by-clause checklist

Start with the sentence that saves the most time in vendor selection: there is no such thing as a Part 11 certified product. No body certifies against 21 CFR Part 11. Compliance is a property of a system as configured and used at your site, established by your validation, under your procedures, with your trained people.

What a vendor can honestly claim is that their product provides the technical controls Part 11 expects, and that those controls are documented and testable. Anything stronger than that is marketing, and it will not help you in an inspection.

With that settled, here is what the regulation actually asks, clause by clause, applied to a temperature monitoring system.

First: does Part 11 even apply to you?

Part 11 governs electronic records and electronic signatures that are required by a predicate rule — the underlying GMP, GLP or GCP regulation. It is not a standalone obligation to digitise anything.

For a monitoring system, the practical test is: does a predicate rule require you to keep this temperature record? If you are manufacturing or distributing for the US market, or handling US-regulated product, then yes, and Part 11 rides along with it. If you are supplying only Indian and other non-US markets, your primary instruments are Revised Schedule M, WHO GDP and the relevant regional GDP, which impose closely related — not identical — expectations. Most manufacturers end up designing to Part 11 anyway, because it is the most prescriptive of the set and satisfying it tends to satisfy the others.

FDA's 2003 guidance on Scope and Application is also worth reading: it narrowed enforcement to a risk-based approach rather than treating every clause as equally critical for every system. That guidance is the reason a risk assessment belongs at the front of your validation, not the back.

§11.10(a) — Validation

"Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records."

The last clause is the one people skip. It is not enough that the system records accurately; it must be possible to detect an invalid or altered record.

Test it: ask your vendor how you would discover that a stored reading had been tampered with. If the answer is "you would not, because nobody can edit it", press further — nobody should be able to, but you also need a way to demonstrate integrity positively. Checksum or hash chaining over the record set is the usual mechanism, because recomputing the chain either verifies or it does not.

§11.10(b) — Accurate and complete copies

"The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying."

Both forms. A PDF alone is not sufficient; neither is a proprietary database export nobody else can open.

Test it: during evaluation, export a month of data and hand it to someone outside the project. Can they read it on a laptop with no special software? Is the electronic form a documented, open format? A CSV of readings plus a PDF report is the combination that satisfies this cleanly.

§11.10(c) — Protection of records

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

Retention period, not backup schedule. If your predicate rule says five years and your monitoring platform's data retention default is twelve months, you have a finding regardless of how good the rest of the system is.

Test it: confirm the contracted retention period in writing, confirm what happens at end of contract, and confirm you can retrieve a record from the oldest retained period now, not in theory.

§11.10(d) — Limiting access

"Limiting system access to authorized individuals."

This is where the most common and most avoidable failures live: shared logins, a generic "QA" account, an installer account that nobody disabled after commissioning.

Test it: list every account on the system. Every one should map to a named human, with a documented role. Administrative access should require multi-factor authentication and should belong to someone who is not also the person producing and approving the records.

§11.10(e) — Audit trails

"Use of 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… Audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records."

Three words carry the weight: secure, computer-generated and independently. A log the application writes and a user can edit is not an audit trail. A log that only records logins is not an audit trail either — it has to cover actions on records.

And the retention requirement is explicit: the trail lives at least as long as the records.

Test it: make a change in a test tenant — acknowledge an excursion, edit a set point, add an annotation — then look at the trail. Does it show who, when, what the old value was, what the new value is, and why? Can you turn it off? (You should not be able to.) Then ask the harder question: who reviews it, how often, and where is that written down? An audit trail nobody reads is treated in practice as no audit trail at all.

§11.10(f) and (g) — Operational and authority checks

Sequencing of steps and events, and checks that only authorised individuals can use the system, sign a record, or alter a record or operation.

For monitoring, this shows up as workflow enforcement: an excursion cannot be closed before it has been assessed; a report cannot be approved by the person who generated it if your procedure requires segregation.

Test it: try to do things out of order in a test environment. A compliant system stops you; a permissive one lets you and relies on your SOP to have prevented it.

§11.10(h) — Device checks

"Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction."

For a sensor network this is the strongest clause and the most frequently ignored. How does the platform know that a reading claiming to be from logger 47 actually came from logger 47?

Test it: ask what identity each device holds and how it authenticates. Per-device credentials on TLS with an X.509 identity is a real answer. A shared API key across a fleet is not — it means any one compromised device can impersonate any other.

§11.10(i), (j), (k) — People and documentation

Training records for everyone using the system, a written policy holding individuals accountable for actions taken under their electronic signature, and controls over systems documentation including revision history.

These are yours, not the vendor's. They are also cheap to fix and highly visible, which makes them a poor place to have gaps.

§11.30 — Open systems

If your records travel over a network you do not control — which for any cloud monitoring platform they do — additional measures apply, including encryption and appropriate use of digital signature standards.

Test it: confirm encryption in transit and at rest, and confirm that documents intended to be trustworthy outside the platform carry a real cryptographic signature rather than an image of one.

§11.50 and §11.70 — Signature manifestations and record linking

A signed electronic record must clearly show the printed name of the signer, the date and time of signing, and the meaning of the signature — approved, reviewed, responsibility. And the signature must be linked to its record such that it cannot be excised, copied or transferred to falsify another record.

Test it: sign something, then look at the rendered record and the exported PDF. All three elements present? Now ask how the link is enforced — cryptographic binding to the record content is the defensible answer.

§11.100, §11.200, §11.300 — Electronic signatures

• Each signature is unique to one individual and never reused or reassigned
• Identity is verified before a signature is issued
• Non-biometric signatures use at least two distinct identification components; the first signing in a continuous session uses all components, and subsequent signings use at least one component executable only by the signer
• ID codes and passwords are controlled, periodically checked and revised, and loss-management procedures exist

Test it: password plus a time-based one-time code satisfies the two-component requirement. A password alone does not, no matter how strong.

The vendor questions worth asking

Cut through the datasheets with these five:

1. Show me an audit trail export for a record you changed. Not a screenshot — an export.
2. How would I detect that a stored reading had been altered? Listen for a mechanism, not an assurance.
3. What identity does each logger hold, and how does the platform authenticate it?
4. What is the contracted data retention period, and what happens to my records at end of contract?
5. What validation documentation ships with the product, and what remains mine to produce? Any vendor claiming their package alone makes you compliant is telling you something untrue.

How we approach it

Abhilekh is built against these clauses as engineering requirements rather than as a compliance appendix: every reading and user action enters a SHA-256 checksum chain so integrity is recomputable rather than asserted; each logger connects with per-device credentials over TLS 1.2 or later (X.509 device certificates and mutual TLS are on the roadmap); e-signatures capture identity, timestamp and meaning of signature under password plus TOTP; PostgreSQL row-level security isolates each tenant; and offline loggers produce an ECDSA P-256-signed PDF report that a recipient can verify without an account on our platform.

What remains yours is the conclusion. In regulated use the operating company owns the validation of its computerised systems — our job is to make that conclusion defensible with shipped protocols, testable controls and documented behaviour. That is exactly the division of labour Part 11 assumes.

---

Practical engineering guidance, not regulatory advice. Confirm applicability to your operation with your regulatory affairs function.

See how the controls are structured on the compliance mapping and validation support pages, or read the companion piece on Revised Schedule M and computerised systems.