Computer Software Assurance vs. Traditional Validation: What Changes in Practice?

The short answer: the evidence should follow the risk

Computer software assurance is not a shortcut around validation. It is a risk-based way to decide how much assurance a software function needs and what evidence will demonstrate that it works for its intended use. The FDA guidance on computer software assurance describes this approach for production and quality system software used in medical device organisations. It applies the same basic discipline that good validation programmes have always needed: understand the intended use, identify risk, test the important behaviours, and retain objective evidence.

Traditional validation programmes often begin with a familiar document set. That can produce a large quantity of scripted testing even when the risk is low, while leaving the most important workflow risks poorly explained. A risk-based assurance plan starts somewhere more useful: the decisions the system supports and the harm that could follow if it behaves incorrectly.

What remains non-negotiable

• A documented intended use and defined scope for the system, module, or function.
• User and regulatory requirements that can be traced to controls and evidence.
• Risk assessment based on product, patient, data, and process impact.
• Controlled configuration, access, change management, and issue resolution.
• Records that let an independent reviewer understand what was tested, by whom, when, and with what result.

A better test selection model

Begin with the process and its critical outputs. Map each high-risk function to the failure mode that matters. A calculation that determines a critical acceptance decision deserves stronger challenge than a colour preference in a dashboard. A role-permission rule, audit trail, electronic signature, or data transfer may require more scrutiny than a low-impact display element even when the latter is more visible.

The evidence can be a mixture of methods. Structured scripted tests are useful when exact repeatability matters. Scenario-based testing is useful when a workflow involves several roles or data states. Unscripted exploration can expose unexpected behaviour when it is planned, bounded, recorded, and reviewed. Automated checks can be valuable when their purpose, limitations, and results are controlled.

How to avoid turning “risk-based” into “lightly documented”

Risk-based does not mean informal. Record the reason for the chosen assurance method. State the risk question, the expected result, the actual result, the tester, the date, and any deviation. If a control is accepted without a separate test because another controlled activity provides equivalent evidence, document that rationale and the reference. The record should make the decision reproducible, not dependent on the memory of the project team.

The useful question is not “How many test scripts do we have?” It is “Can we show why this evidence is enough for this intended use?”

Where VLMS fits

For a regulated team, the work is easier to defend when requirements, risks, tests, defects, approvals, and release decisions sit in one traceable lifecycle. VLMS Software is built around that chain. See the validation readiness benchmarks for a starting framework, then define the evidence package around your own process and system risk.