21 CFR Part 11 Checklist for LIMS: What Your System Must Do

If your laboratory keeps records that FDA regulations require, and it keeps them in a LIMS, 21 CFR Part 11 applies to that system. The regulation is short, but it is often misread in both directions. Some teams treat every database field as a signed legal record, while others assume a vendor’s “Part 11 compliant” label settles the matter. Neither is right. Compliance is a property of a system as it is configured, validated and operated by a regulated company, not a feature that ships in the box. This checklist explains what Part 11 covers, walks through each requirement in Subparts B and C, and maps each one to something you can verify in a LIMS.

Key takeaways

• Predicate rules decide whether Part 11 applies. Part 11 governs records and signatures that other FDA regulations (such as 21 CFR Parts 58, 211 and 820) require, when you keep them electronically.
• No software is compliant on its own. The vendor supplies technical controls; you supply validation for intended use, procedures, training and governance.
• Enforcement discretion is not an exemption. FDA’s 2003 guidance relaxed enforcement of some provisions, but predicate rules and inspection expectations still apply.
• The highest-risk areas in a LIMS are usually access control, audit trail completeness and the binding between a signature and the exact record version signed.
• EU GMP Annex 11 is the European counterpart, with more emphasis on risk management and the system lifecycle. A global lab should design to both.

What Part 11 covers, and what it does not

Part 11 took effect in August 1997. It sets the criteria under which FDA considers electronic records and electronic signatures to be trustworthy, reliable and generally equivalent to paper records and handwritten signatures. It has three subparts: Subpart A (scope, implementation and definitions), Subpart B (electronic records) and Subpart C (electronic signatures).

Electronic records versus electronic signatures

An electronic record is any information in digital form that a computer system creates, modifies, maintains, archives, retrieves or distributes. In a LIMS that includes sample data, results, calculations, specifications, instrument data, investigations, certificates of analysis and the audit trail itself.

An electronic signature is a set of symbols a person executes, adopts or authorizes as the legally binding equivalent of a handwritten signature. Logging in is not signing. A login authenticates a session; a signature is a deliberate act, with a stated meaning, applied to a specific record. Subpart C applies where a predicate rule requires a signature or initials, such as the tester and reviewer signatures on laboratory records under 21 CFR 211.194, or where your procedures designate an action as a signature.

Closed versus open systems

In a closed system, access is controlled by the people responsible for the content of the records. In an open system, it is not.

Most on-premises LIMS installations are closed systems. For a cloud or SaaS LIMS, the question is who controls access to your records. If your organization controls user provisioning, roles and authentication, and the provider’s access is restricted by contract and technical controls, many regulated companies classify the system as closed. That is your decision to justify and document. Data flows that leave your control, such as certificates of analysis sent to customers, may call for the open-system controls in §11.30.

Predicate rules decide whether Part 11 applies

Part 11 does not say which records you must keep. Predicate rules do: the GMP regulations in 21 CFR 210 and 211, the GLP regulations in Part 58, the device quality system requirements in Part 820, and others. Under FDA’s current interpretation, Part 11 applies to:

• Records required by predicate rules that are kept electronically instead of on paper
• Records kept electronically in addition to paper, when you rely on the electronic version for regulated activities
• Records submitted to FDA in electronic form
• Electronic signatures intended to be the equivalent of handwritten signatures required by predicate rules

If the paper printout is the official record and you do not rely on the electronic version, Part 11 may not apply, but FDA expects that decision to be documented. Its 2018 data integrity guidance also makes clear that a static printout does not replace a dynamic electronic record such as a chromatogram. For a modern LIMS, assume the electronic record is the record.

FDA’s 2003 scope and application guidance

In August 2003 FDA published Guidance for Industry: Part 11, Electronic Records; Electronic Signatures — Scope and Application. It announced a narrow interpretation of scope and said FDA intended to exercise enforcement discretion, while it re-examined the rule, for:

• Validation (§11.10(a))
• Audit trails (§11.10(e))
• Legacy systems operational before August 1997
• Copies of records (§11.10(b))
• Record retention (§11.10(c))

The discretion covers the corresponding open-system requirements in §11.30, but it does not remove the underlying expectations. The guidance calls for a documented, justified risk assessment to decide how to validate and whether audit trails are needed, and notes that predicate rules, such as 21 CFR 211.68 on checks of computer inputs, outputs and backups, still apply. FDA continued to enforce everything else: access limits, operational, authority and device checks, training, accountability policies, documentation controls and all of Subpart C.

