Lifecycle, Not Event
The most common misconception about pharmaceutical validation is that it is a project phase — something that happens after the engineering is done. It is not. Validation is a lifecycle that runs in parallel with, and in many phases ahead of, the engineering work.
GAMP 5 defines this lifecycle using two complementary structures: the V-model, which maps design documents to qualification tests, and the phase-gate approach, which defines the formal checkpoints at which a project must confirm completion of one phase before beginning the next. Together they ensure the validation package is coherent, traceable, and complete.
This article walks through all eight phases of the GAMP 5 validation lifecycle as defined in a well-structured Validation Plan — from initial planning through to ongoing lifecycle management. For each phase we cover the gate entry criteria, the key documents produced, and the most common failure modes.
A phase gate is not a review meeting — it is a documented hold point. The next phase cannot begin until the gate entry criteria are met and confirmation is on file. An auditor finding that OQ began before IQ was approved is a serious observation. Phase gate discipline is non-negotiable on a well-run GMP project.
The Eight Phases
Planning is where the validation framework is established before any engineering begins. The three core documents produced here — the Validation Plan (VP), the Project Quality Plan (PQP), and the Risk Management Plan (RMP) — define the rules that every subsequent document must follow.
The VP is the governing document. It defines the GAMP 5 category, the V-model lifecycle, all deliverable documents, phase gate criteria, roles and responsibilities, and the testing strategy. No validation activity can commence without an approved VP — and the VP must be approved before the URS is finalised, because the URS must be written within the framework the VP defines.
The supplier assessment (SAQ/SAR) also typically occurs during planning — qualifying the system integrator and any major sub-suppliers before design work begins.
This is the left side of the V-model — where the system is defined on paper before it is built. The URS defines what the system must do from the user’s perspective. The FDS defines what it does functionally from an engineering perspective. The HDS defines the hardware architecture. The SDS defines the software implementation for Category 5 components.
The Risk Assessment is also completed here and drives test coverage decisions for Phases 3–6. The Traceability Matrix begins in this phase, tracing every URS requirement through the design hierarchy to the test cases that will eventually verify it. By Phase 7, every row must show a PASSED status.
The Factory Acceptance Test (FAT) is executed at the supplier’s works before the system ships to site. It tests the PLC and SCADA application against the approved FDS and SDS — proving the system functions as designed before the cost and disruption of site installation. The software version is frozen and a hash/checksum is documented before the system leaves the supplier’s facility.
The Site Acceptance Test (SAT) follows installation — confirming the system survived transport and that site-specific integration (I/O connections, network, historian) is functioning. FAT and SAT evidence carries forward into IQ and OQ. The Master Deviation Ledger opens at this phase to track all deviations from FAT onwards.
The IQ verifies that the system was installed as designed. Every hardware component is verified against the HDS: PLC model and firmware version, SCADA server hardware and OS version, network switch configuration, UPS, instrument tags and calibration certificates. Software versions are verified and hash/checksum values are documented at this point in the installed environment.
The IQ also verifies environmental and infrastructure requirements: panel environmental ratings, earthing and bonding, power supply redundancy. Critically, the Backup and Recovery Procedure (RBP-SYS-001) must be tested as part of the IQ — backup and restore is a GMP requirement, not an IT nicety.
The OQ verifies that the system operates correctly across its full functional range — all FDS functions, all alarms and interlocks, user access control, audit trail, electronic records, edge cases, and failure modes. Test cases are pre-approved and executed with witnessed signatures. Every deviation from an expected result is raised in the Master Deviation Ledger.
Four SOPs must be approved before OQ begins: System Operation, System Administration, Change Management, and Periodic Review. Operators must be in training by the time OQ starts. Training Records (TRF-SYS-001) are collected throughout this phase.
The PQ proves the system performs consistently under actual production conditions. Unlike the OQ — which tests functions in isolation — the PQ tests the system as an integrated whole, typically over an extended period with real process media or validated simulation conditions.
For most process control systems, PQ includes a monitoring phase where process parameters are recorded and confirmed within specification over a defined number of batches or time period. The PQ is typically led by the client’s process owner. The automation engineer provides technical support rather than driving execution at this stage.
GMP release is the formal closure of the validation project. The Validation Summary Report (VSR) declares the system validated. It summarises every phase, confirms all deviations are closed, confirms the Traceability Matrix is 100% complete with PASSED status on every row, and formally releases the system for GMP use.
The VSR cannot be approved until every Category A (critical) deviation is formally closed. It also records the first scheduled periodic review date — typically 24 months from VSR approval. Once signed, the system is in its validated state.
The validated state is not permanent without maintenance. Two processes keep it alive: change control and periodic review. Every modification to the system — software change, hardware replacement, configuration update — goes through a formal change control process (CCR/CCL) with a documented impact assessment and re-testing where required.
Periodic reviews are scheduled assessments — typically every 24 months per the schedule recorded in the VSR — confirming the system remains in its validated state. The SOP-PR-SYS-001 defines the process; the PRR-SYS-001 documents the outcome. The review covers the change control log, deviation history, audit trail samples, calibration status, and any incident records from the review period.
The Thread That Runs Through Everything
The Traceability Matrix is not a Phase 2 deliverable — it is a living document populated throughout the entire lifecycle. A URS requirement is added in Phase 2. The FDS function that implements it is linked in Phase 2. The test case that verifies it is linked in Phase 3–5. The executed result is recorded at test execution. By Phase 7, every row must show a PASSED status with a reference to the executed test evidence.
An incomplete traceability matrix at VSR approval is a blocking issue. It means a requirement exists with no verified test evidence. No auditor will accept a VSR where the traceability is incomplete — it is one of the first things an inspector checks.
Starting OQ before IQ is approved — or running FAT, SAT, IQ, and OQ concurrently to save time. Phase gates exist because each phase builds on the evidence of the previous one. Concurrent execution means you cannot demonstrate that the system was in a known, verified state before testing began. That is not a documentation problem — it is a fundamental loss of validation integrity.
Your Role Across the Lifecycle
As an automation engineer or system integrator, your involvement is heaviest in Phases 2 and 3. You author the FDS, HDS, and SDS. You execute the FAT. You support the SAT. You may author the IQ and OQ protocols, or provide the technical content that the validation lead formats into the final documents.
From Phase 7 onwards your role shifts to supporting change control. Any modification to PLC code, SCADA configuration, or hardware after GMP release goes through the change control process — and you will typically provide the technical impact assessment and re-test plan.
Understanding the full lifecycle is what separates an engineer who produces good documents from one who understands why those documents exist and how they connect. That understanding is what makes your contribution credible under a QA review or regulatory inspection.
The QLean template pack covers every document across all eight phases: VP, PQP, RMP, SAQ/SAR, CP, URS, FDS, HDS, SDS, Risk Assessment, Traceability Matrix, Engineering Lists, FAT, SAT, IQ, OQ, PQ, Master Deviation Ledger, VSR, all four SOPs, RBP, TRF, CCR, CCL, and Periodic Review Report. Every document is structured to satisfy its phase gate requirements and clearly references the documents it depends on.