GAMP 5: Software Categories, the V-Model and the Second Edition

Introduction

GAMP 5 is the internationally recognised approach to validating computerised systems in regulated industries. GAMP stands for Good Automated Manufacturing Practice, and the guide is published by ISPE, the International Society for Pharmaceutical Engineering, which established the framework in 1991.

Two things about it are frequently misunderstood, and both matter before any validation work starts. GAMP is a guideline, not a regulation: nobody is inspected against GAMP, they are inspected against 21 CFR Part 11, Annex 11 or ISO 13485, and GAMP is the recognised method for demonstrating compliance with those. And the current text is the Second Edition, published in July 2022 — the first major revision in fourteen years, and one that changed the expected approach substantially. A validation strategy written against the 2008 edition is not wrong, but it is doing more documentation than the current guidance asks for.

This guide covers the five principles, the software categories that determine how much validation a system needs, the V-model and where the Second Edition loosened it, and what changed in 2022. For medical device manufacturers there is a specific question underneath all of it — which software in your organisation actually falls under GAMP rather than under IEC 62304 — and that is addressed directly.

Table of Contents

• Which software GAMP actually applies to
• The five principles
• The software categories, and what each one requires
• The V-model, and how far it scales
• Science-based quality risk management in four steps
• Leveraging supplier involvement
• The lifecycle inside the quality management system
• What changed in the Second Edition
• GAMP 5 for medical device manufacturers
• Where validation projects go wrong
• Frequently asked questions
• Conclusions

Which software GAMP actually applies to

This is the first question and it is answered wrongly more often than any other, particularly in medical device companies. GAMP covers computerised systems that support regulated activities — the software you use to run the business, not the software you sell.

ISO 13485 requires the validation of software used in the quality system, in production and in monitoring, and it does not say how. GAMP 5 is the recognised answer to the “how”. This is the reason a medical device manufacturer needs GAMP even though GAMP was written for pharmaceutical manufacturing — and it is why validating an eQMS to IEC 62304 is a category error that produces a large amount of documentation nobody asked for.

The five principles

GAMP 5 rests on five principles, and they are best read as a sequence rather than a list: each one constrains the next.

The order matters. Principle 1 makes principle 4 possible, because you cannot risk-assess a system whose critical functions you have not identified. Principle 4 then determines principle 3, because risk is what the scaling is scaled to. And principle 5 only reduces work if principle 1 has already told you what the supplier’s evidence needs to cover.

The software categories, and what each one requires

The software categories are the mechanism by which GAMP scales effort, and they are the part of the guide most people are looking for. The Second Edition retains the same categories as the first.

Category 2 no longer exists. It covered firmware in earlier versions and was withdrawn in GAMP 5, because firmware is better handled as one of the other categories according to whether it is configured. A validation plan that still assigns systems to Category 2 was written against a guide that is two revisions out of date.

Two practical points about categorisation. The first is that a single system can contain items in different categories: a Category 4 eQMS with a custom-written report generator contains a Category 5 component, and the report generator carries the Category 5 effort while the rest does not. The second is that categorisation is a judgement that must be documented with its reasoning, because the entire validation effort is derived from it. An auditor who disagrees with the category disagrees with everything downstream of it.

The V-model, and how far it scales

The V-model pairs each specification activity on the descending side with a corresponding verification activity on the ascending side. It is the structure most validation packages are built on, and its value is that it makes traceability visible: every requirement has a test, and every test traces to a requirement.

What the Second Edition changed is not the model but its status. The 2022 revision states plainly that validation can follow agile development rather than only a linear model, and it added guidance for iterative approaches where a fully formed user requirements specification does not exist at the start. For a SaaS eQMS that receives vendor updates every six weeks, a validation approach that assumes a single specification frozen before build is not describing the system it is validating.

Three parameters determine how deep the V goes, and they should be recorded before the plan is written:

• Impact on patient safety, product quality and data integrity. The risk assessment identifies which functions carry it, and validation concentrates there.
• System complexity and novelty. Intricate functionality demands more; novel technology demands more still, because there is no track record to lean on.
• Supplier assessment outcome. A supplier with demonstrable quality practices reduces what you have to repeat. Gaps in their evidence increase it.

Science-based quality risk management in four steps

Validation effort concentrates on the functions that matter, and identifying which those are is a risk exercise, not an inventory exercise. The method runs in four steps.

1. Identify the critical functions — those that directly affect patient safety, product quality or data integrity. Everything else is tested, but not to the same depth.
2. Assess the risk for each critical function, considering system behaviour, data handling and user interaction, and what the consequence of failure would be.
3. Implement controls and verify them. Verification is the part that gets skipped: a control listed in the risk assessment and never tested is not a control.
4. Review and monitor across the lifecycle. New risks arrive with every upgrade, and controls that were effective at go-live may not survive a configuration change.

