CSVComputer System Validation

Computer System Validation (CSV) is the documented process of proving a computerised system used in GxP-regulated operations does what it is supposed to do, consistently, predictably and under change control — and continues to do so over its operational life. The system might be a LIMS, an MES, an eBMR, an ERP module touching GMP-relevant data, a building-management system controlling pharma cleanrooms, a Veeva Vault tenant, a chromatography data system, or a custom-built Excel macro reaching into batch records.

CSV is not testing. Testing is one input to CSV. CSV is a lifecycle programme — user requirements, risk assessment, vendor evaluation, design qualification, installation qualification, operational qualification, performance qualification, training, release, periodic review, change control, decommissioning — that together produce a validated system and a defensible documentation file.

There is no rule called 'CSV must be done'. The obligation is constructed from several pieces:

• 21 CFR Part 11 — electronic records and signatures must be trustworthy, reliable and generally equivalent to paper. Trustworthy and reliable depends on the system working as intended, which is what CSV proves.
• 21 CFR 211.68 — automatic, mechanical and electronic equipment must be 'suitable for its intended purpose' and 'routinely calibrated, inspected, or checked'. The same logic extends to software.
• 21 CFR 211.100 — written production procedures must be followed; if the procedure is enforced by software, the software must work.
• 21 CFR 820.70(i) — when computers or automated data-processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol.
• 21 CFR 820.30(g) — design validation includes software validation and risk analysis where appropriate.
• EU GMP Annex 11 §4 — validation documentation and reports should cover the relevant steps of the life cycle.
• EU GMP Annex 15 — Qualification and Validation, the formal framework.
• ICH Q9 — quality risk management, which scales validation depth.

FDA's 2002 'General Principles of Software Validation' guidance is the longest-standing US authority. The 2022 draft 'Computer Software Assurance for Production and Quality System Software' (CSA) is the agency's modern reframing — same outcomes, less paperwork. GAMP 5 (2nd Edition, 2022) is the de-facto industry framework that operationalises all of this.

GAMP 5 categorises software by complexity and risk, and the validation depth scales accordingly. The 2nd Edition retains four operational categories (Category 2 was retired in the 2008 first edition):

The category is decided at the start, documented in the validation plan, and drives every subsequent decision — the URS depth, the supplier audit, the test-script coverage, the periodic-review frequency. Misclassifying a Category 4 SaaS as a Category 3 'standard product' to skip validation effort is the most common GAMP 5 audit finding.

GAMP 5 organises CSV as a V-model: requirements on the left descending into design, configuration and code; testing on the right ascending from unit through integration to user acceptance. Each left-side artefact has a matching right-side test that verifies it.

The traceability matrix is the spine of the V — every URS item must trace to at least one PQ test case; every FS item to at least one OQ test case. Gaps in the matrix are gaps in validation coverage. A defensible validation report includes the matrix and an explicit statement that every URS / FS / DS item is covered.

1. Validation Master Plan (VMP) — site-level plan defining the validation programme, governance, roles, deliverable templates, change-control interaction.
2. User Requirements Specification (URS) — what the business needs the system to do, signed by SME and Quality.
3. Risk Assessment — what could go wrong, how bad would it be, how likely is it, what controls reduce risk to acceptable. Drives test depth.
4. Supplier / Vendor Assessment — audit of the vendor's quality system (Category 4 / 5). Many companies accept a vendor's ISO 9001 + ISO/IEC 27001 + SOC 2 + their own validation pack as evidence and skip a physical audit.
5. Configuration / Functional / Design Specification — what the system will do and how, signed by vendor and customer.
6. Validation Plan — project-level plan: what tests, in what environment, by whom, against what criteria.
7. IQ — install verified against design.
8. OQ — operates within parameters.
9. PQ — performs in production with real users on real SOPs.
10. Traceability Matrix — URS ↔ FS ↔ DS ↔ test cases.
11. Validation Summary Report — signed by Quality, releases the system to production use.
12. Release for production use.
13. Periodic Review (Annex 11 §11) — at risk-based intervals; confirms the system is still validated.
14. Change Control — every change goes through impact assessment that decides on re-IQ / re-OQ / re-PQ.
15. Decommissioning — data migration, retention, system retirement under change control.

FDA's September 2022 draft guidance 'Computer Software Assurance for Production and Quality System Software' (CSA) reframes CSV around risk-based assurance evidence rather than document-heavy compliance ritual. It targets devices (21 CFR 820.70(i)) but the thinking applies broadly. The headline shifts:

• Critical thinking first. Determine the patient-safety / product-quality risk before deciding test depth. High risk → scripted, formal testing. Low risk → unscripted exploratory testing or even vendor-evidence reliance.
• Risk-based testing. Not every function needs an OQ script. The OQ for a SaaS document-management system's 'sort column by date' button is paperwork that adds no patient safety.
• Unscripted testing is acceptable for low-risk functions — exploratory testing, ad-hoc testing, error-guessing — with the test record being a screen capture, a Jira ticket and a tester signature, not a formally executed protocol.
• Leverage vendor evidence. A SaaS vendor's existing test evidence (SOC 2 control reports, ISO 9001 audit reports, vendor's own validation pack) can be referenced rather than re-executed.
• Document only what matters. Reduce the validation file to what is needed to prove the assurance argument, not what was historically expected.

CSA does not change Part 11, Annex 11 or 820. It changes the FDA's expectation of how CSV evidence is produced and presented. Conservative customers continue to run full traditional CSV; aggressive customers (large medical-device companies in particular) have moved hundreds of low-risk systems to CSA-style assurance and reduced their validation effort by 50–70%.

Most modern GxP software is SaaS, and the CSV community has spent the last decade adapting. The principles are unchanged; the execution is different.

• IQ shifts from 'install the binaries on these servers' to 'verify the SaaS tenant is provisioned correctly, the configuration baseline matches the spec, the data is loaded'. Vendor IQ evidence covers the platform; customer IQ covers the tenant.
• OQ shifts from 'test every function' to 'test the configured workflows in the tenant'. Vendor evidence covers vendor-tested platform functions; customer evidence covers configuration-specific workflows.
• PQ is unchanged — real users on real SOPs in the production tenant. SaaS does not relieve the customer of PQ obligation.
• Supplier qualification is heavier. The customer cannot inspect the SaaS vendor's data centre but can — and must — review the vendor's quality manual, validation policy, SOC 2 / ISO 27001 reports, sub-processor list, incident-response history, change-management policy and disaster-recovery testing.
• Continuous delivery (vendor pushes new versions every few weeks) requires a continuous change-control posture. Customers subscribe to vendor release notes, assess each release under change control, decide whether re-OQ is needed, and document the decision.
• Periodic review is more frequent — quarterly is common for high-impact SaaS, compared with annually for traditional on-prem.

1. Validation Master Plan (site-level, referencing this system).
2. Validation Plan (system-specific).
3. URS — what the business needs.
4. Risk Assessment — FMEA or similar, scoring severity / probability / detectability.
5. Supplier / Vendor Assessment — audit report or accepted-vendor justification.
6. Functional / Configuration Specification — what the system will do, signed.
7. Design Specification — for Category 5 custom code.
8. Traceability Matrix — URS ↔ FS ↔ DS ↔ test cases.
9. IQ protocol and execution report.
10. OQ protocol and execution report.
11. PQ protocol and execution report.
12. Test Summary Report — overall pass/fail, deviations, CAPAs.
13. Validation Summary Report — signed by Quality, releases the system.
14. Training records for all users at release.
15. SOPs for system use, administration, change control, periodic review, backup, disaster recovery.
16. Periodic Review reports (ongoing).
17. Change Control records (ongoing).

1. URS missing or post-dated to fit the system that was already bought.
2. GAMP category misclassified to reduce test depth.
3. Traceability matrix has unexplained URS items with no test coverage.
4. OQ done by vendor with customer signing without review.
5. PQ used as 'big OQ' — unit-level tests rather than business-process tests.
6. Change after validation not impact-assessed; system effectively unvalidated.
7. Periodic review skipped or rolled into perpetual 'next quarter'.
8. Audit-trail review during validation not done by Quality independently of validation engineers.
9. SaaS vendor's release notes not reviewed under change control; new features released into production unvalidated.
10. Disaster-recovery test not executed; system fails over in a real incident and the recovery cannot be validated post-hoc.

• Configuration baselines exportable as machine-readable snapshots — workflow definitions, role-permission matrix, kiosk module set per industry profile, document templates, calculation formulas.
• Audit trail on every regulated table with reason-for-change at write time. Annex 11 §9 satisfied at the data layer.
• Two-person e-signature enforced where 211.186 / 111.205 / 820.40 / Annex 11 require, with role-independence and snapshot binding.
• Shipped validation pack: URS, FRS, IQ, OQ, PQ scripts aligned to GAMP 5 Category 4 expectations, plus an additional Category 5 supplement for tenants who write custom server functions.
• Release notes written for change-control consumption — every release lists user-visible changes, regulated-process changes, configuration-baseline impacts and recommended OQ re-execution scope.
• Periodic-review support: per-tenant configuration-diff report showing what changed since last review, who approved, with reason.
• SaaS deployment with SOC 2 Type 2 controls, ISO 27001 alignment, qualified backup and disaster-recovery testing.
• On-premises deployment option (V5 Ultimate On-Premises) for customers who require air-gap operation; same validation pack applies with on-prem IQ extensions.