Toward a Least-Burdensome Approach to Computer Software Assurance

Key Aspects of Computer Software Assurance (CSA)   

 The FDA defines CSA as a risk-based approach to establishing and maintaining confidence that software used in production or quality management is fit for its intended use. This approach aims to focus assurance efforts based on where the areas that have a potential impact on device quality and patient safety are put at major risk. The process includes the Critical Thinking approach, based on leveraging SMEs experience to determine the test cases and direction based on their knowledge, on generating supporting evidence only where it brings value and on spending more time in actively testing and challenging the system to find defects and anomalies in order to prove its fitness for intended use.  

Intended Use as the Starting Point   

Manufacturers must first determine whether a software feature, function, or operation is used directly as part of or to support production or the quality management system. Supporting software often carries lower risk, such that under a risk-based computer software assurance approach, the effort of validation may be reduced accordingly without compromising safety. Software may have one or more intended uses and different risks and related levels of validation effort depending on the individual features, functions and operations. Manufacturers may decide to conduct different CSA activities for individual features, functions or operations risk-based.  

Process vs. Medical Device Risk  

A central distinction in the guidance is between:

• Process risk: The potential for a software failure to compromise production or quality system performance.
• Medical device risk: The potential for such a failure to compromise patient or user safety.

Process Risk is further categorized as:

• High Process Risk: when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning an increased medical device risk. In this case, assurance activities commensurate with medical device risk.
• Not High Process Risk: when its failure to perform as intended would not result in a quality problem that foreseeably compromises safety. In this case, assurance activities commensurate with the process risk.

The Least-Burdensome Principle

The FDA explicitly encourages a least burdensome approach. Where risk is low, manufacturers may rely primarily on:

• vendor assessments
• installation and configuration checks
• unscripted or ad‑hoc testing
• automated logs or system data as evidence

rather than heavy test documentation or scripted testing protocols.

Applying a Risk-Based Approach to determine the appropriate Assurance Activities  

Once intended use is established, manufacturers evaluate software functions to identify reasonably foreseeable failures and determine whether they pose high or not high process risk. This step directly determines the rigor for assurance effort and the type of testing required.

The FDA outlines multiple testing types, each appropriate under different risk conditions:

Unscripted Testing

Unscripted testing applies to Not High Risk features, functions and operations. It is a dynamic testing type in which the tester’s actions are not prescribed by written instructions in a test case. It includes:

• Ad‑hoc testing: specification-based test case design technique based on exercising sequences of instructions.
• Error-guessing testing: test cases are derived on the basis of the tester’s knowledge of past failures or general knowledge of failure modes.
• Exploratory testing: spontaneously design and execute tests based on tester’s knowledge and heuristic. Exploratory testing looks for hidden properties, including hidden, unanticipated user behaviors, or accidental use situations that could interfere with other software properties being tested and could pose a risk of software failure.

Scripted Testing

Scripted testing applies to High Risk features, functions and operations and involves predefined test procedures, expected results, traceability, and often repeatability. It is a dynamic testing in which the tester’s actions are prescribed by written instructions in recorded test cases, in a test management tool or in a spreadsheet. Can be executed manually or executed automatically using an automated testing tool. It includes:

• Robust scripted testing: Includes test objectives, step-by-step test cases, expected results and evidence of repeatability, traceability to requirements, and auditability.
• Limited scripted testing: hybrid approach using scripted testing for high-risk features or operations and unscripted testing for low- to medium-risk items as part of the same assurance effort.

Additional Risk-Influencing Factors  

Manufacturers may scale assurance efforts down when strong safeguards exist, such as:

• downstream inspection controls
• redundant process monitoring
• robust vendor validation artifacts
• continuous system logs and audit trails
• cybersecurity protections and monitoring mechanisms

The flexibility to rely on such controls supports the least-burdensome philosophy.

Additionally, when deciding on the appropriate assurance activities, manufacturers should consider whether there are any additional controls or mechanisms in place throughout the quality management system that may decrease the impact of compromised safety and/or quality, such as:

• procedures to ensure integrity in the data supporting production, subsequent inspection or testing;
• established purchasing control processes for selecting and monitoring software vendors;
• activities to reduce cybersecurity exposure;
• data and information periodically or continuously collected by the software for the purposes of monitoring or detecting issues and anomalies
• use of tools supporting software development and system life cycle activities (e.g., bug, anomaly tracking, requirement traceability tools)
• exhaustive vendor evidences
  
  
  

Establishing the Appropriate Record  

The FDA emphasizes that documentation should be only as rigorous as necessary, and that digital records such as system logs, audit trails, and automated testing artifacts are strongly preferred over screenshots or paper evidence. This aligns with modern development practices and supports the least-burdensome approach.

The Appropriate Record shall include:

• The intended use of the software feature, function, or operation;
• The result of the risk-based analysis of the software feature, function, or operation;
• Description of the assurance activities conducted (scripted or unscripted)
• Issues found and resolutions
• Conclusion of acceptability
• Who performed testing and when

Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified.

Conclusion  

The FDA’s 2026 Computer Software Assurance guidance marks a significant modernization of expectations for validating software used in medical device production and quality management systems. By focusing on intended use, process risk, and medical device risk, manufacturers can apply commensurate activities, whether scripted, unscripted, exploratory, or ad‑hoc testing, to build confidence in their systems without unnecessary burden.

In essence, CSA empowers organizations to apply rational, risk‑driven judgment in determining the rigor for assurance effort, achieving compliance while supporting agility, innovation, and product quality.