21 CFR Part 11 and Clinical Genomics Software: What Compliance Actually Requires

A CLIA-certified lab running laboratory-developed tests does not automatically fall under the FDA's electronic records regulation. A genomics platform submits data to the FDA as part of a companion diagnostic or a drug trial. Knowing which one applies to a given system, before architecture decisions get made, is the difference between building the right controls once and retrofitting them later under deadline pressure.

The confusion got worse, not better, after 2024. FDA finalized a rule that would have regulated most laboratory-developed tests as medical devices, then a federal court vacated that rule in March 2025, and FDA itself formally rescinded it in September 2025 (American Clinical Laboratory Association, March 31, 2025). LDTs are back under CLIA oversight by CMS, not FDA, which changes what "FDA compliance" actually means for most genetic testing labs in 2026.

Getting the scope wrong runs in both directions, and both are expensive. A team that assumes Part 11 applies platform-wide builds signature manifestation, cryptographic record linking, and validation documentation into workflows that will never touch an FDA submission, adding months of engineering effort with no regulatory requirement behind it. A team that assumes Part 11 doesn't apply anywhere, because the lab operates under CLIA, discovers the gap only when a pharma partner's due diligence team asks for evidence that the companion diagnostic pipeline was validated to Part 11 standards, and retrofitting audit trails and signature controls into a system already in production costs far more than designing for them from the start. For teams building clinical genomics software, that distinction has to be made explicit before a single access control or audit log gets designed.

Key Takeaways

• LDTs are regulated under CLIA by CMS, not FDA, following the March 2025 vacatur of FDA's 2024 LDT final rule and FDA's subsequent formal rescission of that rule in September 2025
• 21 CFR Part 11 applies to electronic records required under FDA "predicate rules," meaning other FDA regulations like cGMP, GLP, and GCP that already require recordkeeping; it does not independently create new recordkeeping obligations for a CLIA-regulated lab (FDA, Part 11 Scope and Application Guidance)
• A genomics platform falls under Part 11 when its electronic records support an FDA submission or FDA-regulated activity: an IVD or companion diagnostic pursuing 510(k), De Novo, or PMA clearance, or clinical trial data generated under Good Clinical Practice for an IND or BLA
• The core technical controls the FDA continues to enforce are validation (§11.10(a)), audit trails (§11.10(e)), and electronic signature manifestation and linking (§§11.50, 11.70, 11.100, 11.200) (eCFR, 21 CFR Part 11)

Does 21 CFR Part 11 Actually Apply to a CLIA-Certified Genetic Testing Lab?

Not by default. A laboratory-developed test performed and reported entirely within a CLIA-certified, CAP-accredited lab is regulated by CMS under CLIA, a separate statutory framework from the Federal Food, Drug, and Cosmetic Act under which FDA's Part 11 regulation sits. The March 2025 court ruling that vacated the FDA's LDT final rule was explicit on this point: LDTs are professional laboratory services, not manufactured devices, and Congress addressed their oversight through CLIA specifically, not the FDCA (ACLA, 2025).

That means a genomics lab operating purely as an LDT provider, ordering, sequencing, interpreting, and reporting within its own CLIA certification, doesn't have a Part 11 obligation created by that activity alone. The compliance surface for that lab is CLIA, CAP, and HIPAA. Part 11 enters the picture only when the lab's software also touches FDA-regulated territory. This is the scoping question every team building clinical genomics software needs to answer before writing a single line of validation documentation.

Consider a hereditary cancer panel offered purely as an LDT: a patient sample comes in, the lab sequences it, a molecular pathologist signs the report, and the result goes back to the ordering physician entirely within the lab's own CLIA-certified operation. Nothing in that workflow is submitted to the FDA, and no predicate rule requires the FDA to trust the electronic form of that report. The lab still needs a sound audit trail and signature process because CAP inspectors and CLIA regulations expect one, but that requirement comes from CLIA and CAP, not from 21 CFR Part 11.

When Does a Genomics Platform Actually Fall Under 21 CFR Part 11?

Three scenarios bring Part 11 into scope, and they're worth naming precisely because vague answers are how teams either over-engineer for a regulation that doesn't apply or miss one that does.

A lab pursuing FDA clearance for a test, rather than offering it as an LDT under CLIA, through 510(k), De Novo, or PMA, becomes subject to the Quality System Regulation (21 CFR Part 820), and electronic records supporting that submission fall under Part 11. A genomics platform generating data for a companion diagnostic tied to a drug or biologic approval is in the same position, since the diagnostic development pathway runs through the FDA regardless of where the underlying test is performed. A platform capturing clinical trial data under Good Clinical Practice for an IND or BLA submission is also in scope because GCP is itself a predicate rule requiring records, and Part 11 governs the electronic form of those records.

None of these scenarios are about the genomics platform's general architecture. They're about whether a specific data flow feeds an FDA submission. A single platform can have some workflows in scope and others entirely outside it. A precision medicine company might run its core LDT reporting pipeline entirely under CLIA and CAP, while a separate companion diagnostic development track for a pharma partner's drug trial sits under Part 11 because that data eventually supports an IND or BLA filing. Treating the whole platform as one compliance zone, in either direction, misreads the actual regulatory boundary.

It's also worth being precise about what triggers Part 11 within FDA's own framework: predicate rules. A predicate rule is any other FDA regulation, such as the Quality System Regulation (21 CFR Part 820) for device manufacturers, Good Laboratory Practice (21 CFR Part 58) for nonclinical studies, or Good Clinical Practice requirements for clinical trials, that already requires records to be kept or submitted. Part 11 doesn't create new recordkeeping obligations on its own. It sets the criteria for when the electronic version of a record required by one of those predicate rules is considered trustworthy enough to replace paper.

A fourth scenario worth naming separately is the transition from research use to FDA-regulated use. A biomarker discovery platform built for internal research, generating exploratory data that never leaves the lab's own analysis, sits outside Part 11 because no predicate rule requires those records. If that same biomarker later becomes the basis for a companion diagnostic submitted for FDA clearance, or if the underlying nonclinical study data gets submitted to support an IND, the records tied to that specific transition point move into scope under Good Laboratory Practice or Good Clinical Practice, and the platform needs to be able to produce Part 11-compliant records from that point forward. Teams that don't plan for this transition often find that data generated during the research phase can't retroactively meet validation and audit trail requirements, forcing a costly re-generation of evidence.

What Does 21 CFR Part 11 Actually Require, Technically?

Audit trail requirements under §11.10(e) are the most frequently cited finding in FDA inspection observations, which makes them the highest-priority control to get right architecturally rather than retrofit later.

FDA's own 2003 guidance narrowed how strictly it enforces Part 11, after industry pushback that a rigid interpretation was raising costs without a clear safety benefit. The agency now takes a risk-based approach: it exercises enforcement discretion on some validation and audit trail specifics for lower-risk systems, while continuing to enforce access controls, signature manifestation, and record-signature linking consistently (FDA, Part 11 Scope and Application Guidance).

In practice, that means the level of validation rigor a genomics platform needs should track the actual risk the workflow carries; a companion diagnostic feeding a drug approval decision warrants more validation depth than an internal QC dashboard, not a uniform maximum-compliance posture applied to every system component regardless of what it does.

How Is Building for CLIA and CAP Different From Building for Part 11?

CLIA and CAP validation focus on the analytical and clinical validity of the test itself: does the assay perform accurately, is the lab's quality system sound, is there a documented chain of custody from sample to report. Part 11 focuses narrowly on the electronic record and signature layer: can the system prove a record wasn't altered, and can it prove who signed it and when?

A lab operating purely under CLIA needs strong audit trails and access controls because CAP inspectors expect them, not because §11.10(e) applies. The technical patterns look similar on the surface, but the compliance basis and the evidence an inspector versus an FDA auditor will ask for are different. A platform architected only for CAP inspection readiness will usually need additional signature manifestation and record-linking controls if a workflow later needs to support an FDA submission. For clinical genomics software specifically, this distinction determines which controls get built once versus retrofitted later.

The evidence request itself illustrates the gap well. A CAP inspector reviewing a lab's variant classification workflow wants to see that the analyst who signed off is qualified, that the classification followed documented criteria, and that the report matches the underlying data. An FDA reviewer examining the same electronic record under Part 11 wants to see that the signature is cryptographically or procedurally bound to that exact record version, that the system would detect if the record were altered after signing, and that the audit trail shows the full history of who touched the record and when. Both are legitimate compliance questions. They are not the same question, and a system built to answer one well doesn't automatically answer the other.

How Should a Genomics Platform Be Architected for Both Without Over-Building?

The practical approach is to identify which specific data flows touch FDA-regulated activity and scope Part 11 controls to those flows, rather than applying Part 11's full technical requirements platform-wide by default. A lab's routine LDT reporting pipeline doesn't need §11.50 signature manifestation if nothing in that pipeline ever reaches an FDA submission. A companion diagnostic development pipeline feeding a drug trial almost certainly does.

NonStop builds audit trail, validation, and access control architecture into genomics platforms from the start, scoped to what the platform's actual data flows require: CLIA and CAP evidence for LDT-only workflows, and the additional Part 11 signature and validation controls where a workflow supports an FDA submission. Getting that scoping wrong in either direction, under-building for a workflow that does reach FDA, or over-engineering a pure LDT pipeline with unnecessary signature infrastructure, costs real engineering time either way.

NonStop's Varion accelerator builds audit trail, versioned signature, and 21 CFR Part 11-compliant record linking directly into variant interpretation workflows, scoped to the data flows that actually reach FDA submissions. A scoping call is the fastest way to find out whether Varion's audit trail and signature architecture fits an existing companion diagnostic pipeline.

In practice, this usually means designing the data architecture so FDA-in-scope workflows are cleanly separable from CLIA-only workflows rather than intermingled in one undifferentiated pipeline. A companion diagnostic track can share infrastructure with the core LDT platform, the same cloud environment, the same underlying database technology, while still applying a distinct, heavier set of audit trail and signature controls to the records that will actually reach the FDA. That separation also makes future changes easier: if a test that started as an LDT later moves toward an FDA submission pathway, the workflow can be upgraded to Part 11 controls without re-architecting the entire platform around it.

Frequently Asked Questions