In practice, a QC LIMS has little room to lean on that discretion, because inspectors routinely cite missing or unreviewed audit trails as data integrity failures. Our article on data integrity and ALCOA+ covers that guidance in more detail.

Subpart B checklist: electronic records

§11.10 Controls for closed systems

Section 11.10 requires procedures and controls that protect the authenticity, integrity and, where appropriate, confidentiality of records, and that make it hard for a signer to repudiate a signed record. It lists eleven controls:

• (a) Validation for accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records. For a LIMS, that means your configuration, calculations and interfaces, not only the vendor’s base product.
• (b) Copies of records that are accurate and complete, in human-readable and electronic form, for inspection.
• (c) Protection of records so they can be retrieved accurately and readily throughout the retention period.
• (d) Access limited to authorized individuals.
• (e) Audit trails that are secure, computer-generated and time-stamped, independently recording who created, modified or deleted records and when. Changes must not obscure earlier values, and audit trails are kept as long as the records and available for review.
• (f) Operational checks that enforce permitted sequencing of steps and events.
• (g) Authority checks so only authorized people can use the system, sign, alter records or perform an operation.
• (h) Device checks, where appropriate, to confirm the validity of the source of data input or instructions.
• (i) Training and experience for people who develop, maintain or use the system, including vendor staff.
• (j) Accountability policies that hold individuals responsible for actions taken under their electronic signatures.
• (k) Documentation controls over system operation and maintenance documentation, including change control.

Part 11 itself does not require a reason for each change. The GLP regulations require one for changes to automated data entries (21 CFR 58.130(e)), EU GMP Annex 11 expects one for GMP-relevant data, and most QC labs configure their LIMS to capture it.

§11.30 Controls for open systems

Open systems need the §11.10 controls, as appropriate, plus measures such as document encryption and digital signature standards to protect records from creation to receipt. In a LIMS, check encryption in transit and at rest, and consider signed PDFs or checksums for records sent outside your environment.

§11.50 Signature manifestations

Every signed electronic record must show the signer’s printed name, the date and time of signing, and the meaning of the signature, such as review, approval, responsibility or authorship. These elements are controlled like the record itself and must appear in every human-readable form of the record, on screen and in printouts.

§11.70 Signature/record linking

Electronic signatures, and handwritten signatures applied to electronic records, must be linked to their records so they cannot be removed, copied or transferred to falsify another record by ordinary means. The practical test is whether a signature is bound to a specific version of the record. If the record changes after signing, the signature should be invalidated or the change clearly flagged, and a new signature required.

Subpart C checklist: electronic signatures

§11.100 General requirements

• Each electronic signature is unique to one individual and is never reused or reassigned. Deactivate accounts rather than deleting them, and never recycle user IDs.
• The organization verifies a person’s identity before establishing their electronic signature.
• The organization certifies to FDA in writing that its electronic signatures are intended to be the legally binding equivalent of handwritten signatures. This is often called a non-repudiation letter and usually covers the whole organization; check FDA’s current instructions for submitting it.

§11.200 Electronic signature components and controls

Signatures not based on biometrics must use at least two distinct identification components, such as a user ID and a password.

• When a person signs several times during one continuous period of controlled system access, the first signing uses all components, and later signings use at least one component only that person can execute, typically the password.
• Signings outside one continuous period of access use all components every time.
• Signatures are used only by their genuine owners, and are administered so that misusing someone else’s signature would require two or more people to collaborate.

Biometric signatures must be designed so that only their genuine owners can use them.

Single sign-on deserves attention. A LIMS that relies on an identity provider for login should still require re-authentication at the moment of signing, such as a password or step-up multi-factor prompt. Define what a continuous period of access means in your system, including session timeouts and inactivity locks.

§11.300 Controls for identification codes and passwords

• (a) Each combination of identification code and password is unique.
• (b) Issued codes and passwords are periodically checked, recalled or revised. Current NIST guidance (SP 800-63B) advises against forced periodic password changes without evidence of compromise, so many organizations meet this through periodic account reviews, multi-factor authentication and a documented risk assessment.
• (c) Lost, stolen or compromised tokens and devices are deauthorized and replaced under suitable controls.
• (d) Transaction safeguards prevent unauthorized use of credentials and report attempted misuse urgently to security staff and, as appropriate, management.
• (e) Tokens or cards that bear or generate credentials are tested initially and periodically.

