Written by Hihara — Paddy & Water Inc. / Healthcare & Life Sciences

Risk-Based Computerized System Validation

A Practical Guide Aligned with Good Automated Manufacturing Practice 5 — 2nd Edition

June 2026

Introduction: What Is GAMP5?

0.1　Definition and Purpose of GAMP5

GAMP5 (Good Automated Manufacturing Practice 5) is a best-practice guide for the validation of computerized and automated systems used in GxP environments, published by ISPE (the International Society for Pharmaceutical Engineering). It is not a legal regulation, but it is widely referenced and recommended by the FDA, EMA, and PMDA as a validation methodology for GxP computerized systems, and it has established itself as the de facto industry standard.

The core principles of GAMP5 are the “Risk-Based Approach” and the “Life Cycle Approach.” GAMP5 rejects a uniform approach that requires the same depth of validation for every system and every function, and instead achieves appropriate quality assurance efficiently by adjusting the depth of validation according to the risk to patient safety, product quality, and data integrity.

0.2　History of GAMP

Edition	Year Published	Key Characteristics
GAMP 1	1994	Published by the UK pharmaceutical industry (GAMP Forum). Verification methodology for automated manufacturing systems
GAMP 2	1995	Expanded scope; alignment with European regulations
GAMP 3	1998	Introduction of software categories (1-5). Systematization of validation strategy
GAMP 4	2001	Explicit introduction of risk management; added support for spreadsheets
GAMP 5 (1st Edition)	2008	Taken over by ISPE. Full adoption of the risk-based approach. Alignment with ICH Q9 (Quality Risk Management). Software categories reorganized into Cat. 1, 3, 4, and 5
GAMP 5 (2nd Edition)	2022	Support for cloud, SaaS, and AI. Strengthened support for Data Integrity and Agile development. An integrated approach to CSV from QMS

GAMP5 Is Not a “Regulation” but an “Industry Best Practice”

Common misconception: “Failing to comply with GAMP5 constitutes a regulatory violation.” Correct understanding: “GAMP5 is a recommended approach for satisfying regulatory requirements (GMP, 21 CFR Part 11, EU Annex 11).” Even if a company does not follow GAMP5, it is not a regulatory violation as long as it performs validation using another approach that satisfies GxP regulatory requirements. However, GAMP5 is recognized by regulatory authorities as “an appropriate approach,” and being able to explain during an FDA or EMA inspection that “validation was performed in accordance with GAMP5” is a significant strength when responding to inspections.

Chapter 1: Software Category Classification

1.1　Purpose of Category Classification

GAMP5’s software categories systematize the concept that “the depth of validation is determined by the type of software and the degree of customization.” For software with little customization, the developer has already performed testing, so the validation that the pharmaceutical company needs to perform is more limited. The more customization there is, the more important testing by the pharmaceutical company becomes.

Overview of the GAMP5 Software Categories

Category 1: Infrastructure Software Examples: OS (Windows, Linux), RDBMS (Oracle, SAP HANA), virtualization platforms, network equipment → Sufficiently tested by the manufacturer. Focuses on installation verification (equivalent to IQ) Category 3: Non-Configured Products (off-the-shelf products with no configuration) Examples: general-purpose document management tools (no configuration changes), office software (for administrative use) → Used without configuration changes. Functional testing centered on OQ is performed Category 4: Configured Products (off-the-shelf products that are configured) Examples: SAP S/4HANA, Veeva Vault, LIMS (products that are configured for use) → Validation of the product’s configuration and customization content. The most commonly used category Category 5: Custom Applications (in-house developed) Examples: in-house developed manufacturing management systems, proprietary add-ons → Requires a complete V-model validation covering the entire process (URS→FS→DS→IQ→OQ→PQ) * Category 2 (configurable infrastructure) was merged and discontinued in the 2nd Edition

1.2　Details of Each Category

Category 1: Infrastructure Software

Infrastructure software such as operating systems and databases is extensively tested by the manufacturer before being brought to market. From the GAMP5 perspective, the appropriate approach is to “leverage the manufacturer’s test evidence while performing installation verification (equivalent to IQ) for one’s own environment.” Specifically, the main activities are confirming the installation, recording configuration parameters, and verifying licenses.

Category 3: Non-Configured Products

