GAMP 5 2nd Edition:
What Changed and
What It Means

Why the 2nd Edition Matters

GAMP 5 was first published in 2008. For fourteen years it was the reference methodology for pharmaceutical computerised system validation. Then, in 2022, ISPE published the 2nd Edition — a comprehensive revision that brought the guidance in line with how the industry and its regulators had evolved.

The changes are not superficial. The 2nd Edition reflects a genuine shift in regulatory thinking: away from document production as a proxy for quality, and toward critical thinking, proportionate effort, and demonstrable understanding of what actually matters for patient safety.

If you are using validation templates or writing validation plans that reference "GAMP 5" without specifying the edition, you should be explicit: the current edition is the 2nd Edition (2022). The QLean framework is built entirely on the 2nd edition — and every Validation Plan template states this explicitly in Section 3.1.

Change 1 — Critical Thinking Replaces Prescriptive Checklists

The most significant philosophical shift in the 2nd Edition is the explicit emphasis on critical thinking. The 1st Edition could be — and often was — applied mechanically: produce these documents, fill in these sections, get these signatures. The result was validation packages that were technically compliant but intellectually shallow.

The 2nd Edition pushes back against this. It explicitly states that validation effort should be based on understanding and judgement — not on completing a standard checklist regardless of the system's actual risk profile. The guidance calls for engineers and validation specialists who can think about what matters, not just document what they're told to document.

In practice, this means your Validation Plan methodology section should not just cite GAMP 5 — it should explain how critical thinking has been applied: why the category was chosen, why testing depth is set at the level it is, what risks are considered high priority and why.

Change 2 — Alignment with CSA Thinking

By 2022, the FDA had been promoting Computer Software Assurance (CSA) as the successor to traditional Computer System Validation (CSV) for several years. CSA shifts the focus from documentation production to testing that is meaningful and risk-based — and the 2nd Edition of GAMP 5 explicitly aligns with this direction.

The practical implication: you no longer need to produce the same volume of test evidence for every function regardless of its GMP criticality. A status display on an HMI that shows non-critical process data does not require the same depth of test documentation as a dosing interlock or an electronic batch record function. The 2nd Edition gives you the framework to make this distinction formally — and defend it during an inspection.

This is a meaningful reduction in documentation burden for well-run projects. But it requires the work upfront: a credible risk assessment that explicitly justifies reduced testing for low-risk functions. If the risk assessment is weak, you lose the justification for proportionate effort. This is covered in detail in our article on CSV vs CSA.

Change 3 — Formal Guidance on Supplier Documentation Leverage

The 1st Edition acknowledged that supplier documentation could be used as part of the validation evidence — but the 2nd Edition makes this a formal, structured part of the methodology. The guidance explicitly states that replicating tests already performed by a qualified supplier is wasteful and adds no quality value.

What this means practically: if your SCADA vendor has performed rigorous factory testing of their platform and you have reviewed and accepted that documentation, you can reference it in your FAT and OQ protocols rather than repeating the same tests. This must be planned — documented in your Validation Plan in the supplier documentation section — not discovered retroactively and retrofitted as justification after the fact.

The QLean Validation Plan template (VP-SYS-001) includes a dedicated Section 7 for supplier and vendor documentation, with guidance on how to formally record which vendor evidence is being leveraged and the criteria against which it has been reviewed. This is a direct reflection of the 2nd Edition requirement.

Change 4 — Explicit Integration of ICH Q9(R1)

Risk management in the 1st Edition was broadly aligned with ICH Q9 principles, but the 2nd Edition makes this integration formal and explicit. The risk methodology used for validation must follow ICH Q9(R1) — the harmonised international standard for quality risk management in pharmaceutical contexts.

ICH Q9(R1) is important for one specific reason: it replaces ISO 14971 as the risk management reference for pharmaceutical applications. ISO 14971 applies to medical devices. If your risk assessment methodology references ISO 14971 in a pharmaceutical validation context, that is a red flag for any competent QA reviewer — it suggests the document was adapted from a medical device project without understanding the regulatory context.

The correct reference chain for pharma GMP validation is: ICH Q9(R1) for the risk management methodology, with GAMP 5 2nd Edition providing the application framework for computerised systems specifically. This is how the QLean Risk Management Plan (RMP-SYS-001) is structured.

Change 5 — Category Framework Refined

The GAMP 5 category system (Categories 1–5) was retained in the 2nd Edition, but the guidance around its application was refined in two meaningful ways.

First, the 2nd Edition reinforces that category classification should be applied at the component level, not the system level. A PLC/SCADA system is not "a Category 4 system" — it is a system containing components of different categories: Category 5 bespoke PLC application logic, Category 4 configured SCADA application, Category 1 operating system and infrastructure. Each component is classified independently, and validation requirements apply at that component level.

Second, the guidance strengthens the justification requirement. You cannot simply state a category — you must document the rationale. For a mixed-category system, the Validation Plan must clearly state the category for each software component and the reasoning behind each classification.

The V-Model Lifecycle — What Stayed the Same

One thing that did not change in the 2nd Edition is the V-model lifecycle as the structural framework for validation. The left side of the V (specification and design) mapping to the right side (qualification and testing) remains the backbone of the GAMP 5 approach.

What changed is the emphasis: the 2nd Edition makes it clear that the V-model is not just a document production sequence — it is a traceability architecture. Every qualification test case must traceable back to a specific requirement or design specification. Testing in isolation, without traceability, does not constitute validation evidence under the 2nd Edition.

This is what a well-structured V-model looks like in practice — and why the traceability matrix is not optional documentation.

What This Means for Your Documentation Today

If you are writing validation documentation on a live project, the 2nd Edition has three concrete implications:

• State the edition explicitly. Your Validation Plan, Risk Management Plan, and any methodology statement must reference GAMP 5, 2nd Edition (2022) — not just "GAMP 5".
• Justify your testing depth. The 2nd Edition does not accept "we tested everything because GAMP 5 says so." It requires evidence that testing depth was set proportionate to risk. Your risk assessment drives your OQ test coverage — document the connection explicitly.
• Plan your supplier documentation strategy before FAT. If you intend to leverage vendor test reports, that decision belongs in the VP — specifically in the supplier documentation section. A QA auditor finding undocumented supplier leverage during an inspection is a finding, not a compliment.