Pillar Wissen Jun 9, 2026 · 11:00 9 min read By Daniel Herrmann

CSA vs CSV: What the FDA Final Guidance Means for Your Validation Strategy

CSA vs CSV: direct FDA scope, process risk, suitable assurance activities and objective evidence for your validation strategy.

Computer Software Assurance (CSA) is the final FDA guidance for risk-based software assurance in medical-device production and quality management systems. The revised guidance issued in February 2026 supersedes the September 2025 version and aligns it with the amended 21 CFR Part 820 Quality Management System Regulation (QMSR). Its methods can inform risk-based CSV in other Pharma GxP contexts, but that does not extend the direct FDA scope.

In February 2026, FDA revised its final guidance “Computer Software Assurance for Production and Quality Management System Software.” This version supersedes the final guidance issued on 24 September 2025 and reflects the amendments to 21 CFR Part 820 under the Quality Management System Regulation (QMSR). The core issue remains: test volume is not a synonym for software assurance. IT leads, QA owners and Business Process Owners must therefore establish scope first. This article explains what CSA changes, when the FDA guidance applies directly and how its risk-based methods can be transferred without overstating applicability.

What CSA really is — the FDA definition

Computer Software Assurance is the FDA's methodological answer to a discrepancy that has been growing for years. On one side stood established CSV practice: documentation-heavy, test-intensive, with a tendency toward formalism. On the other side stood the reality of modern software development: agile, iterative, cloud-based, with ever shorter release cycles. CSA closes this gap.

The scope is clear: CSA applies to computers and automated data processing systems used in medical-device production or the manufacturer's quality management system. Depending on intended use, this may include production, laboratory, training, document or quality applications. Software as a Medical Device follows separate regulatory requirements. A LIMS, MES or ERP module is not in scope merely because of its product category; manufacturer context and intended use decide.

At its core, CSA shifts the logic of Validation: away from "test everything that is technically testable" toward "assess on a risk-based basis what protects patient safety and product quality". This shift is not a softening of the requirements. It is a refinement of what Validation should achieve: safety for patient and product — not completeness of test scripts.

Important for context: CSA exists in parallel to 21 CFR Part 11 and 21 CFR Part 820. The regulatory obligations — audit trails, electronic signatures, data integrity, quality system requirements — remain unchanged. CSA does not change what you have to demonstrate. CSA changes how you demonstrate it.

CSV vs CSA in direct comparison

The following table shows the central shifts between classic CSV practice and FDA CSA methodology:

Aspect	documentation-heavy CSV practice	CSA (FDA Final Guidance, revised 2026)
Basic approach	Compliance-first	Assurance-first (patient + product)
Test philosophy	Full testing, scripted	Risk-based, focused
Documentation depth	Extensive, procedural	Lean, benefit-oriented
Mindset	Prove everything	Risk-based justification
Validation effort	High, often proportional to function count	Proportional to risk
Patient safety focus	Implicit	Explicit, primary
Audit trail	Test-volume oriented	Justification-oriented
Modernisation fit	Hard to combine with Agile/DevOps	Natively supported

The comparison table makes it clear: CSA is not less than CSV — CSA is structured differently. Whoever reads column two against column three and thinks "less effort = less safety" has missed the point. CSA reduces redundancy, not substance. Audit robustness remains — it just emerges from documented assessment rather than documented test volume.

"CSA is not less CSV. CSA is smarter CSV."

The four core principles of the FDA methodology

For implementation, we condense the guidance into four working principles. This is a DHC practice model, not the FDA's verbatim structure. It provides a workable framework for software assurance within the direct CSA scope.

First principle: define Intended Use. Before validation begins, it must be clear what the software is used for. A LIMS function that generates sample identifications has a different Intended Use than a LIMS function that prints sample labels. The FDA explicitly requires this differentiation — and not only in the test script, but already in validation planning.

Second principle: assess risk. Which functions could compromise patient safety or product quality if they malfunction? This question governs the entire validation effort. High-risk functions are tested in depth. Low-risk functions are — with documented justification — reduced or covered through supplier declarations. The risk assessment is not an appendix; it is the steering instrument.

Third principle: plan assurance activities. On a risk basis, select the activities that provide the necessary assurance: scripted or unscripted testing, supplier evidence, monitoring and other suitable methods. The choice must fit intended use and process risk; scripted testing is not universally required.

