GAMP 5 Software Categories Explained
Understand Categories 1, 3, 4, and 5, how the current terminology differs from older GAMP material, and how to use categorization without turning it into a rigid validation checklist.
What Are GAMP 5 Software Categories?
GAMP 5 is ISPE guidance for a risk-based approach to compliant GxP computerized systems. It helps regulated companies and suppliers apply good practice across a system lifecycle, from planning and requirements through implementation, operation, maintenance, and retirement. The guide is not itself a regulation, and it does not replace applicable GMP requirements or a company’s quality system.
Software categories describe the nature of a software component—such as whether it is infrastructure, standard software used as supplied, configured software, or a custom application. This gives teams a common way to discuss supplier involvement, the potential for residual defects, and the lifecycle evidence that may be appropriate.
ISPE’s current guidance emphasizes critical thinking: categories should be considered alongside risk assessment and supplier assessment. Lifecycle activities may need to be added, removed, or scaled to fit the actual components and risks. Categories are not intended to create a box-ticking validation checklist. ISPE explains this component-focused, risk-based use of categorization.
The current Computerized System Validation guide explains the broader lifecycle in which categorization is used. For the regulatory context, read the site guide to cGMP.
Current GAMP 5 Category Terminology
The GAMP 5 Second Edition was published by ISPE in July 2022. It retains the risk-based framework while updating its application to modern systems, including service providers, iterative software development, automation, cloud computing, artificial intelligence, and data integrity. The exact categorization language in the current edition is more component-focused than many older summaries found online. ISPE’s overview of the Second Edition describes these updates.
| Category | Current description | Common practical shorthand | Typical component examples |
|---|---|---|---|
| 1 | Infrastructure software, tools, and IT services | Infrastructure / platform layer | Operating systems, databases, middleware, platforms, infrastructure services, or development and support tools, depending on their role and boundary. |
| 3 | Standard system components | Standard or non-configured software | Standard commercial components used with limited or no application-specific configuration; fixed-function software may be assessed in context. |
| 4 | Configured components | Configured product | Commercial software whose parameters, workflows, rules, roles, or other settings are configured to support a site process. |
| 5 | Custom applications and components | Bespoke or custom software | Application code, custom modules, scripts, interfaces, or other software created for a specific user or process need. |
GAMP Category 1: Infrastructure Software, Tools, and IT Services
Category 1 covers foundational software, tools, and services that support computerized applications. They may not implement the regulated business process directly, but they can affect the availability, security, configuration, or performance of the applications that do.
Examples that may fall within Category 1
- Operating systems, database engines, middleware, and shared runtime platforms.
- Virtualization, container, network, identity, and infrastructure services.
- Common development, configuration, deployment, monitoring, or backup tools.
- IT services such as hosting, administration, or support when included in the system boundary.
These are examples, not automatic assignments. Determine whether an item is part of the system boundary, what service is being relied upon, and how failure could affect a GxP function. A platform layer may require robust configuration, security, supplier, backup, and change controls even when it does not need the same functional testing as a custom application.
For example, a database service may not decide a batch disposition, but it could store the electronic record used to support that decision. Its access controls, availability, backup, recovery, and change management can therefore be important to the overall control strategy.
GAMP Category 3: Standard System Components
Category 3 is used for standard software components that are supplied with established functionality and are not materially configured to implement a site-specific business process. Many older guides describe this as a non-configured product or standard commercial off-the-shelf software.
Illustrative examples
- A commercial application used with its standard functionality and no site-specific workflow configuration.
- A fixed-function instrument software package operated within the supplier’s intended operating model.
- A standard component embedded in a larger regulated system where the component’s functionality is not configured for a unique local process.
Do not classify software as Category 3 merely because it is purchased from a vendor. If users set business rules, workflows, calculations, approval routes, specifications, or other behavior to fit the local process, those configured parts may be Category 4. If the organization or supplier writes code or custom logic, that component may be Category 5.
For Category 3 components, teams can often leverage supplier documentation and release evidence, then verify that the product is correctly installed and suitable for the documented intended use. The regulated company still needs to assess GxP impact, data integrity, security, and any critical requirements that supplier evidence does not adequately cover.
GAMP Category 4: Configured Components
Category 4 applies when standard software is configured—through supported settings or parameters—to meet a particular process or organizational need. Configuration usually changes how the product behaves without creating new source code, although the distinction between configuration and customization must be understood for the specific product.
Common examples
- A LIMS configured with local sample types, test workflows, specifications, calculations, and review steps.
- An MES configured with manufacturing recipes, electronic instructions, equipment rules, or user roles.
- An ERP or eQMS configured with site processes, approval routes, quality records, or master-data rules.
- A chromatography data system configured with methods, access roles, processing parameters, and report templates.
Category 4 validation should focus on the approved configuration and how it supports the intended business process. Maintain controlled configuration records, assess the impact of each GxP-relevant setting, and test critical workflows, boundary conditions, calculations, interfaces, access controls, audit trails, and exception handling in proportion to risk.
Supplier testing and documentation can be valuable, particularly for standard product functions. The site should establish what evidence is leveraged, what remains to be demonstrated locally, and how configured behavior is kept aligned with approved requirements. See the related article on URS development.
GAMP Category 5: Custom Applications and Components
Category 5 covers software created or materially customized to meet a specific user or process need. Because custom logic is developed for a particular context, the team may have less broad-use history or supplier evidence to rely on. The lifecycle approach should therefore make design decisions, development controls, verification, release, and maintenance understandable and reviewable.
Examples may include
- A bespoke application built to calculate, evaluate, approve, or report regulated process data.
- A custom module or code extension added to a commercial platform.
- Custom scripts, macros, or low-code logic that perform GxP-relevant calculations or decisions.
- A custom interface or data-transformation component that changes the meaning, routing, or control of regulated data.
Category 5 does not automatically mean “test every line of code” or apply maximal documentation to all custom items. The level of assurance should consider intended use, GxP impact, complexity, novelty, development and supplier controls, and the consequences of failure. Depending on risk, evidence may include requirements, design information, code or configuration review, unit and integration testing, functional and end-to-end testing, traceability, defect handling, and controlled deployment.
Small user-created tools should not be dismissed because they are small. A spreadsheet macro that calculates a release-critical result can have greater GxP impact than a large non-GxP utility. Evaluate the function and risk, then apply suitable controls for access, change, testing, data integrity, and lifecycle ownership.
What Happened to GAMP Category 2?
Category 2 is absent from the current GAMP 5 category set. Older material—particularly content carried forward from earlier GAMP versions—may describe Category 2 as firmware and list Categories 1 through 5. That historical terminology is a common source of confusion.
In the current approach, do not force embedded software or firmware into a legacy Category 2 label by default. Identify the software component, understand how it is supplied and used, and assess it using the current component categories, supplier evidence, and risk. Where an organizational template still contains a Category 2 field, update the controlled template or document how legacy references are interpreted.
How to Classify GAMP 5 Software Components
Classification should follow understanding of the system, not replace it. A computerized system is often made from several components with different categories. ISPE’s current discussion cautions that categories are a continuum, that components should be considered in context, and that the category is only one factor alongside GxP impact, complexity, novelty, and risk. See ISPE’s discussion of category use and critical thinking.
- Define intended use and GxP impact. Identify the process supported, records created or changed, and possible effects on patient safety, product quality, and data integrity.
- Set the system boundary. Map applications, modules, infrastructure, interfaces, data flows, hosting, and supporting services.
- Break the system into relevant components. Separate standard product functions, configured behavior, custom code, platform components, and supplier services where this helps risk assessment.
- Understand how each component was created for this use. Ask whether it is foundational infrastructure, supplied standard functionality, configured product behavior, or custom-developed logic.
- Record a component-level category and rationale. Link the classification to architecture, supplier information, configuration records, and approved intended use.
- Assess risk and supplier evidence. Consider complexity, novelty, use history, supplier capability, defects, and the strength of available documentation or testing.
- Scale lifecycle activities. Select requirements, testing, review, security, change, and operational controls that address the actual risks—not only the category number.
GAMP categorization can support supplier-assessment planning. It should not become the sole basis for deciding that a system is low risk or that validation evidence is unnecessary.
Example: Categories Within a Pharmaceutical LIMS
A regulated LIMS is not necessarily one category from end to end. The following simplified example shows how teams can describe component-level categories without treating them as compliance verdicts.
| Component in the LIMS solution | Possible category | Why the classification may fit | Risk-based evidence focus |
|---|---|---|---|
| Hosting operating system, database, and shared platform services | Category 1 | Foundational software and IT services supporting the application. | Version/configuration management, supplier/service controls, security, backup, recovery, and impact of platform changes. |
| Standard vendor functionality used as supplied | Category 3 | Standard component behavior is not configured to create site-specific process logic. | Supplier evidence, installation/version confirmation, and verification of fitness for intended use. |
| Local test workflows, specifications, roles, and review routes | Category 4 | Product features are configured to implement the laboratory’s process. | Approved configuration, requirements traceability, critical workflow testing, calculations, access, audit trail, and exception paths. |
| Custom interface or script that transforms release-critical results | Category 5 | Custom logic is created for the site’s data flow or decision process. | Requirements/design, data mapping, error handling, code/configuration controls, traceability, and risk-based functional testing. |
This is illustrative only. Classification depends on the product, how it is implemented, the system boundary, and the current licensed guidance. A named product does not have one automatic category: configuration, custom extensions, infrastructure, and services may each need separate consideration.
How Categories Influence Assurance Activities
Categories help teams reason about supplier evidence and the likelihood of residual defects in components. They do not prescribe a fixed document list. A useful validation strategy ties each GxP requirement and risk control to evidence that demonstrates the system works as intended.
| Component profile | Activities that may be appropriate | Key caution |
|---|---|---|
| Category 1 infrastructure, tools, or IT services | Identify versions and dependencies; assess supplier/service controls; manage configuration, access, security, backup, change, and incident response; verify the application operates in the qualified environment. | Infrastructure can still be critical to records and application controls; do not assume “not application software” means “no GxP relevance.” |
| Category 3 standard components | Review supplier documentation and known-use evidence; verify intended-use requirements; test installation, interfaces, and critical functions not adequately covered by supplier evidence. | Standard software can be high impact if it is used for a critical decision or regulated record. |
| Category 4 configured components | Specify and control configuration; assess configuration risk; test critical configuration and end-to-end workflows; verify access, data, calculations, audit trail, and exceptions. | Configuration can be complex or novel; a Category 4 assignment does not automatically imply low testing. |
| Category 5 custom components | Control requirements and design; use appropriate development and review practices; test unit, integration, functional, and end-to-end behavior; trace risks and requirements to evidence. | Scale effort to intended use and risk; avoid both untested custom logic and unnecessary testing with no risk benefit. |
Where relevant, connect the strategy to documented design qualification, IQ, OQ, and PQ evidence. These are familiar lifecycle tools, but a risk-based computerized-system lifecycle may organize evidence differently when it remains complete, traceable, and approved.
Common GAMP Categorization Mistakes
Assigning one category to the whole system
A mixed system may include infrastructure, standard software, configured behavior, and custom code. Component-level understanding produces a more useful assessment.
Treating the number as a risk score
Category describes the nature of a component. Risk also depends on intended use, process criticality, complexity, novelty, detectability, and supplier evidence.
Calling all commercial software Category 3
Commercial origin does not decide category. Site-specific configuration may make components Category 4; custom code or logic may be Category 5.
Using Category 2 from an old template
Check the edition and update the controlled categorization procedure so reviewers do not apply retired legacy terminology as if it were current.
Using category to skip impact assessment
Even a standard component can support a critical GxP record. Assess what failure would mean and what controls demonstrate fitness for intended use.
Equating Category 5 with “test everything”
Custom development often needs strong lifecycle evidence, but testing should still target requirements and risks, with rationale for depth and coverage.
Keep classifications and their rationales controlled within the validation lifecycle. Changes to intended use, configuration, supplier, architecture, or custom logic can change the risk picture and should be assessed through change control and the applicable SOP.
Frequently Asked Questions
What are the current GAMP 5 software categories?
The current GAMP 5 Second Edition uses Categories 1, 3, 4, and 5: infrastructure software, tools, and IT services; standard system components; configured components; and custom applications and components.
What is GAMP Category 1?
Category 1 covers infrastructure software, tools, and IT services that support computerized applications, such as operating systems, database platforms, middleware, and relevant infrastructure services.
What does Category 3 mean in GAMP 5?
Category 3 refers to standard system components supplied with established functionality and used without material application-specific configuration. Older references often call it non-configured software or standard products.
What is the difference between Category 3 and Category 4?
Category 3 generally describes standard components used as supplied. Category 4 describes components configured through product settings or parameters to support a particular process. The actual product setup determines the classification.
What is GAMP Category 5?
Category 5 covers custom applications and components created for a specific user or process need, such as bespoke code, custom modules, scripts, or interfaces with GxP impact.
Is GAMP Category 2 still used?
Category 2 is not included in the current GAMP 5 four-category scheme. Older materials may describe Category 2 as firmware; check the edition and your organization’s controlled procedure when such references appear.
Does the GAMP category determine the amount of validation?
No. It is one input to a risk-based approach. Validation and assurance activities should also consider intended use, GxP impact, complexity, novelty, supplier capability, and the consequence of failure.
Can one computerized system contain more than one GAMP category?
Yes. A system may combine Category 1 infrastructure, Category 3 standard functions, Category 4 configuration, and Category 5 custom components. Component-level assessment is often more informative than a single whole-system label.
Is GAMP 5 a regulation?
No. GAMP 5 is industry guidance published by ISPE. It supports interpretation and implementation of applicable requirements but does not replace laws, regulations, agency guidance, or a company’s quality system.
How should a configured LIMS be categorized?
A LIMS may contain standard Category 3 functions, Category 4 site-specific configuration, Category 5 custom scripts or interfaces, and Category 1 infrastructure or services. Assess each relevant component in its intended-use context.
Official References and Further Reading
- ISPE: GAMP 5 Guide, Second Edition — edition details and its risk-based, lifecycle approach.
- ISPE Pharmaceutical Engineering: “When Is a Category Not a Category?” — current discussion of component categorization, risk, and critical thinking.
- ISPE GAMP topic page — GAMP purpose and guidance resources.
- European Commission EudraLex Volume 4 — GMP guidance index, including Annex 11.
- Computerized System Validation in Pharmaceuticals — related internal article.
This article is original educational content, not a substitute for the current licensed ISPE GAMP 5 Guide, applicable regulations, or an approved site procedure. Confirm exact terminology and approach against your organization’s controlled reference and system-specific risk assessment.
Key Takeaway
Use GAMP 5 software categories to describe components and inform risk-based supplier and lifecycle decisions. In the current scheme, the categories are 1, 3, 4, and 5. Category 2 is legacy terminology. Above all, classify thoughtfully: assess components in context and scale assurance to intended use, GxP impact, complexity, novelty, supplier evidence, and the risks to patient safety, product quality, and data integrity.
.webp)
