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

Computerized System Validation: A Practical Guide

Computer System Validation — A Practical Guide for GxP Compliance

June 2026

Introduction: What Is CSV?

0.1  Definition of CSV

CSV (Computer System Validation) is the process of establishing, through documented evidence, that a computerized system used in a GxP environment “consistently conforms to its intended purpose.” This definition underlies the concepts on which FDA 21 CFR Part 11 and EU GMP Annex 11 are based. The essence of CSV is not to confirm that “the system is running,” but to “prove through documentation that the system fulfills its intended business purpose.”

Systems subject to CSV are, broadly speaking, all computerized systems that affect GxP operations (manufacturing, quality testing, clinical trials, post-marketing safety management, etc.). This spans a wide range of systems, including ERP (e.g., SAP), LIMS, EDC, DMS, MES, and PLCs (programmable logic controllers).

Understanding precisely “why” CSV is needed

Common misconception: “CSV is about producing paperwork to submit to regulators.” The real purpose: “An activity that continuously assures a system reliably fulfills its business purpose.” If CSV is regarded as merely “producing documents”: – Formal documentation exists but does not reflect reality – Re-validation is not performed even when changes are made after validation – Inspectors note that “the system is operating, but the validation is disconnected from actual practice” If CSV is regarded as “continuous quality assurance of the system”: – Impact assessments are performed for every system change or upgrade – Users can be confident, based on evidence, that the system is functioning correctly – Well-founded answers can be given during regulatory inspections

0.2  Legal Basis of CSV

Regulation / Guideline	Applicable Region	Main Requirements for Computerized Systems
21 CFR Part 11 (Electronic Records; Electronic Signatures)	United States (FDA)	Requirements for electronic GxP records and electronic signatures; audit trails, access control, and system validation
EU GMP Annex 11 (Computerised Systems)	EU (EMA)	Lifecycle management and validation requirements for computerized systems in GxP environments
PMDA Guideline on Proper Management of Computerized Systems	Japan (PMDA)	CSV implementation requirements for Japan’s GMP environment; the 2012 revision is currently in effect
GMP Ministerial Ordinance, Article 11	Japan (Ministry of Health, Labour and Welfare)	Domestic legal basis requiring management of computers used in manufacturing and quality control
GAMP5	ISPE (industry association)	Risk-based approach to CSV; software category classification and lifecycle
ICH Q9	Global (ICH)	Quality risk management methodology; applied to CSV risk assessment

Chapter 1: Identifying Systems Subject to Validation

1.1  Not All Computer Systems Are Subject to CSV

CSV does not apply to every IT system. It applies only to systems that directly affect GxP operations (GMP, GLP, GCP, GDP, GVP). The starting point of a CSV program is to build a system catalog (a company-wide inventory of systems) and assess the GxP impact of each system.

System Type	GxP Impact	CSV Requirement	Examples
Directly involved in manufacturing/quality	Direct impact on product quality/safety data	CSV mandatory	LIMS, MES, ERP (production/quality modules), PLC, DCS, environmental monitoring systems
Creation/management of GxP records	Used to record, store, or report GxP data	CSV mandatory	DMS (document management), LES (electronic lab exercises), EDC, CTMS (clinical trial management)
Indirect support of GxP operations	Indirect impact on GxP operations	Limited CSV (risk-dependent)	HR (personnel/training management), maintenance management, asset management
No impact on GxP operations	No impact on product quality/regulatory requirements	Not subject to CSV	Payroll, legal contract management, internal communication tools

1.2  Procedure for GxP Impact Assessment

For each system, a GxP Impact Assessment is conducted and documented to determine whether the system is subject to CSV and, if so, what level of validation is required. The key question is: “If this system malfunctions, would it affect patient safety, product quality, or data reliability?”

GxP Impact Assessment Questions (System Catalog Evaluation)

If the answer to any of the following is “yes,” the system is a CSV candidate: □ Does this system create, modify, store, or report GxP records (electronic records)? □ Does this system manage data related to manufacturing instructions, specifications, or formulations of products? □ Does this system manage testing and specification conformance of raw materials, intermediates, or products? □ Does this system collect environmental monitoring data (temperature, humidity, cleanliness)? □ Would a malfunction of this system affect product release decisions? □ Does this system manage clinical trial data (subject data, efficacy, safety)? □ Does this system manage post-marketing safety information (adverse event reports, signals)? □ Must the access control and audit trail of this system satisfy GxP requirements?

