21 CFR Part 11 applies to a bioinformatics workflow only when an electronic record it produces is required by an FDA predicate rule or submitted to FDA, not because the pipeline is labeled "regulated" software. Once that trigger is met, the record must be handled in a way that supports its trustworthiness and reliability under applicable Part 11 controls. Everything else in this guide explains how to get there.
TL;DR:
- Outputs used in IND, NDA, or BLA submissions, patient reported diagnostic results, or clinical trial endpoints may trigger Part 11; exploratory research generally does not.
- Regulated runs need audit trails tied to exact input files, parameter sets, software versions, and reference databases, not timestamps alone.
- Cloud teams may review vendor attestations instead of duplicating infrastructure qualification, but must still validate their own configuration and use of the service.
- BioCompute Objects record parameters, dependencies, and provenance, but cannot replace Part 11 controls; generate them during execution to catch silent version drift.
Table of Contents
- When does a bioinformatics record fall under Part 11?
- Closed versus open systems: mapping §11.10 and §11.30 to pipeline controls
- What a realistic Part 11 validation package looks like
- BioCompute objects add reproducibility context, not a Part 11 substitute
- Where FDA focuses during inspection
- A practical checklist before your next FDA-facing deliverable
- The checklist culture around Part 11 misses the harder problem
- How we support Part 11 readiness for bioinformatics projects
- FAQ
- Sources
When does a bioinformatics record fall under Part 11?
Part 11 covers electronic records created, modified, maintained, archived, retrieved, or transmitted under an FDA recordkeeping requirement, and any electronic record submitted to the agency. FDA's scope and application guidance frames the question correctly: it is not "is this software Part 11 compliant," but "which regulated record is this, and what predicate rule requires it." Whether a variant-calling output is subject to Part 11 depends on its intended use and whether a predicate rule requires it or it is submitted to FDA. An output used in an IND submission may therefore fall within Part 11’s scope.
Three situations commonly trip this wire for bioinformatics teams:
- An NGS or variant-annotation pipeline feeds results into an IND, NDA, or BLA submission package.
- A bioinformatics output functions as or supports an in vitro diagnostic result reported to a patient or physician.
- A computational pipeline generates a digital endpoint used in a clinical trial's primary or secondary analysis.
Exploratory screening, internal target prioritization, and early research computation generally sit outside Part 11 until their outputs feed a regulated decision or filing.
Closed versus open systems: mapping §11.10 and §11.30 to pipeline controls
eCFR §11.10 lays out the controls for closed systems, meaning systems where access is controlled by the people responsible for the content. For a bioinformatics pipeline, each control category maps to a concrete artifact:
- System validation evidence (documented IQ/OQ/PQ) showing the pipeline performs as intended.
- Accurate, complete, and retrievable copies of records, including raw inputs, intermediate files, and final outputs.
- Protection of records throughout their retention period, with defined backup and archival procedures.
- Authorized, role-based access limiting who can modify pipeline parameters, reference databases, or results.
- Secure, computer-generated, time-stamped audit trails that capture record creation, modification, and deletion.
When the workflow runs on shared infrastructure, such as a multi-tenant cloud environment or a collaboration involving an external lab, eCFR §11.30 adds requirements for open systems: document encryption and appropriate digital signature standards to protect authenticity and confidentiality during transmission. Signature/record linking under §11.70 further requires that an electronic signature cannot be excised or copied to falsify a different record, which for a pipeline means the approval event must be bound to the exact input set, parameter file, software version, and reference database used.
Pro Tip: Log pipeline version, input file hashes, parameter sets, and reference database version together as one record; an audit trail that captures timestamps without linking them to exact inputs will not satisfy a reviewer asking "what produced this result."
What a realistic Part 11 validation package looks like
Teams often overbuild or underbuild validation because they treat Part 11 as a checklist rather than a risk-based exercise. A workable package for a regulated bioinformatics pipeline, cloud or on-premises, typically includes:
- A validation plan that states intended use and scope.
- A documented Part 11 applicability assessment tied to the specific predicate rule.
- Infrastructure qualification (IQ) confirming the computing environment, storage, and network match specifications.
- Operational qualification (OQ) confirming pipeline functions, including version control and parameter handling, perform correctly.
- Performance qualification (PQ) confirming the pipeline produces correct results under real business-process conditions.
- Standard operating procedures covering execution, review, and approval of pipeline runs.
- An access-control matrix documenting who can run, modify, or approve pipeline outputs.
- Change-control records and release notes for every pipeline, reference database, or infrastructure update.
The risk-based principle matters here: validation effort should concentrate on the steps that affect a regulated decision, not on every script in a repository. For cloud platforms, teams do not always need to re-qualify infrastructure a vendor already attests to; a documented review of the vendor's shared-responsibility model and relevant attestations can substitute for duplicating that qualification work, as long as the organization still validates its own configuration and use of the service.
BioCompute objects add reproducibility context, not a Part 11 substitute
A BioCompute Object (BCO) is a structured, JSON-based record of a computational pipeline, developed through precisionFDA and FDA/CBER collaborative efforts. A BCO typically captures:
- The exact parameters and command-line arguments used at each pipeline step.
- Software and reference database versions and dependencies.
- Provenance information describing who ran the analysis and when.
- A description of inputs, outputs, and the biological or clinical question addressed.
For high-throughput sequencing and NGS submissions, a well-formed BCO helps an FDA reviewer reconstruct exactly how a result was generated, which supports the kind of reproducibility that coordination efforts between FDA groups have emphasized. A BCO is documentation of the computational workflow itself. It does not create the audit trails, access controls, or signature linking that Part 11 requires; a team can have a perfect BCO and still fail an inspection if the underlying system lacks secure, time-stamped records of who touched what and when.
Where FDA focuses during inspection
FDA has signaled a narrower, risk-focused interpretation of some Part 11 provisions through enforcement discretion, but the underlying predicate rule obligations never go away. FDA's Q&A on electronic systems in clinical investigations recommends a risk-based validation approach and points to specific inspection priorities: can the organization reconstruct how a result was produced, trace every input file and parameter back to its source, show validation evidence for the processing steps that mattered, and produce change-control records for the version actually used. Teams preparing for inspection can capture provenance metadata at the point of execution and ensure their records help answer questions such as who approved a result, what inputs produced it, and what changed since the last approved run.
A practical checklist before your next FDA-facing deliverable
Most teams can get a useful first pass done in a single working session:
- Map which bioinformatics outputs feed a predicate-rule decision or FDA submission.
- Draft a BioCompute Object for each regulated pipeline, covering parameters, versions, and provenance.
- Confirm audit trails capture user identity, timestamps, and linked inputs for every regulated run.
- Build or update an access-control matrix for who can run, modify, or approve results.
- Write or refresh a validation plan scoped to intended use rather than the whole codebase.
Our BioCompute checklist for regulatory bioinformatics submissions and guide to vetting HIPAA-compliant bioinformatics vendors go deeper on the documentation side. For cloud infrastructure specifically, teams building custom audit-capable platforms sometimes work with specialized software partners such as CorLab Tech for the underlying engineering.
The checklist culture around Part 11 misses the harder problem
Most Part 11 advice for bioinformatics reads like a compliance checklist: validate the system, log the access, sign the record, done. That framing undersells the actual difficulty, which is not procedural but architectural. A pipeline that produces different results from the same inputs because a reference database updated silently, or because a container image drifted, may raise concerns during inspection, regardless of how complete its audit trail looks. The audit trail will faithfully record an action; it will not tell anyone the result was wrong.
The overrated piece of conventional advice is treating BioCompute Objects as a compliance artifact to produce once and file away. Their real value is operational: a BCO forces a team to make every dependency explicit at the moment of execution, which is also the moment version drift and silent reference-data changes get caught. Teams that generate a BCO automatically as part of pipeline execution, rather than retroactively for a submission, end up with better Part 11 evidence almost as a side effect.
What should come first is not the documentation template but the question of which outputs actually touch a predicate rule. Teams that scope this correctly can focus validation effort on the steps that affect regulated decisions instead of loosely validating the entire codebase.
— Hooman
How we support Part 11 readiness for bioinformatics projects
We build custom bioinformatics and computational biology work for biotech and pharma teams, and reproducibility is built into how we structure a project rather than added afterward. On engagements involving virtual screening and hit-to-lead optimization, protein engineering and chimeric protein design, enzyme optimization, or peptide design, we document project details as part of the deliverable, which supports the kind of validation evidence and BioCompute-style documentation a regulated program needs downstream.
If your team needs a bioinformatics partner that treats regulatory traceability as part of the science rather than an afterthought, reach out through our site to discuss your project.
FAQ
What does it mean for a system to be 21 CFR Part 11 compliant?
A system is Part 11 compliant when the electronic records and signatures it produces meet the controls in 21 CFR Part 11, including validation, audit trails, access controls, and signature-to-record linking, for any record an FDA predicate rule requires. Compliance is evaluated at the record and process level, not as a one-time software certification.
What are the reporting requirements under 21 CFR Part 803 for device problems?
A predicate rule separate from Part 11 requires manufacturers and certain entities to report device-related deaths, serious injuries, and malfunctions to FDA. When those reports are submitted electronically, the records themselves must also meet Part 11's authenticity and integrity controls.
What do FDA's regulations say about electronic records and signatures?
21 CFR Part 11 sets the criteria under which FDA considers electronic records and electronic signatures trustworthy, reliable, and equivalent to paper records and handwritten signatures. It requires controls such as validation, audit trails, and record protection for closed systems, with added encryption and signature standards for open systems.
How did Part 11's implementation change what FDA could do with electronic records?
Part 11's implementation allowed FDA to accept electronic records and signatures in place of paper, provided the records meet defined trustworthiness criteria under FDA's scope and application guidance. It did not create new recordkeeping obligations beyond what predicate rules already required.
Sources
- Part 11, Electronic Records; Electronic Signatures - Scope and Application | FDA
- eCFR :: 21 CFR 11.10 -- Controls for closed systems.
- BioCompute Object (BCO) App-a-thon