Computer Software Assurance.
Computer Software Assurance (CSA) is a risk-based FDA approach to software used in production and in the quality management system (QMS) of medical device manufacturers. The nature, extent and evidentiary depth of assurance activities follow the intended use and the risk a malfunction poses to product safety and quality, rather than blanket testing and documentation routines.
No change of course - confirmation of a path.
Risk-based validation is older than the CSA guidance debate: the European GMP framework had already tied the scope and depth of computerized system validation to risk and use before 2002, and ICH Q9 turned quality risk management into a systematic process from 2005 onward. The milestones at a glance - CSA carries that path consistently forward on the FDA side, this time out of the device world.
| Milestone | Role on the risk-based path |
|---|---|
| EU GMP Annex 11 + Annex 15first versions 1992 / 2001 - in force today: 2011 / 2015 | Annex 11 established validation and controlled use of GMP-relevant computerized systems; Annex 15 explicitly required scope and extent of validation to be set on the basis of a risk assessment |
| FDA "General Principles of Software Validation"01/2002 | Anchored risk-based software evidence on the FDA side: the extent of validation explicitly scaled to complexity and risk, evidence framed as a "level of confidence", Least Burdensome as a stated principle. In 2025, CSA superseded only its Section 6 - the rest remains in force |
| FDA initiative "Pharmaceutical CGMPs for the 21st Century - A Risk-Based Approach"2002 / final report 2004 | Elevated risk, science and modern quality systems to an agency-wide guiding principle - modernized how CGMP is applied, no new regulation |
| PIC/S PI 011in force 09/2003 | Translated Annex 11 into risk-based inspection practice: PIC/S guidance for inspectors on computerized systems - deficiency ratings explicitly based on the relative risk of the application and its risk criticality; content unchanged and still in force (PI 011-3, 2007) |
| ICH Q9 / Q9(R1)2005/2006 / 2023 | Harmonized quality risk management (QRM) as a systematic process (assessment, control, communication, review) - incorporated into the GMP guides as Annex 20: EU 2008, PIC/S 2009 |
| GAMP 5 / Second Edition2008 / 2022 | Turns the risk-based lifecycle approach into practical methodology for GxP-relevant computerized systems; the Second Edition strengthens Critical Thinking and scaled evidence - industry good practice, not law; the CSA guidance has named the Second Edition as one point of reference for testing methods since its 02/2026 revision - neither the draft nor the first final version contained the reference |
| FDA CSA guidancefinal 09/2025 / QMSR revision 02/2026 | Spells out the risk-based assurance approach for software in medical device production and QMS: intended use, process risk, appropriate assurance activities, sufficient objective evidence |
| GAMP GPG "Testing GxP Systems"3rd Edition, July 2026 | Spells out risk-based testing in practice - industry good practice, not law: scalable testing activities, quality risk management, supplier evidence; a dedicated chapter addresses computerized test tools, with appendices on iterative approaches, SaaS and AI/ML. The guide explicitly states its approach is consistent with GAMP 5 (Second Edition) and the FDA's CSA guidance. Members of the FDA Industry CSA team (FICSA) contributed to the guide; Frank Henrichmann (QFINITY) reviewed it for the ISPE Editorial Review Board |
Determine the intended use and process risk first. Then target your assurance.
Higher process risk generally calls for more rigor. But the testing method does not follow a risk class mechanically. The guidance distinguishes two types: scripted and unscripted testing. Which of them applies, in what form (such as scenario-based, exploratory, or automated execution) and whether a combination of both is appropriate depends on which method most effectively demonstrates that the specific function is fit for use. The guidance's assignment of methods to risk classes is explicitly not exclusive. Intended Use and process risk both originate in the process - process management lays the groundwork.
Does CSA replace traditional CSV?
No, CSA does not replace CSV - the guidance supersedes only Section 6 of the FDA's "General Principles of Software Validation". For software that is itself part of a medical device, that guidance continues to apply unchanged - CSA covers production and QMS software. Three angles show what CSA actually changes - and what it does not.
Methodology
CSA and GAMP 5 follow a comparable basic logic:
- understand the intended use
- analyze the risks
- select appropriate activities
- produce sufficient evidence
GAMP 5 provides the comprehensive lifecycle framework - CSA states the same logic as an FDA expectation.
Scope
CSA is about more than testing individual functions. The guidance spans:
- intended use and risk-based analysis
- changes across the lifecycle
- supplier evidence, process controls and monitoring
- objective evidence and electronic records
- explicit applicability to automation tools (such as bots and automated workflows), data analytics and AI/ML tools, and cloud computing
The comprehensive validation perspective on process, users, operating environment and data remains in place.
Label
"Assurance" is a new label for a more precisely named object: what you demonstrate is that the software is fit for the intended use the process defines - and that this fitness is maintained across the lifecycle. Answer that question cleanly and you can skip the terminology debate.
CSA changes none of the obligations: which records you must keep is still governed by the predicate rules. What is new is clarity about the assurance record itself - the guidance spells out what it captures:
The documentation must be sufficient to demonstrate fitness for use given the identified risk. Nothing more is required. To see how the same risk-based thinking plays out for AI systems, visit our page on the validation of AI in the GxP environment.
Assurance stays. Formality without evidential value goes.
CSA shifts the emphasis from documentation volume to evidence quality. The test format is chosen for its suitability to the specific function, existing supplier evidence can be credited and effective controls across the lifecycle maintain the fitness demonstrated at go-live. As evidence, the FDA explicitly recommends original digital data such as system logs, audit trails and automatically generated records over redundant screenshots.
CSA in validation - targeted support.
Effort, formality and documentation - commensurate with risk.
"The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk."
ICH Q9(R1), Chapter 3 - the international reference since 2005/2006. CSA applies the same proportionality logic to the assurance of production and QMS software.
CSA does not correct the goal of validation. CSA corrects a practice in which documentation volume was too often mistaken for validation.
Common questions about CSA.
No. An FDA guidance describes the agency's current thinking; it is not binding. What is binding are the applicable requirements - in the US, since February 2, 2026, the QMSR with the incorporated requirements of ISO 13485:2016. CSA describes a recognized risk-based way to meet them; alternative approaches remain acceptable as long as they satisfy the requirements.
No. In Europe, Annex 11 (first version 1992, in force today as revised in 2011) and Annex 15 (2001, today 2015) tied validation to use, lifecycle and risk before the FDA initiative; PIC/S inspection practice (PI 011, 2003) rated deficiencies by the relative risk of the application. The FDA elevated risk to a guiding principle in 2002-2004, and ICH Q9 systematized it as QRM. CSA is the latest confirmation of that path - not its beginning.
Formally, yes: CSA applies to software in the production and quality management systems of medical device manufacturers - device software itself (design verification and validation) is explicitly outside its scope. Its core - testing effort based on intended use and process risk - follows the same thinking as ICH Q9 and GAMP 5, which serve as methodological orientation industry-wide. That is why CSA carries beyond the device world - though it does not replace the requirements that apply there.
Least Burdensome does not mean testing or documenting as little as possible. It means not producing more effort and evidence than controlling the identified risk requires - for example: using existing supplier evidence; digital system records instead of redundant screenshots; unscripted testing, including exploratory, where it is better suited; reusing automated tests; focusing your own testing on genuine evidence gaps. Where risk is high, high rigor remains required.
CSA needs the full picture.
Align validation effort with the real risk.
We develop your validation strategy, planning and specification, derive a risk-based test strategy from them, and build evidence that meets the expectations of the final CSA guidance. Start with a free intro call in which we name exactly where CSA gives you leverage.
Book an intro call