Chapter 2: The V-Model and the Validation Lifecycle

2.1  Concept of the V-Model

The validation lifecycle of CSV is expressed as a “V-Model.” The left side of the V represents the “Specification” phase, and the right side represents the “Qualification/Testing” phase. Each document on the left side serves as the input for the corresponding test on the right side, forming a structure that confirms implementation and operation match the specifications.

Structure of the CSV V-Model

[User Requirements Specification (URS)] ↙ ↘ [Functional Specification (FS)]    [Performance Qualification (PQ)] ↙ ↘ [Design Specification (DS)]    [Operational Qualification (OQ)] ↙ ↘ [Code/Configuration]    [Installation Qualification (IQ)] Left side (descending): the specification phase, progressively detailing “what to build” Right side (ascending): the testing phase, confirming “whether what was built meets the specifications” Business requirements defined in the URS → PQ confirms business scenarios operate correctly Functional requirements defined in the FS → OQ confirms functions operate correctly Design requirements defined in the DS → IQ confirms correct installation and configuration

2.2  Validation Master Plan (VMP/VP)

The Validation Master Plan (VMP) is the top-level document that defines the CSV approach, scope, organization, document hierarchy, and schedule at the company-wide or project level. The Validation Plan (VP) for an individual system is positioned as a subordinate document to the VMP.

Main Contents of a Validation Plan	Content
Scope	Identification of systems subject to validation; results of GxP impact assessment
Validation Strategy	Policy for applying the risk-based approach; application of GAMP5 categories
Organization and Responsibilities	Roles of the validation owner, quality assurance, and IT
Document Hierarchy	Hierarchical structure of the VMP, VP, various specifications, test protocols, and reports
Test Strategy	Policy for conducting IQ, OQ, and PQ; acceptance criteria; deviation handling procedures
Change Control	Change control after validation; triggers for re-validation
Periodic Review	Frequency and method of periodic review

Chapter 3: Key Validation Documents

3.1  User Requirements Specification (URS)

The User Requirements Specification (URS) sits at the top of the V-Model and is a document describing, in the words of the user (the business unit), “what the system should do.” It does not describe technical implementation methods; instead, it defines business requirements, regulatory requirements, data requirements, interface requirements, and performance requirements from a business perspective.

The biggest failure in creating a URS is having “engineers write the URS.” The URS should be authored primarily by the business staff who will use the system, and reviewed by QA (Quality Assurance) from the perspective of GxP requirements. The quality of the URS determines the quality of the entire V-Model.

URS Content Items	Specific Examples
Business Requirements	– Must be able to electronically create and approve manufacturing records for each batch – Must be able to manage traceability of raw materials from receipt to issue
Regulatory Requirements	– Must have electronic signature functionality compliant with 21 CFR Part 11 – Must automatically generate an audit trail that cannot be modified by users
Data Requirements	– Must be able to report with patient identification data anonymized – Data backups must run automatically every day
Interface Requirements	– Real-time inventory data integration with SAP ERP – Automatic transfer of test results to the LIMS (laboratory information management system)
Performance Requirements	– Screen response time within 3 seconds under normal operation with 200 concurrent users
Security Requirements	– Role-based access control (RBAC) – Password policy (90-day renewal, minimum 8 characters, complexity requirements)

3.2  Functional Specification (FS) and Design Specification (DS)

The Functional Specification (FS) is a document that defines the requirements of the URS as functions of the system. It describes functionality at the level of “pressing this button triggers this process,” and traceability is maintained between each URS requirement and the FS function that realizes it.

The Design Specification (DS) describes the technical means by which the functions of the FS are realized. It includes database design, screen design, interface specifications, and security design. Taking SAP as an example, SAP transaction codes, customization settings, and add-on specifications correspond to the DS.

3.3  Installation Qualification (IQ)

Installation Qualification (IQ) is the process of confirming that “the system is installed and configured exactly as specified in the approved design specification.” Hardware, software, network settings, security settings, and licenses are all subject to verification.

