What Part 11 Means for a Software Team
Title 21 CFR Part 11 governs how FDA regulated companies manage electronic records and signatures. It applies any time an electronic system is used to create, modify, retain, or transmit records that a predicate rule (an FDA regulation or statute) requires to exist. For a software engineering team, that means the compliance obligation is not a layer on top of the system. It determines how the system is designed.
The regulation covers closed systems, where access is controlled by the record owning organisation, and open systems. Cloud platforms accessible over public networks fall into the open category and carry additional obligations around encryption and authentication. Most of the life sciences systems we build are cloud hosted, which places them in the open system category and shapes the architecture from the outset.
Getting the scope right before design begins matters more than most teams realise. Part 11 does not apply to every piece of software a regulated company runs. It applies specifically where a predicate rule requires a record, and that record is electronic. Scoping this correctly determines what the system must do, and equally what it does not need to do. That affects build cost, validation effort, and timeline.
Audit Trails, Signatures, and Validation
The regulation requires computer generated, time stamped records capturing who created, modified, or deleted a record and when. That includes the value of the data before the change, not just after. These records must be retained as long as the records they cover, and must not be modifiable by the individuals whose actions they log.
Each electronic signature must be unique to its author, permanently linked to the record it covers, and must capture the signer's full name, the date and time, and the specific meaning of that act: review, approval, or authorisation. A session token or a checkbox does not satisfy the requirement.
Validated systems must demonstrate accuracy, reliability, and consistent intended performance. GAMP 5 is the most widely used framework for structuring this work. It categorises software by type and assigns a corresponding validation burden. The GAMP 5 category is a decision we make explicitly at the outset.
Cloud systems accessed over public networks are open systems under Part 11, which carries requirements beyond those for closed systems: encryption of records in transit, stronger authentication for regulated actions, and documented evidence of measures protecting record integrity across open networks.
Where Projects Typically Run Into Trouble
Most compliance failures in regulated software are not caused by ignorance of the regulation. They are caused by architectural decisions made early that were not made with compliance in mind, and then become very expensive to undo. Bolting on audit trails later is a kludge that rarely holds up under inspection.
When audit logging is added near release, it almost always ends up incomplete. It covers the obvious write operations but misses state changes from background processes, bulk updates, or cascading mutations triggered by reference data changes. In NGS pipelines, secondary analysis steps can change the effective interpretation of upstream records. If those downstream changes do not generate traceable audit events, the gap surfaces during validation, at the point when it is most costly to fix.
The FDA expects validation to be woven into the development lifecycle, not assembled retrospectively. Requirements must be defined and traced to functional specifications. Tests must be executed against a controlled build in a documented environment. We write test automation for regulated projects precisely because manual testing against an uncontrolled build is not a repeatable or auditable artefact.
A system validated at launch is not perpetually validated. Every subsequent change requires a procedure that classifies the change and determines the re-qualification scope. Teams that do not define this at delivery are left working it out the first time they need to ship a fix, often under pressure.
How We Build for Validation
When we build software that a client will take through FDA validation, the delivery process is structured to produce the artefacts each qualification protocol requires. Installation Qualification documents that the system is installed correctly in the target environment: correct version, correct configuration, correct infrastructure. We hold system configuration in version control so the IQ record is reproducible.
Operational Qualification tests that every requirement in the functional specification behaves as defined. Our test automation on regulated projects maps directly to the functional requirements so the suite can be executed against a controlled build to serve as the OQ evidence package. Performance Qualification tests consistent performance under real world conditions. For genomics platforms, that typically means throughput testing against representative sequencing file sizes and concurrent pipeline execution scenarios.
We define the audit event schema in the architecture phase, mapping every actor in the system that can mutate a regulated record and ensuring each has a corresponding write path that cannot be bypassed. Soft deletes are not optional. Records the FDA requires to exist cannot be removed through ordinary user actions, and the data model needs to reflect that from the start.
GenXFlo is a bioinformatics pipeline tool built by SequoiaAT that allows life sciences teams to design and share NGS workflows visually, generating Nextflow code without requiring pipeline engineering expertise for every run. One of the early design decisions in building GenXFlo was structuring it so that client deployments could be treated as configured systems under GAMP 5 rather than bespoke custom builds, reducing the validation burden for every team that adopts it.
Common Questions About FDA 21 CFR Part 11 Compliance
What is FDA 21 CFR Part 11 and when does it apply?
FDA 21 CFR Part 11 governs how FDA regulated companies manage electronic records and signatures. It applies any time an electronic system is used to create, modify, retain, or transmit records that a predicate rule requires to exist. For software teams, that means the compliance obligation determines how the system is designed, not added later.
What are the main technical requirements of Part 11?
The main requirements include computer generated audit trails capturing who did what and when, electronic signatures that are unique, linked to records, and capture meaning, system validation demonstrating accuracy and reliability, and for cloud systems encryption and stronger authentication. These are architectural requirements that need to be designed in from the start.
How does Sequoia Applied Technologies approach Part 11 compliance?
Sequoia builds compliance into the architecture from day one rather than bolting it on at the end. That includes defining audit event schemas before data models, structuring test automation to serve as OQ evidence, and delivering change control procedures as part of the engagement. The GAMP 5 category is a deliberate early decision that shapes the validation burden.
What is GAMP 5 and how does it relate to Part 11?
GAMP 5 is the most widely used framework for structuring validation of computerized systems in regulated environments. It categorizes software by type and assigns a corresponding validation burden. A custom built application carries heavier obligations than a configured commercial system. The GAMP 5 category determines how much validation documentation the client will need to produce and sustain.
What life sciences software does Sequoia build with Part 11 compliance?
Sequoia builds NGS and genomics pipeline engineering, test automation for regulated software, laboratory workflow and LIMS systems, diagnostic and clinical data software, and GenXFlo, a bioinformatics pipeline tool. All regulated projects include audit trails, electronic signatures, validation artifacts, and change control procedures.
What mistakes do teams commonly make with Part 11 compliance?
Common mistakes include adding audit trails after the fact (which almost always ends up incomplete), treating validation as documentation rather than engineering, leaving change control as an afterthought, and missing open system requirements for cloud platforms. Bolting on audit trails later is a kludge that rarely holds up under inspection.