What is Computer System Validation (CSV) in pharma?
Computer System Validation is a lifecycle approach for establishing and maintaining documented confidence that a GxP computerized system is fit for its intended use. Scope and evidence should reflect the regulated process, GxP impact, data integrity, risk, complexity, supplier evidence, configuration or customization, and applicable requirements.
For related guidance, see the GoVal CSV workflow, GAMP 5 FAQ, and CSA FAQ.
The practical CSV question is not “How much documentation do we need?” It is whether the evidence is sufficient to show the system can support its intended GxP use and remain controlled through change.
Regulatory Requirements for CSV
There is no single global CSV regulation. The applicable obligations depend on the product, process, records, and jurisdiction. Common references include:
21 CFR Part 11 is relevant when an organization relies on electronic records or signatures within its scope. EU GMP Annex 11 addresses computerized systems used in GMP activities in Europe. GAMP 5 provides industry guidance for applying lifecycle and risk-based practices; it is not itself a regulation.
A Practical CSV Lifecycle
Qualification is only one part of CSV. A practical lifecycle can be organized into seven stages, with the exact deliverables scaled to intended use and risk.
| # | Stage | Key Output |
|---|---|---|
| 1 | System Inventory & Scope | Intended use, system boundaries, and GxP impact defined |
| 2 | Risk Assessment | Higher-risk functions, data, and controls identified |
| 3 | Requirements | Business, data-integrity, and compliance requirements documented |
| 4 | Design / Configuration | Configuration, custom components, interfaces, and supplier evidence assessed |
| 5 | Qualification / Assurance | Evidence generated for GxP-relevant intended use at a justified depth |
| 6 | Release | Issues evaluated, approvals completed, and system accepted for use |
| 7 | Operation & Retirement | Changes, incidents, review, access, and retirement remain controlled |
GAMP 5 Software Classification
GAMP 5 Second Edition uses Category 1 for infrastructure software, Category 3 for non-configured products, Category 4 for configured products, and Category 5 for custom applications. Category helps describe product type and complexity, but it should not be used as an automatic test-volume rule.
| Category | Software Type | Examples | Assurance Focus |
|---|---|---|---|
| Cat 1 | Infrastructure | Operating systems, databases, network software | Controlled installation, configuration, security, and operation appropriate to the supported GxP use |
| Cat 3 | Non-configured product | Commercial software used largely as supplied | Supplier evidence plus verification of the organization's GxP-relevant intended use |
| Cat 4 | Configured product | QMS, LIMS, ERP, CTMS | Configured workflows, roles, data, reports, interfaces, and higher-risk functions |
| Cat 5 | Custom application | Bespoke applications, custom extensions, automation | Lifecycle evidence for requirements, design, development, testing, release, and change proportionate to risk |
Validation principle: software category is one planning input. Intended use, GxP impact, functional risk, complexity, novelty, supplier evidence, and the degree of configuration or customization should determine the assurance strategy.
IQ, OQ, and PQ — What Each Phase Demonstrates
Where an organization uses IQ/OQ/PQ terminology, the phases address different questions. Their boundaries vary by architecture and quality-system procedure; they should not be treated as three identical document templates for every system.
- Installation and environment verified
- Baseline configuration recorded
- Relevant supplier documentation reviewed
- Higher-risk functions verified
- Access and audit-trail behavior checked where applicable
- Exceptions and error handling assessed
- Representative end-to-end workflows verified
- Users, data, and operating conditions reflected
- Critical interfaces included where relevant
Assurance depth should be justified by intended use, GxP impact, risk, complexity, configuration or customization, and credible supplier evidence. A low-risk standard function and a custom function used for a critical quality decision should not receive the same treatment simply because they sit in the same application.
CSV Control Gaps to Check
Before an inspection or periodic review, focus on whether the current system state is still supported by approved evidence.
Requirements, risks, tests, deviations, and approvals cannot be followed as one evidence chain.
Patches, configuration updates, or interfaces change without a documented GxP impact assessment.
Access, audit trails, electronic records, or review practices do not reflect how the system supports the GxP process.
Periodic review, incidents, supplier releases, or production changes are not reflected in the current validation state.
How FDA CSA Fits into Current Practice
FDA's February 2026 Computer Software Assurance guidance formally applies to software used in medical-device production and quality management systems under 21 CFR Part 820. Within that scope, it supports assurance based on intended use and process risk, appropriate use of supplier evidence, and testing methods proportionate to the risk being controlled.
- Risk drives assurance: higher-risk uses need stronger evidence; lower-risk uses may justify simpler methods.
- Supplier evidence can be leveraged: when it is relevant, credible, and assessed for gaps.
- Testing method can vary: scripted, scenario-based, exploratory, or other methods may be appropriate when justified.
- Objective evidence still matters: the record should show what was assessed, what was performed, what issues were found, and the conclusion.
For pharmaceutical and biotech systems outside the formal scope of FDA's CSA guidance, similar risk-based principles can be applied through GAMP 5, applicable GxP requirements, and the organization's quality system.
Managing CSV with a Validation Lifecycle Management System
CSV becomes harder to control when requirements, risk assessments, tests, deviations, approvals, and change records are maintained in separate files. The issue is not simply document storage; it is maintaining traceability and knowing whether the production state is still supported by approved evidence.
GoVal connects system intake, risk assessment, requirements, qualification or assurance execution, traceability, deviations, approvals, change impact, and periodic review in one environment. Teams can keep related evidence linked through the lifecycle, while the regulated organization remains responsible for defining the validation strategy and ensuring the evidence is appropriate for intended use and risk.
Related Topics
Frequently Asked Questions
What is Computer System Validation (CSV)? +
Which regulations and guidance are relevant to CSV? +
What are the main stages of a CSV lifecycle? +
What is the difference between CSV and CSA? +
What is GAMP 5 and how does it apply to CSV? +
How does GoVal support Computer System Validation? +
Manage your full CSV lifecycle in one platform
Risk, requirements, qualification, traceability, change control, and periodic review — connected in GoVal.