GAMP 5 2nd Edition: What CSV now needs

Why a second edition — and what it is not

The first GAMP 5 edition dates from 2008. Since then, the way regulated companies procure and operate software has shifted fundamentally: away from in-house developed, one-time validated systems, toward configurable off-the-shelf products, continuously delivered cloud services and platforms that change monthly. The Second Edition (2022) is the ISPE's answer to this reality — and to parallel movements at the authorities, in particular the FDA initiative Computer Software Assurance (CSA).

Important for context: the Second Edition is not a reversal. The risk-based, lifecycle-oriented core remains unchanged — the five software categories, the supplier leverage principle, the demand for data integrity. What changes is the emphasis. GAMP 5 always intended proportionate, risk-based validation. In practice, the industry often turned this into documentation rituals: identical test scripts for non-critical functions, screenshots as an end in themselves, reviews that check completeness instead of risk. The Second Edition corrects this misinterpretation explicitly.

Critical thinking: the load-bearing principle

The most visible gain of the second edition is the elevation of critical thinking to a pervasive principle. This is not a buzzword but a concrete expectation: every validation activity should follow from a deliberate, reasoned risk decision — not from a checklist that is worked through identically for every system.

In practice this means: your team asks, before every test case, why it exists. Which patient risk, which data integrity or product quality hazard does it cover? What happens in the worst case if this function fails? For high-risk functions this means more depth than before. For non-critical standard functions already tested by an established supplier it means: less redundant self-testing, more reliance on the supplier's evidence.

The price of this freedom is responsibility. Where a checklist required no justification, critical thinking requires a traceable rationale — and it must hold up in an audit. This is exactly where the burden shifts: away from the volume of documentation, toward the quality of the documented decision.

Critical thinking shifts the burden from the volume of documentation to the quality of the documented decision.

Agile and iterative lifecycles are acknowledged

For a long time, the silent assumption in the GxP environment was that validation required a sequential V-model: first the complete specification, then the build, then the tests, finally a validation report. Agile teams that deliver in sprints thus stood in apparent contradiction to the regulation.

The Second Edition clears up this misunderstanding. It explicitly acknowledges agile, iterative and incremental approaches — provided the controls remain in place. What matters is not the sequence of phases, but that in the end it is provable that: requirements are traceable, risks assessed, tests passed, changes controlled. Whether this evidence emerges spread across sprints or in one large block is secondary from a regulatory standpoint.

For your practice this means: you may use continuous delivery and automated test pipelines — as long as their results stay versioned, traceable and tied to requirements. Automated tests do not become a compliance risk; cleanly configured and qualified, they become a compliance advantage, because they are reproducible and logged without gaps.

Software categories, cloud and the supplier leverage

The five GAMP software categories remain the backbone of risk classification — from infrastructure (category 1) through non-configured and configured off-the-shelf products (categories 3 and 4) to custom application (category 5). What the second edition sharpens is the expectation of how you use this classification to steer effort: the more an established supplier has already demonstrably tested, the more you may rely on this evidence instead of duplicating it.

This leveraging of supplier activities is no longer a sideshow in the cloud era but central. With Software as a Service you do not control the infrastructure yourself, do not see the code and experience updates that the provider rolls out. The Second Edition addresses this situation directly: the focus shifts from self-qualification toward robust supplier management — an audit or sound assessment of the provider, clear service-level and quality agreements, an understanding of how the provider controls and communicates changes.

Concretely, you should check: how does the provider inform about releases? What change control does it maintain? What evidence (certificates, test evidence, pentests) does it provide? The responsibility for regulatory conformity stays with you — even when the technical execution lies with the provider. The EU Annex 11 articulates the same expectation for the governance of service providers and suppliers.

The new view of AI and machine learning

With the second edition and its accompanying materials, artificial intelligence and machine learning enter the GAMP framework for the first time. The reason is obvious: AI components behave differently from classic, deterministic software. They are data-driven, can respond probabilistically, and their behavior can change when training data or model change. A one-time validation run on a cut-off date does not capture this.

The guidelines therefore emphasize aspects that played no lead role in the classic V-model: data quality and data provenance, traceability of the model decision, handling of model drift, and above all risk-based, ongoing monitoring instead of a single validation event. The higher the risk of the application — for instance when a model feeds directly into a quality decision — the stricter the requirements for explainability and human oversight.

This expectation aligns with the broader regulatory direction. The EMA has published a reflection paper on the use of AI across the medicinal product lifecycle; the FDA has published a risk-based draft for AI in the medicinal product lifecycle. The common denominator: AI may support, but the responsibility for the GxP decision stays with the human — and it must be documented traceably.

What your team should concretely adjust — and what stays

Theory turns into work. The following shifts are the ones that hit hardest in practice:

• Validation strategy instead of validation volume: Anchor a documented, risk-based rationale per system and per critical function. Fewer generic test scripts, more targeted depth where patient, product or data are at risk.
• Professionalize supplier evaluation: With cloud and SaaS, the provider assessment becomes the core of your chain of evidence. Contractually anchored change communication, audit rights and quality agreements belong in the standard process.
• Allow agile evidence: Adjust SOPs so that iteratively produced, versioned evidence is explicitly acknowledged — including automated, qualified test pipelines.
• Treat AI/ML separately: For learning or generative components you need data quality controls, monitoring for drift and a clearly defined point of human release — not a one-time acceptance event.

And what deliberately stays the same? The essentials: the obligation to validate itself does not disappear. Data integrity (ALCOA+), traceability from requirement to test, controlled changes, a complete and tamper-proof audit trail and the ultimate QA responsibility — all of that is non-negotiable and was never up for discussion. The Second Edition wants you to validate smarter, not less safely.

How a trust architecture fits in

When critical thinking and AI support come together, a legitimate concern arises in every quality department: do we lose control over the rationale as soon as a model co-authors it? This is exactly where the architecture decides — not the marketing language.

traqx is deliberately built so that the principles of this regulation are not undermined but supported. Sources first: AI outputs are tied to verifiable, internal sources instead of being freely generated. AI as a suggestion: the system delivers a draft, not a decision. The human decides: human release remains mandatory — QA responsibility does not move into the machine. The audit trail remains: who decided what when on which source is logged traceably.

This is not a claim to be GAMP 5 compliant — conformity is always established by your validated procedure in your context, not by a tool. It is the statement that an architecture that treats source binding, human release and a gapless audit trail as its foundation fits well with what the Second Edition demands — rather than working against it.