These are off-the-shelf software products used without configuration changes. Because the manufacturer’s development testing is extensive, the pharmaceutical company’s validation activities center on “confirming fitness for intended purpose (equivalent to OQ).” However, the scope of testing is adjusted according to the degree of impact on GxP operations.

Category 4: Configured Products

SAP S/4HANA is a representative example of Category 4. Although the product itself has been tested by the manufacturer, the “configuration (Customizing)” performed by the pharmaceutical company according to its GxP operations must be validated to confirm it works correctly. OQ and PQ are used to confirm whether the business requirements defined in the URS are realized as configured functions of SAP.

Category 4 (SAP, etc.) Validation Activities	Content	Key Evidence Documents
URS Creation	Defining GxP business requirements, regulatory requirements, and data requirements in business terms	User Requirements Specification (URS)
Supplier Assessment	Confirming SAP’s SDLC, quality management, and support structure	Supplier Assessment Report (audit or documentary assessment)
Configuration Specification Creation	Recording SAP’s configuration content (Customizing, master data settings) as a specification	Configuration Specification (equivalent to CS/DS)
IQ Execution	Confirming that SAP’s installation and configuration match the approved specification	IQ Protocol, IQ Report
OQ Execution	Confirming that the configured functions operate according to the FS specification	OQ Test Scripts, OQ Report
PQ Execution	Confirming that the intended purpose is achieved in actual business scenarios (UAT can be leveraged as PQ)	PQ Protocol, PQ Report
Validation Report	Summary, conclusions, and residual risk of all validation activities	Validation Summary Report (VSR)

Category 5: Custom Applications

In-house developed systems are classified as Category 5 and require the most rigorous validation. Because the developer serves as both the manufacturer and the pharmaceutical company, GxP control is required across the entire software development life cycle (SDLC). SAP add-on development is also often treated as Category 5.

Chapter 2: The Risk-Based Approach

2.1　The Three Axes of GxP Risk

GAMP5’s risk-based approach evaluates the risk of computerized systems based on the principles of ICH Q9 (Quality Risk Management). The three axes of evaluation are “patient safety,” “product quality,” and “data integrity.” Systems and functions that pose a high risk to these areas receive deeper validation, while areas of low risk are addressed with minimal verification.

Risk Assessment Perspective	High Risk (detailed validation required)	Low Risk (simplified validation acceptable)
Impact on patient safety	Errors in manufacturing orders → over-/under-dosing; errors in shipment release systems → shipment of non-conforming product	Internal approval workflows (only indirectly affect product quality)
Impact on product quality	Mismanagement of raw material test data; errors in recording manufacturing conditions	Financial management systems (no impact on product quality)
Data integrity	No audit trail → tampering cannot be detected; deficient electronic signatures → lack of reliability in the approval process	Read-only reference dashboards (systems that do not alter data)

2.2　Procedure for Conducting a Risk Assessment

A risk assessment based on GAMP5 takes a phased approach, beginning with an evaluation of the entire system (System Impact Assessment) and then, for systems that affect GxP, proceeding to a detailed function-level evaluation (Function Risk Assessment).

The Two-Stage Risk Assessment Approach

[Stage 1: System Impact Assessment (SIA)] Evaluate the system as a whole to determine “whether it affects GxP operations” → No GxP impact: outside the scope of CSV. Standard IT management alone is sufficient → GxP impact present: proceed to Stage 2 [Stage 2: Function Risk Assessment (FRA)] Evaluate each function of a system that has been determined to have GxP impact Evaluation axes: ① Impact on patient safety (high/medium/low) ② Impact on product quality (high/medium/low) ③ Impact on data integrity (high/medium/low) Determine the depth of validation based on the evaluation results: ・”High” on all axes → IQ+OQ+PQ, comprehensive testing, detailed traceability ・Some axes “medium” → OQ+PQ, testing of key functions only ・”Low” on all axes → PQ only, or leveraging supplier test evidence alone

Chapter 3: The GAMP5 Life Cycle Model

3.1　Overview of the System Life Cycle

GAMP5 requires that computerized systems be managed across the entire life cycle of “procurement/development → operation → retirement.” Validation is not a “temporary testing activity performed before go-live,” but a life cycle activity that continues until the system is retired.