Fourth principle: keep records appropriately. Documentation scales with the effort of the assurance activities. A thoroughly tested high-risk function receives full test records. A low-risk function covered by supplier assessment receives a brief justification document. The idea: every page of documentation serves a purpose. Whatever has no purpose is not produced.

These four principles work together. Whoever neglects the first cannot assess the second cleanly. Whoever chooses the third incorrectly produces either too little or too much in the fourth. CSA is methodical — and that is exactly where the efficiency gain comes from.

When CSA applies — and when CSV still does

The question "CSA or CSV" is not binary. Both methodologies coexist in 2026 — with a clear scope:

CSA applies directly to: computers and automated data processing systems used in medical-device production or a medical-device manufacturer's quality management system. Whether a LIMS, MES, ERP, document, training or quality application is in scope depends on its intended use.

Other CSV frameworks remain relevant for: pharmaceutical GMP, GCP, GLP or GDP systems outside that direct scope and for other regulatory contexts. Risk-based assurance can be implemented through GAMP 5, ICH Q9 and the applicable rules without presenting FDA CSA as a direct requirement.

Software as a Medical Device (SaMD) follows its own regulatory logic. 21 CFR Part 820, IEC 62304 and the relevant FDA guidances on AI/ML SaMD form the framework here. CSA principles are methodologically related but not directly applicable.

In practical terms, classify manufacturer context, intended use and regulatory basis first. Only systems in the direct scope should be described as FDA CSA applications. Suitable methods may be adopted for other GxP systems, but must remain justified within their own regulatory framework.

What changes in practice in your validation strategy

Whoever applies the CSA methodology consistently sees measurable changes in three areas.

Test volume can be reduced selectively. Where process risk, intended use and usable supplier evidence support it, blanket scripted tests can be replaced with more suitable assurance activities. The result is not automatically less work, but better-justified use of effort.

Documentation structure changes. CSV documentation is classically template-driven — every function is described according to the same scheme. CSA documentation is justification-driven — every function is documented according to its risk profile. Templates remain helpful, but they become tools, not mandatory structures.

The rationale becomes central evidence. Your dossier must show why a function was assessed as high or not high process risk and why the selected assurance activities are appropriate. Audit preparation therefore covers both test evidence and the traceable decision path.

For your validation strategy, clarify applicability, realign risk assessments and test strategies, build reviewer competence and update affected procedures. Timeline and effort depend on the portfolio, governance, system risk and available evidence.

The path to implementation — where to start

CSA introduction is not a big-bang project. It is a structured transition in four steps:

Classify your system inventory. Which of your GxP systems fall within the CSA scope? Which do not? A simple classification table is enough as a starting point.
Select a CSA pilot system. Start with a clearly bounded system in the direct CSA scope whose process risk and evidence base support a defensible pilot assessment.
Apply the methodology in the pilot. Risk assessment, assurance activities, appropriate records — run the four principles through the pilot. Document what works and what needs to be adjusted.
Scale the framework. Based on the pilot, adapt your SOP set, your templates and your reviewer training. Then roll out the methodology across the entire system portfolio.

Set the timeline based on the number and criticality of systems, affected procedures, reviewer competence and governance maturity. The pilot provides the defensible basis for rollout.

Frequently asked questions

Does CSA fully replace the CSV framework?

No. CSA describes a software-assurance approach within its direct scope; the obligation to demonstrate fitness for intended use remains. Outside medical-device production and the related quality management system, the applicable CSV and GxP requirements continue to govern. 21 CFR Part 11 and quality management system obligations remain unchanged.

Does CSA also apply outside the USA, e.g. to EU pharma?

CSA is an FDA guidance with a defined US regulatory scope. Risk-based methods can align with European GxP approaches, but this does not create a direct CSA obligation for EU Pharma. The applicable legal and guidance basis must be established per system.

How do CSA and GAMP 5 2nd Edition relate to one another?

They can be complementary, but they are not interchangeable. GAMP 5 is broader and supports risk-based validation across GxP contexts. FDA CSA directly applies to software used in medical-device production and quality management systems. Methodological overlap helps implementation, but conformity to both references must still be justified separately.

Primary sources

Author

Daniel Herrmann Consulting — boutique consultancy for GxP compliance and Computer System Validation in pharma, biotech and MedTech. 15+ years of hands-on expertise. 60+ validated systems. 100% audit pass rate. 0 critical findings.