IQ Verification Items (Example: SAP S/4HANA)	Verification Method
Software Version Confirmation	Confirm that the SAP S/4HANA release, stack, and patch level match the approved version
OS/Database Settings	Confirm the approved OS version and database (HANA) settings
Security Parameters	Password policy, session timeout, account lockout settings after failed login attempts
Backup Settings	Confirm automatic backup settings, frequency, storage location, and restore procedures
Network Configuration	Confirm the system configuration diagram matches the actual network configuration
Installation Records	Record the installation date/time, the person who performed it, and the reference number of the procedure document

3.4  Operational Qualification (OQ)

Operational Qualification (OQ) is the process of confirming that “the system operates as described in the functional specification.” Individual functions are confirmed using designed test cases, and normal, abnormal, and boundary-value tests are performed. OQ is the phase that proves “the system works.”

3.5  Performance Qualification (PQ)

Performance Qualification (PQ) is the process of confirming that “the system operates as intended using actual business scenarios and actual business data.” End users execute actual business scenarios under production or near-production conditions. PQ in the V-Model is the answer to the URS — the final confirmation of “whether what the users requested has actually been achieved.”

Understanding the Difference Between OQ and PQ Precisely

Example of OQ (functional confirmation): “On the ‘Raw Material Receipt Registration’ screen, entering the lot number, quantity, and receipt date and saving correctly records the data in the inventory database.” → Tested at the function level. Dummy test data is acceptable. Example of PQ (business confirmation): “For manufacturing batch (Lot No. 2024-001) of Product A (item number XXXXXX), the entire business flow from raw material receipt through manufacturing, testing, release decision, and shipment is actually processed in SAP, and it is confirmed that records for every step are correctly retained.” → Tested using actual business scenarios. Test data equivalent to production data is used. → Testing is performed by end users (business staff). PQ often overlaps in purpose with UAT, and it is efficient to position UAT as PQ (using UAT as the supporting evidence).

Chapter 4: The Risk-Based Approach

4.1  Why a Risk-Based Approach?

A historical problem with CSV was the uniform approach of “requiring the same depth of validation for every system and every function.” This wasted resources and created the paradox of neglecting verification of the functions that truly matter most. The risk-based approach advocated by GAMP5 is the principle that “systems and functions with higher risk to patient safety, product quality, and data integrity should receive deeper validation.”

4.2  Three Axes of Risk Assessment

Risk Axis	Assessment Viewpoint	High-Risk Example	Low-Risk Example
Impact on Patient Safety	Would a malfunction of this system directly affect patient safety?	Error in a manufacturing instruction system → potential for over/under-dosing	Internal communication tool → no direct impact on patients
Impact on Product Quality	Would a malfunction of this system affect product quality/specifications?	Error in LIMS test result management → risk of releasing non-conforming product	Error in a financial reporting system → no direct impact on product quality
Impact on Data Integrity	Is there a risk that the reliability of GxP data generated by this system could be compromised?	A system without an audit trail → data tampering cannot be detected	An internal analytics tool not disclosed externally → not data reported to regulators

4.3  Validation Depth According to Risk

Risk Level	Example Systems	Required Validation Depth
High Risk	LIMS, MES, EDC, DCS/SCADA (directly affecting product quality and patient safety)	All stages of URS → FS → DS → IQ → OQ → PQ; test cases created for all functions; comprehensive testing including abnormal cases and boundary values
Medium Risk	ERP (production/quality modules), DMS (used for GxP record management)	URS → FS → IQ → OQ → PQ; focused testing of higher-risk functions; impact assessment performed for configuration changes
Low Risk	Infrastructure (OS, DB, network), spreadsheets (minor use)	Primarily IQ. Leverages the manufacturer’s FAT; mainly confirms installation and configuration

Chapter 5: 21 CFR Part 11 — Electronic Records and Electronic Signatures

5.1  What Is 21 CFR Part 11?

21 CFR Part 11 (Code of Federal Regulations Title 21, Part 11) is the “regulation concerning electronic records and electronic signatures” promulgated by the FDA in 1997. It applies when paper records are replaced with electronic records, or when electronic signatures are used, in a GxP environment. Compliance with 21 CFR Part 11 is a condition for having the use of electronic records and electronic signatures accepted during FDA inspections.

