In GxP-regulated sectors like pharma, biotech, and medtech, computerized systems play a key role in ensuring patient safety, data traceability, regulatory compliance, and integrity. GAMP 5 is one of the most widely used guides for validating those systems and keeping them validated: a risk-based framework from the International Society for Pharmaceutical Engineering (ISPE).
This guide covers what GAMP 5 is, why it matters for GxP compliance, its key principles and software categories, and how to apply it to computer system validation without over-validating.
What are the GAMP 5 guidelines?
GAMP 5 is the fifth major version of ISPE's GAMP guidance, published in full as GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems. GAMP is an acronym that stands for Good Automated Manufacturing Practice. Although it is advisory and has no legal obligation, it is referenced and respected by many regulatory agencies worldwide.
ISPE itself states that GAMP 5 is not a regulation, standard, or regulatory guideline document, and that it is inappropriate for regulated companies, suppliers, or products to claim they are "GAMP certified, approved, or compliant". FDA's current Computer Software Assurance guidance, for example, points to GAMP 5 (Second Edition) as an industry resource for software testing and validation.
The GAMP 5 guideline is applicable to computerized systems used in regulated environments. It is intended to be used by regulated companies, regulatory authorities, suppliers, regulators, and other stakeholders, providing a risk-based approach to ensure that computerized systems used in GMP, GCP, GLP, GDP, GVP, and medical device regulated activities are fit for intended use and compliant. For medical devices, the scope applies where appropriate, for example to production and quality system software and some Software as a Medical Device.
Why is GAMP 5 important for GxP compliance?
GAMP 5 turns broad regulatory expectations for computerized systems into a practical, risk-based way of working. It is intended to be used with other industry guidelines, standards and GxP regulations, including Good Manufacturing Practice (GMP), Good Clinical Practice (GCP), Good Laboratory Practice (GLP), Good Distribution Practice (GDP), Good Pharmacovigilance Practices (GVP), Medical Device Regulations, 21 CFR Part 11 (regulations for electronic records and electronic signatures), EU GMP Annex 11 and other ISO standards.
It is a widely accepted guide for designing, developing, and maintaining computerized systems in a GxP-regulated environment. The importance of GAMP 5 in GxP environments lies in five key outcomes:
- Safeguarding patient safety, product quality, and data integrity
- Achieving fit-for-intended use and compliant computerized systems
- Providing a cost-effective and efficient framework
- Facilitating regulatory interpretation and promoting common industry practices
- Supporting innovation and adapting to evolving technologies
If you'd like to dive deeper into these key related GxP regulations, get a full overview in our guide to GxP compliance in pharma.
Historical developments in GAMP 5
An important point in understanding what the GAMP 5 guidelines are is knowing the history behind the guidelines' launch and revisions:
- GAMP itself was founded in 1991 in the United Kingdom to deal with the evolving US FDA expectations on the management and controls of automated systems required for Good Manufacturing Practices compliance.
- In 1994, the first GAMP guideline was drafted and shared within industry circles, prompted by the initiative of a few UK-based pharmaceutical experts for better management of GxP compliance.
- Then, the first formal GAMP guideline was published in 1995, by GAMP, under the auspices of the ISPE, marking the beginning of a formal partnership between GAMP and ISPE.
- Revisions followed with GAMP 2 (1996), GAMP 3 (1998), GAMP4 (2001), and GAMP 5 (2008). GAMP 4 broadened the scope from automated manufacturing to all GxP systems, and GAMP 5 integrated quality risk management into the full computerized system lifecycle.
- In 2017, the GAMP Community of Practice (CoP) leadership began a formal review of GAMP 5 to determine whether it still met its objectives and to focus its efforts on areas where there is most need and benefit.
- Finally, the second edition of GAMP 5 was published by ISPE in July 2022. This second edition of GAMP 5 is the most significant update in the GAMP 5 guideline over the past 14 years. ISPE states that the overall framework, key concepts, system life cycle, specification and verification approach, and QRM process remain unchanged; the update is in the technical content and the appendices.
The concept behind the GAMP 5 second edition
The initial GAMP 5 version (2008) was conceptually grounded on the science-based risk management strategy mentioned in 21st Century regulatory GxP compliances and the ICH Q8, Q9 & Q10. It was designed to be compatible with IEEE standards, ISO 9000 and ISO 12207, IT Infrastructure Library (ITIL), and other international standards such as PIC/S Guidance Practice for Computerized Systems in Regulated GxP Environments.
GAMP 5 Second Edition keeps that framework and updates how it applies to modern technology. It explores and applies the computerized system assurance concepts discussed in FDA CDRH's Case for Quality program. Those concepts later became FDA's Computer Software Assurance (CSA) guidance (draft September 2022, final September 2025); the Second Edition, published in July 2022, predates both documents.
It also aligns with ISO 14971 for risk management of medical devices, and puts patient safety, product quality, and data integrity ahead of meeting compliance and avoiding inspection findings, with updated guidance on cybersecurity, data integrity, cloud computing, agile development, and risk-based validation of computerized systems.
New appendices in the Second Edition cover topics such as:
- IT infrastructure
- Critical thinking
- Specifying requirements
- Agile software development
- Software tools
- Distributed Ledger Systems (Blockchain)
- Artificial Intelligence (AI) and Machine Learning (ML)
GAMP 5 V-Model
GAMP 5’s specification and verification approach is often drawn as a V-model, a linear representation that pairs each system specification with the testing that verifies it. The specifications a system needs, and therefore its testing scope, depend on its software category. The Second Edition stresses that this approach is not inherently linear and fully supports iterative and incremental (Agile) methods.
For instance, configured products are tested to verify their requirements, functionality, and configuration specifications. In contrast, for commercial off-the-shelf software, functional and configuration specifications are not necessary, so the test scope would be reduced.
Verification ensures the system works as intended by testing it against defined requirements and specifications. The test scripts trace back to them, providing documented proof when they are successfully met.
However, traditional "linear approaches" like the V-model or waterfall may not suit agile environments. That's why the second edition of GAMP 5 introduces the agile model in GAMP 5 to support faster development. We’ll explore this point in greater detail below.
Key principles of GAMP 5 guideline
GAMP 5 is built around five key principles that guide the validation and operation of computerized systems in GxP-regulated life sciences environments. Together, these principles help organizations apply a risk-based approach, maintain control throughout the system lifecycle, and ensure systems remain fit for their intended use.
1. Product and process knowledge
The GAMP 5 promotes critical thinking to apply risk-based testing and validation based on product and process knowledge. This enables the GxP-regulated life sciences industries to make risk-based decisions to ensure that the system is "suitable for use", focusing on aspects crucial to patient safety, product quality, and data integrity.
GAMP 5 adds that data integrity cannot be achieved without a complete understanding of the data flow, and that the extent of requirements specification should be commensurate with risk, complexity, and novelty.
2. Validation lifecycle approach
GAMP 5 recommends a structured, lifecycle-based approach to computerized system validation in GxP-regulated environments. This approach covers four key stages, guiding organizations from initial planning and specification through validation, operation, and eventual system retirement. Understanding each stage helps ensure systems remain compliant throughout their lifecycle.
Concept
Although the conceptual stage falls outside the direct scope of GAMP 5 supplier activities, it is an important starting point. At this stage, manufacturers are considering automation opportunities, listing initial requirements, and searching for suitable computerized system suppliers.
Project
Once a suitable supplier has been selected, the project stage covers the design, configuration, development, deployment, and GxP assessment of the computerized system. Activities are guided by the manufacturer's requirements established during the conceptual stage, ensuring the system meets its intended purpose and regulatory requirements.
Earlier GAMP 5 guidance commonly used the V-model and waterfall approaches to structure system development and validation activities. However, the GAMP 5 Second Edition places greater emphasis on flexibility and supports different development methodologies, including Agile.
Agile is particularly relevant for modern computerized systems, including Software as a Service (SaaS) platforms and systems incorporating artificial intelligence (AI) and machine learning (ML). This enables faster rollouts to meet the evolving needs of life sciences customers in the case of SaaS, and constantly updating and improving performance in the case of AI and Machine Learning. That makes the Agile approach more practical for assessing GxP compliance in these systems.
Once the system has been developed, deployed, and assessed against its intended requirements, it can move into the operation stage of the GAMP 5 lifecycle.
Operations
During this phase, the computerized system is used in day-to-day operations, typically the longest phase in a product's lifecycle. The main objective here is to maintain the computerized system in a validated state. This is supported by the manufacturer's change control, configuration management, handover, support services, system monitoring, incident and problem management, CAPA, periodic review, backup and restore, business continuity and disaster recovery, security management, system administration, and archiving and retrieval.
Retirement
The retirement stage occurs when a computerized system reaches the end of its useful life or needs to be replaced by another system. During this stage, manufacturers carry out the system's decommissioning, retirement, or migration while ensuring that regulated data, records, and documentation remain accessible and secure.
Retirement is the fourth, formally defined phase of the GAMP 5 life cycle. It involves decisions on data retention, migration, or destruction, and data and documentation may not be disposed of before the end of their record-retention period.. According to the GAMP 5 guidelines, all the lifecycle stages of a computerized system should be defined within the quality management system (QMS).
3. Scalable lifecycle activities
GAMP 5 encourages scalable approaches when developing computerized systems. The Second Edition's new Appendix D8 on Agile software development complements this principle by supporting flexibility and adaptability.
GAMP 5 scales lifecycle activities according to the system's impact on patient safety, product quality, and data integrity (risk assessment), its complexity and novelty, and the outcome of the supplier assessment; business impact may also play a role, and the strategy should be defined in a plan. The development model (linear or Agile) is a separate choice.
A typical linear lifecycle includes the following stages:
4. Quality risk management
Manufacturers must prioritize patient safety, product quality, and data integrity. As such, computerized system attributes that directly or indirectly impact these areas should be thoroughly evaluated, with careful attention to their causes and effects.
Quality risk management plays a vital role in determining which tests should be prioritized over others. The risk-based prioritization helps spend more time and effort on critical aspects over non-critical ones.
GAMP 5 applies ICH Q9 through a five-step process:
- Perform an initial risk assessment and determine system impact,
- Identify functions with impact on patient safety, product quality, and data integrity,
- Perform functional risk assessments and identify controls,
- Implement and verify appropriate controls, and
- Review risks and monitor controls.
GAMP 5 2nd edition promotes a GxP risk-based testing approach that emphasizes testing over excessive documentation. For instance, it supports exception-based reporting, where a simple "Pass" is sufficient when the system works as intended. Additional evidence, such as screenshots, can be reserved for high-risk or critical tests where it adds value.
The emphasis is on identifying and investigating unexpected results or deviations that could affect system performance, patient safety, product quality, or data integrity. Similarly, minor documentation errors with little impact on these areas should not receive the same level of attention as critical issues. By prioritizing findings according to their potential impact, teams can focus investigations and corrective actions on the risks that matter most.
5. Leveraging supplier involvement
GAMP 5 also encourages leveraging supplier expertise throughout the system lifecycle, for example in requirements gathering, risk assessment, specifications, configuration, testing, support, and maintenance, to enable faster, more effective adoption. Supplier-provided validation packages can help meet GxP verification requirements, reducing duplication and serving as an additional layer of assurance.
Applying GAMP 5 principles requires more than following validation procedures. Organizations also need the right processes and tools to manage documentation, supplier activities, risk assessments, and changes throughout the computerized system lifecycle.
A digital quality management system (eQMS) can help centralize validation documentation, standardize quality processes, and maintain oversight while reducing the administrative burden of compliance.
GAMP 5 and computer system validation
Computer system validation (CSV) is the documented process of proving that a computerized system consistently performs as intended and complies with applicable GxP requirements. In regulated industries such as pharmaceuticals, biotech, and medical devices, CSV is not optional. It is a core expectation from authorities like the FDA and EMA.
GAMP 5 does not replace regulatory requirements for validation. Instead, it provides a practical, risk-based framework for executing computer system validation in a structured and efficient way. In fact, GAMP 5 is widely recognized as the industry standard approach to CSV.
How GAMP 5 supports CSV
At its core, GAMP 5 aligns computer system validation with a lifecycle model. This means validation is not treated as a one-time testing exercise at the end of implementation, but as a continuous process that begins with system concept and continues through retirement.
Under GAMP 5, CSV typically includes:
- Defining intended use and requirements (URS and functional or configuration specifications where needed)
- Performing risk assessments to determine the level of validation effort required
- Supplier assessment and leveraging vendor documentation where appropriate
- Verification and testing activities based on system category and risk
- Maintaining validation status through change control and periodic review
- Planning the validation in a validation plan and closing it with a validation report that states fitness for intended use
This approach ensures that validation efforts are proportional to patient risk, data integrity impact, and system complexity.
How does GAMP 5 make GxP validation faster?
GAMP 5 speeds up GxP validation by matching effort to risk: critical functions get thorough testing, while lower-risk functions rely more on supplier evidence and lighter testing. One of the key advantages of applying GAMP 5 to computer system validation is scalability. However, not all systems require the same depth of documentation and testing. For example, a highly configurable off-the-shelf system might require less extensive validation than a custom-developed application.
GAMP 5 helps organizations avoid over-validation while still maintaining compliance, by focusing on critical functionality and data integrity. This makes CSV more efficient, audit-ready, and aligned with modern quality management principles.
In short, GAMP 5 operationalizes computer system validation by providing clear structure, terminology, and best practices, so computerized systems remain compliant, controlled, and fit for intended use throughout their lifecycle.
GAMP 5 categories
GAMP 5 categorizes software components by increasing complexity, novelty, and inherent likelihood of residual defects, as a very high-level preliminary risk assessment. Category 2, associated with the firmware in GAMP 4, is removed from GAMP 5.
Firmware-based applications now fall under Category 3, and custom firmware under Category 5. The Second Edition keeps the same numbering (1, 3, 4, 5) but renames the categories and changes how they are used: most systems combine components of several categories, categories 3 to 5 form a continuum with no absolute boundaries, and the category is just one factor in a risk-based approach.
GAMP 5 category 1
Software type:
Infrastructure software, tools, and IT services: layered software (operating systems, database engines, middleware, programming languages), infrastructure software tools, and tools supporting lifecycle and IT processes.
Activity level:
- Not subject to specific functional Verification
- Features are functionally tested and challenged indirectly during the testing of the application.
- Identity and version numbers of layered software and operating systems should be documented and verified during installation.
- For software tools, assess and record the tool's adequacy for use
GAMP 5 category 3
Software type:
Standard system components: off-the-shelf software that cannot be configured to the business process, including software that only accepts run-time parameters (e.g., firmware-based applications, COTS software, some instruments).
Activity level:
- Verification of the installation
- Acceptance testing and "fitness for use"
- Typical approach: requirements for key functionality and intended use, risk-based supplier assessment, demonstration that the supplier has an adequate QMS, record version number and verify correct installation, risk-based testing against requirements as dictated by use, and procedures to maintain compliance
GAMP 5 category 4
Software type:
Configured components: software, often very complex, configured by the user to meet the business process without altering code.
Activity level:
Testing comprises:
- Correct installation and configuration
- Functional testing is conducted because of risk analysis or the supplier assessment
- Acceptance testing and "fitness for use" compared to requirements
GAMP 5 category 5
Software type:
Custom applications and components: software designed and coded to suit the business process, e.g., bespoke interfaces, custom-developed applications, custom ladder logic, custom firmware, and macros written in a product's scripting language.
Activity level:
Testing comprises:
- Correct installation
- Functional & Design Specification
- Functional testing based on risk assessment and supplier assessment
- Acceptance testing and "fitness for use" compared to requirements.
The likelihood of failures or defects generally increases from standard to custom software, which affects the probability (and sometimes the detectability) score in a risk assessment. The more the risk, the more rigorous computer system validation (CSV) approach is needed.
The higher the GAMP 5 category, the higher the activity needed to be performed at the specification and validation steps of the project phase. This approach enables manufacturers to make more rational decisions throughout the system's lifecycle.
The table below summarizes the main software categories, their validation activities, and the relative effort involved.
10 common GAMP 5 implementation mistakes to avoid
During one of our previous Scilife Quality Summits, we welcomed Angela Bazigos, a renowned leader in compliance consulting, to share her practical tips for integrating GAMP 5 into everyday operations.
She also highlighted the "10 Deadly Sins of GAMP", originally presented by Dr. Snipes from the FDA Enforcement Office at the 2009 SQA Annual Conference, insights that continue to remain relevant today.
Here are the top sins Snipes highlighted for companies to watch out for.
- No requirements
- No record of software version used
- Failure to archive all versions of design spec
- Lack of records of testing and input and output of testing
- Lack of forward and backward tracing (TM)
- Lack of defect tracking during testing
- No QAU (no check on trustworthiness of S/W)
- No re-evaluation or retesting when hardware is added
- Lack of hardware qualification (refers to infrastructure as well as app related software)
- Lack of adequate security
Throughout the session, Angela also gave her own tips and tricks from her many years of experience, such as using the same SOP for GxP and non-GxP systems:
"I have seen companies with two different SOPs for GxP systems vs non-GxP systems. From my experience, I have found that it's more efficient to have a single SOP to just reduce the amount of information that you need in the non-GXP systems."
She went on to explain that validation is essentially "good software engineering with documentation on steroids." The purpose is to deliberately slow things down, because these systems may be responsible for critical functions like keeping someone's heart beating or helping a newborn breathe.
And if you have different SOPs, people can run the wrong SOPs. For example, she worked with a large company that had 150 HPLC instruments and 150 Agilent systems. During an IT upgrade, the team mistakenly followed the non-GxP SOP while applying a patch. As a result, half of the systems crashed.
The organization then had to initiate CAPAs, implement change controls, and go through rounds of testing and retesting to restore compliance and functionality.
If you'd like to get more of her GAMP 5 best practices, don't miss her webinar: GAMP: From theory to action in compliance management.
Conclusion
While GAMP 5 guidelines are non-legally binding, they are crucial to ensure patient safety, product quality, and data integrity. The guideline's recommendations are coherent with current GxP requirements defined by the EU & US regulatory agencies, making GAMP 5 one of the most complete frameworks for computerized system validation in GxP environments. The Second Edition (2022) and the supporting GAMP Good Practice Guides extend this guidance to newer technologies such as cloud services, Agile, and AI/ML.
The GAMP 5 practical approach enables life sciences manufacturers to work hand in hand with the computerized system suppliers, noticeably reducing testing burden. Also, when applied correctly, GAMP 5 allows manufacturers to reduce validation and compliance maintenance time and costs, preparing manufacturers to face government audits and inspections efficiently.
