A few years ago I sat in on a customer onboarding call where the Head of Quality opened with a sentence I still remember. “We’ve validated this computerised system three times in five years,” she said, “and we still got a Form 483 observation on it last month.”
That one sentence explains most of what's wrong with how the industry treats GxP computer system validation (CSV). CSV has become one of the most misunderstood activities in regulated life sciences.
Most CSV is documentation. Teams fill the binder, file it on a shared drive, and then act surprised when an inspector finds the system itself isn't actually under control.
The numbers say the same thing. FDA warning letters rose 50% in fiscal year 2025, and data integrity and computerised system control were among the most cited themes. Our own Global Quality Outlook 2026 finds the same gap further downstream: 58% of companies still lag in quality digitalisation, and 40% struggle to make data-driven decisions about quality. None of that happens during the project. It happens once the system is live and in use, which is exactly where most CSV budgets stop paying attention.
So this article works through five things: what GxP computer system validation actually is, how the validation life cycle works, where the risk-based logic comes from, what auditors look for, and where CSV is heading next.
Key takeaways
What is GxP Computer System Validation (CSV)
GxP computer system validation is the documented process of proving, with objective evidence, that a computerised system performs as intended, consistently, and in line with the regulations that apply to life sciences.
“GxP” is the umbrella for Good Practices, where the “x” stands for the regulatory discipline involved: GMP, GCP, GLP, GDP or GVP. If your computerised system handles data tied to any of these, validation is a requirement. The purpose is to safeguard patient safety, product quality and data integrity.
The predicate rules vary by geography. In the US, 21 CFR Part 11 governs how electronic records and electronic signatures stand in for paper, and the FDA treats computer systems used in production or quality as equipment under 21 CFR 211.68. In Europe, EU GMP Annex 11 covers computerised systems in GMP environments. For medical devices, ISO 13485 adds design-control expectations.
If you run an eQMS, LIMS, MES, EDC or ERP, CSV for quality management systems (QMS) applies, which covers most of life sciences. For the framework underneath modern CSV, our Complete GAMP 5 guide for GxP compliant computerised systems is a good companion read.
Recommended learning:
Electronic records and signatures according to 21 CFR Part 11.
The shifting regulatory ground for CSV
Two things shifted in 2025, and any honest piece on GxP computer system validation written in 2026 has to acknowledge them.
First, the FDA finalised its Computer Software Assurance (CSA) guidance on 24 September 2025, with an updated version on 3 February 2026. The final CSA guidance officially supersedes Section 6 of the FDA 2002 Guidance on General Principles of Software Validation. CSA endorses a risk-based, least burdensome approach: critical thinking and targeted testing instead of test-everything documentation.
Second, the European Commission published a draft revision of EU GMP Annex 11 on 7 July 2025, alongside a new Annex 22 on Artificial Intelligence. The draft Annex 11 grows from five pages to nineteen, driven by the growth of cloud services and new technologies. The final version is expected in mid-2026.
Both shifts point the same way. Regulators want more thinking and less binder-stuffing. If your CSV strategy still treats every system the same, the ground has moved under you.
Computer System Validation life cycle
The most common mistake in CSV is treating it as a project that ends at go-live. It is not. The CSV life cycle runs from concept to retirement, and every phase needs evidence.
GAMP 5 2nd Edition defines four life cycle phases:
-
Concept. A business need is identified. The team defines high-level requirements and decides whether a new system is even needed.
-
Project. The heaviest phase. A Validation Plan defines the strategy. The team writes the URS, Functional and Configuration/Design Specifications, performs Quality Risk Management, builds or configures the system, and executes unit, integration, functional and user acceptance testing. The phase closes with a Validation Summary Report.
-
Operation. The system is in daily use. This is the longest stage of the life cycle. State of control is held through Change Management, Incident Management, Periodic Review and ongoing training.
-
Retirement. The final phase covers the documented decommissioning of the system, including data migration and archiving, so regulated records stay accessible and legible for the full retention period.
The V-model
The CSV lifecycle is usually drawn as a V-model, a shape GAMP 5 2nd Edition doesn’t prescribe, but every auditor under fifty still expects to see.
The left side captures what the system must do:
-
URS
-
Functional specifications
-
Configuration and design specifications
The right side mirrors each requirement with the test that proves it was met. Every requirement on the left has a corresponding test on the right. That traceability is what auditors check first.
GAMP 5 2nd Edition reframes the V-model as a critical thinking tool. Unscripted testing is fair game in low-risk areas. High-risk GxP functions still need rigorous evidence.
GxP computer system validation cannot be compressed into a one-week sprint just before go-live. It runs the full life of the system, or it isn't really validation.
Risk-based validation (GAMP-style)
Not every computerised system carries the same risk to GMP-regulated processes. A spreadsheet that calculates KPIs and a website that lists your office hours both run on computers, but only one belongs anywhere near a validation plan.
The core idea of GAMP 5 is to scale your effort to the risk the system actually carries. The computer system risk management and validation life cycle should focus heaviest where patient safety, product quality and data integrity are most exposed.
GAMP 5 sets out four software categories. The old Category 2 is gone: firmware now sits inside Category 3, alongside non-configurable COTS. Same risk profile, cleaner taxonomy.
So the framework runs 1, 3, 4, 5:
-
Category 1: Infrastructure software like operating systems, databases, and network management tools. It requires minimal validation. Indirect evidence of operation is usually sufficient, since infrastructure is qualified rather than validated.
-
Category 3: Standard System Components, including firmware-based applications, non-configured Commercial Off-The-Shelf (COTS) software, and some instruments used as supplied. It requires moderate validation, such as confirming the system meets user needs and vendor requirements.
-
Category 4: Configured commercial products, including systems such as LIMS, ERP, SCADA, DCS, CDS, EDMS, BMS, CRM, spreadsheets, and by extension most eQMS and MES platforms. It requires rigorous verification of configuration settings and business workflows.
-
Category 5: Custom applications built for a single business process. Full life cycle documentation required, including design reviews and intensive unit and functional testing.
GAMP 5 2nd Edition makes a point that often gets lost. The categories are a continuum, not a checklist. One application may contain components from several categories, which calls for a hybrid validation strategy.
What GAMP 5 also puts first is critical thinking. Subject matter experts decide what testing is worth doing, why, and to what depth. That is a meaningful departure from the test-everything default that dominated CSV in the 2010s.
Qualification phases in computer system validation
GAMP 5 2nd Edition (2022) has shifted toward a more flexible framework of Specification and Verification, but the traditional "3Qs" (IQ (Installation Qualification), OQ (Operational Qualification), and PQ (Performance Qualification)) remain widely recognised by regulators and industry practitioners.
Qualification is how you prove the system meets its requirements. In practice, three classic qualification phases in computer system validation still anchor most CSV programmes: IQ, OQ and PQ.
-
Installation Qualification (IQ). Documented evidence that the system, including hardware, software and supporting infrastructure, is installed according to design intent and manufacturer recommendations. For SaaS, the vendor covers the platform. The end user verifies environment configuration, access controls and security settings.
-
Operational Qualification (OQ). Functional testing under controlled conditions: configured functionality, business rules, calculations and interfaces against the functional specification.
-
Performance Qualification (PQ). The total system, with people and procedures included, all performing consistently in its real operating environment against pre-approved specifications.
Recommended learning:
GAMP 5 2nd Edition reframes this work under Specification and Verification rather than the rigid 3Qs. The standard is intentionally non-prescriptive. Use whichever vocabulary your inspectors and auditors recognise.
Vendor validation packages: stop reinventing the wheel
In old-school GxP, there was a sense that if you didn’t write every test script yourself, it didn’t count. GAMP 5 2nd Edition and CSA put an end to that.
I have watched quality teams burn six weeks rewriting IQ scripts for an off-the-shelf eQMS the vendor had already qualified. That is duplication of effort wearing a binder.
A vendor validation package is a complete set of documents the software provider drafts and executes to prove the system works as intended. Used well, it removes most of the duplicated cost and effort. Scilife’s validation package, for instance, is a signed-off CSV documentation set customers can build their own validation on top of.
For SaaS Validation, responsibility is shared. The vendor validates platform infrastructure, core code and standard functionality. The customer validates the configurations, user access levels and change control specific to their intended use.
Key CSV deliverables auditors expect
Auditors now care more about the quality of critical thinking than the height of the binder, but the documented deliverables list hasn't gone away.
These are the documents that any organization should always have ready for audit:
-
Validation Plan (or Validation Master Plan for multi-system programmes)
-
Systems Inventory, with GxP status per system
-
User Requirements Specification (URS)
-
Functional / Configuration Specification
-
Risk Assessment (FMEA or equivalent QRM tool)
-
Test Plan
-
IQ, OQ and PQ protocols and reports
-
Traceability Matrix
-
Test Summary Report
-
Validation Summary Report
-
Change Control records (ongoing)
-
Periodic Review records (ongoing)
Plus the supporting evidence around the system: SOPs for use, administration, maintenance and security; training records showing personnel are qualified; and audit trails of GxP-relevant entries and actions.
The role of traceability and reporting in CSV
Auditors scale their expectations to the system’s risk, complexity and novelty.
For instance, the Traceability Matrix links each URS line to a specification and a test result. The Validation Summary Report closes out the work, addresses deviations and states clearly that the system is fit for its intended use.
Skip the trace and you skip the only thing an inspector reads end to end.
Conclusion: The shift from CSV to CSA, in practice
The binder-stuffing era is over. CSA points teams at where their effort should actually go: high-risk functions that touch patient safety, product quality and data integrity.
Exploratory or unscripted testing may be appropriate in lower-risk areas when adequately documented and performed by qualified personnel. Vendor evidence is now acceptable input.
Run the test yourself. Pull your last validation binder. Count the test scripts that checked functions a five-minute risk assessment would have left alone. That number, minus your defensible baseline, is your CSA opportunity.
For a side-by-side breakdown, see our CSV vs CSA: What are the main differences? piece.
Discover how SciLife Smart Quality QMS helps teams implement CSA more efficiently.
