ISPE published the second edition of GAMP 5 in July 2022, fourteen years after the first. If you were expecting a new set of rules, it can feel like an anticlimax. The life cycle is the same, the software categories are still there, and risk management still sits at the centre. What changed is the tone. The second edition says, more directly than before, that validation effort should follow risk to the patient and to data, and that a lot of the documentation produced in the name of compliance does not add anything.
Here is what that means on an actual project.
Critical thinking is now the headline
The phrase appears throughout the guide. In plain terms it means: before you write a test, ask what could go wrong with this function, how likely it is, how you would find out, and what the impact would be. Then decide how much testing that deserves.
For a configurable laboratory system, that might mean scripted, step-by-step testing of the calculations and the audit trail, and simple unscripted or exploratory testing of screen layouts and report formatting. Under the old habits, both would have got the same scripted treatment, with screenshots of every click.
Where Computer Software Assurance fits
The FDA's draft guidance on Computer Software Assurance, published in September 2022, points the same way. It describes scripted testing for high-risk features and allows unscripted, ad hoc or exploratory testing, with lighter records, where the risk is lower. GAMP 5 Second Edition was written with this in mind, and the two can be used together. CSA is not a replacement for validation. It is a way of choosing how much evidence each function needs.
Leaning on the supplier
The second edition puts more weight on using supplier documentation and testing, provided you have assessed the supplier and their quality system. If a reputable vendor has already tested a standard function thoroughly, re-testing it in the same way adds little. Your effort goes into the configuration you made, the interfaces to your other systems and the way your users actually work.
This only works if the supplier assessment is real. A questionnaire filled in by the vendor's sales team is not an assessment.
Topics that were not there in 2008
Several appendices are new or rewritten: agile software development, cloud and software as a service, IT infrastructure, open-source software, blockchain, and artificial intelligence and machine learning. The agile appendix is the one most teams will use first. It accepts that requirements can be refined during development, as long as the final system is specified, tested and traceable before it is released for GMP use.
What does not change
- You still need a validation plan, user requirements, a risk assessment, testing and a report, scaled to the system.
- Data integrity expectations are unchanged. Audit trails, access control and record retention still need to be designed in and verified.
- Regulators still expect you to justify your choices. "GAMP says we can do less" is not a justification. "We assessed this function as low risk because…" is.
Where to start
Most companies do not need to rewrite their whole CSV procedure. A good first step is to update the risk assessment template so it drives the test approach explicitly, function by function, and to add unscripted testing as an accepted method with a simple record format. Pick one upcoming system, apply it, and see how the test package compares with the last one. Done well, the package gets thinner and the review gets faster, without the system being any less validated.
GAMP Services Limited 2026. All Rights Reserved.