What Is Computer System Validation? A Plain-English Guide

Computer System Validation, almost always shortened to CSV, is the documented process of proving that a computerised system does what it is meant to do — consistently, reliably, and throughout its working life. If you have landed here from outside the pharmaceutical world, note that CSV here has nothing to do with comma-separated spreadsheet files; it is a quality discipline used in regulated industries.

This guide explains what CSV is, why it exists, and how it works, without assuming you already know the jargon.

The one-sentence definition

CSV is how a regulated company demonstrates, with evidence, that a computer system is fit for its intended use and stays in a controlled state.

Two words in that sentence carry most of the weight. Evidence means documentation an inspector can review, not just a working system. Intended use means the specific job the system does in your process — defined up front, because it decides what has to be validated.

Why it exists

In pharmaceuticals, biotechnology and medical devices, computer systems create, process and store the data that decisions about product quality and patient safety depend on. A laboratory system calculates whether a batch of medicine passes its tests. A manufacturing system controls how that medicine is made. If those systems behave unpredictably, or if their data cannot be trusted, patients can be harmed.

Regulators therefore require companies to show that such systems are trustworthy. CSV is how a company produces and keeps that proof. When an inspector visits, the validation records are the evidence that the systems can be relied on.

Where CSV applies

A system needs validation when it supports a GxP activity — the family of Good Practice regulations such as Good Manufacturing Practice (GMP), Good Laboratory Practice (GLP) and Good Clinical Practice (GCP). Typical validated systems include:

• Laboratory systems such as chromatography data systems (CDS) and LIMS
• Manufacturing and automation systems such as MES, SCADA and PLCs
• Enterprise systems such as ERP and quality management systems
• Document and record systems that hold GxP data

The same software can need very different validation at two companies, because their intended uses differ. That is why CSV always starts from intended use, not from the software itself.

How the validation lifecycle works

CSV is not a one-off test; it is a lifecycle that runs for as long as the system is in use. In outline:

1. Plan — a validation plan sets the scope, approach and responsibilities.
2. Specify — user requirements, then functional and design or configuration specifications.
3. Assess risk — identify what could go wrong and how badly, so effort goes where it matters.
4. Test — installation, operational and performance qualification (IQ, OQ, PQ).
5. Report and release — a summary report concludes the system is fit for use.
6. Operate and maintain — changes are controlled; the system is kept validated.
7. Retire — eventually the system is decommissioned, with its data preserved.

A useful mental model is the V-model: each specification on the way down has a matching test on the way up. User requirements are confirmed by PQ, functional specifications by OQ, and design or configuration by IQ.

The rules behind it

A few references come up constantly, and you do not need to memorise them to understand CSV:

• GAMP 5 (from ISPE) — the widely used, risk-based framework for how to validate computerised systems. Now in its second edition.
• EU GMP Annex 11 — the European expectation for computerised systems, taking a broad lifecycle view.
• 21 CFR Part 11 — the US FDA regulation on electronic records and electronic signatures.
• ALCOA+ — the principles that keep data trustworthy: Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring and Available.
• CSA (Computer Software Assurance) — a more recent, risk-focused evolution of CSV thinking from the FDA.

Two common misconceptions

“Validation means testing everything.” It does not. Modern CSV is risk-based: you concentrate effort where a failure would most affect quality, data integrity or patient safety, and apply lighter controls where risk is low. Testing everything equally is a sign of effort misdirected, not rigour.

“A validated system cannot be changed.” It can — change is normal. What matters is that changes go through change control, with their impact assessed, so the system stays in a validated state.

Where to go next

If you are considering this as a career, read how to become a CSV engineer. If you are preparing for a role, the CSV interview questions and answers guide covers what you will be asked and how to answer it well.