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 addresses computers and automated data processing systems used in medical-device production or the quality management system under 21 CFR Part 820. It does not apply 1:1 to other pharmaceutical GxP or EU contexts; only its risk-based thinking is transferable, and that must be checked against the requirements applicable in each context. First, what matters: CSA is not a new standard that supersedes CSV, and not a license to validate less. It describes how medical-device manufacturers establish confidence in the automation they use — with a different emphasis.

The core idea within this FDA scope: 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

Within this FDA scope, 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.

Within the FDA scope, CSA shifts work from copying to reasoning; outside that scope, this is methodological guidance, not an FDA requirement.

What concretely changes for your validation strategy

For software within the FDA scope, CSA describes four possible shifts. Outside that scope — including pharmaceutical GMP and EU contexts — they are not FDA requirements, but methodological guidance that must be checked against the applicable requirements:

• 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 QMSR requirements under 21 CFR Part 820 remain in force; Part 11 applies only where its own scope is met. CSA recommends an approach but does not replace those requirements.
• It applies to production/QMS software in the medical-device context. Its reasoning can inform 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.

Frequently asked questions

What is the difference between CSA and CSV?

Within the FDA scope for software used in medical-device production or QMS under Part 820/QMSR, CSV and CSA pursue the same goal — demonstrating that a system is suitable for its intended purpose and stays under control. In practice CSV has become documentation-driven, where the document itself often turns into the goal rather than the evidence behind it. CSA starts from the risk a function carries and aligns test depth accordingly: lean evidence for low-risk functions, robust script-based testing where product quality or patient safety are directly affected. Outside that scope, CSA is methodological guidance, not an FDA requirement.

Does CSA replace classic CSV?

No. CSA is non-binding FDA guidance within the scope for software used in medical-device production or QMS under Part 820/QMSR, not a new standard and not a license to validate less. Outside that scope it creates no additional FDA obligation; its risk-based reasoning can provide methodological guidance.

What does the FDA CSA guidance recommend?

For software used in medical-device production or QMS under Part 820/QMSR, the guidance recommends a risk-based, four-step line of thought: determine a function's intended use, classify the risk, choose the appropriate assurance activity and capture the evidence appropriately. For the assurance activity the FDA names a spectrum from unscripted testing (ad-hoc/exploratory) to scripted testing (limited or robust), graded by risk. Critical thinking carries it all: every risk classification must be justified, and an empty “low risk” claim does not suffice in an audit.

Does CSA also apply to pharmaceutical manufacturers and in the EU?

The CSA guidance addresses software used in medical-device production or the quality management system under 21 CFR Part 820. A pharmaceutical GMP or EU context alone does not bring a use case within that scope. For a separate pharmaceutical/EU use case, it is not directly applicable. Its risk-based thinking may serve there as methodological orientation alongside the requirements that do apply, such as EU Annex 11; it does not establish 1:1 applicability. GAMP 5 is separate, non-binding industry guidance.

How does CSA fit with GAMP 5?

CSA and GAMP 5 2nd Edition (2022) push in the same direction: risk-based validation with critical thinking instead of template documentation. GAMP 5 is the ISPE industry guide for the lifecycle of computerised GxP systems; CSA is the FDA guidance for software used in medical-device production and QMS under 21 CFR Part 820 that shifts effort from documenting to defensible reasoning — methodically transferable to pharmaceutical GMP and EU contexts, without 1:1 applicability. They complement each other: the GAMP lifecycle and its categories remain usable as tools, while CSA aligns assurance effort and depth of evidence with risk and intended use.