CSA vs CSV: What the FDA Final Guidance means for your validation strategy

What it is about: CSA is a method, not a new rulebook

The FDA published the guidance “Computer Software Assurance for Production and Quality System Software” first as a draft in September 2022 and on 24 September 2025 as the final guidance; in February 2026 the FDA issued an updated edition (now “… Quality Management System Software”, aligned with QMSR terminology). It is addressed to manufacturers of medical devices, but in its way of thinking it is relevant for any regulated software. First, what matters: CSA is not a new standard that supersedes CSV, and not a license to validate less. It is a method for how you fulfill the existing obligation to validate — with a different emphasis.

The core idea: not every function of a piece of software carries the same risk for patient and product. An algorithm that computes a release decision is something different from a configuration field that sets the color of a dashboard. CSA requires making this distinction before testing and aligning the effort accordingly — instead of producing the same script depth for every function.

The real problem: CSV has become documentation-driven

Computerized System Validation as a principle is unchanged and correct: you demonstrate that a system is suitable for its intended purpose and stays under control. In practice, this has turned over the years into a routine in which the document became the goal and not the evidence behind it.

The FDA names this imbalance in the guidance explicitly. It observes that a substantial part of the validation effort flows into creating, reviewing and maintaining documentation — and not into the testing itself. You know the typical symptoms:

• Hundred-page test protocols for non-critical, configured standard functions.
• Screenshots meant to prove that a button works that the manufacturer has tested a million times over.
• Teams that, out of fear of the auditor, repeat the full script depth at every update, instead of assessing the actual change risk.

The result is expensive and — this is the uncomfortable point — often not safer. Documentation burden does not automatically correlate with patient safety. It can even obscure it, when the real test gets lost in the mountain of paper.

What CSA does differently in practice: risk first, method after

CSA reverses the order. Instead of starting with the question “Which protocol do we write?”, CSA begins with “What risk does this function carry?”. Only from the risk classification does it follow how much evidence is appropriate. The guidance sketches a four-step line of thought for this:

• 1. Determine the intended use. What is the function used for — directly quality/safety-relevant or supporting?
• 2. Classify the risk. High risk if a failure directly endangers product quality or patient safety; lower risk for an indirect or supporting function.
• 3. Choose the assurance activity. The FDA names a spectrum: unscripted testing (ad-hoc / exploratory), scripted testing (limited or robust) — graded by risk.
• 4. Capture evidence appropriately. Record what the result and its assessability demonstrate — no more.

The practical effect: for a configured low-risk function, a traceably documented exploratory test can suffice. For a high-risk function that directly influences GxP decisions, the FDA still expects robust, script-based testing with solid evidence. You distribute your budget to where risk arises — not evenly across everything.

Critical thinking instead of a checkbox routine

The term that carries the whole guidance is critical thinking. CSA requires a reasoned decision — per function, per risk, per test intensity — instead of a reflexive repetition of the same protocol. This is a liberation and a burden at the same time.

A liberation, because you no longer have to treat non-critical functions with the same depth as critical ones. A burden, because you must take responsibility for the classification and prove it. An empty protocol with the note “low risk” is not critical thinking — it is a claim. What the auditor wants to see is the rationale: why was this function classified that way, and why is the chosen test depth appropriate for it?

This very chain of reasoning is the sore point. It often lives in the head of experienced validators and not in the system. This is exactly where traqx's trust principle comes in: an AI suggestion for risk classification or test depth is always a suggestion with a source reference — the decision is made by the human, and the audit trail records who decided what on which basis. CSA shifts work from copying to reasoning; a solid reasoning architecture is therefore not a comfort but a prerequisite.

CSA shifts work from copying to reasoning — a solid rationale becomes the prerequisite.

What concretely changes for your validation strategy

If you validate classically by CSV today, the switch is not a rip-and-replace. There are four shifts you can make step by step:

• Risk classification becomes the first activity, not an attachment at the end. Without a documented classification the reduced effort cannot be justified.
• You use the supplier's prior work. For established standard software (GAMP category 3/4) you may build on the manufacturer's tests instead of repeating them — you test your configuration and your use case, not the product.
• Evidence becomes leaner, but not arbitrary. Fewer screenshots, instead solid statements about what was tested, with what result and why it suffices.
• Updates are handled in a risk-based way. A patch without a GxP-relevant functional change does not require full requalification — the change assessment decides.

Consistency is important: the FDA accepts reduced effort where the risk is low — in return it expects high-risk functions to be truly thoroughly tested. CSA is not a discount on validation, but a redistribution. Whoever misunderstands it as a savings program weakens exactly the places the auditor looks at first.

The honest limits: where CSA changes nothing

Finally, the uncomfortable sobriety without which any account of CSA would be incomplete:

• It is an FDA guidance, not a binding law. Guidances represent the authority's current view. The underlying requirements (21 CFR Part 11, Part 820) remain in force unchanged. CSA is the recommended way to fulfill them — not their repeal.
• It is tailored to medical device software. The methodology is transferable to pharmaceutical GMP and EU contexts (EU Annex 11, GAMP 5 2nd Edition) — but you may not infer 1:1 applicability from this. Check the scope for your specific case.
• Less documentation does not mean less responsibility. The burden of proof shifts from the protocol to the rationale. If your classification does not hold, even lean evidence does not help — it only makes the gap more visible.
• AI changes nothing fundamental about this. A tool can suggest risk classifications and test depth and capture evidence consistently. The regulatory responsibility for the decision stays with the human — for CSV as for CSA.