GAMP 5

GAMP 5 Software Categories Explained, With Examples

Updated 2026-11-07

GAMP 5 asks you to classify a system by how much of it is standard off-the-shelf software versus built or configured for you. That classification — the software category — then guides how much validation effort the system needs. Getting it right keeps effort proportionate: light where the software is standard and widely used, heavier where it is custom and unproven.

This article explains the categories with examples. For the wider picture, see what Computer System Validation is.

Why categories exist

The logic is simple: the more a piece of software has been written or configured specifically for you, the more of its behaviour is unique, untested by anyone else, and therefore your responsibility to specify and verify. A standard product used by thousands of sites already carries a lot of real-world and supplier testing; a bespoke application carries none until you do it.

The categories

GAMP 5 uses categories 1, 3, 4 and 5. (There is no category 2; it existed in older GAMP versions and was removed.)

Category 1 — Infrastructure software. The layer the application runs on: operating systems, databases, middleware, antivirus. Example: the Windows Server and SQL Server a laboratory application sits on. These are managed and qualified as infrastructure rather than validated as applications in their own right.

Category 3 — Non-configured products. Commercial software used as supplied, with default configuration only — you do not change its business logic. Example: a simple instrument readout package used exactly as it ships. Validation leans heavily on the supplier and on verifying your intended use, not on re-testing standard functionality.

Category 4 — Configured products. Commercial software you configure to your process — setting up workflows, user roles, calculations, reports — without altering the underlying code. Examples: a LIMS, a configured chromatography data system, an ERP module. Most business systems in a regulated company are Category 4. The configuration is yours, so the configuration is what you specify and test.

Category 5 — Custom (bespoke) software. Software, or parts of it, written specifically for you: custom applications, bespoke modules, macros and scripts. Example: a custom interface written to move data between two systems. Nobody else has tested it, so it carries the most validation effort and the fullest lifecycle.

A grey area worth knowing

Real systems often span categories. A Category 4 LIMS may contain a Category 5 custom script. The practical approach is to recognise that the custom parts carry Category 5 effort even when the system as a whole is Category 4 — you focus the heavier testing on the bespoke pieces.

How the category drives effort

The category is not a bureaucratic label; it changes what you do:

  • Higher category (toward 5) → more of the behaviour is yours, so you specify it in more detail and test it more thoroughly, including the awkward boundary and negative cases.
  • Lower category (toward 3) → more of the behaviour is standard and supplier-tested, so you can justifiably lean on supplier documentation and concentrate your own effort on configuration and intended use.

This is the risk-based, scalable principle at the heart of GAMP 5: effort follows novelty and risk, not a fixed checklist applied identically to everything. See risk-based validation for how that plays out in practice.

Leveraging the supplier

For Category 3 and 4 systems especially, the supplier has often already tested standard functionality. GAMP 5 (second edition) actively encourages leveraging that work where it is reliable and assessed — through a supplier assessment or audit — rather than blindly re-testing what the vendor has already proven. The judgement of what you can rely on, and the documentation of that judgement, is itself part of the work.

Common mistakes

  • Treating everything as Category 5. Over-categorising means over-testing — effort wasted on standard functionality while real risks get the same generic treatment.
  • Ignoring embedded custom code. A macro or script inside a configured system is still custom; it deserves Category 5 attention.
  • Confusing “configured” with “customised”. Configuration uses the product’s own settings; customisation changes its code. The line matters, because it moves you from Category 4 to Category 5.

Next