Computer Software Assurance reframes how teams prioritize testing. This post summarizes the shift from traditional CSV to a risk-based CSA approach.
Regulatory status as of 13 October 2026: FDA's current CSA guidance is "Computer Software Assurance for Production and Quality Management System Software" (final, issued 3 February 2026), which superseded the September 2025 version. It applies to medical device manufacturers under the Quality Management System Regulation (21 CFR Part 820, in effect since 2 February 2026), which incorporates ISO 13485:2016 by reference.
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. The FDA's answer is Computer Software Assurance, or CSA. The guidance was first finalized on 24 September 2025 and reissued on 3 February 2026 as "Computer Software Assurance for Production and Quality Management System Software", which supersedes the 2025 version. CSA does not remove the validation requirement. It describes a risk-based way to meet it.
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 2025, and was confirmed by the February 2026 reissue, is that it stopped being an emerging philosophy and became the agency's actual position. The guidance supplements FDA's General Principles of Software Validation and supersedes only its Section 6 (Validation of Automated Process Equipment and Quality System Software). It's worth being precise about scope. The current guidance applies to computers and automated data processing systems used as part of medical device production or the quality management system, and it was prepared by CDRH and CBER. Its legal anchor is the Quality Management System Regulation (21 CFR Part 820, in effect since 2 February 2026), which incorporates ISO 13485:2016 by reference and removed the former 21 CFR 820.70(i). The software validation requirements it supports are now ISO 13485 subclauses 4.1.6, 7.5.6 and 7.6. Formally, it is a medical device guidance under 21 CFR Part 820, which FDA defines as the device CGMP requirements (21 CFR 820.1(a)). Its scope is medical device production and quality management systems: it is not a drug GMP guidance and not an EU document like Annex 11. In practice, ISPE's GAMP 5 Second Edition (July 2022) applies the same risk-based thinking across GxP computerised systems and discusses FDA's CSA work, and the FDA guidance itself lists it as a reference for testing methods. The underlying question, where does rigor actually buy us anything, doesn't stop being relevant at the edge of one regulation.
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 feature with high process risk (one whose failure may result in a quality problem that foreseeably compromises safety), the guidance suggests more rigor, such as scripted testing or a hybrid of scripted and unscripted testing, scaled to the risk. 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.
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. For high process risk functions the guidance points to more rigor, such as scripted or hybrid testing, although it also accepts that unscripted testing can sometimes be the better fit even there. 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.
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.
Sources:
1. FDA, CSA guidance (February 2026): https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software
2. 21 CFR Part 820 (eCFR): https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
3. QMSR final rule (Federal Register, 2 February 2024): https://www.federalregister.gov/d/2024-01709
4. FDA, General Principles of Software Validation: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation
5. ISPE, GAMP 5 Second Edition: https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition