GAMP 5 Software Categories
1. Purpose
This article defines the GAMP 5 software category model and explains how software categorization is used to determine validation approach, testing depth, and documentation requirements. Software categorization is a key decision step. It establishes how systems are verified based on their complexity and degree of configuration.
2. Role of Software Categorization
Software categories are used to align validation effort with system complexity and risk. Categorization supports a consistent and scalable validation approach. Software categorization is used to:
- Define validation strategy
- Determine level of specification detail
- Establish testing scope and depth
- Define extent of supplier leverage
- Support risk-based decision making
Categorization must be documented and justified for each system.
3. GAMP 5 Software Categories
GAMP 5 defines software categories based on the level of configuration and customization.
3.1 Category 1 — Infrastructure Software
Infrastructure software supports system operation but does not perform GMP-specific functionality. Typical examples include:
- Operating systems
- Databases
- Network components
- Virtual environments
Validation approach:
- Managed through IT controls
- Installation and configuration verification
- Supplier documentation leveraged
- No functional testing against business processes
3.2 Category 3 — Non-Configured Products
Commercial off-the-shelf software with fixed functionality and limited configuration. Typical examples include:
- Standard applications with predefined functions
- Software with minimal parameter setup
Validation approach:
- Verification of installation
- Basic functional verification against intended use
- Limited specification documentation
- High reliance on supplier documentation
3.3 Category 4 — Configured Products
Commercial software that allows user-defined configuration of workflows, rules, and data handling. Typical examples include:
- LIMS
- Manufacturing Execution Systems
- Quality Management Systems
- ERP systems
Validation approach:
- Defined user requirements
- Functional and configuration specifications
- Verification of configured workflows and logic
- Operational testing of system functions
- Moderate reliance on supplier documentation
3.4 Category 5 — Custom Applications
Software developed or significantly modified to meet specific business requirements. Typical examples include:
- Custom-developed applications
- Scripts or programs created internally
- Heavily customized commercial systems
Validation approach:
- Full lifecycle validation
- Detailed specifications and design documentation
- Extensive functional and negative testing
- Minimal reliance on supplier documentation
3.5 Summary
Software categories define the baseline validation approach. Validation effort increases with system complexity and degree of configuration.
| Category | Description | Validation Approach |
|---|---|---|
| Category 1 | Infrastructure software | Infrastructure control Managed through IT processes No business process verification |
| Category 3 | Non-configured products | Basic functional verification Limited documentation High supplier reliance |
| Category 4 | Configured products | Configuration and functional verification Full OQ PQ based on intended use |
| Category 5 | Custom applications | Full lifecycle validation Detailed specifications Extensive testing and documentation |
Final validation scope must be determined by combining:
- Software category
- System impact
- Data criticality
The diagram below provides a structured overview of GAMP 5 software categories, showing progression from infrastructure to custom applications. It illustrates how increasing configuration and customization lead to higher validation effort and reduced reliance on supplier documentation.
4. Supplier Leverage
GAMP 5 encourages the use of supplier documentation where appropriate. Supplier leverage depends on category:
- Category 1: High reliance on supplier and IT controls
- Category 3: High reliance on supplier documentation
- Category 4: Partial reliance with verification of configuration
- Category 5:
Limited reliance,
Full internal verification required
Supplier assessment is required before relying on vendor documentation.
5. Documentation Requirements
Software categorization must be documented and justified. Documentation must include:
- System description and intended use
- Assigned software category
- Justification for categorization
- Impact on validation approach
- Supplier assessment summary
Documentation must demonstrate that categorization is applied consistently and supports risk-based validation decisions.
6. Practical Application
Software categorization must be performed early in the lifecycle and used to guide validation planning. Categorization drives:
- Validation strategy
- Specification depth
- Test design and execution
- Supplier leverage decisions
- Lifecycle control expectations
Incorrect categorization leads to either over-validation or insufficient control.