Computer system validation (CSV) is the documented process of demonstrating that a computerized system consistently does what it is intended to do, and does not do what it is not intended to do, within the environment it is actually used in. For a regulated laboratory, that means proving — with evidence, not assertion — that a LIMS, ELN, chromatography data system, environmental monitoring system, or any other GxP-relevant software correctly captures, processes, and reports data before it is relied on for a regulatory decision. CSV is a lifecycle activity, not a one-time test event: it runs from requirements definition through installation, operational testing, and ongoing use, and it is the mechanism by which a lab can actually answer an auditor’s question, “how do you know this system works?”
This guide follows GAMP 5 (2nd edition, ISPE, 2022), the industry-standard risk-based framework for GxP computer system validation, and FDA guidance on software validation and assurance. It covers a broader question than the audit-trail-and-e-signature mechanics of 21 CFR Part 11 — CSV is what proves a system’s controls, including its Part 11 controls, actually function as designed.
What Validation Means for a Computerized System
Validation is not the same thing as software testing, and it is not the same thing as vendor-supplied qualification documentation. A vendor can hand a lab a binder proving its software was tested during development — that speaks to the product as shipped, not to whether it was installed correctly in this lab, configured correctly for this lab’s workflow, and operates correctly with this lab’s data, users, and interfaces. Validation is specific to the system as actually deployed.
Three qualities distinguish a validated state from an untested or merely “working” one:
- It is documented. A validated system has a defined, approved set of requirements it was tested against, and records showing the tests were executed and passed (or that any failure was resolved and re-tested).
- It is reproducible. The same configuration produces the same behavior; any change to the system — a software update, a configuration change, an interface modification — triggers an assessment of whether re-validation is needed, governed by change control.
- It is proportionate to risk. Not every system, and not every function within a system, warrants the same depth of testing. This is the central principle GAMP 5 formalizes, covered next.
The Risk-Based Approach: GAMP 5 and Scaling Effort to Impact
GAMP 5 (Good Automated Manufacturing Practice), published by ISPE, is the standard risk-based framework referenced across pharmaceutical, biotechnology, medical device, and CRO computer system validation programs. Its central argument is that validating every system, and every function within a system, to the same exhaustive depth is both wasteful and counterproductive — it drains testing effort away from the features that actually carry patient-safety, product-quality, or data-integrity risk and toward low-risk, standard functionality a vendor has already thoroughly exercised.
The practical mechanism is a documented risk and impact assessment, done early, that answers two questions for the system as a whole and then for its individual requirements: what is the potential impact on patient safety, product quality, and data integrity if this fails or behaves incorrectly, and how much of the system’s behavior is standard, vendor-supplied logic versus custom-built or heavily configured logic specific to this lab? The answers determine how much documented testing rigor a given function actually needs — a vendor’s standard, unmodified date-stamping routine warrants a lighter verification than a custom-configured calculation that determines a batch release decision.
GAMP Software Categories
GAMP 5 classifies software into categories that describe how much of its logic is standard versus custom, which in turn scales the validation effort:
| Category | Description | Typical validation effort |
|---|---|---|
| Category 1 — Infrastructure software | Operating systems, database engines, network components, middleware — the platform a GxP application runs on, not GxP-specific itself | Qualified as infrastructure (installation and configuration verification); not independently validated as a standalone GxP application |
| Category 3 — Non-configured products | Commercial off-the-shelf software used as supplied, with no configuration of business logic (e.g., a standard instrument control package run with default settings) | Verify the product meets documented requirements as installed; leverage vendor testing/documentation, focus effort on intended use |
| Category 4 — Configured products | Commercial software configured to the lab’s specific workflow — most LIMS, ELN, and MES deployments fall here, since the configuration itself introduces lab-specific risk | Full validation of the configuration: requirements, functional testing of configured workflows, and the configuration’s data-integrity controls |
| Category 5 — Custom applications | Bespoke software, or custom code/scripts/macros/interfaces built for this specific system | Highest rigor: design specification, code-level review where appropriate, and full test coverage of custom logic |
Most laboratory informatics systems — a LIMS, an ELN, a chromatography data system — are Category 4 in practice: the underlying software is commercial, but the workflows, calculations, and interfaces configured on top of it are specific to the lab and carry the actual validation burden.
The IQ/OQ/PQ Qualification Sequence
Once risk and category are established, qualification proceeds through a sequence of stages, each producing distinct documented evidence and each building on the one before it. Some programs add Design Qualification (DQ) ahead of these three, for custom or high-impact systems, to confirm the proposed design meets user requirements before the system is built or configured.
| Stage | What it verifies | Evidence it produces |
|---|---|---|
| IQ — Installation Qualification | The system (hardware and software) was installed correctly, matches the specified version and configuration baseline, and the environment it runs in meets specification | Installation checklist, component/software version inventory, environmental verification records, signed installation report |
| OQ — Operational Qualification | The system operates as intended across its specified operating range — individual functions perform correctly, including at boundary and error conditions | Executed test scripts with expected-versus-actual results, screenshots or exported evidence, calibration/configuration verification, signed OQ report |
| PQ — Performance Qualification | The system performs consistently and correctly under actual conditions of use — real workflows, real users, real data volumes — not just isolated test scripts | Executed PQ protocol tied to representative business processes, user acceptance evidence, signed PQ report and validation summary sign-off |
The distinction between OQ and PQ is where validation programs most often go wrong: OQ proves a function works when tested in isolation; PQ proves the system works the way the lab actually uses it, with its actual data and its actual people. A system can pass every OQ test script and still fail in practice because the PQ step — testing against a real workflow, not a scripted approximation of one — was skipped or rushed.
CSV and 21 CFR Part 11: Related, Not the Same
21 CFR Part 11 is FDA’s regulation governing electronic records and electronic signatures — it defines the controls a system must have to make its electronic records and signatures trustworthy and legally equivalent to paper records and handwritten signatures: audit trails, access controls, record retention, and signature manifestations, among others.
CSV is the methodology by which a lab proves those controls, and every other function the system performs, actually work as designed in its specific deployment. A system can be “Part 11 capable” — the vendor built in an audit trail feature, role-based access, and electronic signature support — and still be unvalidated, because capability is not the same as verified, working, correctly-configured behavior. Validation is what confirms the audit trail actually captures every relevant change with the required who/what/when detail in this lab’s specific configuration, that access controls are actually enforced for this lab’s user roles, and that the electronic signature workflow actually behaves as the regulation requires. Part 11 defines the destination; CSV is how a lab demonstrates it arrived there.
FDA’s Computer Software Assurance (CSA): The Direction of Travel
Traditional CSV programs have historically leaned heavily toward exhaustive, scripted documentation — testing every function to the same depth regardless of actual risk, largely out of an abundance of caution about audit findings. FDA’s guidance on Computer Software Assurance, finalized in September 2025 (targeted specifically at production and quality system software under the Quality System Regulation, 21 CFR Part 820, in the medical device context), formalizes a different philosophy: scale testing rigor and documentation burden to actual risk, using structured critical thinking and, where appropriate, unscripted or exploratory testing for low-risk functionality, while reserving exhaustive scripted testing for functions that carry genuine patient-safety or product-quality risk.
CSA is not a replacement for Part 11 and does not eliminate the need for validation — it changes how much documentation a given level of assurance requires. Although CSA’s formal scope is the device Quality System Regulation, its risk-based, assurance-over-documentation philosophy is widely treated across GxP computer system validation more broadly, including pharmaceutical and biotech laboratory informatics validation, as the direction GAMP 5’s own risk-based approach was already heading — and GAMP 5’s second edition explicitly incorporates critical-thinking-based testing approaches aligned with it. In practice, this means a validation program built strictly around “test and document everything to the same depth” is increasingly out of step with where both FDA guidance and GAMP 5 itself are pointing; a validation program that can show its risk assessment and justify a lighter touch on genuinely low-risk, standard functionality is the current direction, not an exception to it.
Validation Deliverables Checklist
The specific documents a validation package requires vary by GAMP category and risk level, but the following checklist covers the deliverables a regulated lab’s quality or validation function should expect to see, end to end, for a Category 4 (configured product) system such as a LIMS or ELN.
| Phase | Deliverable | What it evidences |
|---|---|---|
| Planning | Validation Plan (or reference to a Master Validation Plan) | Scope, approach, roles, and acceptance criteria for the validation effort are defined before execution starts |
| Planning | Risk / GxP impact assessment and GAMP category assignment | Validation effort is scaled to actual risk, not applied uniformly |
| Planning | User Requirements Specification (URS) | What the system must do, in terms testable against evidence, agreed before testing begins |
| Planning | Functional / Configuration Specification | How the system will meet the URS — the configuration or design that will actually be tested |
| Planning | Traceability matrix (requirements to test cases) | Every requirement is covered by at least one test, and every test traces back to a requirement |
| Execution | IQ protocol and executed IQ report | Correct installation, version, and environment |
| Execution | OQ protocol, test scripts, and executed OQ report | Individual functions work as specified, including at boundary conditions |
| Execution | PQ protocol and executed PQ report | The system performs correctly under real workflows, users, and data |
| Execution | Deviation and incident records with resolution | Failures during testing were investigated, resolved, and re-tested, not silently dropped |
| Closure | Validation Summary Report | A single signed record of what was tested, what passed, what deviations occurred, and the overall conclusion that the system is fit for intended use |
| Ongoing | SOPs for system use, access management, and audit-trail review | The validated state is maintained operationally, not just at go-live |
| Ongoing | Change control records for every post-validation modification | Changes are assessed for re-validation impact before being applied |
| Ongoing | Periodic review / revalidation schedule | The system’s validated state is re-confirmed on a defined cadence, not assumed indefinitely |
| Ongoing | User training records | Users were trained on the validated configuration before relying on it for GxP work |
Frequently Asked Questions
What is equipment qualification (IQ/OQ/PQ) versus computer system validation?
Equipment qualification and computer system validation follow the same IQ/OQ/PQ logic, but equipment qualification applies it to physical instruments (a balance, a centrifuge, an incubator), while CSV applies it to the software controlling or recording data from that equipment, or to standalone informatics systems like a LIMS or ELN. Many laboratory instruments now have an embedded computer system, in which case both the instrument’s equipment qualification and the embedded software’s CSV are relevant, and are typically documented together.
What is a validation protocol?
A validation protocol is the approved, pre-defined document specifying exactly what will be tested, how, under what conditions, and what result counts as a pass, before testing begins. Separate protocols are typically written for IQ, OQ, and PQ, each with its own acceptance criteria; the executed protocol, with recorded results and sign-off, becomes the evidence record for that stage.
Does every laboratory system need full IQ/OQ/PQ?
No — this is the point of GAMP 5’s risk-based approach. Low-risk infrastructure (Category 1) or unmodified off-the-shelf tools (Category 3) with no GxP-relevant configuration typically need lighter qualification that leverages vendor documentation, while configured (Category 4) and custom (Category 5) systems that directly affect data integrity or product quality warrant the full sequence with commensurate depth of testing.
For the broader laboratory compliance landscape this sits within, see the Laboratory Compliance & Quality pillar. For what a LIMS actually does before deciding how it needs to be validated, see What Is a LIMS?
