GAMP 5 Second Edition arrived in 2022, and the most common reaction in quality groups was to check whether the software categories had changed, find that they had not, and file it. That was a reasonable first read and the wrong conclusion.
The categories are the least changed part of the guide. What changed is the stance: critical thinking moved from an idea mentioned in passing to the organising principle, and the guide stopped assuming that software is delivered in a single waterfall project. Both of those have practical consequences for how a validation plan should be written.
GAMP 5 Second Edition consulting is our practice for this, and this is the short version of what actually moved.
Critical thinking became the point
The First Edition described a risk-based approach and then provided enough structure that it could be followed without exercising much judgement. Many organisations did exactly that, which is how uniform scripted testing came to be applied to configured commercial products that did not warrant it.
The Second Edition is explicit that the framework is a tool for thinking rather than a procedure to execute. The practical test of whether an organisation has absorbed this is simple: can the validation lead explain, for a given requirement, why the testing is as deep as it is and no deeper. If the answer is that the procedure requires it, critical thinking has not happened.
This is also what makes the guide compatible with the FDA's Computer Software Assurance guidance, finalised in September 2025 and reissued in February 2026. Both say the same thing from different directions: effort should follow risk, and the reasoning is the deliverable.
The categories did not change, and the misuse of them did
Categories 1, 3, 4 and 5 remain — infrastructure, non-configured products, configured products and custom applications. Category 2 was removed back in the First Edition and is still gone, which does not stop it appearing in documents.
What the Second Edition presses harder on is that categories describe software, not validation effort, and that assigning a category is not the same as deciding how much testing to do. Over-categorisation is specifically called out as a problem: classifying a configured product as custom because it feels safer produces a large volume of evidence addressing a risk that does not exist, and the effort comes out of the budget that should have covered something real.
In practice the most useful correction is to classify after design rather than during procurement. Before design you are guessing from a brochure; after design you can read what was actually built, and in a configurable platform the category belongs to your implementation rather than to the product. We cover what GAMP over-categorisation costs separately, and Classification Engine and AI Risk Assessment are how we keep classification and risk explicit rather than habitual.
Iterative and Agile delivery is now addressed properly
The First Edition assumed a linear project with specification, build, test and release in sequence. Most software is no longer delivered that way, and quality groups were left bridging the gap with no guidance.
The Second Edition treats iterative and incremental delivery as normal rather than exceptional. The implication is not that validation becomes lighter — it is that the evidence has to be produced continuously rather than assembled at the end. A requirement, its risk assessment, its tests and its evidence need to stay joined through many small changes, which is difficult with documents written at milestones and straightforward with a maintained model.
This is where the traceability question becomes structural rather than administrative. The live traceability matrix covers why a matrix compiled at the end of an iterative project tends to describe an earlier version of the system.
Supplier leverage is expected, not tolerated
Both editions permit relying on supplier activity. The Second Edition expects it, and is clearer that duplicating supplier testing is waste rather than diligence.
The condition is unchanged and is the part organisations skip: you have to assess the supplier, assess the evidence, and record why it is adequate for your intended use. A supplier assessment that concludes the vendor is reputable is not an assessment of evidence. supplier qualification is where this gets done so it survives a question about why you did not test something yourself.
Data integrity moved into the lifecycle
Data integrity in the First Edition read as a related concern. In the Second Edition it is part of the lifecycle: considered at requirements, assessed in risk, and tested rather than assumed from platform features.
The practical change is at requirements time. Asking where the original record lives, how long it is retained, who can change it and how a change becomes visible — at the point requirements are written rather than during a later gap assessment — is substantially cheaper than retrofitting. data integrity (ALCOA+) is the practice, and most of what we find in retrospective assessments was decided by omission at this stage.
AI and machine learning: Appendix D11
The Second Edition introduced Appendix D11 on AI and machine learning, which was the first mainstream attempt to describe an AI/ML lifecycle in GxP terms — concept, project including data modelling and evaluation, and operation including deployment and continuous monitoring.
D11 has since been expanded considerably by the ISPE GAMP Guide: Artificial Intelligence, published in July 2025 and running to roughly 290 pages. If you are building a validation approach for an AI system, those two documents are where the industry's working consensus sits. Neither is a regulation.
On the European side, the draft EU GMP Annex 22 was published for consultation in July 2025 and is not yet in force — it does not appear in EudraLex Volume 4, and EMA's work plan targets a final text in late 2026. It is worth designing towards and it cannot be cited as a binding requirement today. the GxP AI hub and EU Annex 11 & Annex 22 readiness go further.
What to actually change in your documents
Most organisations do not need a wholesale rewrite. Four targeted changes capture most of the value.
- Make the validation plan state the risk rationale per requirement group, so the depth of testing is explained rather than asserted.
- Add a vendor-evidence test path with four fields: the requirement, the evidence relied on and its version, why it is adequate for intended use, and what residual testing you perform.
- Replace milestone-based traceability with traceability that is maintained as requirements change.
- Put data integrity questions into the requirements template rather than into a later assessment.
GAMP 5 Second Edition consulting is the practice, and book a demo if you want an existing framework reviewed against the Second Edition rather than rebuilt.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
