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

Validation Design Guide

SAP Computer System Validation in Life Sciences — Design & Implementation Guide

July 2026

Chapter 1: GAMP5 and SAP — Why Validation Is Required

1.1　Pharmaceutical Regulations and Computerized Systems

In the pharmaceutical, medical device, and food manufacturing industries, Computer System Validation (CSV) of computerized systems that affect product quality is mandatory under GxP (GMP/GCP/GLP/GDP) regulations. The FDA’s 21 CFR Part 11, the EU’s Annex 11, and PIC/S GMP Annex 11 are the governing regulations, and they require system qualification (IQ/OQ/PQ) and ongoing change management.

SAP ERP broadly covers GxP-regulated operations, including manufacturing execution, quality management, inventory management, and financial processing. When a pharmaceutical company implements SAP, it must be positioned not merely as an IT project but as a “CSV project,” and the company must systematically prepare the documentary evidence that regulators will review during inspections.

1.2　What Is GAMP5?

GAMP5 (Good Automated Manufacturing Practice v5) is a set of CSV best-practice guidelines established by ISPE (the International Society for Pharmaceutical Engineering). It classifies systems into categories and defines validation activities proportional to risk, adopting a “risk-based approach” that ensures regulatory compliance while preventing over-validation. The second edition (GAMP5 Second Edition) was issued in 2022, adding coverage of agile methods, cloud systems, and data integrity.

Core Principles of GAMP5	Description
Validation proportional to risk	Validating every system with the same rigor is inefficient. The higher the risk (impact on product quality), the more rigorous the validation performed
Product lifecycle approach	Validation activities continue across all phases: planning → design → development → testing → release → operation → retirement
Leveraging the supplier	Leverage the supplier’s (in this case, SAP’s) development process and quality assurance system. Supplier assessment can reduce the scope of in-house testing
Scalability	Adjust the scope and level of detail of validation documentation according to the system’s scale, complexity, and risk
Scientific rationale	Validation decisions are based on sound scientific reasoning. Provide a logical rationale rather than a customary “this is just how it’s done” judgment

Chapter 2: GAMP5 Category Classification of SAP Systems

2.1　Definition of GAMP5 Categories

GAMP5 classifies computerized systems into four categories (1/3/4/5). The higher the category, the greater the degree of customization and the heavier the validation requirements. A distinctive feature of SAP is that, due to its configuration, it spans multiple categories.

Category	Definition	Validation Requirements	Example in SAP
Cat.1 Infrastructure	The underlying platform on which software runs: OS, DB server, network, etc.	Qualification (equivalent to IQ); retention of configuration records	SAP BASIS environment, Windows Server / Oracle DB, SAP HANA database
Cat.3 Non-configured products	COTS (commercial off-the-shelf) products used without configuration changes	Supplier assessment; functional testing (equivalent to OQ); user acceptance testing (UAT)	SAP standard reports, SAP standard workflows, unmodified standard functionality
Cat.4 Configurable products	Products whose functionality is changed through configuration, such as SPRO settings	In addition to Cat.3: recording of configuration evidence; change management for configuration changes	SPRO configuration changes, organizational structure / account settings, activation of standard workflows
Cat.5 Custom products	Customer-specific programming / custom development (ABAP, etc.)	Full validation (IQ + OQ + PQ + design specification); code review and unit testing	Custom ABAP development, User Exit / BAdI implementations, custom reports and interfaces

2.2　SAP S/4HANA Category Determination Flow

In an SAP implementation project, all functions, configurations, and developments are listed to determine the GAMP5 category, which in turn determines the scope of validation activities. Using the determination flow below covers regulatory risk while preventing over-validation.

GAMP5 Category Determination Flow (SAP Application)