Life Cycle Phase	Key Activities	Key Documents
Concept Phase	GxP impact assessment (SIA); registration in the system catalog; determination of validation strategy	GxP Impact Assessment; Validation Plan (VP)
Project Phase	Creation of User Requirements Specification (URS); supplier assessment; creation of design/configuration specifications; execution of IQ, OQ, PQ	URS, FS/DS, CS; Supplier Assessment Report; IQ/OQ/PQ Protocols and Reports
Operation Phase	Change control; periodic review; incident management; ongoing user training	Change Control Records; Periodic Review Report; Incident Records
Retirement Phase	Data migration planning and execution; system retirement planning; archiving and storage of GxP records	Data Migration Validation Report; Retirement Records and Archive Evidence

3.2　Supplier Qualification

GAMP5 positions “Supplier Qualification (SQ)” — the evaluation of the quality management system of a computerized system’s supplier (manufacturer, systems integrator, or cloud provider) — as an important activity. If the supplier’s SDLC (software development life cycle) is mature, the validation burden on the pharmaceutical company can be reduced.

Method of Supplier Assessment	Applicable Situations	Content Confirmed
Documentary Assessment (Desk Top Review)	Category 1 and low-risk Category 3	Quality manuals and SDLC descriptions; third-party certifications such as ISO 9001 and ISO 27001; validation support documents provided by the supplier
Questionnaire Assessment	Medium-risk Category 3 and 4	Details of the SDLC, change management, and test management; history of quality defects and recalls; security measures and business continuity plans
On-site Audit	High-risk Category 4 and 5	Verification of the actual facilities, organization, and processes; sample review of validation documents; confirmation of nonconformances and corrective actions

3.3　FAT and SAT (Factory Acceptance Testing and Site Acceptance Testing)

For Category 4 and 5 systems, factory acceptance testing (FAT) performed at the supplier’s factory before shipment, and site acceptance testing (SAT) performed at the pharmaceutical company’s site upon receipt, are important elements of validation.

Test Type	Location	Performed By	Purpose	Position within GAMP5
FAT (Factory Acceptance Test)	Supplier’s factory, or online	Supplier + pharmaceutical company representatives	Confirm before delivery that the system operates according to the agreed design specification	Can be leveraged as part of OQ (evidence is retained)
SAT (Site Acceptance Test)	Pharmaceutical company’s production environment	Pharmaceutical company + supplier	Final confirmation of installation, configuration, and functionality in the production environment	Leveraged as confirmation of completion of IQ and OQ

Chapter 4: Documentation Requirements

4.1　The Documentation Framework Required by GAMP5

GAMP5 holds the principle of “achieving the maximum necessary quality assurance with the minimum necessary documentation.” It rejects the creation of documentation for documentation’s sake (paperwork minimization) and requires the creation of documents that genuinely contribute to quality assurance. The documentation framework is determined according to risk, and the same set of documents is not required for every system.

Document	Abbreviation	Purpose	Degree of Necessity
Validation Plan	VP or VMP	Defines the validation strategy, scope, schedule, and organization	Mandatory for all categories
GxP Impact Assessment	SIA	Record of the evaluation of the system’s GxP impact	Mandatory for all systems
User Requirements Specification	URS	Defines business, regulatory, data, and security requirements	Mandatory for Cat. 4 and 5; simplified version for Cat. 3
Functional Specification	FS	Defines the URS as functional requirements	Recommended for Cat. 4 and 5
Design Specification (Configuration Specification)	DS/CS	Records the technical implementation and configuration content	Cat. 4: Configuration Specification; Cat. 5: Design Specification
IQ Protocol and Report	IQ	Installation and configuration verification tests and results	All categories
OQ Protocol and Report	OQ	Functional test records and results	Cat. 3, 4, and 5
PQ Protocol and Report	PQ	Business scenario test records and results	Cat. 4 and 5
Supplier Assessment Report	SER	The supplier assessment process and its conclusions	According to risk
Validation Summary Report	VSR	Summary, conclusions, and residual risk of all validation activities	All categories
Periodic Review Report	PR	Record of periodic confirmation of validation status	All categories (periodic)

4.2　The Traceability Matrix

A traceability matrix is a document that cross-references which FS, DS (configuration specification), and test case each URS requirement corresponds to. It ensures bidirectional traceability by answering the questions: “Is this requirement reflected in the design?”, “Has this design been tested?”, and “Which requirement does this test verify?”

