For nearly two decades, GAMP 5 was the defining framework for how the pharmaceutical industry validated computerized systems. Published by the International Society for Pharmaceutical Engineering (ISPE) in 2008, the original guide shaped entire validation programs, defined software category hierarchies, and gave organizations a structured methodology for demonstrating that their systems were fit for intended use. Then, in 2022, ISPE released the Second Edition - and the update turned out to be far more than a cosmetic refresh.
The Second Edition reflects a fundamental shift in how ISPE and the broader regulatory community think about validation. Where the first edition was largely prescriptive - dictating a specific lifecycle, documentation set, and testing approach - the updated guide is built around principles. It asks practitioners to think critically, apply judgment proportionate to risk, and question whether each activity actually contributes to patient safety and product quality. That shift, subtle as it might sound in the abstract, has significant practical implications for how validation teams operate.
Background: GAMP 5 and ISPE's Role
ISPE - the International Society for Pharmaceutical Engineering - is a global nonprofit that develops technical guidance for the life sciences industry. Its GAMP Good Practice Guides have been influential since the early 1990s, providing the industry with consensus-based frameworks that regulators have broadly accepted as best practice, even when not formally mandated.
GAMP 5, first published in 2008, was titled "A Risk-Based Approach to Compliant GxP Computerized Systems." The core promise was straightforward: not all systems pose the same risk, and validation effort should scale accordingly. That principle was sound, and the guide was widely adopted. However, over time the industry's relationship with GAMP 5 became complicated. Organizations implemented GAMP 5 in ways that created enormous documentation burdens - not because the guide required it, but because over-interpretation had become the norm. The software category system, intended as a risk-scaling tool, evolved into a rigid classification exercise that sometimes drove more testing for lower-risk systems simply because of how a category was assigned.
By the time the FDA published its draft guidance on Computer Software Assurance in 2022, the gap between the stated intent of risk-based validation and its actual practice had become undeniable. ISPE's Second Edition landed in the same year, and the two documents should be read as complementary signals from the same direction of travel.
Critical Thinking as a Core Principle
The most significant conceptual change in the Second Edition is the elevation of critical thinking to a foundational principle. ISPE is explicit: the goal is not to generate documentation, it is to ensure that computerized systems are fit for their intended use and support patient safety, product quality, and data integrity. Every validation activity should be evaluated against that purpose.
This might sound obvious, but its implications are far-reaching. It challenges organizations to examine their validation protocols with a different question: "Does this test actually tell us something meaningful about fitness for use?" In many organizations, IQ/OQ/PQ scripts have been executed for years with marginal variation, driven by precedent rather than reasoning. The Second Edition calls that out directly.
Validation activities should focus on what matters - demonstrating that a system is fit for its intended use, not on generating documentation for its own sake. Critical thinking means asking whether each activity adds genuine value to that demonstration.
In practice, this means validation teams need to articulate the rationale for their approach, not just follow a template. It means user requirement specifications should genuinely capture what the system needs to do and why, rather than being a formatted list of features. It means test scripts should be designed to demonstrate the most critical behaviors, with proportionate effort applied to the most significant risks.
Alignment with CSA and Risk-Based Approaches
The Second Edition is explicitly aligned with the FDA's Computer Software Assurance initiative. CSA pushes back against the compliance-as-documentation culture that had taken hold in parts of the industry, and ISPE's updated guide moves in exactly the same direction.
The alignment goes beyond philosophy. Both documents emphasize that the goal is confidence in system performance, not a specific set of deliverables. Both push organizations toward critical thinking and away from scripted testing of low-risk, low-impact functionality. Both recognize that supplier testing and documentation can - and should - be leveraged rather than duplicated.
This convergence is significant. For organizations navigating both frameworks simultaneously, the Second Edition provides a structured methodology that is consistent with CSA principles. Organizations that have already begun a CSA transition will find the Second Edition reinforces and extends that work. For organizations that have not yet engaged with CSA, the Second Edition provides an accessible entry point into the same risk-based, evidence-focused thinking.
The key practical alignment is around the question of what testing an organization needs to perform versus what it can rely on from suppliers. Both CSA and the GAMP Second Edition encourage organizations to think carefully about this division, and both explicitly support leveraging supplier qualification data rather than treating every test as something that must be re-executed internally.
Updated Software Categories - What Changed
The original GAMP 5 software category system - Categories 1 through 5 - was one of its most recognized features and one of its most misapplied. Category 1 covered infrastructure software, Category 3 covered non-configured software products, Category 4 covered configured software, and Category 5 covered custom software. Category 2 had been retired before the 2008 edition but was still frequently referenced in older SOPs.
The Second Edition retains the category concept but significantly revises how categories should be used. The key change is de-emphasis of the category as a driver of validation effort. In the original framework, category assignment often became the primary input into test planning - Category 5 meant extensive custom testing, Category 4 meant configuration testing, and so on. The Second Edition repositions categories as a starting point for thinking about system complexity and supplier maturity, not as a formula for determining test scope.
Three categories remain in the revised framework:
- Infrastructure software (formerly Category 1) - operating systems, database platforms, and similar foundational components. Qualification focus remains on installation and configuration verification.
- Standard software products (formerly Categories 3 and 4) - commercially available applications that are either used as-is or configured to meet user needs. The merged treatment reflects the reality that the distinction between "non-configured" and "configured" was often artificial and drove disproportionate effort.
- Custom and bespoke applications (formerly Category 5) - systems developed specifically for the organization. This remains the highest-risk category from a validation standpoint, as there is no supplier development lifecycle to leverage.
The practical effect of collapsing the original Categories 3 and 4 is meaningful. Many LIMS, ERP, and MES platforms were classified as Category 4 and subject to extensive configuration verification testing. The Second Edition asks teams to apply risk-based judgment rather than defaulting to a category-driven test scope. A well-established commercial platform with a strong supplier quality system, deployed in a standard configuration, may require far less internal testing than the old Category 4 framework implied.
Emphasis on Supplier Assessment
One of the most actionable changes in the Second Edition is its expanded and sharpened focus on supplier assessment. ISPE is direct: understanding the quality of a supplier's development and testing practices is fundamental to determining how much additional testing an end-user organization needs to perform. A supplier with a robust Software Development Life Cycle (SDLC), mature quality management system, and thorough testing documentation provides a foundation that should reduce - not merely acknowledge - the organization's own testing burden.
This is a departure from how many organizations have historically approached supplier assessment. In practice, many supplier audits checked boxes without materially influencing the validation approach. The Second Edition calls for a genuine evaluation that feeds directly into test planning decisions. Questions to answer include: How rigorous is the supplier's software development process? Does the supplier maintain detailed test documentation? Is there evidence of systematic defect tracking and resolution? How does the supplier manage software change control?
Organizations with strong supplier relationships and access to supplier quality documentation are now in a position to justify significantly leaner internal testing programs. Those that have historically treated supplier assessment as a compliance formality will need to revisit both their assessment processes and the downstream effect on their validation strategies.
Leveraging Supplier Documentation and Testing
Closely connected to supplier assessment is the Second Edition's guidance on leveraging supplier-generated documentation and test evidence. The principle is straightforward: if a supplier has already tested something comprehensively and the evidence is available, having the end-user organization repeat the same tests adds cost and time without adding assurance.
The guide encourages organizations to review supplier test protocols and results as part of validation planning, and to identify specifically what additional testing is needed to address gaps - whether those gaps relate to user-specific configuration, site-specific infrastructure, or use cases not covered by the supplier's standard test suite.
In practice, this means validation teams need to engage more deeply with supplier quality teams and documentation early in the project lifecycle. It requires a shift in mindset from "what tests do we need to write?" to "what evidence exists and what gaps remain?" For organizations with mature supplier relationships and quality agreements that address documentation access, this approach is readily achievable. For others, building those relationships and agreements is a necessary investment.
Agile and Iterative Development within the GAMP Framework
The Second Edition also addresses a gap that had become increasingly visible: the original GAMP 5 framework was implicitly structured around a waterfall development model. User requirements were gathered, functional specifications were written, design specifications followed, and then testing executed in a sequential lifecycle. That model does not map well to agile and iterative development approaches, which have become standard practice for custom software development in many organizations.
The updated guide recognizes that iterative development is legitimate within a GxP context and provides guidance on how validation activities can be structured to align with sprint-based or iterative workflows. Key principles include maintaining traceability throughout iterative cycles, conducting appropriate review at sprint boundaries, and ensuring that the cumulative validation evidence remains coherent even as requirements evolve.
This is particularly relevant for organizations building custom manufacturing execution systems, laboratory information management systems, or other purpose-built applications. Teams that have been applying waterfall-structured validation processes to agile development projects have often found the combination awkward and have either slowed development to accommodate the documentation model or accumulated validation debt. The Second Edition provides a framework for doing both properly.
Practical Adoption Strategies
For validation leaders and quality managers considering how to respond to the Second Edition, the path forward involves both policy revision and cultural change. The two are connected but distinct.
On the policy side, the most immediate priorities are updating validation SOPs to reflect the revised category framework, revising supplier assessment procedures to ensure that assessment outputs materially influence test planning, and building templates that prompt practitioners to document the rationale for their approach rather than simply filling in prescribed fields.
On the cultural side, the more significant work is helping validation teams internalize the critical thinking orientation. This means training that goes beyond explaining what the Second Edition says to practicing the judgment it requires. Case studies, worked examples, and facilitated reviews of existing validation programs against the new principles are all effective approaches. Teams that have been executing scripts from templates for years will need support in developing the evaluative habits the Second Edition expects.
A phased adoption approach works well for most organizations. Start with new projects: apply the Second Edition framework from the outset and use those projects to build templates, refine supplier assessment processes, and develop internal expertise. Use the learnings to inform how existing validation programs are reviewed and updated over time. Avoid the trap of attempting a simultaneous overhaul of all validation documentation - that path leads to enormous effort with limited proportionate benefit.
Finally, engage early with regulatory affairs and quality leadership to align on how the updated approach will be presented in regulatory submissions and audit responses. The Second Edition's principles are well-aligned with current regulatory expectations, but teams need to be prepared to articulate their approach clearly and confidently when questioned.
GAMP 5's Second Edition is not a revolution - it is a maturation. It takes the risk-based principles that were always the stated foundation of pharmaceutical system validation and makes them genuinely central, pushing back against the documentation-heavy practices that had accumulated over time. Organizations that engage with it seriously will find that it supports not just compliance, but better, faster, more defensible validation programs.
Back to Insights