If your organization operates in a regulated life-sciences environment, you have probably encountered GAMP 5. The difficult part is usually not recognizing the name. It is understanding what GAMP 5 actually does, what it does not require, and how to apply its risk-based principles without turning validation into a paperwork exercise.
This guide explains how GAMP 5 applies to GxP computerized systems, including software and hardware categorization, supplier assessment, validation planning, testing, data integrity, cloud and SaaS systems, ongoing control, and system retirement. It is intended as general guidance for regulated computerized systems. Customers implementing a validated commercial platform such as GxPReady may be able to leverage substantial supplier validation evidence rather than recreating a complete validation program from scratch.
What Is GAMP 5?
GAMP stands for Good Automated Manufacturing Practice. Published by the International Society for Pharmaceutical Engineering (ISPE), GAMP 5 is industry guidance for achieving computerized systems that are fit for intended use and appropriately controlled in regulated environments.
GAMP 5 is not a regulation and it is not a certification standard. It provides a practical framework that regulated companies, suppliers, and validation professionals can use to interpret applicable regulatory requirements and scale lifecycle activities according to risk.
The central idea is straightforward: the amount of validation and verification effort should reflect the system's intended use, GxP impact, complexity, novelty, supplier capability, and the potential effect of failure on patient safety, product quality, and data integrity.
Why GAMP 5 Still Matters in 2026
The second edition of GAMP 5, published in 2022, retained the core risk-based lifecycle approach while placing greater emphasis on modern technology and delivery models, including cloud services, SaaS, agile development, software tools, automation, and the increasing role of service providers.
Just as important, the second edition emphasizes critical thinking. Categorization, templates, and lifecycle models are tools. They are not substitutes for understanding the system and its actual risks.
GAMP 5 Software Categories: Useful, but Not a Validation Checklist
GAMP 5 includes software-component categories that can help organizations understand complexity and determine how much reliance may reasonably be placed on supplier activities. The categories should not be used as a mechanical rule that automatically dictates a fixed set of validation documents.
A modern computerized system may contain components from several categories at the same time. GAMP 5 Second Edition encourages organizations to view Categories 3 through 5 as a continuum and to combine categorization with risk assessment, supplier assessment, and knowledge of the intended use.
| Software Category | General Description | Typical Examples |
|---|---|---|
| Category 1 | Infrastructure software, tools, and IT services | Operating systems, database engines, middleware, monitoring or scheduling tools, infrastructure services |
| Category 2 | Not used for software in GAMP 5 | None |
| Category 3 | Standard system components | Commercial components used essentially as provided, including some instruments and standard software components |
| Category 4 | Configured components | Commercial software configured to support user-specific business processes or workflows |
| Category 5 | Custom applications and components | Custom code, bespoke interfaces, scripts, macros, or applications developed for specific user requirements |
SaaS Is Not a GAMP Category
One common mistake is to assume that every SaaS application is automatically Category 4. SaaS describes how software is delivered, not the nature of every component within the system.
A SaaS application may contain standard components, configured components, custom interfaces, infrastructure services, and other elements that fall into different GAMP categories. A high-level whole-system category may sometimes be useful early in a project or when planning supplier assessment, but the validation approach should ultimately reflect the system's actual components, intended use, configuration, and risk.
For example, a calibration management system may use a standard commercial platform while also including customer-specific configuration and possibly custom interfaces. Simply labeling the entire system "Category 4" does not by itself tell you how much verification is appropriate.
Hardware Classification Matters Too
GAMP 5 does not stop at software. Computerized systems also depend on hardware and infrastructure. Hardware classification is simpler than software classification, but it is still part of the overall system assessment.
| Hardware Category | Description | Typical Approach |
|---|---|---|
| Hardware Category 1 | Standard hardware components | Document relevant manufacturer or supplier information, model/version information where applicable, verify correct installation and connection, and maintain appropriate configuration and change control. |
| Hardware Category 2 | Custom-built hardware components | Apply the controls used for standard hardware plus appropriate design specifications, acceptance testing, configuration verification, and risk-based supplier assessment. |
Most commercial servers, workstations, network devices, storage devices, controllers, and similar components will generally be standard hardware. Custom-built hardware deserves additional attention because its design and suitability cannot be supported simply by widespread commercial use.
The important nuance is that Software Category 2 is not used, while Hardware Category 2 is still used for custom-built hardware. Mixing the software and hardware category schemes is an easy source of confusion.
What About Cloud Infrastructure?
Cloud-hosted systems change who operates the infrastructure, but they do not eliminate the need to understand it. The regulated company should know which responsibilities are performed by the application supplier, cloud provider, internal IT organization, or other service providers.
Validation does not normally mean independently retesting every server, storage device, network component, or cloud service. It means establishing appropriate assurance that the infrastructure supporting the GxP application is suitable, controlled, and managed according to defined responsibilities.
Risk-Based Validation: What It Means in Practice
Risk-based validation means applying the greatest effort where failure could have the greatest GxP impact. It is not an excuse to perform less validation. It is a way to avoid spending equal effort on functions with very different levels of risk.
1. Define intended use
Start by defining what the system is expected to do in the regulated process. Intended use determines which functions, data, records, and interfaces actually matter.
2. Assess GxP impact and functional risk
Determine how system functions could affect patient safety, product quality, data integrity, or compliance with applicable requirements. Not every function within a large application necessarily carries the same risk.
3. Understand the system and its components
Identify important software, hardware, infrastructure, interfaces, configuration, and supplier-provided services. Categorization can help here, but it should support the risk assessment rather than replace it.
4. Assess the supplier
Determine whether the supplier's development, testing, quality, security, change-management, and support processes provide evidence that can reasonably be leveraged. A strong supplier may substantially reduce unnecessary duplication of testing.
5. Define the verification strategy
Test what matters. Higher-risk functions generally deserve more rigorous verification. Lower-risk functions may justify simpler testing or reliance on supplier evidence when that reliance is justified and documented.
IQ, OQ, and PQ: Useful Terms, Not Mandatory Labels for Every System
IQ, OQ, and PQ terminology remains widely used in regulated industries, especially for equipment, facilities, utilities, and many computerized-system implementations. However, GAMP 5 does not require every computerized system to be forced into the same IQ/OQ/PQ document structure.
Installation Qualification (IQ) commonly verifies that the relevant system or component has been installed and configured correctly.
Operational Qualification (OQ) commonly verifies that defined functions operate as intended across the appropriate operating range or conditions.
Performance Qualification (PQ) commonly demonstrates acceptable performance under actual or representative conditions of use.
An organization may instead use terms such as installation verification, functional testing, requirements testing, user acceptance testing, or other lifecycle deliverables defined by its procedures. The important point is the evidence, not the label on the protocol.
The GAMP 5 Lifecycle
GAMP 5 treats computerized-system assurance as a lifecycle activity. A system does not become permanently "validated" simply because a validation report was approved at go-live.
Concept and planning
Define the business need, intended use, GxP impact, system boundaries, responsibilities, and overall validation approach.
Requirements
Document requirements at a level appropriate to the system and the risk. Requirements should focus on what the regulated process and users actually need.
Supplier and system assessment
Understand the supplier, system architecture, major software and hardware components, configuration, interfaces, and services that support the application.
Configuration and design
Document important configuration and custom elements to the level necessary to support risk assessment, verification, operation, and future change.
Verification
Generate objective evidence that the system satisfies its defined requirements and is suitable for intended use. Verification should be scaled according to risk and should leverage reliable supplier evidence where appropriate.
Release and reporting
Resolve significant deviations, confirm required procedures and training are in place, and document the basis for releasing the system to regulated use.
Operation
Maintain the validated state through appropriate change control, access management, incident management, backup and recovery, supplier oversight, training, and review.
Retirement
Plan for system retirement so that required records remain complete, understandable, protected, and retrievable for their applicable retention periods. Data migration and archival should preserve the context needed to interpret regulated records.
Data Integrity and Audit Trails
Data integrity is a major consideration in computerized-system validation. The commonly used ALCOA+ principles describe records and data that are attributable, legible, contemporaneous, original or appropriately preserved, accurate, complete, consistent, enduring, and available.
Audit trails are an important control for many regulated electronic records, but the statement that every action in every computerized system must always generate an audit-trail entry is too broad. Audit-trail requirements should be assessed according to the applicable regulation, the record, the system's intended use, and data-integrity risk.
For systems that create or modify regulated electronic records, organizations should determine whether the audit trail appropriately captures significant record changes and preserves information needed to reconstruct what occurred. Relevant considerations may include:
- Who performed the action
- Date and time of the action
- Original and changed information where appropriate
- Reason for change where required
- Protection of audit-trail information from unauthorized modification
- Availability of audit trails for review and retention
See our 21 CFR Part 11 compliance page for additional discussion of electronic records, authenticated actions, and audit-trail controls.
Supplier Assessment and Leveraging Supplier Evidence
A regulated company remains responsible for determining that a computerized system is suitable for its intended use. That does not mean the company must recreate every development or verification activity already performed by a competent supplier. For a validated commercial platform, supplier evidence can significantly reduce the amount of customer-generated validation work that is necessary.
A risk-based supplier assessment may consider:
- Quality-management practices
- Software development lifecycle controls
- Requirements, design, and testing practices
- Defect and incident management
- Change and release management
- Security and access controls
- Backup, recovery, and business-continuity practices
- Availability of validation or verification evidence
- Use and oversight of cloud or other service providers
The depth of supplier assessment should reflect the GxP impact of the system, the nature of the supplied components and services, and the extent to which the regulated company intends to rely on supplier activities.
Periodic Review Does Not Automatically Mean Annual Review
Validated systems should be periodically evaluated as appropriate to confirm that they remain suitable and controlled. However, GAMP 5 does not create a universal rule that every system must undergo a formal periodic review once every year.
The review frequency and depth should be defined according to applicable requirements, company procedures, system risk, complexity, change history, incidents, supplier changes, and operational experience.
A periodic review may consider items such as:
- Changes implemented since the previous review
- Incidents and recurring problems
- User access and privilege status
- Backup and recovery performance
- Audit-trail review where applicable
- Supplier or infrastructure changes
- Validation documentation and outstanding actions
- Continued suitability for intended use
How GAMP 5 Applies to CMMS and Equipment Management Systems
A CMMS used in a regulated environment should be evaluated based on how the organization actually uses it. If the system creates, maintains, or supports records used to demonstrate GMP maintenance, calibration, equipment status, or other regulated activities, the organization should establish documented assurance that the system is suitable for that intended use.
Factors affecting the validation approach include:
- The GxP records and processes supported by the system
- The criticality of the supported equipment and activities
- The software components and level of configuration or customization
- The hardware and infrastructure supporting the application
- Interfaces with other systems
- The supplier's development and quality practices
- The quality and relevance of supplier validation evidence
- Customer-specific procedures and configuration
A commercial CMMS should not be assumed to require the same testing as a custom application. For a system that has already been validated by the supplier, the customer should be able to leverage that work rather than repeat it without a technical or regulatory reason.
GxPReady is provided as a validated platform. Customers therefore do not begin with an unvalidated software product and build a complete validation program from scratch. GxPReady's development and validation lifecycle has been structured using principles consistent with GAMP 5 recommendations, including risk-based verification, supplier-controlled development, documented testing, change control, and lifecycle management.
Flash Validation™ builds on that existing platform validation. Rather than requiring the customer to recreate extensive testing that has already been performed at the platform level, the qualification process focuses customer effort on the elements specific to the customer's implementation, such as intended use, configuration, user roles, procedures, training, and operating environment.
The objective is not to eliminate validation. It is to avoid unnecessary duplication of supplier testing and documentation while maintaining appropriate evidence that the customer's configured implementation is suitable for its intended use. This can substantially reduce the validation effort compared with more conventional implementation and qualification approaches, including approaches sometimes used for commercial cloud software.
Because Flash Validation™ does not always fit the assumptions people bring from conventional validation programs, the approach is best understood by reviewing the underlying methodology, existing platform validation, and customer-specific qualification evidence. Organizations evaluating GxPReady are encouraged to contact us to discuss what validation evidence already exists and what qualification activities are appropriate for their intended use.
Practical Steps for a GAMP 5-Aligned Validation Program
1. Maintain an inventory of GxP computerized systems. Know which systems support regulated processes and records.
2. Define intended use before defining validation deliverables. The system's purpose and risk should drive the validation strategy.
3. Understand both software and hardware. Document relevant application, infrastructure, interfaces, hardware, and service-provider responsibilities.
4. Use categorization intelligently. Software and hardware categories help characterize components; they do not replace risk assessment.
5. Assess suppliers according to risk. Do enough supplier evaluation to justify the degree of reliance placed on their processes and evidence.
6. Leverage existing evidence. Avoid repeating supplier testing without a reason. For validated commercial platforms, use supplier validation evidence wherever it is appropriate and focus customer qualification on intended use, configuration, customer-specific procedures, and any functions or risks not already adequately covered.
7. Put the system under change control. Changes to software, configuration, infrastructure, interfaces, or intended use should be assessed for GxP impact.
8. Define appropriate ongoing review. Establish review activities and frequency based on risk and applicable procedures rather than an arbitrary universal annual schedule.
9. Plan for retirement and data retention. Know how regulated records will remain accessible and meaningful when the system is replaced or discontinued.
What to Look for in a GAMP 5-Aligned System and Supplier
GAMP 5 is guidance, so there is no meaningful "GAMP 5 certification" that makes a software product automatically suitable for every regulated use. When evaluating a system and supplier, look instead for evidence of controlled development and support.
- Defined intended-use support: Can the system support the regulated process without excessive customization?
- Supplier quality practices: Does the supplier operate controlled development, testing, release, and change-management processes?
- Validation evidence: Is useful supplier documentation available to support customer qualification?
- Configuration control: Can significant configuration be identified and controlled?
- Audit trails and access control: Are controls appropriate for the records and workflows being managed?
- Data lifecycle: Can records be protected, backed up, retained, retrieved, exported, and transitioned when necessary?
- Infrastructure responsibilities: Are cloud, hosting, backup, security, and support responsibilities clear?
- Change communication: Does the supplier provide enough information for customers to assess upgrades and changes?
Frequently Asked Questions
Is GAMP 5 a regulation?
No. GAMP 5 is industry guidance published by ISPE. It provides a risk-based framework for achieving computerized systems that are fit for intended use and appropriately controlled under applicable GxP requirements.
Does GAMP 5 require IQ, OQ, and PQ for every computerized system?
No. IQ/OQ/PQ terminology may be appropriate and is widely used, but GAMP 5 supports lifecycle activities and verification scaled to the system's intended use, complexity, risk, and components. The evidence matters more than forcing every system into identical document labels.
Is every SaaS application Category 4?
No. SaaS is a delivery model, not a software category. A SaaS system may contain Category 1, 3, 4, and 5 components. Categorization should be considered together with configuration, supplier assessment, system risk, and intended use.
What happened to Software Category 2?
Software Category 2 is not used in GAMP 5. However, GAMP 5 separately retains Hardware Category 2 for custom-built hardware components.
What are the GAMP 5 hardware categories?
Hardware Category 1 covers standard hardware components. Hardware Category 2 covers custom-built hardware components that generally require additional design, acceptance-testing, and supplier-assessment considerations.
How often should a validated system be periodically reviewed?
There is no universal GAMP 5 requirement that every computerized system be reviewed annually. The frequency should be defined according to applicable requirements, system risk, complexity, operational history, change activity, and the organization's procedures.
Does GAMP 5 require audit trails for every computerized-system action?
No blanket statement covers every action in every system. Audit-trail requirements should be evaluated according to the applicable regulated records, intended use, data-integrity risk, and regulatory requirements. For applicable GxP electronic records, the system should provide sufficient traceability of significant changes.
Does a commercial CMMS need validation?
If a CMMS is relied upon for regulated processes or records, the organization should establish documented assurance that it is suitable for its intended use. The scope and depth of validation should reflect risk, configuration, supplier evidence, and how the system is actually used.
Where can I learn about GxPReady's validation approach?
GxPReady is provided as a validated platform developed and maintained using a lifecycle approach informed by GAMP 5 principles. Flash Validation™ is designed to leverage the validation evidence already established for the platform and focus customer qualification on intended use, configuration, procedures, training, and operating environment rather than recreating the complete platform validation from scratch. Contact GxPReady to discuss the methodology, supporting documentation, and what qualification activities are appropriate for your use.
Conclusion
The strongest lesson from GAMP 5 is not that every system needs a bigger validation package. It is that validation should be based on knowledge of the process, the system, its components, its supplier, and the actual risk.
Software categories are useful. Hardware categories are useful. IQ, OQ, and PQ can be useful. None of them should become substitutes for critical thinking.
A defensible validation program focuses effort where failure matters, makes appropriate use of supplier evidence, verifies the configured implementation and intended use, and keeps the system controlled throughout its lifecycle.
For GxPReady customers, much of the platform-level validation work has already been performed. Customer effort can therefore be concentrated on the customer's intended use and implementation rather than rebuilding the underlying validation package. See the GxPReady platform or contact us to discuss what that means for your application.
Selected references:
