GAMP 5 Software Categories
GAMP 5 (ISPE’s Good Automated Manufacturing Practice guide) classifies software into categories — infrastructure, non-configured, configured, and custom — as the basis for scaling validation effort to the actual risk and complexity of the system, rather than applying one uniform validation approach to every application regardless of how it was built or what it does. The categories are a planning tool, not a regulatory requirement in themselves.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 21 LINKSA category is an argument about where risk lives, not a label on a purchase order: it decides how much of the evidence a supplier can supply and how much the regulated user has to generate themselves.
06 · QUALITY MATURITY — GAMP 5 SOFTWARE CATEGORIES, REACTIVE TO ADAPTIVE
Everything is validated the same way, because a single protocol template is easier to run than a decision about which one applies.
Systems carry a category, assigned once at purchase, and the effort follows it — but the assignment reflects what the vendor called the product.
Category follows what the site actually configured and what a failure would do, is recorded with its reasoning, and drives which testing is leveraged and which is repeated.
Supplier assessment genuinely reduces site testing where it is earned, and the assessment is revisited when the supplier or the configuration changes.
Category is a design input: systems are chosen and configured so that the evidence burden falls, rather than being classified after the fact to justify the burden chosen.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 3
Derived from the 3 standards SPEQ maps to this subject, across 3 regulatory bodies: FDA, EMA, ISPE.
RECORDS & OBJECTIVE EVIDENCE
- The category assigned per system, with the reasoning and who decided
- Supplier assessment records for any testing leveraged rather than repeated
- Configuration specifications distinguishing configured from customised function
- Validation packages whose depth is visibly proportionate to the category
- Change records showing category reassessed when configuration changed
COMMON INSPECTION FINDINGS
- A category taken from the vendor’s marketing rather than from what the site configured
- Custom code treated as configuration, so the testing never addressed what was written
- Supplier testing leveraged with no assessment establishing it could be
- Identical validation depth across systems of obviously different risk
- Category never revisited after a configuration change that altered it
Why Categorisation Exists
Before a risk-based framework, CSV practice tended toward applying the same exhaustive validation package to every system — a fully custom-built manufacturing execution system and an off-the-shelf spreadsheet received similar treatment, which wasted effort on low-risk systems while sometimes under-scrutinising genuinely custom, high-risk code.
GAMP 5’s category scheme lets a validation plan scale documentation and testing rigor to how much a system was configured or built specifically for the user, and to how directly it affects product quality or data integrity.
The Categories
Category 1 (Infrastructure) covers operating systems, database engines, and network components — validated implicitly through qualification of the platform they support. Category 3 (Non-Configured Products) covers standard, off-the-shelf software used as supplied, without configuration to business processes. Category 4 (Configured Products) covers software configured to meet specific business processes — the category most GMP calculation tools, LIMS, and MES configurations fall into. Category 5 (Custom Applications) covers bespoke code written to meet a specific user requirement and carries the highest validation burden because there is no vendor base to lean on for testing evidence.
(GAMP 5’s original Category 2, for firmware, was retired in the second edition and folded into the surrounding categories, which is a common point of confusion when reading older validation documentation.)
What Category Drives
The category informs — but does not by itself dictate — the depth of specification documentation, the extent of testing (vendor-leveraged versus user-executed), and the level of change-control rigor applied over the system’s life. A Category 5 system generally demands full requirements-to-test traceability and user-executed testing of custom logic; a Category 3 system can often lean heavily on vendor documentation and focused user acceptance testing.
Risk to product quality, patient safety, and data integrity remains the overriding factor GAMP 5 itself insists on — category is an input to the risk assessment, not a replacement for it.
Common Pitfalls in Practice
The most frequent mistake is treating the category as a fixed property of the product rather than of the specific implementation: the same LIMS is a Category 4 system when configured to a site’s workflows and edges toward Category 5 wherever bespoke scripts or custom calculations have been added. The categorisation must describe what was actually deployed, and it should be revisited when configuration or custom code changes.
SPEQ interpretation: a second recurring trap is using a low category to justify skipping supplier assessment. A Category 3 or 4 classification leans on vendor testing evidence, which only holds if the vendor’s own development and quality practices have actually been evaluated — an unassessed supplier turns “we relied on vendor documentation” into an unsupported assumption an inspector will challenge. Category and supplier assessment are complementary controls, not substitutes.
FREQUENTLY ASKED
Does a higher GAMP category always mean more work?
Generally yes for direct validation effort, but the relationship is not purely linear — a well-understood, heavily precedented Category 4 configuration can sometimes require less net effort than a poorly scoped Category 3 implementation with unclear requirements.
Is GAMP 5 itself a regulatory requirement?
No — GAMP 5 is an ISPE industry guide, not a regulation. Regulators (FDA, EU GMP Annex 11) require validated computerised systems; GAMP 5 is the most widely adopted framework for demonstrating how that validation was scaled and executed.
How does a SaaS or cloud-hosted application get categorised?
It is still assessed by what was configured versus built specifically for the user — a multi-tenant SaaS platform used with standard configuration is typically treated similarly to Category 4, with additional supplier-assessment considerations for the hosting and shared-infrastructure model.