CSA turns software validation into a risk decision

For years, validating the software behind production and the quality system meant one method applied uniformly: scripted test cases, a screenshot for every click, an IQ/OQ/PQ package sized the same way whether the tool made a safety-critical decision or just tracked training records. FDA's Computer Software Assurance guidance, finalized on September 24, 2025 after three years in draft, tells manufacturers plainly that the underlying rule never actually asked for that uniformity — and that the risk-based alternative it now spells out arrives just as the regulation that rule lived in was itself being replaced.

The old rule asked for validation, not a specific method

21 CFR 820.70(i) required manufacturers to validate computer software used as part of production or the quality system for its intended use — a duty stated in three lines, with no method mandated. Computer System Validation practice filled that gap with heavily scripted testing, applied roughly the same way regardless of what a given piece of software actually did or how much harm a failure in it could cause. FDA's Computer Software Assurance guidance says that habit was never what the rule itself demanded: assurance activities are supposed to be proportionate to the risk the software actually poses to patient safety, product quality, and data integrity, not sized to a single default template.

Unscripted testing and vendor evidence now count as assurance

The guidance explicitly endorses unscripted, exploratory testing; continuous monitoring in production use; and leaning on a supplier's or developer's own testing evidence, in place of manufacturer-generated scripts, wherever the risk profile supports it. It also pushes manufacturers to reuse the electronic records a system already produces as evidence, instead of manufacturing a parallel paper trail purely for the validation file. None of that lowers the bar for software whose failure could actually affect a safety or quality decision — that software still earns the more rigorous, scripted evidence CSV practice built its reputation on. What changes is that low-risk software no longer has to carry the same weight of proof.

The provision the guidance cites was already being retired

The guidance's own regulatory hook, 820.70(i), sat inside the Quality System Regulation FDA had already begun phasing out. The Quality Management System Regulation, finalized in February 2024, incorporated ISO 13485:2016 by reference into 21 CFR 820 and set February 2, 2026 as the compliance date on which most of the old QSR's own numbered subparts — 820.70 included — stopped being the operative text. CSA's final guidance landed in the window between that rule's publication and its compliance date; by the time a manufacturer reads it today, the citation the guidance built its argument around has already moved.

Clause 4.1.6 said ‘proportionate to risk’ on its own

What 820.70(i)'s software-validation duty moved into is ISO 13485 Clause 4.1.6, which requires a documented procedure for validating software used in the quality management system, applied before initial use and after changes — and states directly that the specific approach and activities involved ‘shall be proportionate to the risk associated with the use of the software.’ The standard manufacturers now validate against had already built in the same principle FDA spent three years turning into its own guidance. Read together, the two documents aren't in tension; they're two regulators converging on the same answer from different directions, and a CSA-shaped assurance record built against Clause 4.1.6 satisfies both at once.

Where this meets the file

Software used to run production is a related but distinct case — it falls under the same Clause 7.5.6 duty to validate any process whose output can't be checked by inspection that governs sterilization and other unverifiable processes, rather than Clause 4.1.6's own QMS-software route. And for a shelf built around browser-only tools, the same proportionality principle applies to the tool's own build record: Part 11 doesn't turn on where a tool runs, and neither does the depth of assurance evidence its validation record needs to carry. A risk-proportionate software assurance worksheet, mapped to Clause 4.1.6 and Clause 7.5.6 separately, is previewed in the launch catalog. If your program draws that risk line differently, the shelf takes that correction directly.