Step 1: Assess GxP impact Q: Does this system function directly affect product quality, patient safety, or data integrity? NO → Cat.1 (infrastructure) or out of scope for validation YES → Go to Step 2 Step 2: Presence of custom development Q: Does it include ABAP custom development, User Exits, or BAdI implementations? YES → Cat.5 (full validation) NO → Go to Step 3 Step 3: Presence of SPRO configuration changes Q: Has configuration been changed via a standard SAP SPRO transaction? YES → Cat.4 (configuration evidence recording and configuration change management required) NO → Go to Step 4 Step 4: Standard functionality only → Cat.3 (supplier assessment and functional testing only)

2.3　Example Category Determination for the SAP QM Module

SAP QM Function	Cat.	Rationale
Automatic inspection lot generation (standard)	3	Activated via SPRO configuration, but uses only standard logic
Usage decision logic (standard code)	3	Uses standard usage decision codes and movement types
Inspection plan (standard MIC definitions)	4	Inspection methods, tolerances, and sampling schemes configured via SPRO
Custom quality certificate layout	5	Custom ABAP development in a ZXXXX program
QM–WM integration custom BAdI	5	Custom logic via BAdI implementation
SAP standard quality notification report	3	No configuration changes; uses the standard report

Chapter 3: Designing the Validation Plan (VP)

3.1　Components of the Validation Plan

The Validation Plan (VP) is the master document that defines the policy, scope, organization, schedule, and documentation structure for the entire CSV project. It is a key document that FDA/EMA inspectors typically request first during an inspection. In an SAP implementation project, the VP should be developed immediately after project kickoff and approved by the steering committee.

VP Section	Content	Responsible Party
1. Purpose and scope	Clarification of systems, modules, and sites subject to validation; enumeration of GxP-regulated operations	Quality Assurance (QA) department
2. Applicable regulations and guidelines	Applicable regulations (21 CFR Part 11 / EU Annex 11 / GAMP5); references to domestic pharmaceutical laws and notices	QA department
3. Roles and responsibilities	Definition of roles for the validation lead, QA lead, IT system administrator, process owners, and supplier representatives	Project manager
4. System overview	SAP S/4HANA system configuration (landscape); summary of GAMP5 category classification	SAP BASIS lead
5. Validation strategy	Policy for applying the risk-based approach; overview of validation activities by category	QA department, IT lead
6. Validation documentation structure	Structural diagram of VP → RA → URS → FS/DS → IQ/OQ/PQ plans and reports; templates and naming conventions for each document	QA department
7. Supplier assessment	Policy for assessing SAP’s quality system (leveraging SAP’s ISO 9001 certification and SDL references)	QA department, Procurement
8. Data migration validation	Verification policy for migrating legacy data into SAP	Data migration team lead
9. Schedule	Milestones for the implementation and validation phases	PMO
10. Deviation and change management	Procedures for handling deviations during validation; change management policy after release	QA department

3.2　Risk Assessment (RA)

Prior to the validation plan, a GxP risk assessment is performed for each SAP function. Severity (patient risk / product quality risk / data integrity risk) and likelihood are evaluated, and the intensity of validation activities is determined based on the resulting risk score.

Risk Scoring Criteria (Example)

Severity H (3 points): Directly affects patient safety or product release decisions M (2 points): Affects the accuracy of audit trail or report data L (1 point): Indirect impact (management information, reference data, etc.) Likelihood H (3 points): New development, complex configuration changes, external interfaces M (2 points): Configuration changes to standard functionality, data migration L (1 point): No configuration changes; functionality with a proven track record Risk score = Severity × Likelihood 6-9 points: Validation as rigorous as Cat.5 3-5 points: Cat.4 validation 1-2 points: Cat.3 validation

Chapter 4: Mapping SAP Project Phases to CSV Phases

4.1　Integrating the SAP Activate Methodology with the GAMP5 Lifecycle

SAP S/4HANA’s standard implementation methodology, “SAP Activate,” consists of six phases (Discover / Prepare / Explore / Realize / Deploy / Run). By mapping the GAMP5 lifecycle (Plan → Design → Build & Test → Release & Operate) to each SAP Activate phase, development activities and validation activities can proceed in parallel and efficiently.

