In the era of Industry 4.0, digital transformation in the regulated sector has ceased to be a competitive advantage and has become a survival requirement. However, integrating software into critical manufacturing processes is not a trivial process. Every line of code and every database in a pharmaceutical plant carries an ethical and legal responsibility: ensuring data integrity and, by extension, patient safety.
This is where the GAMP® 5 (Good Automated Manufacturing Practice) guide, published by ISPE, stands as our essential roadmap. Although it is not a legally mandatory regulation, GAMP® 5 is widely accepted by the industry and used as a reference framework to demonstrate the control and validation of computerized systems before regulatory authorities such as the FDA or EMA.
1. The risk-based approach: the heart of GAMP® 5
Unlike the rigid and linear validation models of the past, where a word processor was treated with the same rigor as a process control system (DCS), the GAMP® 5 proposes a pragmatic approach based on Product Quality Risk.
The modern goal is not to generate “mountains of paper” to satisfy an auditor, but to focus testing efforts on features that truly impact consumer health.
- Prioritization: Verification activities should focus on those functions that may impact product quality, data integrity, or regulatory compliance.
- Scalability: The rigor of the validation must be proportional to the complexity of the system and the risk detected.
- Efficiency: By identifying risks early (through an FMEA or similar analysis), fixes are made in the design phase, where they are up to 100 times cheaper than after implementation.
2. Software Categorization: Where do we stand?
To define a coherent validation strategy, we must first classify the technology. GAMP® 5 simplifies this process by dividing software into categories that guide the level of rigor needed during the system's lifecycle.
It should be noted that in previous versions of GAMP there was a Category 2 mainly associated with firmware, but this was eliminated in subsequent revisions of the model with the aim of simplifying the classification and focusing on the most relevant software types from a GxP point of view.
Currently, the model is structured into the following main categories:
Category 1: Infrastructure Software
Includes operating systems, engines database or network tools. These are not validated individually, but are managed under good IT practices (ITIL) and are considered “qualified” as part of the environment.
Category 3: Non-configured products (Off-the-shelf)
We talk about “ready to use” software where the user does not change the code or logic, just configure basic parameters (e.g. units of measurement). Validation here focuses on verifying that the installation is correct and meets the user's requirements.
Category 4: Configured Products
This is the most common category in the industry (ERP, LIMS, MES systems). The software provides standard tools that the user “configures” to tailor the workflow to your specific process. Here, the effort is focused on testing that particular configuration.
Category 5: Custom Applications
It is software developed to measure (custom code) for a unique need. Being the highest risk, it requires the complete life cycle: from source code review to extensive stress testing.
3. The System Life Cycle (V-Model) and Agility
He V model remains the primary visual reference for understanding systems validation. In today's industry, an “Evolved V-Model” has been developed that Enables continuous integrations and enhances scalability. It is recognized that not all systems require the same level of detail: the approach is tailored to risk and complexity. For simple systems, the “V” is compact and agile; For complex systems, the “V” is expanded, maintaining consistency with the need for control and validation.
| The basis: URS (User Requirements Specification) | It is, without a doubt, the most important document. If you don't know what you need, you can't validate that you have it. A poor URS is the number one cause of failed projects and regulatory deviations. |
| The analysis: Risk Assessment | This is where system functions are dissected to identify potential failures. What happens if the temperature sensor fails? What if the system allows you to delete a record without leaving a trace? |
| The design: Functional Specifications (FS) and Design Specifications (DS) | It is the technical response to the URS. This defines “how” the system will satisfy business and compliance requirements. |
| Confirmation: Verification (IQ/OQ/PQ) | · IQ (Installation Qualification): Is everything connected and configured according to the manual?
· OQ (Operation Qualification): Do alarms, limits and access controls work under normal and stress conditions? · PQ (Performance Qualification): Does the system produce consistent results within the actual manufacturing process? |
4. Data integrity (ALCOA+)
Today, a validation according to GAMP® 5 is incomplete without a deep focus on the Data Integrity. Regulatory agencies have moved from inspecting physical samples to exhaustively auditing digital systems.
For data to be complete, it must comply with the principles ALCOA+:
- Attributable: Who created the data and when.
- Legible: That can be understood throughout the retention period.
- Contemporary: Recorded at the exact moment of the action.
- Original: The first record or a certified copy.
- Exact: No errors or unauthorized edits.
The “+” symbol, an extension of the ALCOA concept, includes four additional attributes that focus on the comprehensive management of the data life cycle, especially its archiving, recovery and contextualization:
- Complete: The data must include all the information generated during a regulated activity .
- Consistent: The data and the sequence of events follow a logical and coherent order in all records.
- Enduring (perdurable): Data must remain reliable, secure and intact throughout the retention period
- Available: Data must be easily retrievable and accessible.
In current practice, many organizations apply the V-Model flexibly within agile development approaches, always maintaining traceability between requirements, design, verification and documentary evidence.
5. The challenge of cloud and SaaS in the GAMP® environment
One of the hottest topics today is the jump to the cloud (Cloud Computing) How do we validate software that resides on third-party servers (AWS, Azure) and is constantly updated?
GAMP® 5 (2nd Edition) addresses this by strengthening Supplier Management. It is no longer just the responsibility of the pharmaceutical company to validate the software; It is vital to audit IT providers to ensure that their development processes follow robust quality standards. Validation becomes a shared model of responsibility.
Conclusion: from reactive validation to operational excellence
Applying the GAMP 5 framework should not be understood as a purely documentary exercise, but as a strategic tool to manage the risk associated with computerized systems used in regulated processes.
When adopted correctly, GAMP® 5 allows you to move from reactive validation to a system lifecycle management approach, where design, implementation and operation are aimed at ensuring product quality, data integrity and regulatory compliance.
In an environment of increasing digitalization, having a structured framework such as GAMP® 5 makes it possible to integrate technological innovation and regulatory control in a coherent and sustainable way.
If your organization is implementing new IT systems or needs to evaluate the compliance status of its current platforms, our team can accompany you throughout the system life cycle.