Requirement-to-verification table

Use this table during vendor demonstrations, validation planning and periodic reviews. The right-hand column lists evidence you can see or test, not claims to accept on trust.

Section	Requirement (paraphrased)	What to verify in a LIMS
§11.10(a)	System validation	Vendor validation package assessed; your configuration, calculations and interfaces tested; process for assessing updates
§11.10(b)	Accurate, complete copies	Export of a record with metadata, audit trail and signatures to PDF and a machine-readable format
§11.10(c)	Record protection	Configurable retention; tested backup and restore; records readable after upgrade or migration; defined exit terms
§11.10(d)	Limited access	Unique named accounts; SSO with MFA; timely deprovisioning; periodic access reviews
§11.10(e)	Audit trails	Always on for GxP data; not editable by anyone, including administrators; captures who, what, when, old and new values and reason; explicit time zone
§11.10(f)	Operational checks	Workflow enforces order, such as no approval before all results are entered and reviewed
§11.10(g)	Authority checks	Action-level role permissions; no self-approval; training status gates for method execution
§11.10(h)	Device checks	Instrument interfaces identify the source; data accepted only from registered, qualified instruments
§11.10(i)	Training	Training records for users and administrators; supplier assessment covers vendor staff
§11.10(j)	Accountability policies	User acknowledgment at account activation; policy referenced in SOPs
§11.10(k)	Documentation controls	Controlled SOPs and configuration specifications; vendor release notes; configuration change history
§11.30	Open system controls	Encryption in transit and at rest; signed PDFs or checksums for external records
§11.50	Signature manifestation	Full name, date, time with time zone and meaning on screen and on every report
§11.70	Signature/record linking	Signature bound to record version; edits invalidate or flag it; signatures cannot be copied via UI, API or import
§11.100	Uniqueness and identity	User IDs never reused; deactivation instead of deletion; identity check at onboarding
§11.200	Signature components	Re-authentication at signing, including under SSO; administrators cannot sign as other users
§11.300	Credential controls	Password and MFA policy; periodic account review; device revocation; lockout and alerts after failed attempts

Who is responsible for what

A vendor can build the technical controls in the table, document how they were tested and operate the platform under a quality system you can audit. A vendor cannot validate the system for your intended use, write your SOPs, train your staff, review your audit trails or send FDA your certification letter. For a SaaS LIMS, add a supplier assessment and a quality agreement covering change notification, data ownership, retention and exit. Our LIMS buyer’s guide covers those questions, and our article on moving from CSV to CSA explains how to right-size validation.

EU GMP Annex 11: the European counterpart

EU GMP Annex 11, Computerised Systems, is part of EudraLex Volume 4 and is mirrored in the PIC/S GMP Guide. The version in force dates from 2011. Its seventeen sections run from risk management and supplier oversight through validation, audit trails, security and electronic signatures to business continuity and archiving.

The technical controls overlap heavily with Part 11, but Annex 11 puts more weight on:

• Risk management across the whole system lifecycle
• Formal agreements with suppliers and service providers, including hosting providers
• Reasons for change when GMP-relevant data is changed or deleted
• Periodic evaluation of the validated state
• Business continuity and incident management

Annex 11 expects electronic signatures to have the same impact as handwritten ones within the company, to be permanently linked to their records, and to include the time and date. A revised draft was published for consultation in 2025, so check its status before finalizing a compliance matrix. A lab serving both markets should map its LIMS controls to both texts in one traceability matrix.

Common gaps found in LIMS assessments

• Administrator accounts used for routine work, or shared accounts on instrument PCs
• Audit trails reviewed only during investigations
• Signatures that stay valid after the record is edited
• Signature meaning missing from PDF reports
• Signing under SSO that relies on the existing session alone
• No process for assessing SaaS releases

How HDLIMS approaches this

HDLIMS treats the controls in this checklist, including always-on audit trails, version-bound electronic signatures with recorded meaning and role-based authority checks, as core platform behavior, and provides validation documentation to support your own assessment. See our compliance overview and security practices, or request a demo to walk through this checklist against the system.