GAMP 5 second edition: what changed for computerised system validation

The first edition made risk-based validation respectable. The second makes it uncomfortable, usefully so: it asks teams to justify their effort rather than produce it, and that takes away the comfort of a fat binder.

Almost four years after it appeared in July 2022, the second edition of GAMP 5 is still misread in two ways: as a regulation, and as a new way of sorting software. It is neither. It keeps the four software categories of the 2008 edition and changes how the work is argued.

Below are the changes at a glance, then the foundations every project still starts from: what GAMP is, what a computerised system is made of, and how the software and hardware categories scale the effort. The last sections cover the shifts we see on projects and where artificial intelligence fits.

GAMP is guidance, not regulation

GAMP stands for Good Automated Manufacturing Practice. It is published by ISPE, the International Society for Pharmaceutical Engineering, which describes it as a “cost-effective framework of good practice” for computerised systems that are fit for intended use and “compliant with applicable regulations”. Industry writes it for industry. GAMP 4 (2001) gave way to GAMP 5 in 2008, and the second edition of GAMP 5 came out in July 2022.

The requirements themselves sit in the regulations. In Europe that means Annex 11 of the EU guide to good manufacturing practice (GMP); in the United States, 21 CFR Part 11 and the predicate rules. The Pharmaceutical Inspection Co-operation Scheme (PIC/S) guide on computerised systems, PI 011-3 (2007), points to the GAMP Guide for detailed guidance and says that its own advice “is not mandatory for industry” (§3.2). In an inspection the question is how you met Annex 11 or Part 11. GAMP is a recognised way to structure your answer.

Two habits follow. Cite the regulation for what must be achieved, and GAMP for how you chose to achieve it. And check the dates before writing that GAMP “conforms” to a text: GAMP 5 (2008) predates the current Annex 11 (2011), and PI 011-3 still lists the five software categories of GAMP 4 (§15.1). GAMP is written to be consistent with these texts and builds on the quality risk management of ICH Q9 (2005, revised as Q9(R1) in 2023). None of them makes it mandatory.

ISPE also publishes GAMP Good Practice Guides, a separate series that goes deeper on one subject. The laboratory guide is older than GAMP 5: it appeared in 2005 and was rewritten in 2012 as A Risk-Based Approach to GxP Compliant Laboratory Computerized Systems. The guide on IT infrastructure control and compliance is in its second edition (2017).

A computerised system is more than the computer

Annex 11 defines a computerised system as “a set of software and hardware components which together fulfill certain functionalities” (Principle). The PIC/S guide draws the boundary wider: “A computerised system is composed of the computer system and the controlled function or process” (§6.2). GAMP 5 uses the same terms: hardware, software and network components, with the functions they control and the documentation that goes with them.

On a project, that boundary has three consequences.

• Validation covers the whole system. An application run by untrained people, or without an approved procedure, is not a validated system, whatever its test reports say. Procedures and training records are part of the evidence.
• The infrastructure underneath is qualified. Annex 11 says it in one line: “The application should be validated; IT infrastructure should be qualified.” Servers, operating systems and networks are shown to be installed as specified and kept under control; the application is shown to do its job in the process.
• The environment is outside the boundary, not outside the risk. Other networked systems, shared media, people and equipment around the system are not validated with it. Its interfaces to them are, and a change on the far side of an interface should go through change control as well.

Firmware sits with the hardware in this model. It is still software, and GAMP no longer gives it a category of its own.

Software categories: a scale for the effort, not a verdict

GAMP sorts software by how much of it is standard and how much is configured or written for you. The category never decides whether a system is validated; its GxP impact (on patient safety, product quality and data integrity) decides that. What the category helps with is how much evidence you produce yourself, from the user requirements specification (URS) to the tests, and how much you can take from the supplier.

GAMP 4 had five categories, still listed in the PIC/S guide: operating system, firmware, standard software packages, configurable software packages and custom (bespoke) software. GAMP 5 refined them in 2008 and dropped category 2, firmware; ISPE’s own summary of the change says that category 2 “no longer exists”. Firmware is now classified like any other software, by what is done with it. The numbering kept its gap, so the categories are 1, 3, 4 and 5.

Spreadsheets deserve their own paragraph, because they cause more arguments in validation meetings than most servers. The office package is infrastructure. What someone builds with it is classified by what it does: a template with simple formulas, a workbook with statistical functions and a workbook with macros sit at three different points on the scale. Some site procedures add a threshold such as “more than five calculation steps”. That can be a sensible local rule, but it is the site’s rule, not GAMP’s. The second edition adds data integrity considerations for spreadsheets and other end-user applications.