Structure of a Traceability Matrix (Example)

Requirement ID │ URS Description │ FS Reference │ CS Reference │ Test ID │ Test Result ────────┼───────────────────┼───────────┼───────────┼───────────┼────────── URS-001 │ Can create and approve │ FS-012 │ CS-SAP-07 │ OQ-045 │ PASS │ batch records electronically │ │ │ PQ-023 │ PASS URS-002 │ Automatically generates │ FS-018 │ CS-SAP-11 │ OQ-052 │ PASS │ an audit trail │ │ │ URS-003 │ Role-based │ FS-005 │ CS-SAP-03 │ OQ-031 │ PASS │ access control │ │ │ OQ-032 │ PASS This matrix makes it possible to: ・Identify at a glance any untested requirements (rows with a blank Test ID) ・Trace requirements with a FAIL test result back to the URS ・When an inspector asks “Where is this URS requirement tested?” 　immediately present the corresponding test record

Chapter 5: Data Integrity and GAMP5

5.1　Data Integrity Has Become a Central Theme of GAMP5

In the 2nd Edition of GAMP5 (2022), support for Data Integrity (DI) was significantly strengthened. Since 2016, data integrity findings by the FDA, MHRA, and PMDA have increased sharply, and ensuring the reliability of GxP electronic records has become the most critical theme in CSV and GAMP5 implementation.

Data Integrity Principle	Implementation in System Design and Validation
Data is recorded immediately at the time it is generated (contemporaneous)	The system automatically applies timestamps; the design prevents retroactive correction of manual entries
Data has not been tampered with (accurate and complete)	All changes are recorded in the audit trail; the design prevents deletion or overwriting (soft delete only)
All corrections must be recorded with a reason	A function that requires entry of a “reason for correction” when making corrections; both the original data and the corrected data are retained
The approval process can be proven with evidence	Implementation of electronic signatures; recording of “who approved what, and when”
Backup data has the same reliability as production data	Periodic restore testing from backups; retention of restore test records

5.2　GAMP5 Compliance for Spreadsheets (Excel)

In the pharmaceutical industry, Excel spreadsheets are widely used for quality control, stability evaluation, and process validation calculations. Excel spreadsheets used for GxP purposes correspond to GAMP5 Category 4 or 5 (depending on use) and require appropriate validation.

Key Points for Validating GxP Excel Spreadsheets

① Determine the type of spreadsheet and how it will be managed ・Manage as a version-controlled template file (e.g., .xltx), separate from the copy used for data entry ・A change management mechanism is needed if multiple people will edit it ② Perform functional testing ・Confirm that all formulas calculate correctly (equivalent to OQ) ・Confirm input value range checks and error message behavior ・Confirm calculation results for normal, abnormal, and boundary values ③ Define requirements equivalent to a URS ・Clarify “what calculations this spreadsheet is used to perform” ・Clarify “which cells are input cells and which are calculation result cells” ・Clarify “which data affects GxP” ④ Version control ・Manage changes to formulas as version upgrades ・Data created with an older version can be reproduced and verified using that older version ⑤ Data protection ・Lock (protect) formula cells to prevent unintended modification ・Manage the protection password via an SOP [Note] Excel’s “Track Changes” feature may not satisfy GxP audit trail requirements. Its use restrictions should be clearly defined.

Chapter 6: Key Changes in GAMP5 2nd Edition (2022)

6.1　Background to the 2nd Edition

Since the 1st Edition of GAMP5 was published in 2008, the environment surrounding computerized systems has changed significantly. The spread of cloud and SaaS, the rise of agile development methodologies, the use of AI and machine learning, and strengthened regulation of data integrity — the 2nd Edition was published in 2022 to address these changes.

