Computer System Validation (CSV)
GxP & Audit-Ready Compliance in accordance with GAMP 5

Computer System Validation is a systematic process for verification and documentation that a computer system meets the defined requirements and reproducibly achieves the desired results. In the pharmaceutical and chemical industry, CSV is essential to ensure compliance with GxP regulations (Good Practice Guidelines) such as GMP, GLP, and GCP, and to guarantee data integrity.

The most important regulatory requirements come from:

• FDA 21 CFR Part 11: Electronic Records, Electronic Signatures
• GAMP 5 (Good Automated Manufacturing Practice): Guidance for the validation of systems in automation and computer technology
• EU Directive Annex 15: Qualification and Validation
• ICH Q7/Q14: Guidelines for pharmaceutical production and development
• GxP Guidelines: GMP, GLP, GCP, and further industry-specific requirements

The CSV process typically follows these phases:

• User Requirements Specification (URS): Definition of business and functional requirements
• Functional Specification (FS): Detailed description of system functions
• Design Specification (DS): Technical design of the system
• Installation Qualification (IQ): Verification of correct installation
• Operational Qualification (OQ): Validation of system functions under normal conditions
• Performance Qualification (PQ): Verification of system performance with real data

• Verification answers the question “Was the system built correctly?” – It checks whether the system conforms to the specifications.
• Validation answers the question “Was the right system built?” – It checks whether the system fulfills the intended business function.

Both processes are essential for comprehensive CSV and must be documented.

Data Integrity refers to ensuring that data is correct, complete, and unchanged. This includes:

• Authenticity: The data originates from a known source
• Integrity: The data has not been altered without authorization
• Availability: Data is accessible and readable
• Traceability: All changes are documented and can be traced back

This is ensured through audit trails, electronic signatures, and access controls.

The retention period depends on the regulatory requirements:

• Pharmaceutical Systems: At least as long as the product is marketed, often 5-10 years
• Clinical Trials: At least 2 years after approval or rejection
• Lifecycle Management: Documentation should be available throughout the entire system lifecycle

Country-specific regulations and customer-specific contracts may impose differing requirements.

Revalidation is required after:

• Changes to the system: Software updates, hardware upgrades, or configuration changes
• Operating environment changes: Changes to the operating system, database, or IT infrastructure
• Process changes: Changes to critical business processes
• Regulatory changes: New or changed compliance requirements
• Bug fixes: For critical system errors

The extent of revalidation depends on the impact of the change (Impact Assessment).

Risk Assessments are central to the CSV strategy:

• They identify critical system functions and potential sources of error
• They determine the extent of validation: Systems with higher risk require more comprehensive validations
• They document measures for risk mitigation
• They support the prioritization of validation activities
• They make the validation strategy traceable and justified

This is performed using methods such as FMEA (Failure Mode and Effects Analysis) or other standardized procedures.

An Audit Trail is a chronological log of all system actions and data changes that documents:

• Who (User ID)
• When (Timestamp)
• What (Action performed or change made)
• Why (Optional: Reason for change)

Audit Trails are critical for:

• Regulatory Compliance (21 CFR Part 11, FDA)
• Traceability of data changes
• Detection of unauthorized access
• Forensic analysis in case of suspected errors

They must be immutable and retained throughout the system lifecycle.

• COTS Systems (Commercial Off-The-Shelf): The manufacturer is responsible for base validation. The user must validate the system configuration, integration into existing infrastructure, and application in the specific business context. The validation effort is often lower.
• Custom/Custom-Built Systems: The developer and/or the user are responsible for complete validation from the start (from URS to PQ). The validation effort is typically more comprehensive, as all aspects of the system must be validated.

Both approaches require a Validated State and continuous monitoring during operation.