FDA's Computer Software Assurance: Why High Process Risk Decides Your Testing

On September 24, 2025, FDA finalized Computer Software Assurance for Production and Quality Management System Software — the agency's long-anticipated replacement for the exhaustive, scripted testing that computer system validation has demanded for decades. FDA revised the guidance again in February 2026 to align its terminology with the QMSR, which had just taken effect. The headline is not that validation got easier. It is that FDA now expects a documented risk call before you decide how hard to test — and “high process risk” is the call that decides everything downstream.

What actually changed

CSA is not a new regulation. It is FDA's current articulation of what 21 CFR Part 820 — now the QMSR — has always required: that software used in production or the quality system be validated for its intended use. What changed is the method FDA now endorses for getting there. The prior approach, built around computer system validation's exhaustive, scripted test case for every function regardless of risk, consumed validation budgets on low-risk features — a spell-checker in a document-control system scripted as thoroughly as a batch-record calculation — while sometimes under-testing the features that actually mattered. CSA asks for a documented risk call first, then lets the testing method follow that call.

The call that decides everything downstream

The guidance's operating mechanic is narrow by design: manufacturers map their software inventory to intended use, then determine, feature by feature, whether a failure would foreseeably compromise product safety or quality. Get that call right and the rest of the assurance activity follows logically. Get it wrong — by defaulting everything to high risk out of caution, or by waving low-risk features through without analysis — and the program either drowns in unnecessary scripted testing or leaves real risk unexamined.

• High process risk. A failure would foreseeably compromise product safety or quality. These features warrant the most rigorous assurance — typically scripted, documented testing.
• Not high process risk. A failure would not foreseeably compromise safety or quality. These warrant proportionally less rigorous assurance — unscripted or ad hoc testing is an acceptable method, not a shortcut.
• Vendor assessments and existing records count. FDA explicitly invites manufacturers to leverage vendor certifications such as ISO 13485 assessments, system logs, and audit trails instead of generating fresh paperwork for its own sake.
• Cloud and AI tools are in scope. IaaS, PaaS, and SaaS systems, along with AI-enabled tools, fall under CSA whenever they are used directly as part of production or the quality system.

Least burdensome does not mean least documented. It means the documentation matches the risk you actually identified — not the risk you assumed by default. Reading CSA's risk-based intent

Where the Part 11 question fits

FDA has paired CSA with continued enforcement discretion for certain 21 CFR Part 11 requirements — but that discretion has limits. It does not extend to validating software used in production or the quality system; that validation obligation stands regardless of the Part 11 posture a manufacturer otherwise takes. Teams that read “enforcement discretion” as “skip validation” are reading past the guidance's actual carve-out.

None of this is a license to under-validate. It is a license to stop over-testing what was never actually high risk, and to redirect that effort to the features where a failure really would reach the patient. Companies that treat the high-process-risk call as a one-time checkbox will find it unravels the first time an investigator asks for the reasoning behind a “not high process risk” determination. Companies that build a defensible, documented process around that call — and connect it to the quality system it supports — are the ones CSA was actually written for. If your validation program still scripts every feature the same way regardless of risk, our computer system validation work exists for exactly this gap. For a related look at how the QMSR reshaped the regulation CSA validation supports, see why an ISO 13485 certificate isn't QMSR compliance; for how a comparable software determination plays out on the device side, see FDA's 2026 clinical decision support guidance.