Key Changes in the 2nd Edition	Difference from the 1st Edition	Impact on Practice
Support for cloud and SaaS	Assessment of cloud providers; support for the shared responsibility model	Clarified validation strategy for using SaaS in a GxP environment
Abolition of Category 2	Cat. 2 (configurable infrastructure) abolished and merged into Cat. 1	Simplified infrastructure validation approach
Support for agile development	Added a GxP management approach for sprint-based development	CSV can now be applied to development methodologies other than waterfall
Strengthened data integrity	Revised structure to place DI requirements at the center of validation activities	DI risk evaluation is now explicitly incorporated into SIA and FRA
CSV from QMS	Validation is managed in an integrated manner as part of the QMS (quality management system)	Promotes integration of CSV with QMS activities such as change management, CAPA, and training
Strengthened supplier assessment	Development of an assessment framework that includes cloud providers and SaaS vendors	Clarified assessment methods for Microsoft, SAP, AWS, and others

6.2　Applying GAMP5 in an Agile Development Environment

Under the CSV approach that assumes traditional waterfall development, it was difficult to accommodate agile (sprint-based) development. In the 2nd Edition, GAMP5 presents an approach for maintaining GxP compliance even in agile development.

Principles for CSV in Agile Development

Principle ①: The risk-based approach does not change → Even if the development methodology changes, the criteria for judging “what to validate and to what depth” remain the same → Perform FRA early in the sprint to clarify validation requirements Principle ②: URS can be expressed as “User Stories” → Agile User Stories (in the format “As a ___, I want to ___ so that I can ___”) can be 　 documented as URS requirements → Evaluate the GxP impact of each User Story and predefine test criteria Principle ③: Sprint releases are accompanied by evidence → At each sprint release, retain evidence (test records) of “what was tested and what the results were” → Automated test results from CI/CD (continuous integration) can also be used as GxP evidence Principle ④: Changes to GxP functions go through change management → Integrate agile backlog management with GxP change management → Evaluate at each sprint whether the functions added or changed in that sprint affect GxP

Chapter 7: A Practical GAMP5 Guide — Approaches by Category

7.1　Validation Practice for SAP S/4HANA (Category 4)

SAP S/4HANA is a representative example of GAMP5 Category 4 (configured products). Validation is required for SAP modules used in GxP operations (manufacturing, quality control, logistics, etc.). The following are key points in the validation practice for SAP S/4HANA.

SAP S/4HANA Validation Point	Rationale	Practical Considerations
The SAP software itself is treated as Category 1	The software platform provided by SAP (ABAP infrastructure, etc.) has been extensively tested by SAP, so manufacturer test evidence is leveraged	Leverage the SAP Trusted Partner Program and ISO certifications/SOC reports as supplier assessment evidence
Customizing (configuration) is the object of Category 4 validation	Confirm that the content configured through SAP Customizing (approval workflows, quality management settings, etc.) operates correctly	Record the configuration content in a Configuration Specification and test it via OQ
Add-ons are Category 5	Proprietary programs (ABAP) that extend SAP’s standard functionality are Category 5 and require SDLC management	Perform URS, FS, DS, and testing for add-ons using the standard V-model; retain design documents and test records
Upgrades (EHP, SP) require change management	Applying SAP Enhancement Packages or Support Packages requires an assessment of the impact on GxP functions	Prior confirmation in a test environment; verification of the impact scope through regression testing; creation of change management records

7.2　Validation Practice for LIMS (Category 4)

A LIMS (Laboratory Information Management System) is one of the most important GxP systems in quality control testing for pharmaceutical and life sciences companies. Because it is responsible for recording, managing, approving, and reporting test results, its impact on data integrity is at the highest level, and it requires the most rigorous validation.

Key Points to Confirm When Validating LIMS	Content
Electronic recording requirements for test results	Whether the entire process of entering, calculating, and approving measured values is recorded in compliance with 21 CFR Part 11
Completeness of the audit trail	Whether all changes, approvals, and deletions of test results are recorded in the audit trail; whether the design prevents users from deleting or modifying the audit trail
Automatic determination against specification values	Where pass/fail determination against specification values is automated, verify via OQ that the calculation logic is correctly implemented
Coordination with test method validation	Whether the test methods registered in LIMS (reagent quantities, acceptance criteria, etc.) match the validated test methods
Data import	Verify the accuracy, completeness, and traceability of automated data import functions from instruments (HPLC, UV, etc.)

7.3　Validation Practice for MES (Category 4-5)

An MES (Manufacturing Execution System) is a middle-layer system that connects the shop floor with the upper-level planning system (ERP). It has functions such as the deployment of manufacturing orders, collection of production results, management of process parameters, and electronic batch records, and its GxP impact is very high.

