21 CFR Part 11 Compliance Checklist: A Clause-by-Clause Self-Assessment

This is a practical self-assessment tool for a laboratory or clinical-data system that is already operating under 21 CFR Part 11 — not an introduction to what Part 11 is. If you need the underlying definitions and regulatory background first, start with 21 CFR Part 11: Electronic Records & Signatures. This page assumes you already know a predicate rule (GLP, GMP, or GCP) applies to your records and walks through each operative clause of the regulation as a checklist item: what it requires, and the objective evidence an FDA investigator or internal auditor would actually ask to see against it.

Work through this against one system at a time — an ELN, a LIMS, an EDC/CDMS, a chromatography data system, a document management system — rather than trying to self-assess an entire lab’s Part 11 posture in one pass. Each system has its own validation record, its own audit trail configuration, and its own access-control setup, so each gets its own checklist run.

Before you start: confirm the scope actually applies

FDA’s 2003 guidance, Part 11, Electronic Records; Electronic Signatures — Scope and Application, narrowed the rule’s practical enforcement: it applies where (1) a predicate rule requires the record to be created, modified, maintained, archived, retrieved, or transmitted, and (2) you are keeping that record electronically in place of paper, or you have chosen to rely on the electronic version to perform a regulated activity. FDA stated in the guidance that it would exercise enforcement discretion on the validation, audit-trail, record-retention, and record-copying requirements of §11.10 for records falling outside that narrowed scope, though the predicate rule itself (GLP, GMP, or GCP) still applies regardless of Part 11.

Before running the checklist, write down, in one sentence per record type, which predicate rule requires it and why you’re keeping it electronically. If you can’t answer that for a given record type, that’s the actual first finding — not a §11.10 item.

Subpart B — Electronic records: §11.10 controls for closed systems

§11.10 sets eleven lettered requirements for closed systems (systems where access is controlled by the people responsible for the content — the normal case for an internal LIMS/ELN/EDC). Go through each as a pass/fail item and record the evidence, not just a checkbox.

11.10(a) — System validation

• Requires: validation of systems to ensure accuracy, reliability, and consistent intended performance, and the ability to discern invalid or altered records.
• Evidence to have ready: a current validation summary report or validation master plan entry for this specific system, referencing the URS/functional spec, IQ/OQ/PQ (or equivalent) protocols and results, and a defined revalidation trigger (major version upgrade, configuration change, migration). See Computer System Validation (CSV): GAMP 5, IQ/OQ/PQ, and 21 CFR Part 11 and Validation Master Plan (VMP) for a Regulated Laboratory if this item fails — it’s the single most common gap and the one worth fixing before the rest.

11.10(b) — Accurate and complete copies

• Requires: the ability to generate accurate and complete copies of records in both human-readable and electronic form suitable for FDA inspection, review, and copying.
• Evidence to have ready: a documented export/reporting procedure, and a recent sample export that an auditor can compare line-for-line against the live system record.

11.10(c) — Record protection and retrievability

• Requires: protection of records to enable their accurate and ready retrieval throughout the required retention period.
• Evidence to have ready: the defined retention period per predicate-rule record type, a backup/archival procedure, and proof of at least one successful restore or archive-retrieval test within the current review cycle.

11.10(d) — Access limitation

• Requires: system access limited to authorized individuals.
• Evidence to have ready: a current user-access list reconciled against active personnel, a documented account provisioning/deprovisioning procedure, and proof that a departed employee’s access was revoked within your stated SLA. See Laboratory Security: A Buyer’s and Compliance Guide to Access Control and Systems for the physical/systems-access pairing.

11.10(e) — Audit trails

• Requires: secure, computer-generated, time-stamped audit trails that independently record the date, time, and content of operator entries and actions that create, modify, or delete an electronic record, without obscuring previously recorded information; audit trail records must be retained for at least as long as the underlying record and be available for review and copying.
• Evidence to have ready: an audit-trail review SOP stating who reviews it, how often, and what triggers escalation; a sample completed review with a reviewer signature/date; and confirmation the audit trail itself cannot be disabled or edited by a standard user account (test this against a non-privileged account, don’t just read the config).

