GAMP 5 — published by ISPE, now in its Second Edition (2022) — is the industry-standard framework for validating computerized systems in regulated environments. Its core idea: not every piece of software needs the same depth of validation, and the depth should scale with risk, not with how much documentation you can produce.
The five software categories
| Category | What it covers | Validation depth |
|---|---|---|
| 1 — Infrastructure | Operating systems, databases, network components | Minimal — verify installation and configuration, no functional testing of the OS itself. |
| 3 — Non-configured products | Off-the-shelf software used as-is, no configuration | Verify it does what the vendor says, for your intended use. |
| 4 — Configured products | Off-the-shelf software configured for your workflows (e.g. most eQMS/LIMS platforms) | Test the configuration you built, not the vendor's underlying code. |
| 5 — Custom/bespoke | Software built specifically for you, with custom code | Full lifecycle validation — the highest rigor, because nobody else has tested this exact code. |
A worked example: if you deploy a configured eQMS (Category 4) with a custom-built integration script pulling data from an HPLC (Category 5 for that script), you validate the eQMS configuration at Category 4 depth and the integration script at Category 5 depth — not the same level for both.
What changed in the Second Edition (2022)
- Explicit guidance for validating cloud and SaaS-based systems — increasingly relevant as more GxP software moves off-premise.
- Updated data-integrity expectations aligned to ALCOA+.
- New cybersecurity considerations woven into the validation lifecycle.
- Formal endorsement of Computer Software Assurance (CSA) — a shift toward risk-proportionate, critical-thinking-driven testing instead of exhaustive, checklist-heavy documentation regardless of actual risk.
A genuinely useful, underused angle
GAMP 5 categorization doesn't just apply to systems you build — it applies to how you should validate the eQMS or LIMS you buy. A Category 4 configured product means your validation effort should focus on testing your specific configuration (your workflows, your access rules, your custom fields), not re-testing the vendor's core platform.
CSA vs. traditional CSV
Computer Software Assurance shifts the emphasis from producing volumes of test documentation to applying critical thinking about what actually needs testing, given the system's risk to product quality and patient safety. A low-risk Category 3 tool used for internal scheduling doesn't need the same test-script rigor as a Category 5 system controlling batch release — CSA formalizes that proportionality rather than treating every validation the same.
Ready to see this in your own lab? Book a free ValiCore demo.