This is a ready-to-use validation plan for GxP software built or heavily configured through Agile sprints and a CI/CD pipeline. Write and approve it before the first sprint; retrofitting an Agile narrative onto an inspection is far harder than declaring it up front. Replace every <<FILL: ...>> placeholder and route it through Quality Assurance approval as a controlled document. A filled specimen follows. This is general educational content to adapt, not regulatory advice; confirm each reference against the current source.
Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (validation lead) | <<FILL>> | ||
| Reviewer (system owner) | <<FILL>> | ||
| Approver (Quality Assurance) | <<FILL>> |
Document control header
| Field | Entry |
|---|---|
| Document title | Agile/Iterative Validation Plan for <<FILL: system>> |
| Document number | <<FILL: VP-ID>> |
| Version | <<FILL: version>> |
| System / product | <<FILL: system, GxP use>> |
| Effective date | <<FILL: date>> |
1. Scope
This plan governs validation of <<FILL: system>>, delivered by <<FILL: in-house team / vendor>> using Agile sprints and CI/CD. It covers the GxP-impacting functionality: <<FILL: e.g. result management, OOS handling, e-signatures, audit trail, batch disposition>>. It states the iterative validation approach, the environments and gates, the risk-based rigor, and the deliverable set. Non-GxP functionality is out of scope for formal validation and is covered by ordinary engineering practice.
2. Validation approach
Validation is treated as a continuously maintained state, not a one-time milestone. The validated state lives in the qualified production environment only; the control gate is the promotion of code and configuration into it. Each increment that touches GxP functionality must leave the system in a documented, tested, traceable, and QA-approved condition before it reaches production. Rigor is set per user story by risk, following Computer Software Assurance thinking and ISPE GAMP 5 (2nd ed.), not applied uniformly per project.
3. Risk basis
Each GxP-tagged story is risk-assessed at backlog refinement (severity, probability, detectability) to assign a rigor tier:
| Tier | Trigger | Rigor |
|---|---|---|
| High GxP | GxP calculation, OOS/spec rule, audit trail, e-signature, batch/release logic | Scripted acceptance + automated regression + QA review; full traceability |
| Medium GxP | GxP report field, workflow step with downstream review | Scripted or rigorous unscripted test + automated test; QA review |
| Low / non-GxP | UI layout, non-GxP filter, logging | Automated test + peer review |
The rigor decision for High GxP stories is approved by QA. Developers do not self-assess GxP impact alone.
4. Environments and gated pipeline
| Environment | Purpose | Control |
|---|---|---|
| Development / sandbox | Build and unit test | Uncontrolled; no GxP data |
| Test / QA | Integration, regression, acceptance | Representative of production; config controlled |
| Production (validated) | Live GxP use | Promotion only through the gated pipeline; direct write access locked down |
The pipeline enforces the gates: a build cannot reach production unless tests pass, required approvals are recorded, and the branch is approved. The pipeline definition (pipeline-as-code), the test code, and the environment definitions are controlled configuration items under the same change discipline as the application.
5. Deliverables mapped to sprint-native homes
| Traditional deliverable | Agile equivalent | Where it lives |
|---|---|---|
| Validation plan | This plan (written once) | Controlled document |
| URS | Backlog of GxP-tagged user stories with acceptance criteria | Controlled backlog, versioned |
| Risk assessment | Story-level risk notes + this plan’s approach | Story + plan |
| Functional/design spec | Acceptance criteria + linked configuration notes | Story or linked design records |
| Traceability matrix | Auto-generated requirement-to-test links | Toolchain |
| Test protocols + results | Automated test definitions + retained CI results + scripted tests for high-risk | CI system + test tool |
| Validation summary report | Increment release record + periodic summary | Release record + periodic report |
The definition of done is the documentation contract that makes each story’s evidence complete by construction. Reference the DoD document: <<FILL: DoD document ID>>.
6. Change control
A standing change framework authorizes the iterative delivery process itself (environments, pipeline, gates, DoD, risk method), approved once with QA. Each production increment is a change executed under that framework, with the release record as its change record. Changes outside the framework (a new high-risk module, a platform upgrade, a vendor major version) trigger a normal change assessment. The emergency change path is defined in <<FILL: emergency change procedure ID>>.
7. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Validation lead | Owns this plan, the risk method, the DoD, and the traceability standard |
| QA | Approves the plan and risk approach, reviews high-risk evidence, approves production releases |
| Product owner | Owns the backlog and acceptance of stories |
| SME | Judges GxP impact and severity, witnesses high-risk acceptance |
| Developer | Builds, writes unit/integration tests, peer-reviews |
| Automation/test engineer | Maintains the automated suites and the pipeline gates, ensures results are retained |
| Release manager | Owns the controlled pipeline, promotion path, and environment controls |
| System owner | Accountable for the system staying validated in operation |
8. Schedule and operation
This plan applies for the life of the system, reviewed at <<FILL: interval>> and on any major change. Periodic review confirms the accumulated increments remain validated. The regression suite is the continuous verification: every promotion re-proves prior GxP behavior, including audit trail and e-signature functions.
9. Acceptance criteria for the validated state
The system is and remains validated when: every GxP story met its tier’s DoD before its increment reached production; every release has a release record with recorded QA approval and a named rollback target; requirement-to-test-to-result traceability exists for high-risk functions; test results are retained for the released versions; the pipeline gates cannot be bypassed and direct production access is controlled; and periodic review confirms the state holds.
10. References
FDA Computer Software Assurance for Production and Quality Management System Software (current version issued 3 February 2026). ISPE GAMP 5 (2nd ed.), iterative development and software tools (referenced by title; described in original wording). 21 CFR Part 11; EU GMP Annex 11 (in-force 2011 version; a draft revision and a draft Annex 22 on artificial intelligence went to consultation 7 July 2025, consultation closed 7 October 2025, not in force, confirm final text before citing).
11. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
The following shows the environments-and-gates section (section 4) completed for an illustrative LIMS, so you can see the level of detail expected.
System: LIMS (GxP: QC result management, OOS handling, e-signatures, audit trail). Framework: CHG-FRW-004.
| Environment | Purpose | Control |
|---|---|---|
| Dev sandbox | Build, unit test | No GxP data; developers have full access |
| QA (PROD-representative) | Integration, regression, scripted acceptance | Config baseline CFG-master; refreshed from a controlled snapshot |
| PROD-1 (validated) | Live QC operations | Promotion only via pipeline CHG-FRW-004; no interactive write access; break-glass access alerts QA and requires an emergency change record |
Gate summary: commit runs unit tests and static checks; merge to main runs integration + regression and requires a recorded peer review; deploy to QA runs smoke tests; the acceptance stage runs scripted and unscripted tests for the increment with SME sign-off; release to production requires the DoD verified and a recorded QA approval, producing a release record. Break-glass access to PROD-1 exists for emergencies but is alarmed and always generates an emergency change record, so the controlled-path argument holds.
Common inspection findings this plan prevents
- An Agile project with no validation plan stating the iterative approach, so the whole method looks ad hoc at audit.
- Uniform rigor that either buries low-risk stories in paperwork or under-tests high-risk ones.
- A pipeline whose gates can be silently removed because its configuration is uncontrolled.
- A manual back door to production that voids the controlled-path argument.
- No defined emergency-change path, so urgent fixes become undocumented edits.
How to adapt this plan
- Write and approve this plan before the first sprint; get QA sign-off on the approach.
- Set the tiering triggers in section 3 to the real GxP functions of your system.
- Reference your actual DoD, emergency change procedure, and standing change framework by document number.
- Keep the pipeline-as-code, test code, and environment definitions in scope as controlled configuration items.
- Confirm the CSA version and the Annex 11/22 draft status in section 10 against the current source before issue.