11.10(f) — Operational system checks

• Requires: use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.
• Evidence to have ready: for workflow-driven systems (e.g., an EDC enforcing visit order, an ELN enforcing sign-off before edit-lock), a walkthrough or test script showing an out-of-sequence action is actually blocked or flagged, not just documented as a rule.

11.10(g) — Authority checks

• Requires: authority checks to ensure only authorized individuals can use the system, electronically sign a record, access the operation or device, alter a record, or perform the operation at hand.
• Evidence to have ready: role/permission matrix mapped to actual job functions, and confirmation that role assignments are periodically reviewed (quarterly or annually, whichever your SOP states) rather than set once at go-live and left static.

11.10(h) — Device checks

• Requires: device checks, where appropriate, to determine the validity of the source of data input or operational instruction.
• Evidence to have ready: if instruments feed data directly into the system, documentation of how the system verifies the instrument/device identity (e.g., authenticated interface, IP allowlist, instrument ID check) — mark this item not-applicable, explicitly, if no instrument integration exists, rather than leaving it blank.

11.10(i) — Personnel qualifications

• Requires: that persons who develop, maintain, or use the system have the education, training, and experience to perform their assigned tasks.
• Evidence to have ready: role-based training records tied to system version — retraining on record after a significant system update, not just an onboarding record from three versions ago.

11.10(j) — Accountability policies

• Requires: a written policy holding individuals accountable for actions taken under their own electronic signatures, to deter record and signature falsification.
• Evidence to have ready: a signed acknowledgment on file for each system user, referencing your electronic-signature accountability policy specifically (a general code-of-conduct acknowledgment doesn’t satisfy this).

11.10(k) — Documentation controls

• Requires: adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance, and revision/change control procedures to maintain an audit trail documenting time-sequenced development and modification of systems documentation.
• Evidence to have ready: a document control log for SOPs/specifications tied to this system, and a change-control record for the system itself (config changes, integrations, upgrades) with approval sign-off before implementation, not after.

11.30 — Additional controls for open systems

If any part of this system is an open system — access is not fully controlled by the people responsible for the record’s content, e.g. a cloud platform, an externally hosted portal, or a system with third-party read/write access — §11.30 requires the §11.10 controls above plus additional measures “as appropriate,” which the rule names as document encryption and appropriate digital-signature standards, to protect authenticity, integrity, and confidentiality from creation through receipt.

• Evidence to have ready: if open-system, documentation of the specific additional control chosen (encryption in transit/at rest, digital signature standard) and the risk rationale for why it’s sufficient; if the system is genuinely closed, a one-line justification on file is enough — don’t skip the determination entirely.

Subpart C — Electronic signatures

11.50 — Signature manifestations

• Requires: every signed electronic record must include, in both electronic and any human-readable printed form, the signer’s printed name, the date and time the signature was executed, and the meaning associated with the signature (e.g., review, approval, responsibility, authorship).
• Evidence to have ready: a signed record and its printed/exported form side by side, confirming all three elements render in both.

11.70 — Signature/record linking

• Requires: electronic signatures and handwritten signatures executed to electronic records must be linked to their respective records so the signature cannot be excised, copied, or otherwise transferred to falsify another record by ordinary means.
• Evidence to have ready: a technical description (from your validation package) of how the system enforces this binding — signature stored as a discrete database field tied to a record ID is not, by itself, sufficient evidence; you need the control that prevents copying the signature value onto a different record.

11.100 — General requirements

• Requires: each electronic signature must be unique to one individual and never reused or reassigned; identity must be verified before an individual’s electronic signature is established; and before or at the time of first use, the individual (and the organization) must certify to FDA in writing that electronic signatures are intended as the legally binding equivalent of handwritten signatures.
• Evidence to have ready: the identity-verification record for each signer at account creation, and a copy of the organization’s electronic-signature certification letter on file (this is a one-time submission to FDA, not a per-user document — confirm it exists and covers this system).

11.200 — Electronic signature components and controls