The Most Important Points to Confirm When Validating MES

① Completeness of the Electronic Batch Record (EBR) Verify that the complete manufacturing process record (raw material usage, process parameters, operators, approvals, etc.) is recorded electronically and contains information equivalent to a paper batch record ② Consistency of the interface with ERP Confirm via PQ business scenario testing that the transfer of manufacturing orders from SAP PP to MES, and the transfer of results from MES to SAP, is accurate and complete (exception flows such as “split orders, rework, and disposal processing” must always be verified) ③ Reliability of data collection from PLCs Confirm that process data (temperature, pressure, etc.) collected by MES from PLCs and sensors on the shop floor is recorded accurately and that timestamps are accurate ④ Integration with environmental monitoring data Where temperature, humidity, and differential pressure monitoring data for manufacturing areas is integrated into MES, verify the behavior of alarm settings, recording, and deviation notifications

(End)

Chapter 8: Good Practice Guides (GPG) — Supplementary GAMP5 Guidance Documents

8.1　What Are GPGs?

In addition to the main GAMP5 body, ISPE (the International Society for Pharmaceutical Engineering) publishes a series of Good Practice Guides (GPGs) that provide detailed guidance on specific topics. GPGs are practical supplementary materials to the GAMP5 framework, showing concretely “how to apply the principles described in GAMP5 to this system and this situation.” The main body of GAMP5 presents the principle of “make risk-based decisions,” while the GPGs contain practical examples of “how, specifically, to make that decision.”

Major GAMP5 GPG Titles	Target Audience / Use	Year Published
IT Infrastructure (Operation Qualification)	A guide specialized in the qualification of IT infrastructure (servers, networks, virtualized environments); serves as a common language between IT teams and validation teams	2021
Records and Data Integrity	How to implement data integrity (DI) within the GAMP5 framework; how to build ALCOA+ principles into system design	2017
A Risk-Based Approach to Compliant GxP Computerized Laboratory Systems	Applying GAMP5 to laboratory systems such as LIMS, Chromatography Data Systems (CDS), and ELN	2012 (under revision)
Electronic Data Management (Using an Operational DMS)	GxP management of document management systems (DMS) and electronic documents; life cycle management of GMP documents	2010
Testing of GxP Systems	A practical guide to validation testing (IQ/OQ/PQ); concrete methods for test design, execution, and documentation	2012
Validation of Process Control Systems	A practical guide to validating PLCs, DCS, and SCADA; validation methods specific to process control	2014
Cloud Computing (Appendix to GAMP5 2nd Ed.)	Applying GAMP5 to cloud systems; validation by IaaS/PaaS/SaaS classification	2022 (2nd Edition appendix)

8.2　Scenarios for Using GPGs

Representative Scenarios in Which GPGs Should Be Used

[When newly introducing a LIMS] → Refer to the 'A Risk-Based Approach to GxP Computerized Laboratory Systems' GPG → Confirm how to address risks specific to LIMS (sample mix-ups, integrity of test results, OOS management) [When introducing a cloud ERP or SaaS system] → Refer to the 'Cloud Computing' Appendix → For SaaS, confirm the audit requirements for the supplier (cloud vendor) and the approach to the scope of validation the user should perform [When validating a DCS or PLC] → Refer to the 'Validation of Process Control Systems' GPG → Confirm the testing methods and alarm validation techniques specific to real-time control systems, which differ from office IT [When unsure how to design validation tests] → Refer to the 'Testing of GxP Systems' GPG → It contains concrete templates for the scope and test case design methods of 　 each test phase (IQ/OQ/PQ)

Chapter 9: A Deeper Look at Infrastructure Qualification (IQ)

9.1　Scope of Infrastructure IQ

While software OQ and PQ tend to attract the most attention, the higher-level validation cannot be valid if the IQ of the underlying hardware, network, OS, and security configuration is insufficient. In the 2nd Edition of GAMP5, it was made clear that “the qualification of IT infrastructure is just as important as software validation.” Especially in today’s cloud environments, it is essential to clarify the division of infrastructure validation responsibility (vendor vs. user).