Key Requirements of 21 CFR Part 11	Technical Implementation
§11.10(a) Validation	Proving through CSV that the system functions as specified; re-validation upon changes
§11.10(b) Accurate and Complete Copies	Providing human-readable copies of electronic records; provision to regulatory authorities
§11.10(c) Protection of Records	Prevention of unauthorized modification or deletion of records; data backup and disaster recovery
§11.10(d) Access Control	Only authorized users may access the system; user ID/password management and role-based access control
§11.10(e) Audit Trail	Automatically records the date/time, user, and before/after values for the creation, modification, and deletion of records; the design must prevent users from modifying or deleting it
§11.10(g) Authority Checks	Procedure to confirm the authority of the electronic signer before approval is carried out
§11.50 Signature Manifestations	The electronic signature must include the signer’s name, the date/time, and the meaning of the signature (approval/review/execution)
§11.70 Signature/Record Linking	The electronic signature must be linked to, and inseparable from, the specific record

5.2  Implementing the Audit Trail

The audit trail is regarded as one of the most critical requirements under 21 CFR Part 11 and EU Annex 11. All operations (creation, viewing, modification, deletion, approval) performed on GxP electronic records must be automatically recorded and stored in a manner that users cannot tamper with. SAP’s audit trail functionality (change documents, log records, etc.) addresses this requirement, but must be properly configured and enabled.

Audit Trail Configuration Checkpoints in SAP

Audit trail requirements to confirm in SAP S/4HANA: 1. Enabling of Change Documents Confirm that change documents are recorded for GxP-relevant data objects Examples: batch master, quality information records, inspection lots, etc. 2. Audit Information System (AIS) Recording of user actions, logins, logouts, and authentication failures Confirm configuration of TCode SM20 (security audit log) 3. Table Change Log (TCode: SCU3) Enabling of change history for GxP-critical tables 4. Electronic Signatures for Process Instructions (PI) Where electronic signatures are implemented for approvals such as manufacturing orders and quality decisions Confirm configuration of SAP Digital Signature functionality 5. Protection of the Audit Trail Confirm that only system administrators can delete or modify audit trail data, and that this action itself is designed to be recorded in a separate log

Chapter 6: EU GMP Annex 11

6.1  Overview of EU GMP Annex 11

EU GMP Annex 11 (Computerised Systems) is an annex to EU GMP (Good Manufacturing Practice) that defines requirements for the use of computerized systems. The 2011 revision is currently in effect, and it stands alongside U.S. 21 CFR Part 11 as a primary reference regulation for GxP computerized systems.

Annex 11 sets requirements for the entire system lifecycle, dividing it into a “project phase” and an “operational phase.” Whereas 21 CFR Part 11 focuses on the technical requirements of “electronic records and electronic signatures,” Annex 11 is distinguished by governing the entire management process of a system “from selection through decommissioning.”

Key Clauses of Annex 11	Content
Clause 1: Risk Management	Adoption of a risk-based approach across the whole system; application of the ICH Q9 quality risk management methodology
Clause 3: Suppliers and Service Providers	Qualification of computerized system suppliers; conducting audits and concluding quality agreements
Clause 4: Validation	Determining the scope of validation based on risk; maintaining URS, specifications, and test records
Clause 7.1: Data and Data Management	Ensuring the accuracy and completeness of data; conformance with ALCOA+ principles
Clause 9: Audit Trail	Implementation of an audit trail for all data affecting GxP; periodic review of the audit trail
Clause 11: Electronic Signature	Conditions and record requirements for the use of electronic signatures
Clause 13: Change Control	Impact assessment of system changes; determination of the need for re-validation
Clause 17: Archiving	Management of the storage, migration, and disposal of GxP records

Chapter 7: CSV Requirements in Japan (PMDA and the PMD Act)

7.1  PMDA Guideline on Proper Management of Computerized Systems

In Japan, the Ministry of Health, Labour and Welfare issued the “Guideline on Proper Management of Computerized Systems” in 2012, setting out the proper management methods for computerized systems used by pharmaceutical marketing authorization holders and manufacturers in a GMP environment. This guideline is based on the concepts of GAMP5 and requires a risk-based approach, lifecycle management, and vendor evaluation.