The second edition keeps the four categories but reads them differently. In ISPE’s summary of the edition, the categories were updated to reflect that “computerized systems are generally made up of a combination of components from different categories”, and categories 3 to 5 “should be viewed as a continuum”. The software category is “just one factor”: life-cycle activities are scaled on the GxP impact, the complexity and the novelty of the system.

Take an illustrative supervisory control and data acquisition (SCADA) system on a production line. It runs on servers, drives PLCs and exchanges data with the manufacturing execution system (MES).

In practice, label the components rather than the system. “It is a category 4 system” hides the custom interface, which needs the most evidence, and the category 1 layer nobody put under change control. A component list, with category, GxP impact and named source of evidence on each line, takes an afternoon to write and is hard to argue with.

Hardware: standard or custom-built

Appendix M4 also sorts hardware, into two categories. Most of the hardware on a site is standard: it has to be identified and checked, not designed. The rare custom-built item needs a specification and tests of its own.

For the servers and networks under the applications, this is what Annex 11 means by a qualified infrastructure. ISPE’s guide on IT infrastructure control and compliance covers it in depth, cloud platforms included.

Three shifts we see in practice

The biggest change in the second edition does not show in the tables. It shows in how a project argues for its effort.

• Critical thinking is the deliverable. A short rationale explaining why a test is not needed carries more weight than a test nobody read.
• Supplier assessment does real work. The guide explicitly encourages leveraging a competent supplier’s testing, which makes it worth assessing that supplier properly, once, and reusing the result.
• Data integrity is a design input. Teams used to look it up after an observation. Now it is a question answered while the system is being specified, and the second edition links it to ISPE’s data integrity guidance.

The guide also explores computer software assurance (CSA), the approach promoted by the US Food and Drug Administration’s device centre (CDRH): effort and records follow the risk of each software function. The FDA guidance became final in September 2025 for production and quality system software and was reissued in February 2026. How the same logic plays out in a test plan is covered in how deep a test should go.

Artificial intelligence: from an appendix to a guide

The second edition added appendix D11 on artificial intelligence and machine learning (AI/ML), which gives a basic understanding of the technologies and guidance on compliance and fitness for use.

Three years later the subject had a guide of its own: ISPE published the GAMP Guide: Artificial Intelligence in July 2025. That same month the European Commission put a draft Annex 22 on artificial intelligence out for consultation, together with a revised Annex 11. The draft restricts critical GMP uses to static, deterministic models and asks for acceptance criteria “at least as high as the performance of the process it replaces” (§4.3). At the time of writing it is still a draft.

For a machine-learning model, the specification becomes a set of performance metrics agreed before testing (for a visual inspection model, the rate of missed defects and of false rejects), measured on test data kept apart from training. That is what the often-repeated line about key performance indicators acting as the model’s acceptance criteria means on the ground. What such a model must prove, and who signs for it, is set out in AI in the pharmaceutical industry.

What it means for your next project

Expect less paper and more argument. The URS gets shorter and sharper, the traceability matrix stops being a formality, and the test set shrinks around what actually carries risk. Teams used to producing volume often find this harder. The second edition asks you to defend judgement, and coverage is no longer somewhere to hide.

Start from the model and the component list: draw the boundary of the computerised system, give each component its category and GxP impact, and write down which evidence comes from the supplier. The rest follows: a URS that drives the qualification, then what the supplier’s tests can prove for you.

Validation effort should be proportional to risk. Everyone has agreed with that sentence for fifteen years. The second edition makes you show your reasoning.

References

• ISPE, *GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems*, Second Edition (July 2022): appendices M4, M11, M12 and D8 to D11.
• S. Wyn and C. Clark, “What You Need to Know About GAMP 5 Guide, 2nd Edition”, Pharmaceutical Engineering (ISPE), January–February 2023.
• PIC/S, PI 011-3, Good Practices for Computerised Systems in Regulated “GxP” Environments (25 September 2007), §3.2, §6.2 and §15.1.
• EudraLex Volume 4, EU GMP Annex 11, Computerised Systems (2011), Principle.
• European Commission, draft Annex 22, Artificial Intelligence, consultation from 7 July to 7 October 2025, §4.3.
• US FDA, *Computer Software Assurance for Production and Quality Management System Software* (February 2026; supersedes the final guidance of 24 September 2025).