IQ Target	Example Verification Items	Form of Evidence
Hardware (servers, storage)	Whether the model number and specifications match the specification document; confirmation of RAID configuration and redundancy settings; confirmation of UPS (uninterruptible power supply) operation; records of rack installation and cabling	Installation record photos; a checklist comparing against the hardware specification; screenshots of BIOS/UEFI settings
OS / Middleware	Records of OS version and patch level; time zone and NTP server settings; a list of installed components; startup settings for services and processes	Installation records; a list of OS configuration parameters; command output such as systeminfo / uname -a
Network	Confirmation of IP address and DNS hostname settings; confirmation of firewall rules; VLAN configuration and bandwidth settings; expiration date and configuration of SSL/TLS certificates	Comparison against the network configuration diagram; a list of firewall rules; detailed SSL certificate information
Security configuration	Password policy (complexity, expiration); confirmation that unused accounts have been disabled; confirmation that logging (audit trail) is enabled; antivirus configuration and definition file updates	Screenshots of security policy settings; a list of user accounts; a security scan report
Backup / DR	Confirmation of backup job configuration; execution of backup and restore testing; confirmation of alignment with RTO/RPO targets; confirmation of replication to the DR site	A list of backup job configurations; restore test records; a DR drill report

Chapter 10: Applying GAMP5 to AI and Machine Learning Systems

10.1　Characteristics of AI/ML Systems and Validation Challenges

AI and machine learning (ML) systems have fundamentally different characteristics from conventional software. Conventional software operates according to programmed rules, whereas ML-based systems perform inference using a statistical model learned from data. This “uncertainty arising from learning” introduces new challenges for GxP validation. The 2nd Edition of GAMP5 includes a discussion of AI/ML applications, and ISPE is currently developing a dedicated AI/ML GPG.

Challenge of AI/ML Systems	Difference from Conventional Systems	Validation Response
Uncertainty of output	Conventional: same input → same output. ML: probabilistic output — a “prediction” by the model, with no guaranteed correct answer	Define thresholds and confidence intervals; predefine passing criteria for model performance metrics (accuracy, recall, etc.)
Black-box nature	For neural networks and similar models, explaining the inference process is difficult (the need for explainable AI)	Restrict use for critical decision-making; maintain a human review process; adopt explainable AI algorithms
Model drift	Model performance may degrade over time after going into production	Periodic monitoring of model performance; defined triggers for retraining and revalidation; model version control
Quality of training data	Bias or gaps in the training data directly affect output quality	GxP management of training data sets; documentation of data preparation; tracking of data lineage

10.2　Validation Strategy for AI/ML Systems

Under the current view of ISPE and PDA, AI/ML systems are recommended to be treated as “GAMP5 Cat. 5” and to have a high risk level of validation applied. In particular, the separation of the model’s “training, validation, and testing” into three stages, and documentation of the results of each, is required. Additionally, in the use of AI for GxP purposes, the principle of “human in the loop” is emphasized, whereby the final decision is made by a “trained human.”

Framework for Validating AI/ML Systems

[Step 1: Define Use and Risk] ・Which GxP operation the AI will be applied to (e.g., visual inspection, anomaly detection, predictive maintenance) ・Evaluate the impact of an incorrect output on patient safety and product quality ・The role of human review processes (whether to use AL or HITL) [Step 2: Manage and Document the Dataset] ・The split policy for training, validation, and test data (e.g., 70/15/15) ・GxP management of training data (version control, provenance, records of preprocessing) ・Evaluation of and countermeasures for data bias [Step 3: Document Model Development and Selection] ・Record the algorithm and hyperparameters used ・The rationale for model selection (evaluation metrics, comparison results) ・Version control of model files [Step 4: Performance Verification (equivalent to OQ)] ・Acceptance criteria: accuracy, recall, specificity, AUC, etc. ・Confirmation of performance on an independent test dataset ・Testing under worst-case conditions (edge cases) [Step 5: Operational Monitoring Plan (equivalent to PQ)] ・Ongoing performance monitoring using production data ・Thresholds and alert settings for drift detection ・Establishment of SOPs for retraining and revalidation

Chapter 11: Data Integrity by Design — Building In DI from the Design Stage

11.1　The Concept of “Building In” DI to a System

Addressing Data Integrity (DI) by “enabling the Audit Trail after the fact” or “mandating DI via an SOP” alone is insufficient. What regulatory authorities require is that “DI be built in from the system’s design stage (Data Integrity by Design).” This is also consistent with GAMP5’s principle of “integration of quality risk management.” It is important to translate each ALCOA+ principle into system requirements and define DI requirements starting from the URS (User Requirements Specification) stage.

