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.
Nature, extent and evidence depth of assurance activities follow intended use and the risk a malfunction poses to product safety and quality. Blanket testing and documentation routines do not set the measure.
No change of course. Confirmation of a path.
Risk-based validation predates CSA. The European GMP framework tied scope and depth of computerized system validation to risk and use before 2002. ICH Q9 systematized quality risk management from 2005. CSA continues that line for medical devices.
| Milestone | Contribution to the risk-based approach |
|---|---|
| EU GMP Annex 11 + Annex 15first issued 1992 / 2001, current versions 2011 / 2015 | Annex 11 established validation and controlled use of GMP-relevant computerized systems. Annex 15 tied the scope and extent of validation to a risk assessment. |
| FDA "General Principles of Software Validation"01/2002 | This guidance anchored risk-based evidence for software on the FDA side. Validation scales with complexity and risk, and the evidence establishes a "level of confidence". As of 2025 CSA replaces only its Section 6. |
| FDA initiative "Pharmaceutical CGMPs for the 21st Century - A Risk-Based Approach"2002 / final report 2004 | The initiative made risk and science the agency's guiding principles. Modern quality systems became the measure for applying CGMP. No new regulation followed. |
| PIC/S PI 011in force 09/2003 | The PIC/S inspection guidance carried Annex 11 into risk-based inspection practice. It grades deficiencies by relative risk and criticality of the application. |
| ICH Q9 / Q9(R1)2005/2006 / 2023 | ICH Q9 harmonized quality risk management (QRM) as a systematic process of risk assessment, control, communication and review. |
| GAMP 5 / 2nd Edition2008 / 2022 | GAMP 5 turns the risk-based lifecycle into a practical methodology for GxP computerized systems. The 2022 2nd Edition strengthens Critical Thinking and scaled evidence. As industry good practice, it is not a regulation. |
| FDA CSA guidancefinal 09/2025 / QMSR revision 02/2026 | The guidance sets out what risk-based evidence means for production and QMS software at medical device manufacturers, from intended use through process risk to objective evidence. |
| GAMP GPG "Testing GxP Systems"3rd Edition, July 2026 | Like GAMP 5 good practice without legal force, the guide makes risk-based testing workable: scalable testing activities, quality risk management, supplier evidence and a chapter on computerized test tools. It states its approach is consistent with GAMP 5 (2nd Edition) and the FDA's CSA guidance. |
Determine the intended use and process risk first. Then put the effort where it counts.
Higher process risk generally calls for greater evidence depth, but the method does not follow mechanically from the risk level, as the guidance makes clear. It distinguishes scripted from unscripted testing, and the method of choice is the one that best shows the function is fit for use. Combined tests follow the same criterion. Intended use and process risk can only be derived from the business process in which the software runs. Process, users, operating environment and data therefore belong to the picture. Our page on process management shows how to describe and maintain it.
CSA or CSV: what is the difference?
CSA does not replace CSV. The guidance supplements the FDA's "General Principles of Software Validation" and supersedes only its Section 6. Its general validation principles continue to apply to production and QMS software. The guidance provides for no more effort than necessary (Least Burdensome), unlike a practice that applied one template of scripted tests and extensive protocols to every function. The first question is the intended use, the second the malfunction: could it cause a quality problem that foreseeably compromises safety? What counts are failures that are "reasonably foreseeable", not merely likely. Only then is the process risk high, and rigor then follows the medical device risk, otherwise the process risk. For high process risk the guidance points to scripted testing, otherwise to unscripted testing, supplier evidence and ongoing monitoring. The assignment is not binding but the default. The standard of evidence is unchanged: objective evidence, captured as a record.
Methodology
CSA and GAMP 5 follow a comparable basic logic:
- understand the intended use
- analyze the risks
- select appropriate activities
- produce sufficient evidence
Scope
CSA covers more than function testing:
- intended use and risk-based analysis
- changes across the lifecycle
- supplier evidence, process controls and ongoing monitoring
- objective evidence and electronic records
- automation tools such as bots and automated workflows, data analytics, AI/ML tools and cloud computing
CSA formally applies to medical device manufacturers. Its core principle extends beyond that scope without replacing the requirements that apply there.
The term
"Assurance" is a new term for a familiar object of evidence: to demonstrate that the software is fit for the intended use the process defines and stays fit across the lifecycle. Anyone who demonstrates that soundly needs no terminology debate.
CSA changes no obligations: which records you keep, the predicate rules still decide. New is the clarity about the assurance record:
Documentation should demonstrate fitness for intended use to a depth matching the risk. The same approach carries over to AI-enabled systems, see our page on the validation of AI in the GxP environment.
The evidence stays. Formality without evidential value goes.
CSA shifts the emphasis from documentation volume to evidence quality. The manufacturer chooses the test format to suit the function tested. Existing supplier evidence can be credited. Effective controls keep the fitness demonstrated at go-live throughout the lifecycle. The FDA recommends digital records such as system logs, audit trails and automatically generated records as evidence, rather than redundant screenshots.
How we bring CSA into your validation practice.
Frank Henrichmann (QFINITY) reviewed the GAMP Good Practice Guide "Testing GxP Systems" (2026) for the ISPE Editorial Review Board. Members of the FDA Industry CSA team (FICSA) also contributed.
Scale effort, formality and documentation to the risk.
"The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk."
ICH Q9, Chapter 3, the international measure since 2005/2006, unchanged by the 2023 revision Q9(R1). CSA applies the same proportionality to software in production and QMS.
CSA leaves the goal of validation untouched and corrects a practice that too often mistook documentation volume for validation.
Common questions about CSA.
CSA stands for Computer Software Assurance, the FDA guidance for production and QMS software at medical device manufacturers, final since September 2025, aligned with the QMSR in February 2026. Device software itself is not covered and stays under the General Principles. The term also stands for the approach: evidence scaled to intended use and process risk, not to a template.
No. An FDA guidance describes the agency's current thinking and creates no obligation. The applicable requirements are binding, in the US since 2 February 2026 the QMSR and the ISO 13485:2016 requirements it incorporates. CSA is one recognized risk-based way to meet them. Alternatives remain permissible if they cover the same requirements.
CSA is an FDA guidance, GAMP 5 an ISPE good practice guide. Both start from the intended use, which sets risk and evidence depth. Since February 2026 the CSA guidance names GAMP 5 2nd Edition once, in a test-methods footnote. Critical Thinking is a general skill that the GAMP guides anchored in the validation context. The guidance does not use the term.
Not testing as little as possible, but spending no more effort and generating no more evidence than the risk requires. In practice, use existing supplier evidence, keep digital system records instead of redundant screenshots, reuse automated tests and use unscripted testing where it is more effective. Where risk is high, evidence depth stays high.
No. The guidance does not call for blanket repetition. At the next change, the periodic review or a deliberate reassessment of evidence depth, existing evidence, intended use and current risk are assessed again, and testing effort can then be aligned with the risk.
Last updated:
CSA needs the full picture.
Reduce testing effort defensibly.
We determine with you which functions of your production and QMS software are critical, derive test strategy and evidence depth, and document both so that an inspector can follow the reasoning. In a free intro call, we show where you test more than the risk warrants.
Book an intro call
