Computer Software Assurance.
Computer Software Assurance (CSA) is the FDA's risk-based approach to software in production and the quality management system (QMS) of medical device manufacturers. The nature, extent, and depth of evidence of assurance activities follow the intended use and the risk a malfunction poses to product safety and quality - not 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 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. Here are the milestones at a glance - CSA carries the path forward on the FDA's side, coming from the device corner.
| Milestone | Role on the risk-based path |
|---|---|
| EU GMP Annex 11 + Annex 15first versions 1992 / 2001 - in force today: 2011 / 2015 | Annex 11 established the 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 supersedes 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 steering 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 of 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) - adopted as Annex 20 into the GMP guides: 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 source of orientation for testing methods since its 02/2026 revision - neither the draft nor the initial final contained the reference |
| FDA CSA guidancefinal 09/2025 / QMSR revision 02/2026 | Makes the risk-based assurance approach concrete for software in medical device production and QMS: intended use, process risk, appropriate assurance activities, sufficient objective evidence |
| GAMP GPG "Testing of GxP Systems"3rd Edition, announced | The upcoming testing guide embeds the CSA mindset natively in the testing methodology - created with members of the FDA CSA team contributing; testing activities scale with the system's complexity and novelty, and defects are found early rather than processed formally |
Determine the intended use and process risk first. Then assure with intent.
Higher process risk generally calls for more rigor. But the testing method does not follow a risk class mechanically: scripted, unscripted, exploratory, automated or hybrid testing is chosen by which method most effectively demonstrates that the specific function is fit for use - the guidance explicitly does not tie the methods to risk classes. Intended Use and process risk both originate in the process - process management lays that groundwork.
Does CSA replace traditional CSV?
No, CSA does not replace CSV - the guidance itself 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 takes over the area of production and QMS software. Three angles show what CSA actually changes - and what it does not.
Methodology
CSA and GAMP 5 share the same 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 covers more than testing individual functions. The guidance covers:
- intended use and risk-based analysis
- changes across the lifecycle
- vendor evidence, process controls and monitoring
- objective evidence and electronic records
- explicitly including automation bots, data analytics and AI/ML tools
The comprehensive validation view of process, users, operating environment and data remains in place.
Label
"Assurance" is a new label for a more precisely named object: what is demonstrated is that the software is fit for the intended use defined by the process - and that this fitness is maintained across the lifecycle. Answer that question cleanly and the terminology debate takes care of itself.
CSA changes nothing about the obligations: which records you must keep still follows from the predicate rules. What is new is clarity about the assurance record itself - the 2026 revision spells out what it captures:
The documentation must be sufficient to demonstrate suitability for 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.
Not less assurance. Less formality without evidential value.
CSA does not simply shift the emphasis from documentation to testing - it shifts it from documentation volume to evidence quality: appropriate assurance activities instead of rigid test formats, solid vendor evidence instead of needless repetition, effective lifecycle controls instead of one-off go-live validation. And the FDA explicitly recommends original digital evidence - system logs, audit trails, automatically generated data - 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 yardstick since 2005/2006. CSA carries the same proportionality logic into 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 does not bind. What binds 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 steering 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 - is fully consistent with ICH Q9 and GAMP 5, which apply industry-wide. That is why CSA resonates 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 - say, using existing vendor evidence, digital system records instead of redundant screenshots, unscripted or exploratory testing 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 stands up to the final CSA guidance. Start with a free intro call in which we pinpoint your CSA leverage.
Book an intro call