• Requires: a non-biometric electronic signature must use at least two distinct identification components (typically an ID code plus a password) — both used together for the first signing in a session, with only the password required for subsequent signings within that same continuous session; both components required together for any signing not part of a continuous session; and administered so no individual can readily attempt to falsify a signature without collaboration of at least two people.
• Evidence to have ready: a session-timeout configuration record showing what counts as “continuous” in your system, and confirmation the two-person control exists for signature administration (e.g., password reset requires a second authorized party, not self-service alone).

11.300 — Controls for identification codes and passwords

• Requires: uniqueness of each ID-code/password combination; periodic checking, recall, or revision of codes and passwords (including password aging); loss-management procedures to deauthorize compromised credentials and issue replacements under suitable controls; transaction safeguards to detect and report unauthorized attempts; and initial and periodic testing of any devices that bear or generate identification codes/password information.
• Evidence to have ready: your password policy (aging interval, complexity), a credential-deauthorization log showing time-to-revoke after a reported loss, and — if hardware tokens are in use — a device-testing record.

Assembling the self-assessment record

An inspector doesn’t want a verbal walkthrough — they want the documents. For each item above, the minimum defensible record is: the clause, a pass/fail/not-applicable determination, the specific evidence reviewed (file name, log excerpt, or screenshot reference), the reviewer’s name and date, and — for any fail — a remediation owner and target date. Store this alongside your validation master plan entry for the system, not as a standalone spreadsheet nobody else knows exists.

If this system also falls under EU GMP (Annex 11) because it’s used for product released into the EU market, run this checklist first — Annex 11 and Part 11 overlap heavily but aren’t identical, and Annex 11 goes further on supplier assessment and a mandatory system inventory. See EU Annex 11 vs. 21 CFR Part 11 for exactly where the two diverge, so you don’t treat a Part 11 pass as an Annex 11 pass by assumption.

For lab notebook systems specifically, Electronic Lab Notebook Validation Under 21 CFR Part 11 and GxP walks the same clauses in ELN-specific terms. For the broader GMP context these controls usually sit inside, see Good Manufacturing Practice (GMP): A Guide for Research Institutions.

Frequently Asked Questions

Does every electronic record need to comply with all of 11.10?

Only records where a predicate rule (GLP, GMP, or GCP) requires the record and you’re relying on the electronic version. FDA’s 2003 scope-and-application guidance narrows enforcement to that intersection — records outside it aren’t automatically exempt from the predicate rule itself, but §11.10’s validation/audit-trail/copying requirements aren’t the enforcement focus for them.

Do we need this checklist for a system that’s been running unchanged for years?

Yes — validation status doesn’t expire on its own, but it does need periodic confirmation (per your validation master plan’s review cycle) and revalidation on any material change: version upgrade, configuration change, new integration, or migration. A system that passed IQ/OQ/PQ five years ago and has had three unreviewed patches since is not current evidence of §11.10(a) compliance.

What’s the difference between this and a computer system validation (CSV) protocol?

CSV (IQ/OQ/PQ under a GAMP 5-style approach) is how you build and document the evidence that §11.10(a) requires. This checklist is broader — it covers all eleven §11.10 items plus the electronic-signature subpart, not validation alone. See Computer System Validation (CSV) for the validation-specific protocol structure.

Is a scanned handwritten signature attached to a PDF an electronic signature under Part 11?

No, not on its own. Subpart C’s requirements — unique identity binding, the two-component signing control under §11.200, the record-linking requirement under §11.70 — apply to signatures the system itself executes and controls. An image of a wet-ink signature pasted into a document doesn’t carry those controls and isn’t treated as a Part 11 electronic signature.

Do we need to re-run this checklist for every minor bug-fix release?

Your change-control procedure (§11.10(k)) should define what counts as material enough to trigger re-review — typically anything touching data integrity, access control, audit-trail behavior, or signature workflow. A cosmetic UI fix with no functional change to those areas generally doesn’t require a full re-run, but the determination itself should be documented, not assumed.

This checklist supports an internal self-assessment; it is not legal or regulatory advice, and passing it does not substitute for a qualified quality/regulatory affairs review or FDA inspection outcome.