From CSV to CSA: what FDA's final guidance actually changes for validation teams
For years, the working assumption in computer system validation was simple, if exhausting: script every test case, document every step, treat every feature as equally deserving of rigor. It was thorough. It was also, for most of what actually gets tested, wildly disproportionate to the risk involved.
FDA's Computer Software Assurance (CSA) guidance has been trying to change that for a while. The draft landed in September 2022. It became final guidance in September 2025. Then, in February 2026, FDA updated it again — not to walk anything back, but to align it with the new Quality Management System Regulation that took effect that same month, which harmonizes 21 CFR 820 with ISO 13485. Three years from draft to a settled, QMSR-aligned final version.
The actual shift
CSA replaces "test everything the same way" with "test based on process risk." Features with high process risk — the ones that could actually affect product quality or patient safety if they failed silently — still get rigorous, often scripted testing. Features with lower risk can be covered with leaner methods: exploratory testing, scenario-based checks, leaning on vendor-supplied evidence instead of re-proving what the vendor already validated.
It's worth being precise about scope here: this specific guidance formally applies to software used in medical device production and quality management systems — it comes from CDRH and CBER, tied to 21 CFR 820 and the QMSR. It is not, strictly, a pharmaceutical GxP guidance. But the industry reaction has been consistent: treat the risk-based principle as best practice for validation generally, regardless of which specific regulation technically governs a given system. The logic holds up whether you're validating a device production line or a clinical data system.
Why this makes traceability more important, not less
Here's the part that doesn't get said enough: risk-based validation only works if the risk assessment behind it is trustworthy. Under the old model, exhaustive testing was its own justification — you tested everything, so the coverage question never really came up. Under CSA, every decision to apply lighter-touch assurance rests on a specific, stated risk judgment. If that judgment lives in a spreadsheet that drifted out of sync with the actual system six weeks ago, the entire assurance strategy is standing on a claim nobody can currently verify.
That's not a smaller documentation problem than CSV had. It's arguably a sharper one — the traceability chain from requirement, to risk assessment, to the testing approach that assessment justified, has to stay genuinely connected, not reconstructed from memory during an audit.
It's exactly the reason Tracidor keeps requirements, specs, risk fields and test evidence in one live chain instead of a document that's accurate the day it's written and stale every day after. Run it in Standard mode for conventional delivery, or switch to GxP mode for full IQ/OQ/PQ rigor — but either way, when someone asks why a given feature got lighter testing, the answer is a traceable record, not a reconstruction.