How to Apply Computer Software Assurance
Right-size software validation effort with critical thinking, per FDA CSA.
What a how-to is not
A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.
Computer Software Assurance (CSA) is the FDA’s least-burdensome, risk-based approach for assuring software used in medical-device production and quality systems. It leads with intended use and risk, then chooses the least-burdensome assurance activity — favouring critical thinking and unscripted testing over exhaustive scripted testing where risk is low.
- 1
Define the intended use
Define what the software is actually used for in the process, and be specific — not the product, the use. The same platform can be a production-critical control in one deployment and a convenience in another, and the assurance effort follows the use rather than the vendor. Write the intended use so that someone unfamiliar with the system could judge what would happen if it were wrong.
- 2
Determine the risk
Determine whether the use directly affects product quality or patient safety, and how severe the consequence would be if the software failed undetected. Detection matters as much as severity: a failure that the process would catch immediately carries different risk from one that would propagate silently into released product, and the second is what justifies effort.
- 3
Choose the least-burdensome assurance activity
Choose assurance activities proportionate to that risk, and prefer the ones that produce insight over the ones that produce paper — unscripted or exploratory testing where the aim is to find problems, scripted testing where a specific behaviour must be demonstrated. The point of the approach is to move effort from documenting tests to performing them, and that only happens if the choice is made deliberately.
- 4
Record the right evidence
Record the evidence the activity actually produced: what was tested, who tested it, what happened, and what issues were found and resolved. Evidence proportionate to risk is the principle, and a high-risk function with a light record is the gap an inspector will find. Keep enough to establish the system was fit for its intended use — not a transcript of every keystroke.
- 5
Maintain assurance across changes
Maintain assurance across changes, patches and upgrades by assessing each against the intended use and the risk, rather than revalidating on a schedule or not at all. The state being maintained is fitness for use, and a vendor patch that alters a function the process depends on needs the same thinking as the original assessment, at smaller scale.
- !Scripted-testing everything regardless of risk — the exact over-documentation CSA is meant to end.
- !Re-testing vendor-tested functionality instead of leveraging it.
- !Producing evidence that adds no assurance while under-testing the genuinely high-risk features.
- !Treating CSA as an excuse to skip assurance rather than to focus it.
How to Apply Computer Software Assurance: frequently asked questions
Common questions on apply computer software assurance.
What is Computer Software Assurance (CSA)?
CSA is the FDA’s risk-based, least-burdensome approach for assuring software used in medical-device production and the quality system. It leads with intended use and risk, then applies the least-burdensome assurance activity — favouring critical thinking and unscripted testing where risk is low.
Does CSA apply outside medical devices?
The FDA’s CSA final guidance is scoped to device production and quality-system software. Its principles (risk-first, least-burdensome, critical thinking) are widely borrowed for pharma CSV, but the formal guidance is device-scoped — do not assume FDA applies it to pharma manufacturing or clinical software.
How is CSA different from traditional CSV?
Traditional CSV often defaulted to heavy scripted testing and documentation regardless of risk. CSA reallocates that effort — focusing rigorous testing on high-risk features, allowing unscripted testing for low-risk ones, and recording only evidence that adds assurance. GAMP 5 (2nd ed.) already incorporates this mindset.