CSV vs CSA: for twenty years, Computer System Validation has been synonymous with endless protocols, screenshots and signatures on every page. With FDA's final guidance Computer Software Assurance for Production and Quality Management System Software, published on 24 September 2025 and updated on 3 February 2026, Computer Software Assurance (CSA) becomes the official reference: less defensive documentation, more critical thinking and testing proportionate to risk. In this article we look at what really changes compared with traditional CSV, how to apply the new approach and what it means for GxP professionals.
CSV vs CSA: why FDA changed its approach
"Classic" CSV stems from FDA's 2002 guidance General Principles of Software Validation (GPSV) — a document written for an era when software was largely custom-built and installed on-premise. Over time, however, GPSV implementation degenerated into excess bureaucracy: test scripts signed line by line, hundreds of screenshots, duplicated paper evidence. The result, observed by FDA itself, is paradoxical: companies invest more energy in producing documentation than in assuring the actual quality of the software.
CSA flips the perspective. The goal is not to prove you tested everything in the same way, but to focus assurance effort where the risk to product quality and patient safety is highest, applying the least burdensome approach. The final guidance formally supersedes Section 6 of the 2002 GPSV (the section covering production and quality system software), while the rest of the GPSV remains in force.
From the 2022 draft to the final guidance: the milestones
CSA's journey has been long, and it is worth retracing because many companies are still stuck at the draft:
- September 2022: FDA publishes the draft guidance Computer Software Assurance for Production and Quality System Software.
- 24 September 2025: CDRH and CBER publish the final guidance, incorporating the comments received on the draft.
- 3 February 2026: FDA issues an updated version titled Computer Software Assurance for Production and Quality Management System Software, aligned with QMSR terminology (21 CFR Part 820 harmonized with ISO 13485, applicable from 2 February 2026).
Compared with the draft, the final version adds a terminology section on IaaS, PaaS and SaaS, clarifies that the framework can also apply to artificial intelligence tools used in production or in the quality system, expands the guidance on how far you can rely on vendor documentation, and stresses the preference for digital evidence over paper.
How CSA works: intended use, risk, assurance
The CSA method follows four logical steps, to be repeated for each software (or individual feature) in scope:
- Identify the intended use: is the software (or feature) used directly in production or in the quality system, or does it merely support them?
- Process risk analysis: could a software failure create a quality problem that foreseeably compromises safety? If yes, process risk is "high"; otherwise "not high". FDA uses this binary classification but allows more granular scales (moderate, low).
- Select assurance activities commensurate with risk: rigorous scripted testing for high-risk functions, unscripted methods for the rest.
- Record the evidence: intended use, risk determination, what was tested, by whom and with what outcome.
Regulatory paradigm shifts like this one are easier to digest one piece a week: subscribe to The Pragmatic GMP, GuideGxP's free weekly newsletter, for practical, audit-ready analysis of CSA, Annex 11 and data integrity.
CSV vs CSA: the point-by-point comparison
| Aspect | Traditional CSV (GPSV 2002) | CSA (final guidance 2025) |
|---|---|---|
| Starting point | Documenting validation of the whole system | Intended use and risk to patient/quality |
| Testing | Mostly scripted, uniform | Scripted only where risk is high; unscripted elsewhere |
| Evidence | Screenshots, printouts, manual signatures | Digital records: system logs, audit trails, results in the tool |
| Vendors | On-site audits and internal revalidation | Risk-based leverage of vendor documentation (ISO, SOC, SBOM) |
| Cloud and AI | Not addressed | IaaS/PaaS/SaaS and AI tools explicitly in scope |
| Documentation effort | High, regardless of risk | Proportionate to risk (least burdensome) |
Scripted and unscripted testing: how to choose
The most tangible change for validation practitioners is the legitimization of unscripted testing. For "not high" risk functions, the guidance explicitly points to methods such as ad-hoc testing, error-guessing and exploratory testing: the tester exercises the system with realistic scenarios and records concisely what was done and what was observed, without pre-approved step-by-step scripts. For "high" risk functions, more rigorous and traceable testing — typically scripted — remains recommended. No method is mandated by law, however: the choice must be justified with critical thinking and documented in the risk analysis.
Evidence and documentation: what FDA expects
CSA does not mean "no documents". It means the right documents. The minimum file an inspector expects to find includes: the software inventory mapped to intended uses, the process risk classification for each item, a description of the assurance activities performed, who performed them and the results. The guidance explicitly discourages screenshots and paper duplication when the system already generates logs and audit trails usable as evidence. One frequently misunderstood point: if records are electronic, 21 CFR Part 11 still applies, and FDA does not exercise enforcement discretion over the validation of production and quality system software.
What about pharma? GAMP 5 and Annex 11
Formally, CSA is a medical device guidance (production and quality management system software under 21 CFR Part 820). But its principles are already common practice in pharma: GAMP 5 Second Edition (ISPE, 2022) embeds critical thinking, agile testing and vendor leverage in full consistency with CSA, and the ongoing revision of EU GMP Annex 11 pushes in the same risk-based direction. GxP organizations can therefore adopt the CSA mindset in their validation methodology, keeping Annex 11 and Part 11 as the binding references for electronic records.
GuideGxP Recommendation
Do not rewrite all your SOPs overnight. The move from CSV to CSA is made gradually and with solid evidence: first update your computerized system risk assessment procedure to introduce classification by intended use and process risk; define in your SOP when unscripted testing is allowed and how to document it; revise supplier qualification to leverage vendor certifications and test packages defensibly; and make sure audit trails and logs are actually retrievable, because under CSA they are your primary evidence. In an audit, the question will not be "how many scripts did you execute?" but "how did you decide where to focus your testing?".
To set up defensible data integrity governance, audit trail review and QC lab controls, take a look at our Data Integrity in GMP – Operational Guide to governance, audit trail review and QC laboratories: the ideal companion for bringing CSA into your PQS.
