Validation

Computer software assurance: what FDA's final guidance changes for validation

By QLogix · Published 12 October 2026 · 4 min read

FDA's final guidance on computer software assurance replaces test-everything validation with effort matched to risk. Features that could compromise safety get scripted testing; the rest can be covered by unscripted testing and supplier evidence.

Final guidance announced in the Federal Register.: 24 Sep 2025
QMSR took effect, bringing ISO 13485:2016 into 21 CFR Part 820.: 2 Feb 2026
Risk levels in the guidance: high process risk, and not high process risk.: 2

Key takeaways

FDA announced the final guidance, Computer Software Assurance for Production and Quality System Software, in the Federal Register on 24 September 2025.
It covers software used in medical device production or the quality system. It does not cover software that is itself a device or part of one.
Each software feature is judged by process risk: whether its failure could foreseeably compromise safety.
The record needs to show the intended use, the risk decision, what was tested and the conclusion. Screenshots of every step are not the measure of assurance.

What is computer software assurance?

Computer software assurance, or CSA, is a risk-based approach to establishing confidence that software used in production or in the quality system is fit for its intended use. FDA issued it as a draft in September 2022 and announced the final guidance on 24 September 2025.

It is aimed at the habit that grew up around computer system validation: scripting and documenting every function to the same depth, whatever the risk. CSA asks teams to think first about what the software does and what happens if it fails, and to spend the testing effort there.

Which software does the guidance cover?

The guidance comes from FDA's device and biologics centers and applies to computers and automated data processing systems used as part of medical device production or the quality system. Examples include an electronic QMS, a manufacturing execution system, a laboratory system and the tools used to trend quality data.

It does not apply to software as a medical device or software in a medical device. Drug manufacturers are not its formal audience, but many apply the same reasoning under GAMP 5 Second Edition, which takes the same risk-based, critical-thinking approach.

How does the risk-based approach work?

Identify the intended use of the software, feature or function, and whether it is used directly in production or the quality system or only supports them.
Decide the process risk. A feature is high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety.
Choose assurance activities that match the risk: more rigor for high process risk, less for the rest.
Keep a record that is enough to show the software was assessed and performs as intended.

Which testing methods does the guidance accept?

Unscripted testing: ad hoc testing, error guessing and exploratory testing, where the tester works from the objective without a step-by-step script.
Scripted testing: limited or robust, with predefined steps and expected results, used where the risk calls for repeatability and traceability.
Evidence from the supplier: the developer's own testing and quality practices can be relied on where an assessment of the supplier supports it.

Matching assurance effort to process risk

Feature	Process risk	Fitting assurance activity	Record
Spell check in a document editor	Not high	Supplier evidence, no further testing	Intended use and risk decision
Dashboard that trends closed CAPAs	Not high	Unscripted: exploratory testing	What was tested, by whom, result
Electronic signature on batch release	High	Scripted: robust testing	Steps, expected and actual results, conclusion
Limit check that rejects out-of-range results	High	Scripted: robust testing, including failure cases	Steps, expected and actual results, conclusion

A reading of the final guidance's approach. The examples are ours; each team records its own risk decision.

How does this relate to the QMSR?

The Quality Management System Regulation, which amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference, took effect on 2 February 2026. Software used in the quality system still has to be validated for its intended use, with the effort proportionate to the risk. The CSA guidance describes how FDA expects that proportionate effort to be decided and recorded.

What does CSA mean for AI-enabled quality tools?

The same question applies: what does this feature do, and what happens if it is wrong? An AI feature that drafts text for a qualified person to review and approve sits at a different risk level from one that changes a record or a disposition by itself. Keeping the human decision in the workflow, and recording it, is what keeps the process risk low.

AI adds one thing ordinary software does not: its behaviour can change when the model or the prompt changes. The assurance record should name the model version, and a change of model should go through change control with regression testing against a fixed set of cases.

Common questions

Does CSA replace computer system validation?

CSA changes how validation effort is decided; it does not remove the requirement. Software used in production or the quality system must still be validated for its intended use. The guidance supersedes the section of FDA's 2002 General Principles of Software Validation that covered automated process equipment and quality system software.

Does the CSA guidance apply to pharmaceutical manufacturers?

It was issued for medical device production and quality system software. Drug manufacturers remain subject to 21 CFR Parts 210 and 211 and Part 11, and commonly apply the same risk-based approach through GAMP 5 Second Edition.

Is unscripted testing acceptable to FDA?

Yes, for features that are not high process risk. The guidance names ad hoc testing, error guessing and exploratory testing as acceptable assurance activities, with a record of what was tested, by whom, and the result.

Sources

This article is general information for quality and regulatory professionals. It is not regulatory or legal advice. Check the source documents for their current status before acting on them.