GAMP 5 in modern software projects

GAMP 5 has a reputation the guide does not deserve: ponderous, document-heavy, incompatible with modern development. In fact it demands the opposite – a risk-based approach, use of what the supplier has already tested, and critical thinking instead of form-filling. The reputation usually comes from the implementation, not from the guide.

1. What GAMP 5 is

GAMP 5 is an ISPE industry guide for validating computerised systems in a GxP environment. It is neither law nor a standard: regulators do not require “GAMP compliance” but controlled, documented processes. GAMP 5 is a widespread and recognised way of meeting that expectation – but it is guidance, not a rule.

The regulatory basis sits elsewhere: Annex 11 of the EU GMP guidelines, 21 CFR Part 11 and the respective national requirements. The deep dive software validation under GxP describes the process in detail.

2. The software categories

The best-known part is the classification into software categories. Their purpose is not classification for its own sake but deriving an appropriate level of effort:

The practical consequence is substantial and often overlooked: the architecture decision directly influences the validation effort. What is expressed as configuration of a proven platform is evidenced differently – and usually more cheaply – than individually programmed logic. Build a lot yourself and you buy evidence work.

3. Risk-based instead of exhaustive

The second core idea: not every function is tested to the same depth. The measure is the impact on product quality, patient safety and data integrity. A workable approach in three steps:

1. List the functions – at a granularity that can still be described in domain terms, not at method level.
2. Assess the impact – what happens on malfunction, how likely is it, how reliably would it be detected?
3. Assign the test depth – from “regular quality assurance” to “documented test cases including negative tests”.

What matters is recording this assignment beforehand. Test depths justified after the fact look like an excuse in any inspection.

4. Using the supplier’s work

GAMP 5 explicitly allows building on the supplier's activities instead of repeating everything – provided a supplier assessment shows those activities are sound. What counts:

• a traceable development process at the supplier,
• test evidence for standard functions,
• documented versioning and release processes,
• a defined way of handling defects and security vulnerabilities,
• availability of the documentation for an inspection.

For platform vendors that means: solid statements about your own process are worth more than marketing claims about compliance – they genuinely reduce the customer's effort.

5. Iterative working and the V-model

The V-model is ubiquitous in GAMP presentations, but it describes a relationship – every specification level has a corresponding test level – not a sequence in time. That relationship can be established iteratively just as well as sequentially.

What additionally has to be settled when working iteratively:

• From which point does a requirement count as “relevant to validation”?
• How are intermediate states handled that never go to production?
• When is the validation status updated – per release or in batches?

The answers belong in the validation plan. Settled there, iterative development is no contradiction to GAMP 5.

6. Automated tests as evidence

From a GAMP perspective automated tests are attractive: reproducible, logged, re-run on every change. For them to serve as evidence, though, three things have to be controlled:

• The test environment – known, versioned, documented.
• The test data – defined and traceably produced.
• The test tool itself – assessed for fitness; the effort for that again follows the risk.

Retention comes on top: a test run whose log disappears after 30 days is not evidence. See evidence by design.

7. Where AI-assisted development fits

An AI tool in development is first of all exactly that: a tool. It changes neither the category of the resulting software nor the scope of validation, because what ships is what ships – deterministic software. What has to be added are the questions from the deep dive AI and GxP: data flows, review duties, documentation of the tool's use.

It is different when a model influences GxP-relevant decisions at runtime. That is a separate and considerably more demanding question and deserves its own assessment.

Common mistakes

• Treating everything as bespoke and thereby re-proving standard functions.
• Skipping the supplier assessment and losing the relief GAMP 5 explicitly provides.
• Writing the risk assessment afterwards to justify the test depth already chosen.
• Reading the V-model as a schedule instead of as a mapping.
• Producing documents instead of evidence – confusing volume with quality.

Checklist: applying GAMP 5 in practice

Conclusion

Applied correctly, GAMP 5 reduces effort rather than creating it: through categorisation, a risk basis and the use of what the supplier has already tested. The most common mistake is not too little documentation but too much – in the wrong places.

The most effective decision is made early and outside validation: the more a system uses configured, proven platform functionality, the smaller the part that has to be evidenced individually.