How the SDLC Changes When You're in a GxP Environment

Every software system that touches a GxP-regulated process — clinical trial data capture, batch manufacturing records, pharmacovigilance case processing — still gets built the same way any other enterprise system does: through a Systems Development Lifecycle with phases for requirements, design, build, testing, and release. What changes is not the lifecycle itself, but what each phase is required to produce and prove.

That requirement has a name: Computer System Validation, the formal discipline of demonstrating that a system does what it claims to do, consistently, before it’s trusted with GxP-relevant data. Teams new to GxP-regulated work often treat CSV as a separate track — a validation project that starts once development is “done.” That’s backwards, and it’s expensive. Every CSV deliverable — the Installation Qualification, the Operational Qualification, the Performance Qualification — is really just formal evidence for something the SDLC already produces. The question worth answering isn’t how to validate a system after it’s built, but which SDLC phase already generates the evidence a given validation step needs.

This article maps that overlay, phase by phase.

Why Requirements Capture Needs a Regulatory Lens

The Requirements Capture Phase of any SDLC gathers what a system needs to do. In a GxP environment, that same activity has to capture something more specific: which regulatory obligations the system inherits from the GxP disciplines it will support.

A system supporting Good Clinical Data Management Practice needs requirements for audit trail granularity, electronic signature workflows, and role-based access control — not because someone added a compliance checklist afterward, but because those are functional requirements the system must satisfy from day one. A system supporting Good Manufacturing Practice’s batch-release testing needs requirements for data that meets ALCOA+ principles: attributable, contemporaneous, and enduring, at minimum.

None of this requires a separate GxP requirements process running alongside the normal one. It requires the Requirements Capture Phase’s usual stakeholders to include Quality Assurance and Regulatory Affairs as requirements sources, the same way security and privacy are already integrated into every applicable SDLC phase. GxP obligations are inputs to requirements gathering, not a separate gate bolted onto its output.

How GAMP Risk Categorization Shapes the Design Phase

Not every GxP-relevant system carries the same validation burden, and the Design Phase is where that gets decided. Good Automated Manufacturing Practice (GAMP) provides the risk-based framework the industry uses to categorize software by risk — from off-the-shelf infrastructure that needs configuration verification, through configured commercial software, to custom-built applications that require full lifecycle validation.

That categorization is a design decision, not a validation-team decision made in isolation. It determines how much design documentation the system needs, how rigorously its functional specifications get reviewed, and how much of the downstream SIT and UAT effort has to produce formal validation evidence rather than ordinary test results. Applying GAMP’s categorization at Design, rather than retrofitting it once a system is built, is what keeps validation effort proportional — avoiding both the risk of under-validating a high-risk system and the cost of over-validating a low-risk one.

How Build Turns Design’s Risk Category Into Practice

The Implementation and Build Phase is where GAMP’s risk categorization stops being a design decision and becomes a set of controls a development team actually follows. A system categorized as custom-built and high-risk needs configuration management and version control disciplined enough to prove, later, that the code tested in SIT and UAT is the exact code that reaches Production — not a close approximation of it.

That traceability is the point. Regulators don’t accept “we’re confident this is the same build” as evidence; they expect a documented chain from a specific, controlled version of the code to the specific test results and approvals attached to it. Build-phase discipline — controlled repositories, documented code reviews, a locked configuration baseline before testing begins — is what makes that chain provable rather than assumed.

Why SIT and UAT Become IQ, OQ, and PQ

This is where the SDLC and Computer System Validation overlap most directly — and where the two are most often mistaken for separate activities.

Installation Qualification confirms a system is installed and configured exactly as specified — the same verification that should already be happening as a system moves through Pre-Production Staging and into Systems Integration Testing. Operational Qualification confirms the system performs each of its functions correctly across its full operating range, which is, in substance, what SIT already exists to test. Performance Qualification confirms the system performs reliably for its actual intended use, typically with representative users and real-world-like data, which is precisely what User Acceptance Testing already sets out to demonstrate.

IQ, OQ, and PQ are not three additional testing phases stacked on top of SIT and UAT. They are SIT and UAT, documented to a standard formal enough that a regulator can independently verify the results — traceable test scripts, recorded evidence, signed approvals — rather than a pass/fail summary. Teams that treat CSV testing as separate from SIT and UAT end up running the same tests twice, once for the team and once for the auditor. Teams that design SIT and UAT to produce IQ, OQ, and PQ evidence directly only run them once.

What Production Means in a Validated Environment

In most SDLCs, moving into the Production Phase means the system is live. In a GxP environment, it means something more specific: the system has entered a validated state, and everything about it — its configuration, its documented evidence, its approvals — is now the baseline that future changes get measured against.

That validated state doesn’t happen automatically at go-live. It requires a validation summary report that ties the Requirements Capture Phase’s regulatory requirements, Design’s risk categorization, and Build’s configuration and traceability evidence to SIT and UAT’s IQ, OQ, and PQ results. Quality Assurance signs off on that report before Production begins. It also requires documented evidence that the people who will actually operate the system completed training against the validated version, sourced from the SDLC’s own Training and Education Phase — a validated system nobody was trained to use correctly is still an audit finding waiting to happen. Once a system enters that validated state, it stays there through Operations and Maintenance only if changes to it are managed through formal change control — a discipline significant enough, in a GxP context, to warrant its own dedicated treatment rather than a closing paragraph here.

Learn More

This article is the GxP-specific instance of a general practice: IF4IT’s Systems Development Lifecycle (SDLC) Best Practices document already addresses how regulatory validation overlays onto the SDLC in “Regulatory Validation and Certification Within the SDLC.” The phase model referenced throughout this article is defined in full in “The 13 Phases of the IF4IT Systems Development Lifecycle (SDLC).”

For the GxP side of this overlay — including GAMP’s risk-based validation approach and where it fits into a GxP-relevant enterprise’s broader IT governance — see “Map IT Applications, Data, and Access to GxP Compliance Scope” in the GxP Compliance Framework.

The formal change control this article defers past go-live is addressed directly in IF4IT’s Release Management Best Practices document, and specifically in “Align Release Management With Every Applicable SDLC Phase” for how that discipline integrates with the SDLC.