CSA Framework — from paper to practice
The end-to-end Computer Software Assurance operating model — risk profiling, test-strategy selection, vendor-evidence leverage, and audit posture.
Computer Software Assurance is FDA's guidance on how much testing a GxP system actually needs, finalised in September 2025 after three years in draft. Instead of testing every requirement to the same depth, you assess what happens if each one fails and concentrate effort where failure would affect patient safety, product quality or data integrity. CSA does not replace validation — it changes how the effort inside it is distributed.
Step 1 — Identify the intended use
Everything downstream depends on this being specific. 'The system manages quality records' is not an intended use; it is a product category.
- 1
Intended use stated per function
What the system is used for in your process, function by function, in your own words rather than the vendor's.
- 2
Direct or indirect impact determined
Does this function touch product quality, patient safety or record integrity directly, or support something that does?
- 3
Out-of-scope functions named
Functions you have licensed but do not use for GxP purposes, explicitly excluded with a reason.
Step 2 — Determine the risk
The heart of CSA. Assess the harm from failure, not the complexity of the feature — these are routinely confused, and the confusion is what produces inflated test plans.
- 4
Failure consequence assessed
What actually happens if this function fails or produces a wrong result. Severity drives everything that follows.
- 5
Detectability considered
Would a failure be noticed by a downstream control, or would it pass silently into a record?
- 6
High vs non-high risk assigned
FDA's model is deliberately binary at the top level. Resist inventing a five-point scale that nobody can apply consistently.
- 7
Rationale written at the time
Recorded as the decision is made, not reconstructed later. A rationale written after an audit question reads exactly like one.
Step 3 — Choose the assurance activity
Three options, and the skill is in matching them honestly. Picking the lightest option everywhere is not CSA; it is the thing CSA gets blamed for.
- 8
Scripted testing
Pre-defined steps with expected results and captured evidence. For high-risk functions where failure would reach the patient or the record.
- 9
Unscripted testing
Exploratory, ad-hoc or error-guessing testing with a session record of what was covered and what was found. For non-high-risk functions.
- 10
Vendor evidence leverage
Relying on supplier testing where their quality system has been assessed and their evidence is specific enough to cite.
- 11
Selection mapped to risk
A table linking each function to its risk level and the activity chosen. This table is what an inspector will ask to see.
Step 4 — Establish the record
CSA reduces documentation volume, not documentation discipline. What you keep must be enough to reconstruct the decision.
- 12
Evidence proportionate to risk
Full records for scripted testing; a session record naming the tester, scope, duration and findings for unscripted.
- 13
Issues recorded regardless of method
A defect found during exploratory testing is still a defect and still needs resolving and recording.
- 14
Traceability maintained
Every function links to its risk determination, its chosen activity and its outcome.
- 15
Conclusion documented
A statement that the system is fit for its intended use, supported by the evidence actually gathered.
Making the transition from traditional CSV
The most common failure mode is a CSA policy that nobody applies because the templates still demand scripted evidence for everything.
- 16
Procedures updated first
Your validation SOP has to permit unscripted testing and vendor evidence, or your teams cannot legally use them.
- 17
Templates rebuilt
Protocol templates that only accommodate scripted steps will quietly force scripted testing forever.
- 18
Assessors trained
Risk assessment is a judgement skill. Teams that have only ever scripted everything need practice at justifying less.
- 19
Applied to new systems first
Re-baselining a validated estate under CSA is a bigger project than it looks. Prove the model on new work.
- 20
QA aligned before, not after
A CSA rationale rejected at approval wastes more time than scripting everything would have.
CSA is guidance, not a regulation. It describes an approach FDA considers acceptable; it does not oblige you to adopt it, and it does not override your own quality system.
CSA is frequently misread as permission to test less. The reduction is a consequence of the risk assessment, not the goal of it. A reduced test effort with no documented rationale is simply under-testing.
This is a working aid, not a regulatory document, and it does not replace your own quality system procedures.
Explore related resources, products and services: GxP Copilot, TraceDraft, validation services, AI transformation.
Sources
Primary documents referred to on this page, from their official publishers.
Common questions
Prefer to talk first? Chat with us on WhatsApp or book a call with an expert.
What is Computer Software Assurance (CSA)?
CSA is FDA's guidance on assurance for production and quality system software, issued as a draft in 2022 and finalised in September 2025 and reissued in February 2026. It asks you to determine each function's intended use, assess the harm if it fails, and choose an assurance activity proportionate to that harm — scripted testing, unscripted testing, or reliance on assessed vendor evidence.
Is CSA replacing CSV?
No. CSV is the activity of establishing documented evidence that a system is fit for its intended use; CSA is guidance on how to size the effort within it. You still produce a validation lifecycle, a traceability matrix and a summary report. What changes is how much testing each individual requirement receives.
How much testing can we actually remove under CSA?
There is no fixed figure, and any number quoted without reference to your risk profile should be treated with suspicion. The reduction falls out of the risk assessment: low-risk functions on a well-assessed commercial product may need little direct testing, while high-risk functions need as much scripted evidence as they ever did.
What is unscripted testing and is it acceptable?
Unscripted testing is exploratory, ad-hoc or error-guessing testing performed without pre-defined steps, documented with a session record naming the tester, the scope covered, the duration and the findings. FDA explicitly recognises it as an assurance activity for non-high-risk functions. Findings must still be recorded and resolved.
What do we need to change to adopt CSA?
Your validation SOP must permit unscripted testing and vendor-evidence reliance, your protocol templates must accommodate something other than scripted steps, your assessors need practice at writing defensible risk rationales, and QA must agree the approach before the first package arrives for approval rather than after.
Put this to work on your system.
Bring a URS. We show you risk-sized testing on your own requirements.
- We reply within one business day
- We run your URS live on the call
- You get a clear plan for your system