SAP Activate Phase	GAMP5-Aligned Activities	Key CSV Deliverables
Discover	Initial development of the validation plan; supplier assessment (SAP assessment); initial GxP impact assessment	Validation Plan (VP) draft; supplier assessment record; GxP impact assessment report
Prepare	Finalization of the project validation plan; GAMP5 category classification; risk assessment	VP finalized and approved; category classification table; risk assessment record
Explore	Development of the User Requirements Specification (URS); development of the Functional Specification (FS); initial Traceability Matrix (TM)	URS (including GxP requirements); Functional Specification (FS); TM (URS–FS columns)
Realize	Development of the Design Specification (DS); creation of IQ and OQ protocols; start of configuration record (SPRO evidence) collection; ABAP code review	DS (Design Specification); IQ and OQ protocols; SPRO configuration records; code review records
Deploy	IQ execution and IQ report creation; OQ execution (functional testing) and OQ report; PQ protocol creation; data migration validation	IQ execution records and IQ report; OQ execution records and OQ report; PQ protocol; data migration validation records
Run	PQ execution (operational verification) and PQ report; validation summary report; establishment of change management procedures	PQ execution records and PQ report; validation summary; change management procedure (SOP)

Chapter 5: Designing the Traceability Matrix (TM)

5.1　What Is the Traceability Matrix?

The Traceability Matrix (TM) is a management table that shows, in a single view, the relationships among all validation deliverables — from user requirements to design, test cases, and test results. Regulators use the TM to confirm that “all regulatory requirements are reflected in the design and verified through testing.” The TM is the “backbone” of the validation documentation structure and is one of the most frequently reviewed materials during inspections.

5.2　TM Column Structure (SAP Application Example)

TM Column	Content	Example Entry
URS number	Requirement ID from the User Requirements Specification	URS-QM-001
Requirement description	Description of the function or performance requested by the user	An inspection lot shall be automatically generated at goods receipt
GxP relevance	Relevance to GxP regulations (21 CFR / Annex II, etc.)	21 CFR 211.68(b) / GAMP5 Cat.4
GAMP5 category	Applicable category	Cat.4
FS reference	Reference ID of the Functional Specification	FS-QM-014
DS reference	Reference ID of the Design Specification (Cat.5 only)	DS-ZQMRPT-001
IQ test case	ID of the item verified in IQ	IQ-TC-QM-003
OQ test case	Test case ID for OQ functional testing	OQ-TC-QM-015
PQ test case	Test case ID for PQ operational testing	PQ-TC-QM-002
Test result	Pass/fail and deviation number	Pass / No deviation
Completion date	Date the test was completed	March 15, 2025

5.3　Managing and Maintaining the TM

The TM is not a static document; it is a living management table that must be continuously updated as the project progresses. Changes to the URS, design changes, and updates to test results must be reflected each time, and validation is considered complete only when every column is filled in. If any GxP-relevant requirement remains unverified, go-live to production will not be approved. It is common to manage the TM using Excel or an ALM (Application Lifecycle Management) tool.

Chapter 6: Performing IQ / OQ / PQ

6.1　IQ (Installation Qualification)

IQ (Installation Qualification) is the phase in which it is confirmed that the SAP system has been installed and configured according to the design specification. It proves that “the correct thing has been correctly installed.”

IQ Verification Item	Verification Content	Method of Obtaining Evidence
Hardware configuration	Server specifications and redundancy configuration match the design specification	Screenshot of the BASIS system information screen
OS version	Approved OS version and patch level	Capture of OS information command output
SAP S/4HANA version	Implemented version and Support Package level	SAP Software Center / SPAM screen
License	Confirmation that all required licenses are valid	SAP System Measurement screen
Landscape configuration	Three-tier Dev → QA → Prod configuration and transport routes	Screenshot of STMS configuration
Backup configuration	Scheduled backup schedule and restore test results	Backup configuration screen and restore test records
Security configuration	Password policy and failed-login lockout settings	List of security profile parameters
Printers and peripherals	Confirmation that approved peripheral devices are connected	Device configuration records

