Agile software development for GxP systems.
Agile software development for GxP systems combines iterative delivery with demonstrable compliance: the evidence comes into being record-based in the software development tool chain - from requirements, risk assessments and test results - and every iteration stays audit-ready. We build the regulatory requirements into your agile workflows in a way that preserves the benefits of agility.
Develop the agile way, prove it the GxP way.
On the surface, agile principles seem to conflict with the applicable GxP requirements. In fact, GAMP 5 Second Edition describes how agile methods can be evidenced appropriately - through standards for epics and user stories, integrated risk assessments and a deliberately chosen software development tool chain. What matters is the change of perspective: the evidence is not produced alongside development - it comes into being as records within it.
The GAMP Good Practice Guide "Enabling Innovation" (2021) mapped out this route, and the Second Edition (2022) carried it into the main guide. Set up this way, agile development lowers the validation effort for the computerized system - it takes specialist expertise and careful judgment to adapt agile methods to the regulatory requirements. How every iteration carries its own evidence is shown in the sprint workflow.
The GxP-compliant iteration cycle.
Agile development in a regulated environment delivers in short iterations while demonstrably meeting the regulatory requirements. Risk assessment and evidence belong to the cycle itself; the FDA's Computer Software Assurance (CSA) takes the same risk-based approach.
- 1
Backlog & requirements
Capturing and managing requirements as epics and user stories - including regulatory and security requirements - to defined standards, with clear roles and responsibilities.
- 2
Sprint planning & risk assessment
Selecting the user stories for the iteration alongside an integrated, risk-based assessment - so the risk assessment is part of sprint planning rather than a separate activity.
- 3
Implementation in the tool chain
Building the increment directly in the software development tool chain - the evidence comes into being as records from the development work: requirement baselines, pipeline runs, reviews.
- 4
Test & verification
An agile test strategy and test plan, automated and manual, with demonstrable coverage of the defined requirements in each iteration.
- 5
Review & evidence
The iteration's records are consolidated into the sprint result - fully traceable and audit-ready, with no duplicate upkeep in downstream documents.
- 6
Release in a validated state
Releasing the iteration without losing the validated state - increments move into operation in a controlled, demonstrable way.
Agile or waterfall in the regulated environment.
Both models can be run in a GxP-compliant way. The difference lies in how requirements, risk assessment and evidence are spread across the lifecycle - and how quickly the project can respond to new findings.
| Aspect | Waterfall | Agile (GxP-compliant) |
|---|---|---|
| Requirements | Fully defined up front | Captured as epics and user stories, refined iteratively |
| Delivery | Once, at the end of the project | In short, working increments every sprint |
| Risk assessment | Phase by phase, mostly at the start | Built into every sprint, ongoing |
| Documentation | A downstream, separate phase | As records from the tool chain, continuously |
| Handling change | A costly, formal change procedure | Planned into the next iteration |
| Validation effort | High and bunched near project end | Spread across the iterations, carried by continuously accruing evidence |
Do the tools themselves need validation?
No - backlog, traceability and test tools are not GxP business applications in the proper sense. The tools of development are infrastructure software in GAMP terms; the FDA, for its part, treats supporting test and automation tools as software that supports production and the quality system - evidence is required, but at a depth graduated to risk. What is required is a documented adequacy assessment based on intended use - the depth of control follows the risk of the task the tool takes on.
| Tool | Depth of control by intended use |
|---|---|
| Backlog and requirements management | documented adequacy assessment and baseline controls for access and versioning - this is where epics and user stories come into being |
| Traceability and test management | controlled workflows: the link between requirement, risk and test evidence inside the tool carries the traceability |
| Automated testing for high-risk software | the deepest level of control: verified testing workflows and protected, available records across the full retention period |
What used to live in documents now lives in the tools: requirement baselines, risk assessments, test results. Data integrity requirements therefore reach the data held in the tools: it must stay protected, available and retained across the retention periods - that is where the real duty of care lies, not in validating the tool itself.
Agile development, guided to stay compliant.
We do not just apply GAMP 5 - we helped write it.
QFINITY contributed to GAMP 5 Second Edition on the core team - the industry standard that describes how agile, iterative development is evidenced appropriately in the regulated environment.
The GAMP Good Practice Guide "Enabling Innovation" (2021) mapped out this route: critical thinking, agile methods, records in tools instead of downstream documents. The Second Edition (2022) carried these principles into the main guide - the two works act in concert, from Scrum through the Scaled Agile Framework (SAFe) to continuous integration and continuous delivery (CI/CD).
Frequently asked questions about agile development in GxP.
Yes. No regulation prescribes a development model; what is required is a demonstrable, risk-based handling of requirements, risks and testing. How agile approaches are evidenced appropriately is described by GAMP 5 Second Edition - through standards for epics and user stories, integrated risk assessments and a controlled software development tool chain.
No - the tools of the software development tool chain are not GxP business applications but infrastructure software; what is required is a documented adequacy assessment based on intended use, with the depth of control following the risk. The records inside the tools deserve particular attention: they are the evidence, and they must stay protected, available and retained across the retention periods.
They act in concert: the Good Practice Guide (2021) worked out the methodology - critical thinking, agile workflows, records in tools instead of downstream documents. GAMP 5 Second Edition (2022) carried these principles into the main guide: requirements as epics and user stories, integrated risk assessment, test evidence from the tools. GAMP is methodology, not regulation - it describes the route; the requirements come from the regulations.
Set up correctly: yes. When the evidence comes into being as records in the tool chain, the effort spreads across the iterations, and the evidence is already there at release. What is validated is the computerized system in the process - agile development keeps feeding it the evidence, continuously.
Develop in sprints, keep the validated state intact.
We mesh your agile development model with requirements standards, built-in risk management and a GxP-compliant tool chain - so validation effort goes down instead of piling up at project end. In an initial conversation we pinpoint where your sprints need regulatory sharpening. Free of charge, about 30 minutes.
Book an intro call