Key Requirements of Japan’s CSV Guideline	Content
Maintaining a System Inventory	Creation and maintenance of a system inventory listing all GMP-relevant systems; management of GxP impact assessment results and validation status
Vendor Evaluation	Evaluation of the SDLC (software development lifecycle) of computerized system suppliers; confirming vendor qualification through questionnaires and audits
Validation Planning and Execution	Creation of the VMP (Validation Master Plan); creation and retention of URS, specifications, test protocols, and reports
Change Control	Impact assessment of changes made after validation; determination and execution of re-validation as needed
Periodic Review	Periodic (typically every 3 years) reassessment of a system’s validation status; confirming the system continues to meet GxP requirements
Operational Management	Documentation of user management, backups, incident response, and security management

7.2  The 2022 Revision of the PMD Act and Its Impact on GxP and CSV

The 2022 revision of Japan’s Pharmaceuticals and Medical Devices (PMD) Act incorporated strengthened requirements for data integrity, the introduction of the GDP guideline, and expanded electronic filing. In particular, “ensuring data reliability” has become a top-priority theme in recent PMDA inspections, and prevention of tampering with electronic records and the integrity of audit trails have become central review items in CSV.

Chapter 8: Applying CSV to Cloud and SaaS Systems

8.1  The Approach to Cloud CSV

When using cloud/SaaS systems such as SAP S/4HANA Cloud (RISE with SAP), Veeva Vault, or Microsoft Azure in a GxP environment, an approach different from traditional on-premises CSV is required. For the infrastructure, OS, middleware, and application platform managed by the cloud provider, it is efficient for pharmaceutical companies to leverage the provider’s certifications and audit trails, and to concentrate their own validation efforts on “application configuration, business processes, and data.”

Division of Responsibility in Cloud CSV	Cloud Provider	Pharmaceutical Company
Infrastructure (servers, network)	Management responsibility (evidenced by ISO 27001, SOC 2, etc.)	Only confirms the provider’s certifications
OS/middleware/DB	Management responsibility	Confirms through the provider’s documentation and certifications
Application platform (SaaS functionality)	Provides validation evidence for functionality (in some cases, FAT/IQOQ is provided)	Reviews the evidence provided by the provider, and confirms fitness for business use (PQ)
Configuration/customization/add-ons	Handles change management and release management	Creates configuration specifications; conducts OQ/PQ testing
Business processes/data	—	Defines URS; performs PQ; assures data integrity

8.2  Managing SaaS Upgrades

One characteristic of cloud SaaS is “provider-led upgrades (automatic updates).” On-premises systems allow patches to be managed through a change control process, but with SaaS, periodic upgrades are pushed out by the provider. If such an upgrade affects GxP functionality, re-validation (or confirmation that validation is maintained) is required.

CSV Strategies for Handling SaaS Upgrades

Approach 1: Automation of Regression Testing – Manage test scripts for GxP-critical functions using automation tools – Run automated regression tests with each upgrade – If there is no impact from the change, record it as “validation maintenance confirmed” Approach 2: Leveraging Provider-Supplied Release Notes – Obtain the provider’s release notes and change impact assessment documents – Assess whether there is any impact on GxP functionality – If no impact is determined, handle it with a lightweight Periodic Review record Approach 3: Sandbox Verification in a Test Environment – Apply the upgrade in a Sandbox/QAS environment before applying it to production,   confirm the impact on GxP functionality, and then apply it to production – This procedure serves as evidence in the change control record

Chapter 9: Change Control and Periodic Review

9.1  Change Control After Validation

CSV is not “finished once validation is performed.” When a system is changed after validation, it is mandatory to assess whether the change affects GxP functionality and to carry out re-validation as needed — this is “Change Control.” Making modifications without change control constitutes a serious GMP violation.

Type of Change	Example	Response Approach
Minor Change	Change to the character count in the password policy; UI label text change; bug fix (no impact on GxP functionality)	Create a change control record; partial re-confirmation of IQ/OQ, or incorporate into the Periodic Review
Major Change	Addition of an SAP module affecting GxP functionality; data migration (from another system); infrastructure migration (on-premises → cloud)	Impact assessment of the change; re-execution of OQ/PQ for the affected scope; creation of a post-change validation report
Emergency Change	Response to a major production incident; emergency patch for a security vulnerability	Creation of change control documentation after the fact; confirmation of impact through regression testing; retrospective QA approval (in emergency cases)

9.2  Periodic Review

Periodic Review is the process of periodically (typically every 2 to 3 years) assessing whether a validated system continues to maintain its validated state. It is required by EU GMP Annex 11 and PMDA guidelines, and a situation in which “a system was implemented but has not been reviewed for years” carries a risk of GMP violation.

Periodic Review Checklist

Confirm the following; if there are no issues, conclude that “the validated state is maintained”: □ List of changes implemented since validation and confirmation of change control records □ Status of deviations/incidents that have occurred and completion status of CAPAs □ Review of user access privileges (confirming removal of privileges for departed/transferred staff) □ Records of periodic backup/restore execution and success rate □ Status of security patch application □ Status of training implementation (user training records) □ Records of periodic audit trail reviews □ Status of response to revisions of GxP regulations/guidelines □ Status of certification renewal for suppliers (SaaS providers) If an issue is discovered: → Conduct a risk assessment; if minor, corrective action alone is sufficient → If a serious issue exists, partial or full re-validation is required

End.

Chapter 10: 21 CFR Part 11 in Depth — Closed, Open, and Hybrid Systems

10.1  Definitions of Closed and Open Systems

The first key concept to understand under 21 CFR Part 11 is the distinction between a “Closed System” and an “Open System.” Since the security requirements demanded of each differ significantly, correctly determining the type of system is the starting point for implementation.

Category	Definition	Representative Examples	Additional Requirements
Closed System	A system in which access to the system used to create, modify, maintain, or transmit electronic records is controlled by the organization that uses the electronic records of that system	An in-house LAN-based LIMS; a manufacturing execution system (MES); an internal ERP (SAP); a laboratory data acquisition system	Access restriction via user ID and password; automatic recording of the audit trail; electronic signatures
Open System	A system that does not meet the definition of a closed system, particularly an environment in which the creator/modifier of a record and the recipient belong to different organizations	Email sent over the internet; cloud-based systems (managed by an external vendor); EDC systems (external clinical trial sites)	In addition to closed-system requirements: encryption, digital signatures, measures ensuring document authenticity (e.g., timestamps)
Hybrid System	An environment in which electronic and paper records coexist; requires special management under the FDA’s interpretation of 21 CFR Part 11	A workflow in which data is entered electronically but approved on paper; LIMS output printed to paper for storage	It must be clearly defined whether the paper portion or the electronic portion is the master record

10.2  Management Procedures for Hybrid Systems

Many pharmaceutical companies face the hybrid environment of “electronic entry, paper approval.” The FDA does not prohibit hybrid systems, but it requires that “which record is the official master record” be clearly documented, and that the associated management rules be strictly enforced. Where a hybrid setup is operated unintentionally (for example, transcribing data to paper “as a backup” even though an electronic record exists), inconsistencies in the audit trail and dual-management problems arise.

Decision Matrix for Hybrid System Management

Case 1: Electronic entry + electronic approval + paper as a reference copy → The electronic record is the master. A “COPY” stamp is required on the paper. → All Part 11 requirements apply to the electronic side. Case 2: Electronic entry + printing to paper + paper approval → The paper record is the master. The electronic data is a supplementary record. → Change control and backup of the electronic data are required, but the Part 11   electronic signature requirement is exempted (though an audit trail is still recommended). Case 3: Paper entry + scanned storage (electronic archive) → Management of the original documents (rules for disposal of the paper originals) is important. → The authenticity, searchability, and readability of the scanned images must be demonstrated. → The Part 11 electronic record requirements apply (the scanned images are also subject to Part 11). ★Risk: The most common problem in hybrid environments is   data inconsistency arising from lack of clarity over which record is the master.   This must be documented clearly in the SOP and system design document at the time of implementation.

Chapter 11: Handling Procedures When a Test Deviation Occurs

11.1  Approach to Out-of-Expectation (OOE) Results and Test Failures During Validation

When an unexpected result occurs during the execution of a validation test (IQ/OQ/PQ), it is called a “Deviation” or “Test Failure.” What matters is not the fact that a deviation occurred, but rather “whether the correct process was followed in response to the deviation” — this is the point regulatory inspectors confirm. The most serious violation is rewriting a failed test result or concealing test results.

