The GAMP 5 categories in current use are Category 1 (infrastructure software, tools and IT services), Category 3 (standard, non-configured components), Category 4 (configured components) and Category 5 (custom applications and components). Category 2, which covered firmware in GAMP 4, was withdrawn when GAMP 5 appeared, so the numbering simply skips it. The category tells you what kind of software component you are dealing with and shapes its deliverables and supplier reliance. Category does not tell you how much validation the component needs: intended use and risk decide that.

The four GAMP 5 categories, with examples and typical approach

ISPE’s Second Edition of GAMP 5, published in July 2022, kept the same categories as the first edition. The table below gathers the definitions, common examples and the baseline lifecycle each category usually starts from.

Category	What it covers	Typical examples	Usual starting approach
1: Infrastructure software, tools and IT services	Software that builds, runs, secures or monitors the environment GxP applications run in	Operating systems, database engines, middleware, virtualisation and cloud infrastructure services	Record version and configuration, verify installation against approved procedures; the infrastructure is qualified, not validated
3: Non-configured products	Commercial software used as supplied, with only run-time parameters set	Standard instrument software, firmware-based applications, document viewers, basic data-acquisition tools	Abbreviated lifecycle: URS, risk-based supplier assessment, version recording, installation verification, risk-based testing against requirements
4: Configured products	Commercial packages whose behaviour is shaped to the business process without changing supplier code	LIMS, MES, ERP, eQMS, SCADA, DCS, EDMS	Controlled configuration specification, testing of the configuration and the process it supports, supplier audit where risk warrants it
5: Custom applications and components	Software written for a specific user or process need	Bespoke applications, custom modules, scripts, macros, interfaces, custom ladder logic	Full lifecycle: requirements, design, code review, unit and integration testing, traceability

Two details in that table catch people out. Category 1 is not validation-free: an operating system or database upgrade can invalidate the validation of the application above it if drivers, interfaces or security settings change, so version control and change management stay essential. And Category 3 does not switch off data integrity: a Category 3 balance or chromatography data system that generates GMP release data still needs audit trails, access control and backup in scope.

Category 5 has its own trap. A macro-driven spreadsheet used for calculations or batch tracking can be custom application software needing full validation if it supports GxP decisions, because the category follows customisation and ownership rather than how simple the tool looks.

Is instrument or COTS software Category 3 or Category 4?

The line between Category 3 and Category 4 is whether you shape the software’s behaviour to your process, and the actual product setup decides it rather than the product’s brochure. Category 3 software is still configured, but for its environment (run-time settings such as where records are stored), and that environment-only configuration is what separates it from Category 4. A configurable product used with only the supplier’s defaults may therefore sit in Category 3. Commercial applications typically move into Category 4 once workflows, roles, business rules or calculations are configured.

A 1997 definition of a configured product by Wingate, quoted in a 2021 Waters white paper, describes a stock program configured to a user’s application “by ‘filling in the blanks’” without altering the basic program; custom work means writing bespoke code. The same paper uses a pH meter to show how blurry this gets: it looks like Category 3, yet configuring its serial output from the available options introduces Category 4 elements.

Where configuration shades into customisation

The Category 4 to Category 5 boundary is crossed when executable logic is introduced or modified beyond the supplier’s standard behaviour: source code, scripts, macros, database procedures, custom algorithms, plug-ins or custom interface code. US Validation suggests deciding borderline cases with a short set of questions, recorded as a documented rationale:

• Is executable logic being created, or does the user define algorithms or decision logic?
• Does the result run within supported product functions, and does the supplier’s testing cover that mechanism?
• Do source-like artefacts need version control, and can the logic be independently reviewed?
• How will upgrades affect it, and who maintains it?

Low-code and no-code platforms sit across this boundary. Supplier-supported forms, workflow steps, approval rules and role assignments align with Category 4, while executable expressions, custom functions, connectors or complex decision logic bring in Category 5 elements, and the “low-code” label on its own does not make a component low risk. A categorisation goes wrong here when the platform is bought as a configured product while its riskiest logic is effectively custom code.

What happened to GAMP Category 2, and where does firmware go now?

Category 2 was withdrawn because firmware ranges from simple fixed code to something close to custom software, and the GAMP Forum argued it could be placed in the other categories according to its nature. The other categories were kept, partly because many companies had built their computerised system validation (CSV) policies on them.

Sources disagree on what that means in practice. GxPLearn describes firmware as generally subsumed into Category 3 and assessed as a non-configured product, whereas US Validation says embedded software should be categorised by how it is supplied and used: standard supplier-controlled firmware as part of a non-configured product, configurable equipment-control software with Category 4 elements, custom embedded logic with Category 5 elements, while supporting operating or communication software may include Category 1 components. Both positions agree on the common case (fixed firmware handled like a non-configured product); beyond that case, identify the component, understand how it is supplied and used, then apply the current categories, supplier evidence and risk rather than a legacy label. A validation plan that still assigns systems to Category 2 was written against an outdated guide.

There is a credible dissent from the laboratory side. R.D. McDowall, writing in Spectroscopy on the then-new GAMP 5 categories, proposed reinstating Category 2 for many laboratory instruments so that software classification lines up with the USP <1058> qualification approach for Group B instruments, while stressing that user-defined programs on such instruments still need separate validation and control. That is a proposed modification, not ISPE guidance, and the current Second Edition still uses four categories.

A GAMP category is not a risk rating

The categories are not GxP risk levels, and they do not decide whether a system is critical, how deeply it must be validated or whether a fixed IQ/OQ/PQ package applies. ISPE’s Pharmaceutical Engineering put it directly in January/February 2026: categorisation is a useful starting point for assessing a component’s risk of failure, “but it is not a validation checklist”.

The reason is visible in how GAMP 5 assesses risk. The Appendix M3 process combines severity of harm, probability of occurrence and likelihood of detection; severity comes from the business process and is unaffected by software category, while probability (and sometimes detection) can be influenced by how configured or customised the software is. Category alone therefore cannot set the risk priority, and basing the validation approach on category is inconsistent with a risk-based method.

ISPE frames the categories as positions on a continuum describing the likelihood of residual defects, which is why a very complex configured component can carry more defect risk than a very simple custom one. The useful division of labour is short enough to remember: category shapes the test methods, evidence sources and supplier reliance, while risk sets verification depth. Supplier capability can even reverse the naive ordering, since a Category 3 product from a poorly controlled supplier may need more independent assurance than a well-evidenced Category 4 product.

Validation depth follows intended use, impact on patient safety, product quality and data integrity, complexity and novelty, and the supplier assessment outcome. FDA’s Computer Software Assurance guidance, written for medical device production and quality system software, is also risk-based, scaling assurance effort to the risk to device safety and quality so the validation burden is no more than the risk needs.

None of this licenses an undocumented shortcut. A category drives the deliverables, so a category assigned without recorded reasoning leaves everything downstream unsupported, and an auditor who disputes it disputes the plan built on it.

Categorise the components, not the whole system

Computerised systems are generally combinations of components from different categories, and the Second Edition says categories 3 to 5 should be viewed as a continuum. US Validation’s LIMS example shows the spread: the operating system and database are Category 1, a document viewer is Category 3, the configured LIMS application is Category 4, and custom calculations, reports, scripts or interfaces are Category 5. One label for the whole LIMS would hide real differences in supplier responsibility, testing and lifecycle control.

The practical consequence is that each component carries the effort of its own category. 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 of the system does not. ISPE’s 2026 article goes further and says whole-system categorisation adds little value, except as an early first step to scale supplier assessment before component detail exists, or as an informal early view of likely deliverables.

Checklist: what a useful categorisation should establish

Drawing on US Validation’s list, a categorisation that earns its place answers these for each component:

1. Which software components exist, and how was each developed?
2. Which are configured, and which contain custom logic?
3. What does the supplier control, and what does the regulated organisation control?
4. What supplier evidence can be leveraged?
5. Which specifications are needed, and where is configuration control required?
6. Where is code review appropriate, and what must be verified directly?
7. How will each component be maintained, and when should the category be reassessed?

The last point matters over time. If configuration, use or regulatory impact changes, the category should be reassessed with traceable reasoning rather than left frozen.

What the GAMP 5 Second Edition changed, and what it left alone

The Second Edition kept the principles, framework and categories of the first edition and updated how they apply to service providers, newer development approaches and wider use of software tools and automation. The changes that touch categorisation concern how categories are used, not what they are:

• Critical thinking by knowledgeable subject matter experts, formalised in a dedicated appendix, with patient safety and product quality ahead of compliance for its own sake.
• Alignment with FDA Computer Software Assurance, shifting from validating everything to assuring what matters, with unscripted and exploratory testing accepted where appropriate.
• Agile and iterative development, with the V-model treated as one valid approach rather than the only one.
• New and updated appendices on AI/ML, blockchain, cloud computing and open-source software.
• Categories clarified as components on a continuum, with category as just one factor in scaling lifecycle activities.

The most common misreading treats critical thinking as licence to skip documentation. It means putting rigour where risk is real, with the reasoning still fully recorded. For how these ideas carry over to cloud platforms, SaaS and other modern stacks, see our piece on applying the GAMP software framework to modern systems.

Is AI/ML software automatically GAMP Category 5?

The Second Edition’s treatment of AI/ML is Appendix D11, which covers static and dynamic ML subsystems, a risk-based AI/ML lifecycle aligned with GAMP’s concept, project and operation phases, and the importance of data integrity. In July 2025 ISPE added a stand-alone GAMP Guide: Artificial Intelligence, designed to be used in parallel with GAMP 5 Second Edition.

GMP Insiders writes that AI and ML systems are generally treated as Category 5 because of their potential for autonomous decision-making. Against that, ISPE authors writing on ML in 2023 tie risk to intended use, including the level of human involvement and how significant the output is to the decision it informs. They also note that many aspects of the traditional lifecycle still fully apply to ML systems (user interface, reporting, security, access control, data integrity).

We read the two positions as compatible once you classify AI/ML software by component. A model your team trains, the training pipeline and the inference code are custom elements and tend to carry Category 5 expectations; the GPU servers, operating system and framework runtime underneath are infrastructure; and a vendor’s packaged AI feature used as supplied may look more like Category 3 or 4. The category then tells you which evidence you must produce yourselves, and the intended use (assistive or autonomous, informational or release-deciding) tells you how deep to go.

ML systems also change over time. ISPE authors write that operational ML subsystems give different outputs as they evolve, so verification must stay current through change management, version control and monitoring, and stochastic models need validation on a sufficiently large data set with performance measures robust to run-to-run variation. Code, data and models all need configuration management in validation-ready AI operations.

For teams building AI systems for regulated settings, see AI engineering for life sciences and healthcare.

FAQ

What does GAMP stand for in pharmaceuticals?

GAMP stands for Good Automated Manufacturing Practice, and the guide is published by ISPE, the International Society for Pharmaceutical Engineering. It is guidance rather than regulation: compliance is assessed against rules such as 21 CFR Part 11 or EU GMP Annex 11, and GAMP is a recognised method for showing it.

What types of software fall under GAMP Category 5?

Category 5 covers software designed and coded for specific business processes: internally or externally developed applications, custom process control applications, custom ladder logic, custom firmware and macro-driven spreadsheets. Custom scripts, modules and interfaces with GxP impact also count as Category 5 components.