6.2　OQ (Operational Qualification)

OQ (Operational Qualification) is the functional testing phase that confirms the system operates as designed. It systematically tests “whether it works as configured” and “whether it behaves correctly even at boundary or abnormal values.” In SAP, each business process is tested on a scenario basis.

OQ Test Case Documentation Format

Test case ID: OQ-TC-QM-015 Requirement under test: URS-QM-001 (automatic inspection lot generation) Test objective: An inspection lot is automatically generated by a goods receipt trigger Preconditions: ・Inspection settings have been completed on the quality management tab of the material master (QM01 performed) ・An inspection plan has been assigned to the material/plant Test steps: Step 1: Perform a GR (goods receipt: movement type 101) via MIGO Material: FG-001, Quantity: 100EA, Plant: 1000 Step 2: Confirm via QA32 that an inspection lot has been generated Step 3: In QA32 → inspection lot details, confirm that the inspection plan has been automatically copied Expected results: ・The inspection lot is displayed in QA32 immediately after goods receipt via MIGO ・The inspection plan (MICs and tolerances) is automatically populated ・The usage decision is in “undetermined” status Actual result: (Pass / Fail / Deviation number) Date performed:　　　　Performed by (signature):

6.3　PQ (Performance Qualification)

PQ (Performance Qualification) is the phase in which actual business scenarios (or data close to real operational data) are used to confirm that the system can support the required GxP operations. Whereas OQ tests individual functions, PQ covers the entire end-to-end business process and is led by the process owner (business department).

Example PQ Scenarios (SAP QM)	Test Content
PQ-SC-01 Raw material receiving inspection	End-to-end verification from goods receipt of raw materials from a supplier → inspection lot generation → sampling → recording of inspection results (MIC) → usage decision (321) → release to inventory
PQ-SC-02 Quality control of intermediate products during manufacturing	Completion of production order → intermediate product inspection lot → in-process inspection → blocking on failure (344) → retest → final usage decision
PQ-SC-03 Product release decision	PQ inspection of finished goods → final usage decision based on GMP requirements → release of shipping block (321) → delivery via sales order
PQ-SC-04 Deviation handling (OOS scenario)	Quality notification creation upon occurrence of an OOS (out-of-specification) result → retest instruction → root cause investigation → quality rejection (553)
PQ-SC-05 Audit trail verification	After performing all transactions, verify the change log (CDHDR/CDPOS); confirm that who changed what, when, and to what is recorded

Chapter 7: Obtaining and Recording SAP Configuration Evidence

7.1　Turning SPRO Configuration into Validation Evidence

Configuration of SAP S/4HANA is performed via the SPRO transaction, and its settings directly affect product quality. For example, “whether an inspection lot is generated for movement type 101” is determined by SPRO configuration, and from a GxP perspective, the configuration values and their approval records must be kept as evidence. Evidence for SPRO configuration is obtained using the following methods.

Evidence-Gathering Method	Content / Purpose	Tool
Screenshots	Captures of the SPRO configuration screen; visually record configuration values	Print Screen / Snipping Tool; managed in GitHub, etc.
SE16N table content export	Export configuration tables (e.g., T001/T156Q) to Excel/CSV format	SE16N → “Program” → Export
SCC1 / SPRO comparison tool	Verify configuration differences between the Dev and Prod environments; evidence that “it was transported exactly as designed”	SPRO → configuration comparison tool
Transport request record (SE10/STMS)	Evidence of configuration transports from Dev → QA → Prod; history of when, by whom, and what was transported	SE10 (transport request management), STMS (Transport Management System)
Change pointers (SCU3)	Change log for SPRO configuration changes; records values before and after the change	SCU3 transaction
Validation configuration register	An Excel register maintained by QA that organizes all GxP-relevant configuration values as validation documentation	Created and maintained by QA department

