Building Software for Regulated Life Sciences Environments

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 — which 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 — which affects build cost, validation effort, and timeline.

Audit trails

The regulation requires computer-generated, time-stamped records capturing who created, modified, or deleted a record and when — including 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. In NGS and genomics pipelines, this requirement becomes substantially more involved than in a typical application. Sample metadata, quality scores, alignment outputs, and variant calls all flow through multiple processing stages, and each state change across that chain is a potential audit event. Getting coverage right means designing the audit model before the data model. On every regulated project we take on, that is how we start.

Electronic signatures

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 — whether review, approval, or authorisation. In laboratory workflow systems, signature chains across review and release steps are among the first things an auditor examines. A session token or a checkbox does not satisfy the requirement. The signature record is a document of its own, written once and thereafter immutable.

System validation

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 to each — a custom-built application carries heavier obligations than a configured commercial system. When we design the architecture of a regulated system, the GAMP 5 category is a decision we make explicitly at the outset, because it determines how much validation documentation the client will need to produce and sustain over the life of the system.

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.

Audit trails added after the fact

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. 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.

Validation treated as documentation rather than engineering

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. The test suite we deliver is structured so it can serve as OQ evidence when re-executed as part of the change control process — not just run once at release and set aside.

Change control as an afterthought

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. We deliver a change control procedure as a defined part of the engagement, not as an advisory note in the handover document.

Open system requirements missed for cloud platforms

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. These are structural requirements, not configuration options. All regulated cloud systems we build treat them as defaults from the start.

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 and not dependent on anyone's memory of how the environment was set up. 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.

The following are the structural requirements we treat as non-negotiable starting points on any regulated project, regardless of scale.

• Immutable audit log capturing timestamps, user identity, action type, and before/after values for every regulated record mutation — in a table no application user can write to directly
• Role-based access control with a documented access management procedure and periodic reviews built into the operating model
• Session timeout and re-authentication required for actions that carry regulatory significance
• Electronic signature records capturing signer identity, timestamp, and meaning — stored as linked records that cannot be edited after signing
• Encryption in transit and, where the predicate rule or data sensitivity requires it, encryption at rest
• System configuration in version control with a tested, documented deployment process for validated environments
• Automated test suite covering all functional requirements, structured to serve as OQ evidence when run against a controlled build
• Change control procedure defined at delivery — classifying change types and the re-qualification scope each triggers

Data model and third-party services

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. Database schema changes on a validated system are change control events — they require a documented assessment and re-qualification before production deployment. We version migration scripts and treat schema changes as controlled releases on regulated projects. Third-party services that store or process regulated records are part of the validated system and require vendor qualification — cloud infrastructure providers, authentication services, and pipeline tooling included. That work is a defined part of the engagement, not an afterthought.