Computer Software Assurance reframes how teams prioritize testing. This post summarizes the shift from traditional CSV to a risk-based CSA approach.
For years, the default answer to "how much should we test this?" was "the same as everything else." A scripted test case for every requirement, a screenshot for every step, the same rigor for a font-color tweak as for a function that decides whether a batch ships. That default has a name — Computer System Validation, or CSV — and on 24 September 2025 the FDA finalized guidance that formally moves away from it: Computer Software Assurance, or CSA.
CSA has been circulating as an industry idea since well before 2025 — it traces back to FDA's Case for Quality initiative and a 2022 draft guidance that spent three years collecting feedback. What changed in September is that it stopped being an emerging philosophy and became the agency's actual position, replacing Section 6 of the older General Principles of Software Validation guidance. It's worth being precise about scope: the final guidance applies to computers and automated data processing systems used in medical device production or quality systems under 21 CFR 820.70(i), issued jointly by CDRH and CBER. It is not, technically, a GMP or Annex 11 document. In practice, the risk-based thinking it codifies has been adopted far more broadly across GxP validation than its formal scope suggests, because the underlying question — where does rigor actually buy us anything? — doesn't stop being relevant at the edge of one regulation.
What CSA actually changes
CSA does not remove the requirement to validate software for its intended use. That requirement is unchanged. What it changes is the question a team asks before deciding how to demonstrate it.
The starting point is intended use, not the software as a whole. A single system routinely gets split into pieces: parts that directly automate a process or control a quality record, parts that only support testing or monitoring, and parts that sit outside production and quality entirely. Those pieces don't get the same treatment. The next question is a plain one — if this feature fails, what's the worst realistic outcome for the patient or the product? — and the answer determines how much assurance work actually gets done.
For a high-risk feature, that still means scripted, step-by-step testing, recorded in detail. For a lower-risk feature, CSA explicitly makes room for unscripted approaches — exploratory testing, scenario testing, deliberate error-guessing — carried out by someone who understands the system well enough to probe it usefully, without a pre-written script dictating every click. It also makes room for leaning on work that's already been done: a vendor's own test evidence, a SOC 2 report, an ISO certification, rather than a manufacturer redoing from scratch what a supplier has already demonstrated. And it pushes documentation toward evidence a system already produces — logs, audit trails, automated test output — instead of manually assembled screenshots whose only purpose is proving someone looked at a screen.
None of this is a discount. It's a redirection. The hours a rigid CSV process spent documenting a low-risk configuration screen in exhaustive detail are meant to end up spent on the handful of features where a failure would actually matter.
Where this gets misread
A few misreadings come up often enough to be worth naming directly. CSA is not a way to validate less — the obligation to establish confidence that software is fit for intended use is exactly as real as it was under CSV, and regulators still expect it. It is not a rule that every system gets one risk label — the same system routinely mixes high-risk and low-risk features, and the assurance approach is expected to follow the feature, not the system as a whole. It does not mean unscripted testing is the default for everything — high-risk functions still get scripted testing, the same as before. And leaning on a vendor's certifications doesn't transfer accountability to the vendor; the manufacturer is still the one who has to be able to explain the risk reasoning behind every choice.
That last point is really the center of the whole shift. CSA trades a validation culture built on demonstrating volume of documentation for one built on demonstrating quality of reasoning. An inspector reading a CSA-based validation package is expected to be looking for a defensible risk classification and a rationale that matches it, not a stack of test scripts thick enough to prove diligence by weight.
What it means for a validation team on a Monday morning
Concretely, this asks for skills that a checklist-driven CSV process didn't need as much of. Someone has to be able to look at a feature and reason about what actually happens if it fails, not default to "critical" because that's the safer paperwork position. Someone has to be comfortable running unscripted testing well, which is a different skill from executing a script someone else wrote. Vendor management stops being a procurement formality and becomes something quality actually leans on for evidence, which means someone has to actually read the SOC 2 report instead of filing it. And whatever system holds all of this — the risk classifications, the rationale, the mix of scripted and unscripted evidence — has to make that reasoning visible and defensible on demand, because the reasoning is now the artifact that matters, not the paperwork volume around it.
That last requirement is where CSA connects back to a broader shift already underway in how validation gets treated: not as a project that produces a static binder, but as a living record of risk decisions and evidence that has to stay coherent as the system, and the team's understanding of its risk, keeps evolving. CSA gives teams permission to stop treating every feature the same. It does not give them permission to stop being able to explain why.
.png)
