Computer System Validation (CSV) is the process of establishing documented evidence that a computerized system consistently performs according to its intended purpose in a GxP-regulated environment. Defined under 21 CFR Part 11 and GAMP guidance, CSV ensures that software used to create, modify, maintain, archive, or transmit GxP records is accurate, reliable, and fit for use. It encompasses the entire system lifecycle — from requirements definition through decommissioning — with appropriate documentation at each phase.
CSV requirements in pharma derive from multiple regulatory sources. 21 CFR Part 11 governs electronic records and signatures for FDA-regulated systems. 21 CFR Parts 210/211 (GMPs) require that laboratory and manufacturing systems be qualified. EU GMP Annex 11 sets requirements for computerized systems in European operations. ICH Q7 and Q10 provide quality system context. GAMP 5 (published by ISPE) is the industry's primary implementation framework. Together, these create a layered compliance obligation that CSV documentation is designed to satisfy.
A traditional CSV lifecycle follows the V-model: User Requirements Specification (URS) defines what the system must do; Functional Specification (FS) and Design Specification (DS) describe how it will do it; Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) provide structured evidence that it does so in practice. A Validation Summary Report closes the lifecycle. Change control, periodic review, and retirement procedures maintain validated status throughout the system's operational life.
IQ (Installation Qualification) verifies that the system is installed correctly in its intended environment — hardware, software versions, network configuration, and environmental controls. OQ (Operational Qualification) confirms that the system operates as designed across its specified operating range, typically testing individual functions against design specifications. PQ (Performance Qualification) demonstrates that the system performs consistently and reliably under real-world production conditions, using representative data and processes. Each phase builds on the previous, with documented evidence at each step.
Any computerized system that creates, modifies, maintains, archives, retrieves, or transmits GxP records — or that directly controls, monitors, or influences a GxP process — requires validation. This includes LIMS, ERP/ERP modules used in manufacturing, MES, SCADA and DCS systems, electronic batch records, chromatography data systems (CDS), clinical trial management systems, and quality management systems. The scope is determined by the system's GxP impact, not its technology type.
The URS is the foundation of the entire CSV lifecycle because it defines what the system must accomplish from a business and regulatory perspective, independent of any technical solution. All subsequent specifications, test protocols, and qualification activities trace back to the URS. A poorly written URS — vague, incomplete, or untraceable — propagates through every downstream document, creating gaps that inspectors routinely identify. A well-constructed URS with clear, testable, numbered requirements is the single most effective risk mitigation in the CSV process.
A Validation Summary Report should document: the system scope and intended GxP use; validation strategy and risk assessment approach; references to all executed qualification protocols and their outcomes; deviations encountered and how they were resolved; confirmation that all requirements in the URS were tested and met; residual risks and any accepted deviations; and a formal conclusion that the system is in a validated state and fit for its intended use. It serves as the single reference document for audit and inspection purposes.
Change control for validated systems requires a formal impact assessment before any change is implemented. The assessment must determine whether the change affects validated functions, what testing is required to re-establish validated status, and whether the change triggers a formal requalification. Minor configuration changes may require only documented impact assessment and targeted regression testing; major functional changes may require partial or full requalification. All changes — including vendor-released patches and software upgrades — must pass through the change control process before deployment to validated environments.
Periodic review is a scheduled assessment of validated systems to confirm they remain in a validated state and continue to meet their intended purpose. Reviews typically occur annually for high-risk GxP systems, though frequency should be risk-based. A periodic review checks for: accumulation of unreviewed changes, outstanding deviations or anomalies, changes in regulatory requirements, software version currency, vendor support status, and system performance trends. The outcome is documented confirmation — or a revalidation trigger — that the system's validated status is maintained.
Deviations during CSV qualification — test steps that do not achieve their expected result — must be documented immediately in a deviation report. Each deviation requires: a precise description of what occurred versus what was expected; an investigation into root cause; an impact assessment on validation scope; and a documented resolution, which may include test script correction, software defect correction and retest, or formal acceptance of the deviation with documented justification. Unresolved or undocumented deviations are a consistent finding in FDA warning letters and EU GMP inspections.
Yes. CSV requirements for commercial software include an assessment of the vendor's quality system to determine whether their development and testing processes are adequate. For higher-risk systems (GAMP categories 4 and 5), a formal vendor audit — either on-site or via questionnaire — is standard practice. The audit evaluates software development lifecycle practices, testing rigor, change management, defect tracking, and documentation quality. A strong vendor quality system supports the use of vendor-supplied testing evidence, reducing the company's own qualification burden.
A Requirements Traceability Matrix maps every user requirement from the URS to its corresponding test case(s) in IQ, OQ, or PQ protocols. It provides auditable proof that every stated requirement was tested and that no qualification effort was wasted on untraceable tests. Without an RTM, it is impossible to demonstrate completeness of testing during an inspection. An RTM also serves as a critical change control tool — when requirements change, the RTM immediately identifies which test cases must be updated or re-executed.
Traditional CSV remains regulatory acceptable — no agency has mandated abandonment of legacy CSV approaches. However, the FDA's September 2022 CSA final guidance signals a strong preference for risk-based, critical thinking approaches over prescriptive documentation. Companies that maintain traditional CSV processes are not immediately at risk of enforcement action, but they face growing documentation overhead, longer validation timelines, and increasing misalignment with modern inspector expectations. New validations and major revalidations are increasingly expected to reflect CSA principles.
SaaS validation under CSV follows the same risk-based logic but adapts the model for cloud-hosted systems. The regulated company remains responsible for validation but can leverage vendor-supplied IQ evidence (infrastructure, hosting, security) and OQ evidence (vendor test documentation, release notes). The company's direct responsibility focuses on: vendor quality system assessment, configuration qualification (confirming their specific setup meets requirements), user acceptance testing for GxP-impacting workflows, and ongoing change management. A shared responsibility model — documented in a Vendor Responsibility Matrix — clarifies boundaries.
CSV and 21 CFR Part 11 address different but overlapping obligations. CSV is the broader validation requirement — establishing that a system is fit for its GxP purpose. 21 CFR Part 11 applies specifically when a system creates, modifies, maintains, archives, retrieves, or transmits electronic records that substitute for paper records, or uses electronic signatures. A system may require CSV without triggering Part 11 (e.g., a process control system with no electronic records). Most enterprise GxP systems require both, and the Part 11 assessment is typically a component of the CSV effort.
Risk assessment in CSV determines which system functions have GxP impact, what the consequence of failure would be for product quality or patient safety, and what level of testing evidence is proportionate to each risk. A Functional Risk Assessment (FRA) — sometimes called a Critical Function Assessment — maps each system function to its GxP criticality level. High-criticality functions receive detailed scripted testing; low-criticality functions may receive simplified evidence. This structured approach ensures validation effort is invested where it genuinely matters, consistent with both GAMP 5 and the CSA framework.
CSV and data integrity are closely related but distinct. CSV validates that a system functions as intended; data integrity ensures that data produced by validated systems is attributable, legible, contemporaneous, original, and accurate (ALCOA+). A validated system that lacks data integrity controls — inadequate audit trails, shared credentials, or the ability to backdate records — fails both GMP and regulatory expectations. Data integrity requirements must be explicitly addressed within the CSV process, not treated as a separate post-validation concern.
CSV documentation must be retained for the operational life of the validated system plus the applicable record retention period. FDA GMPs (21 CFR Part 211) require records to be retained for at least one year after the expiry date of the last batch associated with the record. GAMP guidance recommends retaining validation documentation for the life of the system plus applicable regulatory retention periods. Practically, most pharmaceutical companies maintain CSV records for a minimum of five years post-system retirement, though longer periods apply for certain product types and market jurisdictions.
A computerized system inventory (or register) is a maintained list of all GxP computerized systems within an organization's scope, along with their validation status, risk classification, owner, and review dates. It serves as the master reference for regulatory inspections and internal audits. Systems not appearing in the inventory may be operating in a GxP capacity without validation coverage — a significant compliance risk. Regulatory inspectors routinely request the system inventory as a first step in a computer system inspection.
The most frequently cited CSV deficiencies in FDA warning letters include: failure to validate computer systems used to create or maintain GxP records; inadequate audit trail coverage or failure to review audit trails routinely; use of shared logins that prevent individual user attribution; insufficient change control for validated systems; failure to address deviations from validation protocols; and incomplete qualification documentation missing required phases or signatures. Chromatography data systems (CDS) and LIMS are particularly common subjects of CSV-related observations.