ALCOA+ Principle	Example Translation into URS (for LIMS design)
Attributable — who did what, and when	・User IDs and passwords are assigned to individuals and must not be shared ・All operations (entry, correction, deletion, approval) automatically receive a user ID and timestamp ・The audit trail must not be manually alterable or deletable
Legible — readable and understandable	・Electronic records remain accessible in a human-readable form throughout the retention period ・UX requirements for font size and display format ・Formatting requirements for printing
Contemporaneous — recorded at the time it is performed	・Test results are captured automatically from instruments (minimizing manual entry) ・The difference between the time of testing and the time of entry is within a configured value ・Automatic timestamping of the approval workflow
Original — preservation of original data	・Raw data is preserved and cannot be overwritten ・When corrections are made, the original is retained along with the corrected value ・Data acquisition from instruments uses bidirectional integration (automatic linkage rather than re-entry)
Accurate — accuracy of data	・Fixed and validated formulas ・Automatic unit conversion and prevention of input errors (input validation) ・Validation of the accuracy of instrument integration
Complete	・Mandatory required fields (cannot save blank) ・Transition to approved status only after confirming that all test items have been recorded ・Deletion is logical only (physical deletion is not possible; a reason for deletion must be recorded)
Consistent	・Unified date/time format and time zone settings ・Consistency checks against master data (item codes, etc.)
Enduring	・Backup and DR plans ・Lifespan and migration planning for storage media ・Confirmation of the cloud vendor’s data retention policy SLA
Available	・Maintenance of search, retrieval, and printing functions throughout the retention period ・Ensuring alternative access methods after retirement

Chapter 12: Applying GAMP5 to Cloud Computing

12.1　Cloud Service Models and the Division of Validation Responsibility

The Cloud Computing Appendix of the GAMP5 2nd Edition organizes, for each service model (IaaS, PaaS, SaaS), what “validation the user must perform” and what “can be addressed by delegating to the vendor.” The biggest characteristic of cloud services is that part or all of the infrastructure that a user traditionally managed is now managed by the vendor. This represents a transfer of validation responsibility, but the GxP responsibility itself remains with the user.

Service Model	Scope Managed by the Vendor	Validation the User Must Perform
IaaS (Infrastructure as a Service)	Physical hardware; network infrastructure; virtualization layer	IQ of the OS and middleware; full validation of the application; confirmation of the vendor’s data center certifications
PaaS (Platform as a Service)	Physical hardware; OS and runtime environment; database infrastructure	IQ/OQ of the application configuration; functional validation of the application; assessment of the impact of platform changes
SaaS (Software as a Service)	Physical hardware; OS and the application itself; the entire infrastructure	OQ of user configuration; confirmation of fitness for the business process (PQ); execution of the vendor management program

12.2　Cloud Vendor Management Program

When using SaaS, the user does not have control over the infrastructure or the application itself. Instead, the vendor’s GxP capability is confirmed on an ongoing basis through a “Vendor Management Program.” It is important to confirm third-party certifications provided by the vendor, such as ISO 27001 and SOC 2 Type II, and to secure user audit rights. In addition, change management in response to vendor-driven system updates presents a unique challenge.

Validation Strategy for a SaaS System (Example: Cloud ERP)

[Vendor Management Program] ・Initial audit: confirm the vendor’s GxP capability (confirmation of ISO 27001, SOC 2 Type II, and GxP-specific certifications) ・Annual review: confirm the vendor’s security reports and incident response history ・Contract: contractually document data ownership, retention period, migration rights, and audit rights via the SLA [Configuration IQ] ・Covers only the user configuration of the cloud system ・Documentation of the list of configuration parameters and the rationale for configuration ・Retention of configuration screenshots and exported data [OQ: Business Process Verification] ・Testing based on GxP business scenarios ・Confirmation of the operation of user access management and the audit trail ・Confirmation of the operation of security settings [Change Management: Responding to Vendor-Driven Updates] ・GxP impact assessment of the vendor’s release notes ・Regression testing when GxP-related functions change ・Establishment of SOPs for minor updates and security patches

(End)