Validation29 September 20263 min readBy QLogixCMC

Computer software assurance: how much testing does your system actually need?

Computer software assurance (CSA) is FDA's risk-based approach to establishing confidence that software used in production and in the quality system does what it is intended to do. Its point is that testing effort follows the risk of each function: scripted, documented testing where a failure could affect product quality or patient safety, and unscripted or ad hoc testing, with the result recorded, everywhere else. Most validation packages still test every function the same way.

What changed

FDA published its computer software assurance guidance in draft in 2022 and finalized it in 2025. It does not change what 21 CFR Part 11, Part 211 or Part 820 require; it changes how much evidence is reasonable for each function. GAMP 5 Second Edition, published in 2022, had already moved the industry's own guidance in the same direction with its emphasis on critical thinking over documents.

The practical effect is that a site may stop producing a scripted test, with screenshots, for every menu item, and instead put its effort where a wrong result would matter. The risk assessment that decides which is which becomes the document an inspector reads first.

The method in four steps

Identify the intended use of the software and of each feature, in the site's own process
Assess the risk of each feature: does a failure affect product quality, patient safety or the integrity of a GMP record directly, indirectly or not at all
Choose the assurance activity to match: scripted testing for high-risk features, unscripted testing for medium, ad hoc testing or vendor evidence for low
Record what was tested, by whom, when, with what result and what was found, in enough detail for the test to be repeated

Interactive

Testing hours: everything scripted versus scaled to risk

High-risk functions12Medium-risk functions25Low-risk functions60Vendor evidence assessed and accepted for standard functions

59%less testing effort with CSA

291 hours scripted end to end, against 120 hours scaled to risk, with the high-risk functions tested the same way in both.

Traditional: every function scripted
CSA: scripted, unscripted and ad hoc by risk

Segments left to right: high, medium and low risk; lighter means lower risk.

Illustrative planning figures. High-risk functions, the ones whose failure could affect product quality or patient safety, get the same scripted, documented testing under both approaches. The saving is in the medium- and low-risk functions, which CSA covers with unscripted and ad hoc testing whose results are still recorded, and in accepting vendor evidence where it is adequate.

Where sites go wrong

Treating the vendor's validation package as sufficient without assessing it against the site's configuration and intended use
Scripting everything out of habit, so a 400-page package says little about the ten functions that matter
No risk rationale on file, which turns a lean package into an unexplained one
Unscripted testing that was done but never recorded, so it did not happen as far as an inspector is concerned
No periodic review, so the risk assessment describes a system three releases old

How QLogixCMC helps

QLogixCMC writes the validation master plan and the risk model, runs the risk assessment with the people who use the system, assesses vendor evidence, and executes the scripted tests with the site's users while recording the unscripted ones. The same approach is applied to AI-enabled features, where the intended use and the test records matter more, not less.

Questions this post answers

Is CSA less rigorous than traditional CSV?

No. High-risk functions get the same scripted, documented testing as before. CSA removes the uniform documentation from functions whose failure would not affect product quality, patient safety or record integrity, and asks for a risk assessment that explains the difference.

Will an inspector accept unscripted testing?

Yes, when the risk assessment explains why the function qualifies for it, the test and its result are recorded with the tester and the date, and the high-risk functions still carry scripted evidence. Unscripted does not mean unrecorded.

Can we rely on the vendor's validation package?

Where it covers the site's intended use, yes, after assessing the supplier and the package. What the vendor could not test, the site's configuration, its procedures and its integrations, the site tests itself.