7.2　Validation Evidence for Custom Development (Cat.5)

Checklist for Obtaining ABAP Custom Development Evidence

☐ Functional Specification (FS): design document translating business requirements into technical specifications (QA approval required) ☐ Design Specification (DS): ABAP technical design document (module structure, database design, interface specifications) ☐ Code review record: results of ABAP code review by a different reviewer (signed) ☐ Unit test record: unit tests performed by the developer (input / expected result / actual result) ☐ OQ test execution record: records of functional testing performed using QA-approved test cases ☐ Transport request record: transport history from Dev → QA → Prod (SE10/STMS) ☐ Source code version control: version control of the ABAP code (SE80/Git integration) ☐ Change management record: approval record from the Change Advisory Board prior to transport to production

Chapter 8: Change Control

8.1　GxP Change Management Requirements

All changes made to an SAP system after validation has been completed are subject to change control. To confirm that “a validated system has not been invalidated by a change,” regulators require evidence of impact assessment, approval, implementation, and re-validation for each change.

Type of Change	Example	Need for GxP Impact Assessment	Response
Emergency fix	Fixing a critical bug in the production system; applying a security patch	Required (post-hoc assessment acceptable after emergency response)	Perform per the emergency change procedure, then submit a post-hoc assessment and deviation report
Planned configuration change (SPRO change)	Changes to organizational structure; addition or change of inspection settings	Required (mandatory for functions with GxP impact)	Obtain prior approval from the Change Advisory Board (CAB); transport after impact testing is performed
ABAP custom change	Addition of a report function; modification of an existing function	Required (Cat.5)	Perform full validation (DS / code review / OQ testing) before transport
SAP upgrade (Support Package)	SAP Support Package level upgrade; activation of new features	Required; a re-validation plan is needed	Develop a regression test plan; re-execute OQ testing for affected functions
Infrastructure change	Database version upgrade; server expansion	Required (IQ scope)	Re-verify IQ items; update BASIS configuration records
Security change	Adding/removing roles; changing user authorizations	Required (access control)	Assess the impact of the authorization change; follow the access control SOP

8.2　Change Control Execution Flow

Standard SAP Change Control Flow (GxP-Compliant)

Step 1: Raise a change request → Record the change content, reason, GxP impact level (H/M/L), and urgency → Register in the change request system (a change management tool or SAP Solution Manager) Step 2: GxP impact assessment → The QA representative assesses the GxP impact level → Document the impact assessment record (which validated functions are affected) Step 3: Change Advisory Board (CAB) review and approval → Approval by IT, business, and QA (electronic or handwritten signature) → Confirm the implementation schedule and risk mitigation measures Step 4: Implementation and testing in the Dev environment → Perform ABAP development or SPRO configuration changes → Regression testing of affected functions (re-run OQ test cases) Step 5: QA approval and testing in the QA environment → Verification testing in the QA environment → QA approval record (signed) Step 6: Transport to the production environment (STMS) → Execute the transport to production after CAB approval → Record the transport request number in the change record Step 7: Close the change record → Close the change record after confirming production and verifying no abnormalities → Update validation documentation (TM and configuration register)

Chapter 9: Re-validation During SAP S/4HANA Upgrades

9.1　Criteria for Determining Re-validation

Applying SAP Support Packages, version upgrades, and adding functionality (Enhancement Packages) can affect validated functions. To rationally determine the scope of re-validation, an impact assessment should be performed and documented, with supporting rationale, on “what needs to be re-tested.”

