For two decades, validating software used in production and quality systems meant generating documentation — often a great deal of it, and often with little relationship to actual risk. FDA’s computer software assurance guidance, issued in final form on 24 September 2025, formalises a different approach: think first about what could go wrong, then decide how much assurance activity is warranted.
What CSA actually is
Computer software assurance is a risk-based method for establishing and maintaining confidence that software is fit for its intended use. The guidance applies to computers and automated data processing systems used as part of medical device production or the quality system — not to device software functions such as software as a medical device or software embedded in a device, which are governed elsewhere.
The guidance was first issued in draft in September 2022 and finalised three years later. Its central move is to shift effort away from producing evidence for its own sake and towards testing that actually reduces risk.
The four questions CSA asks
In practice the method resolves into a short sequence applied to each software feature, function or operation:
- What is the intended use? Assurance is scoped feature by feature, not system by system — a single platform may contain both high-risk and trivial functions.
- What is the risk? The question is whether a failure could compromise device quality or patient safety, with process risk considered separately from direct safety impact.
- What assurance activity fits that risk? Options range from unscripted and exploratory testing through to fully scripted testing, chosen deliberately rather than by default.
- What record is needed? Enough to establish what was tested, by whom, when, and with what result — and no more.
Where the effort moves
CSA does not reduce the obligation to have confidence in the software. It reallocates where that confidence comes from. Unscripted testing — ad hoc, error-guessing and exploratory approaches performed by people who understand the process — is explicitly recognised as legitimate evidence for lower-risk functions. That frees capacity for the features where failure would genuinely matter.
It also places more weight on what the supplier has already done. Where a vendor has tested a function competently and that testing is visible to you, repeating it adds cost without adding assurance. The corollary is that supplier assessment becomes a more substantive exercise, not a form-filling one.
How CSA sits alongside European expectations
CSA is a US guidance document, but the thinking behind it is not confined to the United States. The ISPE GAMP 5 Guide, second edition, made critical thinking by subject matter experts an explicit principle in 2022, and the draft revision of EU GMP Annex 11 published for consultation on 7 July 2025 is similarly risk-oriented, while raising expectations on audit trail review, access management and cybersecurity.
Companies operating on both sides of the Atlantic should not maintain two philosophies. The realistic target is a single, risk-based validation approach whose documentation can satisfy an FDA investigator, a notified body and an EU GMP inspector without being rebuilt each time. What differs between jurisdictions is emphasis and terminology, not the underlying logic.
The common failure mode
Teams sometimes read CSA as permission to do less, and quietly stop testing. That is a misreading with predictable consequences. CSA requires a documented rationale for the level of assurance chosen — the justification is the deliverable. A thin test record with no reasoning behind it is weaker under CSA than the over-documented package it replaced.
How PQRA helps
PQRA helps manufacturers and healthcare innovators design validation approaches that are risk-proportionate and inspection-ready: intended-use and risk determinations, assurance strategies, supplier assessments, test design, and the transition from legacy CSV documentation to a CSA-aligned model that still meets EU GMP expectations.
To review how your current validation approach would hold up on both sides of the Atlantic, contact PQRA.
No responses yet