Why GAMP 5 needed a 2nd edition
GAMP 5 (Good Automated Manufacturing Practice) is a risk-based approach for the implementation, operation, and validation of GxP computer systems in regulated industries – including the life sciences. It’s owned and maintained by the International Society for Pharmaceutical Engineering (ISPE).
Recent technological advances have forced many organizations to rethink their business models once they realized a noticeable number of activities and documentation no longer added value to their company.
That is why GAMP 5 2nd Edition, published in July 2022, is the most significant update in over 14 years. Its objective was to update guidance to contemporary practices and specifically eliminate burdensome approaches.
The 2008 legacy GAMP 5 focused too much on compliance and on avoiding inspection findings rather than advancing products and processes through new technologies. With the GAMP 5 2nd Edition, a novel critical thinking methodology has emerged as a cornerstone of the guideline. Now, the approach is more oriented toward patient safety, product quality, and data integrity.
Key takeaways
Structure of the new GAMP 5 2nd Edition
GAMP 5 2nd Edition consists of a main body text supported by a set of appendices. The main body establishes the overarching framework, setting out guiding principles and a lifecycle approach applicable to GxP-regulated computerized systems. The appendices complement this framework by providing practical, topic-specific guidance.
In the GAMP 5 latest version, several sections have been updated, new content has been added, and three sections have been retired and incorporated into other appendices.
The following is a summary of the main changes to the GAMP structure:
In particular, the updated edition refines and strengthens the following key topics:
- Emphasis on patient safety, data integrity, and product quality
- Enhanced process and product understanding
- Lifecycle approach embedded within a quality management system (QMS)
- Scalable lifecycle activities
- Science-based quality risk management
- Leveraging supplier involvement
In addition, other topics have been updated to reflect current and emerging technology, such as artificial intelligence (AI), machine learning (ML), and blockchain.
Recommended learning:
AI in the pharmaceutical industry - all the innovations and challenges you need to know!
The core principles of the GAMP framework have been maintained. Some appendices have been updated, and new appendices have been introduced for the first time in the history of GAMP 5.
Overall, these updates reflect the incorporation of novel technologies, evolving processes, and emerging technical topics, alongside the need to modernize guidance for system management, development, and operational use.
Overview of GAMP 5 2nd Edition
Overall, GAMP 5 2nd Edition now has appendices that reflect and guide the use of cutting-edge technology. The guide was based on one core objective: to “protect patient safety, product quality, and data integrity by facilitating and encouraging the achievement of [computerized] systems that are effective, reliable, and of high quality.”
The main issues addressed in GAMP 5 2nd Edition relate to innovation, emerging technologies, critical thinking, agile methodologies, and IT service management. The guidance shows a clear evolution from Computer Systems Validation (CSV) to Computer Software Assurance (CSA).
Linear Approach in 2008 vs. Agile Approach in 2022
The 1st edition of GAMP 5, published in 2008, suggested a linear approach for the development and validation of software. This approach made sense in the early 2000s, when software was static, and updates or new releases were less frequent: You bought an application, you installed it on your system, and validation (via CSV) was completed in a one-and-done process.
Back then, the so-called "GAMP 5 V Model” was the most commonly used approach for developing and validating computerized systems in GxP environments.
It’s essentially a waterfall model, where development and testing activities proceed linearly. In practice, this means working through a series of sequential steps:
- Analyze
- Plan
- Design
- Build
- Test
- Fix
- Test
- Deploy
The left side of the GAMP 5 V Model comprises verification activities (URS, Functional Specifications, Design), the right side comprises validation activities (Unit Testing, Integration Testing, System and Acceptance Testing), with the two sides connected through the Development Stage.
However, the waterfall “V model,” with its linear process, is not necessarily the most appropriate approach anymore.
Modern software development uses an iterative, incremental, and exploratory approach more akin to a cyclical process. The GAMP 5 2nd Edition, reflects this shift in mindset and culture by suggesting an agile approach to developing and validating computerized systems in GxP environments.
The Agile Model requires a discovery mindset (rather than a certainty mindset), which enables us to manage learning and adaptation throughout the development lifecycle in a controlled way:
As most of the applications we use today in quality management systems are cloud-enabled, the reality is that software is no longer static like it was back in 2008. Improvements are constantly being applied to the software we use (which includes QMS and other software operating in GxP environments).
The agile model is useful because it is iterative, incremental, and exploratory. Additionally, the use of risk-based methodology helps with ensuring full compliance with this new methodology.
New appendices (D8 to D11) on software development have been included in GAMP 5 2nd Edition, covering:
- Agile Software Development
- Artificial Intelligence and Machine Learning
- Software Tools
- Blockchain
Paradigm change: From documents to tools and systems
Clearly, we are moving away from traditional paper documents and toward keeping records and information in tools and systems.
In the early 1990s, the GAMP guide was primarily used to control suppliers of manufacturing equipment for the pharmaceutical industry. As a result, the GAMP 5 V model was adopted in the first four versions of the GAMP guide from 1994 to 2008.
At the time, this approach worked very well for manufacturing equipment and equipment with relatively simple computer-controlled configurations. But more suitable alternatives are now available.
With the recognition of agile methodologies in GAMP 5 2nd Edition as a non-linear approach for software development and validation, legacy validation documents from GAMP 1st Edition, such as installation (IQ), operation (OQ), and performance qualification (PQ) documents, are no longer considered relevant.
Critical thinking
A new appendix on Critical Thinking (M12) has been included in GAMP 5 2nd Edition. As a fundamental pillar of the guideline, critical thinking is, in my opinion, the most interesting addition to this new version.
Essentially, the appendix encourages the application of critical, patient-centered, risk-based thinking to software assurance and aligns GAMP 5 critical thinking principles with the new FDA guidance “Computer Software Assurance for Production and Quality System Software,” published in September 2022.
IT infrastructure
A new appendix on IT Infrastructure (M11) has been included in the Management Appendices of GAMP 5 latest version. The appendix also clarifies new expectations around electronic records, signatures, and audit trails.
ITIL approach to software development (IT Infrastructure Library)
All operation appendices have been brushed up and updated to reflect an IT QMS item approach, leading to more clarity in change management vs. problem management vs. incident management.
Free Computer System Validation template to validate any software and make sure its meet your requirements
Main changes in GAMP 2nd Edition
Changes to the introduction
Specific emphasis is given in this new version to apply critical thinking and risk-based approaches as a cornerstone to safeguard patient safety, product quality, and data integrity in the use of GxP computerized systems. Now, compliance is no longer the only focus of the guideline.
The guidance is now aligned with ISO 14971 for medical devices – application of risk management to medical devices and agile approach for development and validation.
The introduction covers the justification for updating most of the technical content of the guideline, not the main framework, to include the importance of IT providers, agile methodology, the use of software tools to be used throughout the lifecycle, the inclusion of artificial intelligence and machine learning (AI/ML), blockchain, cloud computing, and Open-Source Software (OSS).
The general framework, key concepts, system lifecycle, specification, verification approach, and Quality Risk Management (QRM) process remain unchanged.
M11 - IT infrastructure
This is an appendix that was originally identified as Appendix S5 in the first edition. This appendix applies current risk-based thinking on good practices for managing the infrastructure that resides within a regulated company’s own facilities, as well as to external suppliers based on the cloud (IaaS, PaaS, and SaaS).
Infrastructure must be managed to a controlled state. Both confirmation of components’ fitness for purpose and management to a controlled state are likely to involve automated processes.
The guideline suggests QA to have a reduced oversight in some minor changes, by having an agreement between IT and QA with a standard change list without the need for a formal change control. For example, when there is a need to perform a change with low-risk.
M12 - Critical thinking
This is a new appendix. Critical thinking is in favor of applying sufficient thought to ensure the approach taken is customized and proportionate to the needs of different systems.
A pragmatic approach is promoted that is against over-compliance and against activities that are non-value-added compliant. It is also against the use of rigid tables, predefined templates, and tick-in-the-box methods that could inhibit innovation and the adoption of new technologies.
A good practice is to map and understand processes. Risks should be found to ensure that the computerized system is fit for purpose with the best implementation strategy.
Critical thinking can be applied in all activities related to validation (preparation, execution, and review) to consider which activities add value. Only added-value activities should be considered for remedial actions. Here, more really is less.
D1 - Specifying requirements
There is a significant update to this appendix. The legacy GAMP 5 1st Edition contained separate appendices for User Requirement Specification (URS) and FRS (Functional Requirements Specifications).
Now they are combined into this appendix D1.
The main revision is about the use of Agile development methods and the use of tools and automation in the capture and definition of requirements. Requirements specifications can now be maintained in an appropriate management tool or in a document, depending on your methodology (agile V model).
All requirements are to be categorized and prioritized based on criticality to patient safety, product quality, and data integrity.
D5 - Testing of computerized systems
There is a significant update to this appendix, mainly related to the concept of computer software assurance (CSA). The appendix covers the testing of GxP computerized systems, offering information on the types of testing approaches that can be used for optimal assurance that the system is fit for its intended use. Testing should be limited in the use of GxP cases based on risk assessment.
Now, more testing is more important than more documentation. An example of this is the adoption of an exception-reporting approach to recording results. This means that if the system is working as intended, a simple “Pass” recording is enough.
There is no need to capture excessive screenshots as evidence in most of the tests. Only those tests that are critical may require additional screenshots as evidence. It is better to focus on unexpected issues to find the root cause and apply the proper corrective action. This is more valuable.
The guidance mentions that looking for minor errors in documentation gives little value and poses a low risk to patient safety, product quality, and data integrity. Hence, it is better to focus on other issues.
Regarding validation packages from suppliers, they can be effectively leveraged to satisfy the GxP verification requirements to avoid duplication. This acts as an additional layer of assurance. There is no reason not to use the validation package from the supplier: The more you can leverage, the better.
Regarding the person who executes the testing, GAMP 5 requires identifying who is performing the tests, as the quality of testing is significantly impacted by the knowledge and skill of the tester. At the same time, GAMP 5 states it is unnecessary to use test witnessing or to require the tester to initial every single test step to affirm they followed the instructions. A final signature at the end of the page is enough.
D8 - Agile software development
This is a new appendix. The focus is on how to use agile processes to deliver software for GxP applications without modifying the agile methodology to meet GxP requirements, for example, by superimposing linear (V-model) activities.
Some organizations are purchasing Software as a Service (SaaS) products from companies that are using agile software development, like the Jira tool. These companies are able to be agile to continually improve. They push updates while the regulated customer maintains the compliance state.
With agile, teams can deliver effective and useful software in a controlled way that is compliant with GxP regulations. It is a different mindset where discovery encourages acting, learning, and rapid continual improvement.
The guideline describes that the planning, specification, verification, and reporting activities are not inherently linear. Agile is compatible with other incremental, iterative, and exploratory models and methods.
Software development using an agile approach discovers and iterates ongoing changes as opposed to waterfall software development, used in the legacy guideline GAMP 5 1st Edition.
In addition, GAMP 5 2nd Edition clearly states that 21 CFR Part 11 is not applicable to the approval process of Agile methodology, as the approval is not equivalent to a traditional handwritten, which is a legally binding signature required by a predicate regulation. In other words, only Part 11 records need a special level of scrutiny.
The approval of software lifecycle deliverables can also be achieved by many other means (e.g., status change, email, audit trails).
D9 - Software tools
This is a new appendix that applies to software that is not a component or application in a GxP-regulated business process, like Jira. As they cannot directly impact GxP data/records, the predicate rules do not apply.
The guideline states that tools used in computerized systems lifecycle processes, IT processes, and IT infrastructure processes do not require computerized system validation. They can be managed by good IT practices. Instead, you can perform an IT risk assessment and procurement practice instead of formal validation.
D10 - Distributed ledger systems (Blockchain)
This is a new appendix. Currently, blockchain technology is not yet widely implemented in GxP environments.
However, blockchain technology could be used for very specific applications, such as the recording and tracking process and product activities across the product lifecycle, from the purchase of raw material to the final consumer, giving high security and transparency. An application could be for the use of audit trails and public or private networks.
D11 - Artificial Intelligence and Machine Learning
This is a new appendix. Artificial intelligence (AI) and machine learning (ML) are new technologies to automate many functions previously performed by humans. As long as you are able to define the boundaries of the AI and ML algorithm and the use case, the system can be validated. The use of key performance indicators acts as the technical specifications for the acceptability of the ML model.
S2 - Electronic production records
Due to the evolution of novel technologies, this appendix was updated significantly. There is more clarification on data audit trails and the frequency of data audit trail review according to predicate rules, and also for non-cGMP data.
Risk-based methods are to be used to define which audit trails should be reviewed and at what frequency.
Regarding backup and recovery of electronic data, it is basic to define the recovery point objectives (RPO) that dictate the frequency of backups, and the recovery time objectives (RTO) that dictate the interval between system failure and recovery. This period of time is expected to be in line with the system risk assessment.
Which appendices have been retired?
Appendix D2
- Functional specifications
- Appendix D2 Functional Specifications has been retired. The content has been incorporated into
- Appendix D1 Specifying Requirements.
Appendix O7
- Repair activity
- Appendix O7 has been removed. Repairs are to be managed as standard changes, service requests, and/or system administration tasks. The requirements for repair activities are now defined in Appendix O6.
Appendix S5
- Managing quality within an outsourced IS/IT environment
- Appendix S5 has been withdrawn. The revised content has been included in Appendix M11.
How technology is reshaping GAMP 5 implementation
Modern technology is reshaping GAMP 5 implementation by integrating automation, AI, and digital documentation systems into the validation lifecycle for software operating in GxP environments. Benefits include efficiency gains, better data integrity, and flexible risk-based validation approaches.
Implications of technologies on GAMP 5 implementation include:
- Shift towards Computer Software Assurance (CSA): By using automated tools for testing and evidence generation in validation approaches, technology enables greater emphasis on critical-thinking and automation approaches, and marks a departure from traditional CSV towards CSA.
- Efficiency and traceability: Software tools such as electronic QMS systems and automation of processes increase efficiency and enable automated traceability and documentation.
- Data integrity: Digital systems automate data capture and storage, which reduces human error, leading to increased data integrity and reduced time delays.
- Vendor assurance: Vendor assurance was once a one-time supplier qualification, but because of technology, this is shifting towards continuous, risk-based oversight updated in real-time. The quality systems of suppliers are becoming increasingly important, and allow organizations to monitor rather than duplicate validation testing.
From CSV to CSA: Streamlining software validation with a risk-based approach
Examples of how different technologies are being applied include:
- AI and ML are helping to shift GAMP 5 away from validating fixed functionality towards CSA. This means a focus on validating and assuring intended use, risk controls, and assessing ongoing performance.
Real-world example: AI-enabled pharmacovigilance (PV) systems can detect safety signals by triaging data from real-time adverse events and prioritizing them for human review. GAMP 5 assurance focuses on intended use, performance monitoring, and human oversight rather than validating exact algorithm outputs.
- Cloud SaaS is moving assurance activities away from local infrastructure testing toward supplier oversight (a part of which is vendor assurance through audits, certificates, and documentation).
Real-world example: Cloud-based QMS platforms, such as Scilife eQMS, are delivered as SaaS. Scilife software is aligned with GAMP 5 and CSA principles.
- Blockchain is reducing reliance on procedural controls by embedding data integrity and traceability directly into system design.
Real-world example: Blockchain is being used to increase clinical trial data integrity and traceability by using a blockchain-based ledger to track data submissions and amendments.
- Automation is replacing manual, document-heavy validation activities with repeatable, risk-based verification built into the lifecycle.
Real-world example: In a laboratory, automated scripts extract instrument data, perform predefined checks, and flag out-of-trend results for analyst review. GAMP 5 activities focus on verifying the automation logic and exception handling, reducing manual testing and documentation effort.
Case study: Implementing GAMP 5 for an AI-enabled pharmacovigilance system
Context
A mid-size pharmaceutical company implemented a commercial, AI-enabled PV system to support safety signal detection. The system uses machine-learning algorithms to analyse adverse event reports, literature, and real-world data, prioritising potential safety signals for human review. As the system influences patient safety decisions, it was considered GxP-relevant.
Challenge
Traditional CSV approaches, based on deterministic behaviour and extensive IQ/OQ/PQ testing, were not well-suited to this system. The AI models evolve over time, and outputs are probabilistic rather than fixed, making full upfront specification and static validation impractical.
GAMP 5 (Second Edition) approach
The company applied a risk- and intended-use-based GAMP 5 approach aligned with CSA principles:
- The system was classified as decision support, with final safety decisions retained by qualified medical professionals.
- User requirements focused on data sources, performance boundaries, transparency, and human oversight rather than exact algorithm outputs.
- Assurance activities relied heavily on supplier documentation, audits, and quality systems, reflecting the use of a commercial SaaS platform.
- Validation was treated as a lifecycle activity, supported by ongoing performance monitoring, drift detection, and defined triggers for review following model updates.
Outcome
The organization achieved a compliant, defensible implementation that supported innovation without compromising patient safety. Assurance was maintained through continuous risk management and operational controls rather than static validation documentation, demonstrating a practical shift from traditional CSV to a CSA-aligned GAMP 5 implementation.
Best practices for implementing GAMP 5 2nd edition
The GAMP 5 latest version is intended to be implemented with a critical thinking mindset. Best practices and considerations for implementing GAMP 5 guidelines within your pharmaceutical company’s validation processes include:
- Start with the intended use of the computerized system and the level of patient and data risk, not the system type.
- Apply critical thinking, don’t fall back on blanket validation templates.
- Scale activities based on risk and complexity.
- Leverage supplier oversight where you can and reduce duplicative testing.
- Embed assurance across the entire system lifecycle, not just go-live.
- When decisions affect patient safety, always design systems that require human oversight.
- Implement GAMP 5 training for validation professionals through the International Society for Pharmaceutical Engineering (ISPE), which owns and maintains GAMP 5 guidance.
Conclusion
GAMP 5, Second Edition, isn’t really about adding new rules. It’s about recognizing that the way we build and use software has changed — and that our validation mindset has to change with it.
Agile development, cloud platforms, automation, and AI don’t sit comfortably in linear, document-heavy models, and GAMP 5 acknowledges that. The real focus now is on understanding intended use, thinking critically about risk, and applying controls that genuinely protect patient safety, product quality, and data integrity.
In practice, this shift is as much about culture as it is about process. It means moving away from validation as a one-off compliance milestone and toward ongoing software assurance that’s part of day-to-day operations. Tools don’t replace judgment, but the right ones can make it easier to apply good judgment consistently and transparently.
That’s where modern, cloud-based quality systems can help. Platforms like Scilife eQMS are built to support GAMP 5 and CSA-aligned ways of working: enabling structured workflows, real-time visibility, and clear traceability without forcing teams back into rigid processes that no longer reflect how software actually works.
