Category 3 / 4 vs Category 5
How much validation a computerized system needs depends on how custom it is.
What a comparison is not
A comparison is SPEQ’s reading of how two published documents differ. Neither is the right answer, it is not a determination of which applies to you, and neither is summarised in a way that replaces reading it.
GAMP 5 classifies software to scale validation effort. Category 3 is non-configured (used out of the box), Category 4 is configured (set up to your process without code change), and Category 5 is custom/bespoke code written for you. The higher the category, the more the risk sits with you rather than the vendor — and the more validation rigour is expected.
| ASPECT | CATEGORY 3 / 4 | CATEGORY 5 |
|---|---|---|
| What it is | Cat 3: used as supplied · Cat 4: configured to your process | Cat 5: custom-coded for you |
| Where the risk sits | Largely with the vendor (esp. Cat 3) | Largely with you — nobody else has tested this code |
| Supplier leverage | High — leverage vendor testing, focus on your config (Cat 4) | Low — custom code must be verified in full |
| Typical effort | Lower; verify intended use and configuration | Higher; design, code review, and thorough testing |
| Examples | Cat 3: firmware, off-the-shelf tools · Cat 4: configured LIMS/MES/ERP | Cat 5: bespoke interfaces, custom modules, tailor-made apps |
| Category 1 | Infrastructure software (OS, databases) — managed, not "validated" as apps | — |
Categories 3 and 4 let you lean on the supplier: for Category 3 verify the system does what you need out of the box; for Category 4 focus validation on your configuration and its impact, leveraging vendor evidence for the base product.
Category 5 (custom code) puts the assurance burden on you — nobody else has tested this software — so expect design documentation, code review, and thorough, risk-based testing of the bespoke functionality.
The category sets the effort: the more bespoke the software, the more of the assurance is yours to provide. The common mistake is validating a Category 4 configured system as if it were Category 5 (re-testing vendor code) or a Category 5 custom app as if it were Category 4 (under-testing bespoke logic). Categorise first, then size the effort — and remember critical thinking (CSA) applies within every category.
Category 3 / 4 vs Category 5: frequently asked questions
Common questions on how Category 3 / 4 and Category 5 differ and when each applies.
What are the GAMP software categories?
GAMP 5 uses Category 1 (infrastructure software), Category 3 (non-configured products used as supplied), Category 4 (configured products), and Category 5 (custom/bespoke applications). Category 2 (firmware) was retired in GAMP 5. The category guides how much validation effort is appropriate.
Why does the category change the validation effort?
Because it reflects where the risk and the untested novelty sit. Off-the-shelf and configured products carry vendor testing you can leverage; custom code has been tested by no one but you, so it needs more rigour. Effort scales with category and risk.
Is a configured LIMS Category 4 or 5?
A commercial LIMS set up to your workflow through configuration (not custom code) is Category 4. If you add bespoke custom code or modules, those custom parts are treated as Category 5 within an otherwise Category 4 system.
Does Category 3 need validation?
It needs verification appropriate to its risk — confirming the system does what you need for its intended use — but you can leverage the supplier’s development and testing rather than re-doing it. The effort is lower than for configured or custom systems, not zero.