Risk-based software assurance, from intended use to record
Less evidence where the risk is low. The record still has to hold up.
FDA's guidance on computer software assurance, usually just called CSA, has been talked about since the draft came out in 2022. It's now final, and it has already been reissued once. It also gets misquoted a lot. You'll hear that it ends validation paperwork, or that it applies to drug manufacturers. Neither is true. This article covers what the guidance says, where it applies, and how its approach compares with what EU inspectors are likely to expect.
Final in 2025, reissued in 2026
The draft, titled Computer Software Assurance for Production and Quality System Software, appeared in September 2022. FDA finalised it on 24 September 2025. Then, on 3 February 2026, it reissued the guidance under a slightly different title, Computer Software Assurance for Production and Quality Management System Software, which supersedes the September version. The reissue came a day after the Quality Management System Regulation took effect on 2 February 2026. The QMSR incorporates ISO 13485:2016 by reference, and the new version of the guidance swaps its references to the old 21 CFR 820.70(i) for the matching ISO 13485 clauses.
Who it applies to
The guidance covers software used in production or in the quality management system for medical devices. CDRH and CBER issued it, in consultation with CDER, and like any guidance it isn't binding. It doesn't cover software that is itself a medical device. It also doesn't formally apply to drug manufacturers, whose rules for computerised systems are in 21 CFR 211.68 and Part 11. Pharma teams draw on it anyway, mostly through ISPE's GAMP 5 Second Edition, which discusses CSA and puts the same weight on critical thinking. That's a choice those teams make. Nothing requires it.
Four steps
CSA asks you to work out the intended use of each software feature, function or operation, decide on a risk-based approach, pick assurance activities to match, and keep a record. The central idea is high process risk. A feature is high process risk if its failure could lead to a quality problem that foreseeably compromises safety, and anything else is not high process risk. FDA keeps it to two categories for simplicity and accepts finer grading if you want it. The guidance calls itself least burdensome, and it wants validation effort to be no more than the risk requires.
Scripted and unscripted testing
The guidance names two kinds of testing. Unscripted testing covers scenario-based, ad hoc and experience-based methods, such as exploratory testing and error guessing. Scripted testing can be robust or limited. High process risk may call for scripted or hybrid testing, and features that aren't high risk may be tested with unscripted methods, though FDA says neither pairing is exclusive. The idea is to put your testing effort where a failure would matter, instead of writing the same depth of script for every screen.
You still need a record
CSA cuts out evidence you don't need, but the record stays. FDA expects it to state the intended use, the result of the risk analysis, what testing was done, any issues found, whether the result is acceptable, who tested and when, and, where appropriate, who reviewed or approved it. It shouldn't hold more evidence than necessary, and FDA prefers digital records such as system logs and audit trails to paper and screenshots. Electronic records kept to meet the regulation are still subject to Part 11.
Vendors, SaaS and the older guidance
You can use a vendor's own development and validation work as your starting point, through purchasing controls, with evidence such as SOC reports, ISO certifications and security documentation. FDA accepts that an onsite audit may not be feasible, and cloud services used in production or the quality system are in scope. CSA doesn't replace the 2002 General Principles of Software Validation. It supplements it, and supersedes only Section 6, the part on automated process equipment and quality system software.
Reading it next to Annex 11
If you supply both the US and the EU, the two approaches don't line up neatly. The draft revision of EU GMP Annex 11, which isn't final yet, expects approved test scripts, executed scripts with screen captures where relevant, and every test case traceable to a requirement. CSA allows exploratory testing without step-by-step scripts and prefers system records to screenshots. Neither is wrong; they're written for different regulators. Our advice is to check any validation approach built on CSA-style evidence against the Annex 11 text before you rely on it for systems that serve the EU.
Where Comeply comes in
Comeply's requirement database keeps requirements from frameworks like 21 CFR Part 11 and EU GMP Annex 11 side by side, and marks how binding each one is. A validation lead can see where they ask for the same thing and where they differ. Reports then check those requirements against your own validation SOPs, with verified quotes, so whether a procedure meets both gets answered from the procedure itself.
Validation
See Part 11, Annex 11 and your validation SOPs side by side.
We can show you how Comeply compares requirements across frameworks and reads them against your own procedures.
Book a walkthrough