Type of Deviation	Definition	Approach to Handling
Planned Deviation	A departure from procedure that was known before test execution. Example: it was decided in advance that a substitute test instrument would be used	A Deviation Report is raised and approved before the test is executed
Unplanned Deviation	An unexpected problem that arises during test execution. Example: the system crashed, or a result different from the expected value was obtained	Record immediately during testing and pause the test; raise a Deviation Report, investigate the cause, implement corrective action, then re-test
Protocol Deviation	A case where the procedure of an approved test protocol was executed incorrectly. Example: testing was performed with a shortened wait time than specified	Address via protocol change control (Protocol Amendment), or record as a deviation and perform an impact assessment

11.2  Structure of the Deviation Report

The Deviation Report is a critical document that regulatory authorities always review during an inspection. It must document not only “what happened” but also “why it happened (root cause)” and “what will be done to prevent recurrence (CAPA).” Simply stating “restarted the system and re-tested, and it passed” is not sufficient.

Required Content of a Deviation Report

1. Deviation ID, title, and date/time of occurrence 2. Detailed description of the deviation What happened, who discovered it, and during which test procedure it occurred Comparison of the expected value and the actual result 3. Impact Assessment The impact of the deviation on GxP (patient safety, product quality, data reliability) Whether there is any impact on other systems or processes 4. Root Cause Analysis Analysis of “why the deviation occurred,” using methods such as the 5 Whys or a fishbone diagram Pursuing not only the direct cause but also the systemic cause 5. Corrective and Preventive Action (CAPA) Corrective Action: action taken to fix the problem Preventive Action: a change to the system to prevent recurrence The person responsible and target completion date for each action 6. The test conclusion (pass/fail/conditional pass) and its rationale 7. Approver’s signature and date

Chapter 12: Data Migration Validation

12.1  Data Migration and the Need for Validation

When migrating from a legacy system to a new system (for example, from an old LIMS to a new LIMS, or from an old ERP to SAP S/4HANA), the migration of GxP-relevant data requires rigorous validation. It is not sufficient simply to say “the data was moved” — it must be demonstrated that “the post-migration data fully matches the original data, and that the data was not altered, lost, or tampered with during the migration process.”

Phases of Data Migration Validation	Main Activities	Deliverables
Planning Phase	Identification of data to be migrated (classification into GxP/non-GxP); definition of migration rules (mapping); determination of the scope of data cleansing; preparation of the migration test environment	Data migration plan; data mapping specification; migration test plan
Verification Phase	Validation of migration tools/scripts; backup of pre-migration data; pilot migration (trial migration of a portion of the data); establishment of the post-migration data verification method	Migration tool verification report; pilot migration report
Production Migration	Backup of production data; execution of production migration (downtime management); completeness verification of post-migration data (100% reconciliation or statistical sampling); retention of migration evidence	Production migration execution record; data reconciliation report; migration completion report
Post-Migration Verification	Confirmation of business continuity on the post-migration system; archiving/decommissioning procedure for the legacy system; ensuring access to GxP records during the statutory retention period	User acceptance test report; decommissioning record

12.2  Data Reconciliation Methods

Post-migration data reconciliation is the core activity that confirms the original data and the migrated data match. Full reconciliation is ideal, but depending on the data volume, statistical sampling may be used instead. In either case, “how the reconciliation was performed” and “how any discrepancies found were handled” must be documented.

Data Reconciliation Policy (Example: SAP Migration)

[Data Requiring Full Reconciliation] – Master data (customer master, material master, BOM) – Data directly related to GxP (inspection lots, licenses, test results) – Monetary/quantity data (balances, inventory quantities) [Data for Which Statistical Sampling Is Acceptable] – Large volumes of transactional data (orders, invoices, etc.) – Non-GxP reference data [Reconciliation Methods] 1. Checksum comparison: confirming that record counts and total amounts match 2. Field reconciliation: comparing key fields/critical fields across all records or a sample 3. Business rule validation: confirming that migrated data satisfies business rules (e.g., expiration date > manufacturing date; inventory quantity ≥ 0) 4. Visual sampling: visually confirming random samples on screen [When a Discrepancy Is Found] → Record as a deviation → root cause analysis → correct the migration rule → re-migrate