Change Content	Determining the Scope of Re-validation	Recommended Approach
SAP security patch (no functional change)	No impact on GxP functionality → update IQ items only	Record the patch level update; regression testing not required (document the rationale)
Support Package (SAP-provided function fixes)	Review the release notes; identify GxP-impacted functions	Re-run OQ test cases for affected functions; attach the supplier release notes as evidence
Enhancement Package (new function addition)	GAMP5 category determination for the added function; impact assessment on existing functions	Added function: validate from a new URS; existing function: impact assessment plus regression testing
SAP S/4HANA major version upgrade	Broad impact on the entire system; a full re-validation plan is required	Develop a re-validation plan; regression test all GxP functions
Custom development modification (ABAP change)	The modified ABAP and downstream functions affected by it	Update the design specification; re-run OQ test cases (affected scope)

9.2　Regression Testing Strategy

Re-running all OQ test cases with every upgrade is inefficient. Based on the risk-based approach, adopt a three-tier regression testing strategy: “high-risk functions (directly tied to patient safety or product release) are always re-run,” “functions with change impact are selectively re-run,” and “functions with no impact are exempted from regression testing, using the impact assessment record as evidence.” Documenting this strategy in the re-validation plan provides evidence of a rational judgment during inspections.

Chapter 10: Key Validation Focus Points by SAP Module

Module	Key Functions with GxP Impact	Validation Focus Areas
QM Quality Management	Inspection lot generation, usage decision, inventory status changes (321/344/553), MIC (management characteristics) / tolerance management	Verify that inventory blocking → release → rejection controls operate as configured; linkage between usage decision and inventory movement type
MM Materials Management	Raw material receipt (101), supplier evaluation (ME61), MRO consumables management	Linkage of GxP raw material receiving inspection; supplier blocking function; batch management and expiration date management
PP Production Planning	Production order / backflush, GR (101) / scrapping (551), production records (linked to EBR)	Integration with Electronic Batch Records (EBR); production order status management; traceability of raw materials used
WM/EWM Warehouse Management	Inventory tracking by storage location, expiration date management (FEFO), serial number tracking	Storage condition management for GxP raw materials; verification of FEFO picking behavior; inventory control in temperature-managed areas
FI Financial Accounting	Accounting treatment of GxP costs; recording of scrapping losses; warranty cost management	Configuration of GxP cost codes; linkage between scrap goods movements and cost posting
SD Sales and Distribution	Shipment authorization after product release decision; shipping block control; serial number shipment tracking	Linkage between the QM usage decision and shipping block; shipment records for product serial numbers

Chapter 11: CSV Documentation Structure and Retention

11.1　List of Required CSV Documents

Document Name	Abbreviation	Purpose / Content	Approximate Retention Period
Validation Plan	VP	CSV policy, scope, and organization for the entire project	Product lifecycle + 1 year
GxP Impact Assessment	GxP-IA	Results of the GxP impact assessment for all functions	Same as above
GAMP5 Category Classification Table	Cat.Table	List of category classifications by function/development unit	Same as above
Risk Assessment Record	RA	Risk scores and response policy by function	Same as above
User Requirements Specification	URS	Business requirements specification including GxP requirements	Same as above
Functional Specification	FS	Specification translating the URS into functional design	Same as above
Design Specification (Cat.5 only)	DS	Technical design specification such as ABAP	Same as above
Supplier Assessment Record	SA	Record of the assessment of SAP’s quality system	Same as above
IQ Protocol and Report	IQ	Plan and execution record for installation verification	Same as above
OQ Protocol and Report	OQ	Plan and execution record for functional testing	Same as above
PQ Protocol and Report	PQ	Plan and execution record for operational testing	Same as above
Traceability Matrix	TM	Mapping of requirements → design → tests	Same as above
Deviation Report	DR	Records and analysis of test deviations/defects	Same as above
Validation Summary Report	VSR	Summary report concluding the validation	Same as above
Change Control Record	CCR	Change records after production release	5+ years from the date of change
CSV Procedure (SOP)	SOP	Procedures for change management, periodic review, etc.	Current version + 5 years after retirement

End of document.