21 CFR Part 11 for LIMS and lab software: a practical compliance checklist
What 21 CFR Part 11 really asks of LIMS and lab software — audit trails, e-signatures, access control and validation — as a clause-by-clause checklist.
- Part 11 applies when an electronic record is required by an FDA predicate rule or submitted to the FDA — not to every file in the lab.
- No software is “Part 11 certified”. Compliance comes from technical controls, written procedures and validation, together.
- Audit trails and e-signatures are where most lab systems fall short: missing old values, no reason for change, shared logins.
- Build the controls into the data model from day one; retrofitting an audit trail is far more expensive than designing one.
If your lab produces results that end up in an FDA submission, a batch release or an inspection, the software that holds those results has to meet 21 CFR Part 11. It is one of the most quoted regulations in pharma and one of the most misunderstood: vendors call their products “Part 11 compliant”, auditors ask for things the brochure never mentioned, and lab teams end up with workarounds on paper.
This guide is written for QA heads, lab managers and IT teams who are buying, building or fixing a LIMS or any other lab system. It explains what Part 11 covers, then turns the regulation into a checklist of controls you can check your software against.
What Part 11 actually covers
Part 11 is the US FDA regulation that sets the conditions under which electronic records and electronic signatures are treated as trustworthy, reliable and equivalent to paper records and handwritten signatures. It took effect in 1997.
The key idea is the predicate rule. Part 11 does not create new record-keeping duties; it applies to records that other FDA regulations already require you to keep — for example the GMP rules in 21 CFR 211 or the GLP rules in 21 CFR 58 — and to records you submit to the FDA. If a regulation says “keep a record of this test” and you keep it electronically, Part 11 applies to that record.
In 2003 the FDA published guidance, Part 11, Electronic Records; Electronic Signatures — Scope and Application, which narrowed how it interprets the rule and said it would take a risk-based approach to some requirements, such as validation and audit trails. That guidance did not make those controls optional; it made clear that the predicate rules still demand trustworthy records and that the depth of control should match the risk to product quality and patient safety.
Does Part 11 apply to your lab?
Part 11 is likely to apply if any of these are true:
- You manufacture or test drugs, APIs or medical devices for the US market.
- You are a CRO, CDMO or contract testing lab whose results support a US client’s filings.
- Your electronic records are used for batch release, stability studies or regulatory submissions.
- Your clients audit you against Part 11 or Annex 11 as part of supplier qualification.
Many Indian pharma QC labs, CROs and API makers fall into at least one of these groups. Diagnostic labs that serve only local patients are usually assessed against ISO 15189 and NABL requirements instead — but the data-integrity expectations are close enough that the same software controls pay off.
The checklist: controls your software must have
Section 11.10 lists the controls for closed systems — systems where access is controlled by the people responsible for the records, which describes most LIMS installations. Here is each requirement and what it means in software terms.
| Requirement | Clause | What it means in the software |
|---|---|---|
| Validation | 11.10(a) | Documented evidence the system does what it should, accurately and consistently, and can detect invalid or altered records. |
| Accurate, complete copies | 11.10(b) | Records can be exported in human-readable and electronic form, with their metadata and audit trail, for inspectors. |
| Record protection | 11.10(c) | Records are retrievable for the full retention period — backups, restores that are tested, and readable formats. |
| Limited access | 11.10(d) | Unique user accounts, role-based permissions, no shared logins, disabled accounts for leavers. |
| Audit trails | 11.10(e) | Secure, computer-generated, time-stamped trail of every create, change and delete — who, what, when, old and new value. |
| Operational checks | 11.10(f) | The system enforces the right order of steps — e.g. a result can’t be approved before it is reviewed. |
| Authority checks | 11.10(g) | Only authorised roles can sign, approve, change specifications or alter records. |
| Device checks | 11.10(h) | The system confirms data comes from a valid source, such as a qualified instrument or terminal. |
| Training | 11.10(i) | People who build, run and use the system are trained, and that training is recorded. |
| Accountability policy | 11.10(j) | Written policy that users are responsible for actions under their e-signature. |
| Documentation control | 11.10(k) | System documentation is controlled, versioned and changes are tracked. |
Items (a) to (h) are mostly technical — they live in your software. Items (i) to (k) are procedural — they live in your SOPs. An inspector will look at both.
Audit trails: where most systems fall short
Part 11 asks for audit trails that record the date and time of operator entries and actions that create, modify or delete electronic records, and says changes must not obscure previously recorded information. The trail must be kept at least as long as the record itself and be available for FDA review and copying.
In practice, these are the gaps we find most often when we review lab software:
- Only the new value is stored. The trail says “result updated” but not what it was before.
- No reason for change. Data-integrity guidance expects a reason for changes to GxP data; the system should ask for one.
- The trail can be switched off or edited by an administrator. It should be append-only, with no user able to alter it.
- Time comes from the user’s PC. Time stamps should come from a synchronised server clock, with the time zone recorded.
- Nobody reviews it. A trail that is never read does not protect data. Reviewing relevant audit-trail entries should be part of result review.
- Deleted runs disappear. Re-running a test and discarding the first result without a trace is exactly what inspectors look for.
The fix is architectural. We design audit trails at the database layer as an append-only log, with each entry capturing the user, server time, record, field, old value, new value and reason. Making it tamper-evident — for example by chaining a hash of each entry into the next — lets you prove the log has not been edited.
Electronic signatures, done right
Subpart C of Part 11 covers electronic signatures. For a LIMS, the requirements that shape the screens and the data model are:
- Signature manifestation (11.50). A signed 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. This must appear wherever the record is displayed or printed.
- Signature/record linking (11.70). Signatures must be linked to their records so they cannot be removed, copied or transferred to falsify another record.
- Uniqueness (11.100). Each e-signature belongs to one person and is never reused or reassigned. Before using e-signatures, the organisation must also certify to the FDA that they are intended to be the legally binding equivalent of handwritten signatures.
- Two components (11.200). Signatures not based on biometrics need at least two distinct components, such as a user ID and a password. In one continuous session, the first signing uses all components; later signings need at least one component that only the signer can use.
- Password controls (11.300). Unique ID and password combinations, periodic checks, procedures for lost credentials, and detection and reporting of attempts at unauthorised use.
A good signing flow re-asks for the password at the moment of signing, makes the user choose the meaning of the signature, and stores the signature as its own record pointing at a specific version of the data — so if the data changes later, the signature visibly no longer applies.
Part 11 is not a certificate you can buy
There is no official “Part 11 certification” for software. A vendor can build the technical controls, but compliance belongs to the regulated company and depends on three things working together:
- Technical controls in the software — audit trails, access control, e-signatures.
- Procedural controls — SOPs for access, backup, periodic review, training and change control.
- Validation — documented evidence that the system, as configured in your lab, is fit for its intended use. Our guide to GAMP 5 software validation walks through what that evidence looks like.
When you evaluate a system, ask the vendor for a Part 11 assessment that maps each clause to a feature, and for the validation documents they can supply. If the answer is only a logo on a brochure, plan for extra work.
A quick self-check for your current system
Answer these honestly. Every “no” is a finding waiting to happen:
- Does every person have their own login, including at shared instrument PCs?
- Can you show who changed a result, when, from what value to what value, and why?
- Is it impossible for any user — including admins — to edit or disable the audit trail?
- Do signed records show the signer’s name, date, time and meaning of the signature?
- Are calculations done inside the validated system rather than in uncontrolled spreadsheets?
- Have you restored a backup in the last year and checked the data came back intact?
- Is there a documented, current validation package for the system as it is configured today?
If you are building a new lab platform, or your current one fails several of these, we can help. We build LIMS and drug-safety systems with these controls in the data model from day one, and deliver the validation pack alongside the code. Talk to an engineer about your system.