Chapter 13: CSV for Process Control Systems (PLC, DCS, SCADA)

13.1  Characteristics of Process Control Systems and GAMP5 Categories

Process control systems on the manufacturing floor (PLC: programmable logic controller; DCS: distributed control system; SCADA: supervisory control and data acquisition) directly control manufacturing processes such as batch manufacturing, continuous manufacturing, and temperature control. These systems have a direct impact on GxP and require rigorous CSV, but they have characteristics different from office IT systems.

Types of Process Control Systems	Purpose/Characteristics	CSV Considerations
PLC (Programmable Logic Controller)	A microcontroller that controls the operation of machinery and equipment; embedded in tablet presses, filling machines, and packaging machines; programmed using ladder diagrams	Inseparability of hardware and software; program change control is especially important; treated as GAMP5 Category 4 (configured product) or Category 5 (custom)
DCS (Distributed Control System)	Monitors and controls process variables across an entire plant; used for continuous processes such as distillation columns, fermenters, and reactors; multiple controllers distributed throughout the plant	Real-time recording of process parameters; validation of alarm management and interlocks; ensuring evidence for data collection and trend records
SCADA (Supervisory Control and Data Acquisition)	A monitoring system positioned above the PLC/DCS; provides plant-wide visualization and data collection; includes the HMI (human-machine interface)	Validation of HMI screens (display accuracy); integrity of data archiving; audit trail as an electronic record
BAS/EMS (Building Automation System/Environmental Monitoring System)	HVAC control, temperature/humidity, and differential pressure management for cleanrooms; real-time monitoring of pharmaceutical environmental conditions	Application of CSV to environmental monitoring data; records of alarm response; annual re-validation

13.2  Validation of Process Parameters

In the OQ of a process control system, it is verified that process parameters (temperature, pressure, pH, agitation speed, etc.) are accurately controlled and recorded within specified ranges. Of particular importance are the calibration of sensor accuracy, verification of alarm setpoints, and confirmation of the operation of interlocks (automatic shutdown when a specified range is exceeded).

Chapter 14: Computer System Decommissioning

14.1  Importance of Decommissioning Planning

The decommissioning (retirement) of a GxP system must be carried out through a validated process, just as system implementation is. The main issues to address during decommissioning are ensuring access to GxP records throughout their statutory retention period, and the complete migration and archiving of electronic records and electronic signatures. A situation in which “the old system was deleted, so the test records can no longer be viewed” constitutes a serious GMP violation.

Statutory Retention Periods for GxP Records (Major Regulations)	General Retention Principle
GMP (manufacturing records, quality records)	At least 1 year after the product’s expiration date (Japan PMD Act); FDA: batch records at least 3 years; stability data expiration date + 1 year; EU GMP: at least 1 year after expiration date, minimum of 5 years
GCP (clinical trial records)	15 years from final approval/non-approval of the investigational drug (FDA); 25 years after trial completion (EU); 3 years after trial completion (Japan GCP Ministerial Ordinance)
GLP (non-clinical study records)	10 years after submission of the study report (Japan); 2–10 years (OECD guidance)
Special Considerations for Electronic Records	Even after hardware, OS, and applications are decommissioned, electronic records must remain accessible in a human-readable format throughout the retention period

14.2  Decommissioning Procedure

Implementation Procedure for GxP System Decommissioning

[Phase 1: Formulating the Decommissioning Plan (12–6 months before decommissioning)] 1. Creation of the Decommissioning Plan Confirm the reason for decommissioning, planned decommissioning date, scope of impact, and replacement system 2. Inventory of GxP records and confirmation of retention periods Which records are still within their retention period, and where are they stored 3. Determination of the data migration/archiving policy Migration to a successor system, or migration to a read-only archive system [Phase 2: Execution of Data Archiving (3 months before decommissioning)] 4. Complete export and archiving of electronic records 5. Verification of archive integrity (data reconciliation, checksums) 6. Access verification testing of the archive system [Phase 3: Execution of Decommissioning] 7. Recording the date/time of decommissioning and the person who performed it 8. Recording the disposal of hardware and licenses 9. Issuance and approval of the Decommissioning Completion Report ★Even after decommissioning, the decommissioning record itself must be retained (as evidence that decommissioning occurred)

End.