Definition · Plain-language
Computer system validation (CSV)
Computer system validation is the documented evidence that a computerised system consistently performs as intended in a regulated GxP environment.
The step most authors miss
Doing CRediT right? Don’t stop at the statement.
A CRediT statement credits you inside one paper. The recognition CRediT was built for happens when those roles are tied to you, persistently. Sign in with your ORCID — free — and claim your CRediT contributions on casrai.org, the home of the standard. They become a verified, portable part of your identity, not a line that disappears into one PDF.
Free: claim your contributions, then export a journal-ready CRediT statement, schema.org structured data, JATS XML, CSV or BibTeX — and preview your public profile. A membership publishes that profile publicly and verifies the journals you serve.
What CSV establishes
Computer system validation provides documented, objective evidence that a computerised system — software together with the hardware and procedures around it — meets its predetermined specifications and intended use. It typically follows a lifecycle: defining user and functional requirements, assessing risk, qualifying the installation and operation, testing against requirements, and maintaining the validated state through change control. The output is a body of documentation that lets an organisation, and a regulator, trust the records and decisions the system produces.
Why it matters in GxP
In manufacturing, laboratory and clinical settings, computerised systems generate and store the records that demonstrate product quality and patient safety. If a system is not validated, there is no assurance that those records are complete and accurate, which undermines data integrity and regulatory compliance. CSV is therefore closely tied to expectations such as 21 CFR Part 11 for electronic records and signatures, and to the ALCOA data-integrity principles that the records produced by the system are expected to satisfy.
The shift to CSA
Historically CSV became document-heavy, with extensive scripted testing applied uniformly regardless of risk. The FDA’s Computer Software Assurance (CSA) approach, set out in draft guidance, reframes the effort as risk-based assurance: identify the system’s intended use, determine the risk to patient safety and product quality, and concentrate critical-thinking and testing where that risk is highest, using lighter approaches such as unscripted or ad hoc testing elsewhere. CSA is an evolution of CSV, not a replacement of the underlying objective.
Key facts
At a glance
- Definition: documented evidence a computerised system works as intended
- Abbreviation: CSV
- Lifecycle: requirements, risk, qualification, testing, maintenance
- Linked to: 21 CFR Part 11; ALCOA data integrity
- Framework: GAMP 5 is the common industry guide
- Evolving to: FDA Computer Software Assurance (CSA), risk-based
Common misconceptions
What people often get wrong
Often heard: Validating a computer system is a one-time, install-and-forget task.
Actually: The validated state must be maintained through change control, periodic review and revalidation when the system or its use changes.
Often heard: CSV means testing every function exhaustively, regardless of risk.
Actually: The FDA’s Computer Software Assurance approach focuses effort on intended use and risk, allowing lighter testing for low-risk functionality.
Often heard: Computer Software Assurance abolishes computer system validation.
Actually: CSA is a risk-based evolution of CSV; the goal — assurance the system does what it should — is unchanged, but the effort is targeted by risk.
Going deeper