The method is the same one ISO 14971 uses for device risk, applied to a different object. Medical device manufacturers already run this process, and duplicating it in a parallel software-only framework produces two risk systems that disagree with each other.

Leveraging supplier involvement

Responsibility for validation rests with the organisation using the system, and it does not transfer. What the supplier’s documentation can do is remove duplication: test protocols and results already produced by a competent supplier are evidence you do not have to generate again.

The condition attached to that is the supplier assessment. Using supplier evidence without having assessed whether the supplier’s development and testing practices justify relying on it is not leveraging supplier involvement — it is accepting a claim. And a supplier assessment that consists of a completed questionnaire held on file, never reviewed and never repeated, is the same thing with more paperwork.

The assessment mechanics are the same as any other critical supplier evaluation: defined criteria, a documented decision, a monitoring arrangement and a re-evaluation trigger. Our guide to supplier qualification under ISO 13485 covers the criteria and the records, and a software supplier is a critical supplier whenever the software touches a critical function.

The lifecycle inside the quality management system

GAMP asks that validation be governed by a documented procedure inside the quality system rather than run as a project. That procedure covers the whole life of the system: concept, where requirements are defined; project, where it is specified, built and tested; operation, which is the longest phase by far; and retirement, where data are migrated or archived and the decommissioning risks are assessed.

The operational phase is the one that fails. Validation packages are produced with care at go-live and then the system runs for eight years, receiving patches, upgrades, configuration changes and new users, with no periodic review and no re-validation trigger defined. The procedure has to state what kind of change requires what kind of re-verification, because that decision made ad hoc under time pressure is always made the same way.

Retirement is the phase nobody writes a procedure for, and it carries a specific regulatory risk: records subject to retention obligations sitting inside a system nobody can log into any more. The migration or archiving plan belongs in the validation procedure, not in the decommissioning ticket.

What changed in the Second Edition

ISPE released GAMP 5 Second Edition in July 2022, the first major revision since the original 2008 guide. It keeps the same risk-based framework and the same five software categories — which is why the categories above are unchanged — but it updates the guidance substantially for how software is actually built and hosted now.

The through-line is a change of emphasis from compliance to fitness for intended use. The stated objective was to update the guidance to contemporary practice and specifically to eliminate burdensome approaches, and organisations that adopted the Second Edition properly report doing less documentation, not more.

The most common misreading is treating critical thinking as licence to skip documentation. It means allocating rigour to where risk is real, with the reasoning still fully documented. A validation file that got smaller because someone decided the system was low risk, without recording why, is worse than the over-documented file it replaced.

ISPE has continued to extend the framework through supplementary guides rather than a new edition — a standalone GAMP Guide on Artificial Intelligence was published in July 2025, covering the lifecycle of AI-enabled systems including data governance and model risk management. For medical device manufacturers whose devices contain models, that guide sits alongside rather than instead of the device-side obligations covered in our guide to AI medical device regulation.

GAMP 5 for medical device manufacturers

GAMP was written for pharmaceutical manufacturing and is used by medical device manufacturers because ISO 13485 requires software validation without specifying a method. Three things follow from that, and they are the ones device companies get wrong.

The scope is narrower than people assume. GAMP covers the systems that support the business. The device software is IEC 62304’s territory, and the two frameworks have different objects, different deliverables and different auditors’ expectations. A company that validates its eQMS to IEC 62304 has produced a software development plan and a software architecture for a product it bought.

The risk framework should be one framework, not two. The functional risk assessment GAMP asks for and the risk management process ISO 14971 requires use the same logic. Running them as separate systems produces two hazard lists, and the one that gets updated is whichever the auditor asked about last.

It surfaces in audits under production and purchasing, not under a heading of its own. In an MDSAP audit the validation of production and quality system software is sampled inside the production and service provision chapter, and the software supplier assessment inside purchasing. There is no chapter called computer system validation, which is why the evidence has to be reachable from the process documentation rather than filed in a validation folder of its own.

Where validation projects go wrong

Categorisation without a rationale. The category drives the entire effort, so a category assigned without recorded reasoning leaves everything downstream unsupported. This is the equivalent of an unjustified safety classification in IEC 62304, and it produces the same finding.

A risk assessment written to justify the test plan. Visible from the dates on the two documents, and it inverts the logic of the entire framework.

Supplier documentation accepted without assessment. The certificate is filed, the supplier’s testing is relied upon, and no one has established whether the supplier’s practices justify the reliance.

