GAMP 5 Validation.
GAMP 5 is the authoritative ISPE guide to the risk-based validation of computerized systems in GxP environments. Its Second Edition (2nd Edition) was published in July 2022. GAMP 5 validation follows the life cycle model: evidence begins in the concept phase and ends only at retirement, not with the validation report. Life science companies around the world draw on it as a reference, as do regulators such as the FDA. QFINITY was part of the Core Team behind the Second Edition and brings that expertise directly to every engagement.
The reference for computerized systems.
The GAMP 5 Guide offers a pragmatic framework for efficiently delivering compliant computerized systems that are fit for their Intended Use. Its risk-based approach, grounded in scalable specification and verification, has proven effective for systems of all sizes.
What is new in the GAMP 5 Second Edition?
The GAMP 5 Second Edition (2nd Edition, July 2022) keeps the framework, key concepts and ICH Q9-aligned quality risk management. What is updated is how the guide is applied in practice. What has shifted is the emphasis. Patient safety and product quality come before compliance, and critical thinking is called out explicitly. That the life cycle need not be linear is stressed more strongly than in the First Edition, with a dedicated appendix on iterative and agile development. New appendices cover critical thinking, in-house and third-party IT infrastructure, software tools across the life cycle, blockchain, plus AI and machine learning. Also updated are planning and reporting for SaaS solutions, the assessment of cloud service providers, requirements and testing with tool support, and handover into operation. The guide allows records from automated tools to replace formal specification and test documentation, applying the Computer Software Assurance concepts from the FDA's Case for Quality program.
How does a GAMP 5 validation work?
A GAMP 5 validation follows the guide's life cycle model with four phases: concept, project through to go-live, operation and retirement. The preparatory work takes place in the concept phase, so that the context no longer shifts during the project and nothing from earlier phases has to be finished alongside it. The project phase covers planning, specification, configuration or development, verification and release, with scope and depth scaling with risk, complexity and novelty. Once in operation, the system keeps its validated state through change, incident and problem management, configuration management and periodic review. The GAMP 5 Second Edition calls for critical thinking along the way. In the end, the evidence must show that the system is fit for its Intended Use and can be operated in a validated state.
| Phase | What happens |
|---|---|
| Concept | Need and Intended Use emerge from the business process; an initial risk assessment and the in-principle decision on the solution approach and the supplier. |
| Project | Planning, specification, configuration or development, verification and release are scaled according to risk; supplier deliverables are assessed and leveraged rather than duplicated. |
| Operation | The longest phase: change and configuration management, periodic review, and incident and CAPA processes maintain the validated state. |
| Retirement | An orderly exit: data migration or archiving in line with retention requirements. The records remain readable and available beyond the life of the system. |
And the V-model? It is a specification-verification model. It shows which verification activity answers which level of specification. Nothing more. It covers exactly one phase, the project; concept, operation and retirement do not appear in it. The V-model sits inside the life cycle, but it is not the life cycle. The guide itself drew that conclusion early: the First Edition (2008) had already moved away from the classic V diagram because the V had too often been misread as a linear waterfall. The Second Edition carries the generic specification-verification representation consistently forward, and the same logic also supports iterative, agile approaches. There it is simply applied incrementally.
What the system produces follows IT's oldest pattern: input, processing, output. A function turns input data into output data; the sum of the functions is the system. Its outputs are electronic records and signatures. They are subject to 21 CFR Part 11 and Annex 11, and the evidence that they are generated in compliance is produced as part of validating the system. Annex 11 is part of the GMP framework. The principle applies across the entire GxP spectrum, in clinical research, for instance, through ICH E6(R3) and the EMA guideline on computerised systems.
What goes into a GAMP 5 validation?
A GAMP 5 validation consists of a chain of evidence. It begins in the concept phase and closes the project with the validation report. Each link answers a question an inspector will ask later, such as what the system is meant for, which risks were identified, how it was tested and who released it. Eight steps deliver the core of that evidence. How deep each step goes is set by the risk. The chain does not end with release. Every later change to the system runs through it again, scaled to the size of the change, and the periodic review establishes whether the evidence still matches the system in use. Evidence kept current in operation is what keeps the system in the validated state that GAMP 5 sets out as the aim of that phase.
The risk process behind the evidence.
Within the phases, quality risk management governs what evidence is produced and how deep it goes. ICH Q9 defines the systematic process. GAMP 5 translates it into five steps for computerized systems:
- 1
Initial risk assessment
A first appraisal of the system in its process context: How does it influence GxP-relevant operations? What is the system's overall impact level?
- 2
Identify the relevant functions
Which functions touch patient safety, product quality or data integrity? Only they carry the risk, and only they warrant that depth of testing.
- 3
Functional risk assessment & controls
For each identified function: identify and assess failure scenarios and define technical, procedural or organizational controls.
- 4
Implement & verify controls
The controls are implemented and verified in a documented way, traceable back to the requirement they safeguard.
- 5
Review periodically
Risks and controls are reassessed regularly in operation. The validated state is a maintained state, not an archived document.
Software categories: a continuum, not a checklist.
The GAMP categories classify software by type and degree of customization; behind them sit two causal drivers: novelty and complexity. The more customization a regulated company demands and the further it thereby departs from the software's standard, the less weight the supplier's assessable prior work carries, and the larger the company's own share of the evidence becomes.
| Category | What follows from it |
|---|---|
| 1 · Infrastructure softwareoperating systems, databases, middleware | Established and widely deployed, hence low novelty. It is operated under control and qualified, not validated individually. |
| 3 · Standard productsnon-configured, used "as supplied" | The evidence rests on assessed supplier work: a supplier assessment plus verification against the company's own requirements. |
| 4 · Configured productsLIMS, MES, eQMS, ERP | The configuration is the new, unproven part. The evidence concentrates on it and on the processes it maps. |
| 5 · Custom applicationsbespoke development, custom code | Maximum novelty, no prior work for the evidence to lean on: the full life cycle evidence from specification to testing rests with the regulated company, supported by its supplier. |
The Second Edition spells out what practice often oversimplifies: the categories are a continuum, not a grid. Real systems mix components from several categories. An MES, for instance, carries parts of 3, 4 and 5 at once. And the category is only one scaling factor alongside GxP impact, complexity and novelty. Treating them as a validation checklist means the validation misses the risk. How widely a product is deployed plays its own role: the more users a standard function has, the more the supplier itself has a stake in hardening that standard. A defect there damages the supplier's reputation. Yet only what exists as assessable supplier work can feed into the evidence. Applied correctly, GAMP 5 makes validation efficient: verifiable requirements, risk-based decisions, leveraged supplier work, targeted testing, tools and automation. The effort lands where the risk is.
Frequent questions about GAMP 5 validation.
No. Validation itself is required by the regulations, EU GMP Annex 11 and 21 CFR Part 11. GAMP 5 is not a regulation but the industry's established methodology for producing that evidence on a risk basis. The FDA's CSA guidance, in its current revision (02/2026), names the Second Edition as one source of information on testing methods.
Risk-based: alongside scripted testing, the Second Edition explicitly encourages exploratory and unscripted testing as well as test automation, and lets electronic records from tools take the place of formal test documents. The measure is demonstrable coverage of the risk-relevant requirements, not the template.
Yes, explicitly since the Second Edition: it brings medical device industry regulation into scope and addresses manufacturers' production and QMS systems. The First Edition still excluded embedded medical device software.
No. Computer Software Assurance is how the FDA gives concrete form to risk-based testing for the production and QMS software of medical device manufacturers. GAMP 5 had already laid the methodological groundwork for that risk-based testing. The approach receives attention well beyond that formal scope. The two documents refer to each other in passing, not as rival approaches. The CSA guidance names GAMP 5 once in a footnote on testing methods, and GAMP 5 in turn refers to the FDA's earlier CSA work in its chapter on testing and in its glossary. GAMP 5 provides the life cycle, CSA sharpens the test strategy: not a replacement, but two perspectives on the same evidence. How closely the two strands are interwoven is clear from the people involved: members of the FDA Industry CSA team (FICSA) contributed to the GAMP Good Practice Guide "Testing GxP Systems" (3rd Edition), published in July 2026, and Frank Henrichmann (QFINITY) reviewed it for the ISPE Editorial Review Board. A dedicated chapter covers computerized test tools and assesses them against ISPE GAMP 5 (Second Edition).
The regulated company. It can involve suppliers and service providers and use their evidence, provided it has assessed them. Responsibility for the validated state stays with the operator, even when third parties deliver the work. GAMP 5 describes the roles of process owner and system owner for this. The business owns Intended Use and requirements, IT owns operation and the quality unit owns the independent review.
QFINITY on the GAMP 5 Second Edition Core Team.
As a long-standing, active member of the ISPE GAMP Community, QFINITY worked on the Core Team, contributing to the creation and review of the guide. That experience counts wherever the text leaves room for judgment: we know the intent behind the wording. The Core Team also included members of the FDA Industry CSA team (FICSA), so the CSA perspective fed straight into the Second Edition. Our assessment of the Second Edition appeared as an article in Pharm. Ind. How the methodology holds up in an engagement is shown by the S/4HANA conversion case study: validated, and taken live without local outages.
- Contributed to the creation and review of GAMP 5 Second Edition
- Frank Henrichmann: Chair of the GAMP Global Steering Committee
- Oliver Herrmann: GAMP Track Lead, ISPE Europe Annual Conference 2026
- Qualified ISPE GAMP trainers
- Contributed to the GPG "Enabling Innovation", which the Second Edition builds on
The guide the FDA itself points to.
QFINITY presented the Second Edition just months after its release, at the 15th official GAMP 5 conference in Mannheim (2022), and knows the guide's principles first-hand. The FDA itself has long drawn on the guide as a reference: in 2003, its Part 11 guidance named the GAMP 4 Guide as an industry reference for validation; since its 02/2026 revision, the CSA guidance has named the Second Edition for testing methods. Neither the draft nor the original final version contained that reference.
Last updated:
From the guide to everyday practice.
Let's talk about your validation.
We translate GAMP 5 Second Edition into a concrete validation strategy for you, from risk-based CSV and Computer Software Assurance to AI/ML, agile and cloud/SaaS. Your first consultation is free, about 30 minutes, directly with a contributor to the Core Team. You name the system and its category; we tell you what evidence we consider appropriate for it, and what you can do without.
Book an intro call