Validation that stops at go-live. No periodic review, no defined re-validation trigger, and a system that has drifted a long way from the one that was validated.

Everything validated to the same depth. The most expensive error, because it looks like diligence. It usually means principle 1 was never applied and nobody could say which functions were critical.

Working to the 2008 edition. Four years of guidance updates on cloud, agile, critical thinking and CSA, applied to systems that are all three of those things. The documentation burden is higher than the current guidance asks for, and the approach does not fit the software.

Frequently asked questions

What is GAMP 5?

GAMP 5 is a risk-based framework for the specification, implementation, operation and validation of computerised systems used in regulated industries. GAMP stands for Good Automated Manufacturing Practice, and the guide is published by ISPE, the International Society for Pharmaceutical Engineering. It is a guideline rather than a regulation: compliance is assessed against 21 CFR Part 11, EU GMP Annex 11 or ISO 13485, and GAMP is the recognised method for demonstrating it.

What are the GAMP 5 software categories?

Four categories are in use. Category 1 is infrastructure software such as operating systems, databases and IT tools, which is qualified rather than validated. Category 3 is non-configured off-the-shelf software used as supplied. Category 4 is configured products such as eQMS, ERP and LIMS. Category 5 is custom applications and bespoke code, which carry the full lifecycle. Category 2, which covered firmware, was withdrawn in GAMP 5.

What changed in the GAMP 5 Second Edition?

The Second Edition, published by ISPE in July 2022, keeps the same risk-based framework and the same software categories, but formalises critical thinking by subject matter experts in a dedicated appendix, aligns with the FDA’s Computer Software Assurance approach, explicitly supports agile and iterative development, and adds guidance for cloud services, IT infrastructure, AI and machine learning, blockchain and open-source software.

Is GAMP 5 mandatory?

No. GAMP is a guideline published by an industry association, not a regulation, and no authority inspects against it directly. It is the internationally recognised method for meeting the software validation requirements that regulations do impose, which in practice means departing from it requires a justification.

Does GAMP 5 apply to medical device software?

Not to software that is a medical device or embedded in one — that falls under IEC 62304. GAMP applies to the computerised systems a manufacturer uses to run its business: the eQMS, ERP, LIMS, and software used in production or in monitoring and measurement. ISO 13485 requires those to be validated for their intended use and does not specify a method; GAMP 5 is the recognised method.

What is the V-model in GAMP 5?

The V-model pairs each specification activity with a corresponding verification activity: user requirements with performance qualification, functional specification with operational qualification, design specification with installation qualification. Its value is traceability. The Second Edition confirms it is one valid approach rather than the only one, and provides guidance for iterative lifecycles where a complete specification does not exist before development begins.

What is critical thinking in GAMP 5?

Critical thinking is the use of documented judgement by knowledgeable subject matter experts to determine the appropriate validation strategy for a given system, rather than applying a uniform prescriptive approach. It was formalised in the Second Edition and aligns with the FDA’s Computer Software Assurance approach. It means allocating rigour where risk is real, not reducing documentation across the board.

How does GAMP 5 relate to 21 CFR Part 11?

Part 11 sets requirements for electronic records and electronic signatures — audit trails, access controls, record integrity. GAMP 5 is the framework used to demonstrate that a system meets them. Part 11 states what the system must do; GAMP describes how to establish, and evidence, that it does.

Conclusions

GAMP 5 is a method for spending validation effort where it changes the outcome. The framework is built so that understanding the system determines the risk assessment, the risk assessment determines the scaling, and the category determines the deliverables — and it fails whenever that chain is run backwards, which is what a risk assessment written to justify an existing test plan does.

Two things are worth acting on. Confirm which edition your procedure was written against: if it predates July 2022 it is asking for a documentation burden the current guidance has explicitly moved away from, and it has nothing to say about the cloud services and agile-delivered software most quality systems now run on. And check the scope boundary, because validating business software to IEC 62304, or device software to GAMP, produces a large volume of documentation that answers the wrong question.

For medical device manufacturers the requirement itself sits in ISO 13485 — clause 4.1.6 for quality system software, 7.5.6 for production, 7.6 for monitoring and measurement. The ISO 13485 Documentation Kit covers the procedures those clauses require, into which the GAMP method fits.

Related articles

• ISO 13485:2016 — The Complete Guide to Medical Device Quality Management
• IEC 62304: Safety Classes, Processes and Edition 2 Status
• ISO 14971 Risk Management for Medical Devices
• ISO 13485 Supplier Management and Qualification
• MDSAP Audits: Process Chapters, Grading and Preparation
• AI Medical Device Regulation: EU MDR, FDA and ISO 42001