Computer Software Assurance for Production and Quality Management System Software (FDA guidance)

Context and history

Computer Software Assurance is FDA's risk-based approach to gaining confidence in software used in device production and quality systems. It aims to move effort from producing documents to critical thinking and testing where risk is highest. FDA issued a draft on 13 September 2022 and finalised it on 24 September 2025. This version, issued on 3 February 2026, supersedes that one, and updates the title and references to fit the Quality Management System Regulation, which took effect on 2 February 2026.

It builds on FDA's General Principles of Software Validation, and does not replace the basic idea of validating software for its intended use.

Who and what it applies to

Computers or automated data processing systems used as part of production or the quality management system for medical devices, for manufacturers subject to the QMSR. Drug manufacturers often read it for ideas, but it is written for devices.

Not covered: Software that is part of a device, and drug manufacturing, are not the subject of this guidance.

What it contains

I to II Introduction and background

Why FDA promotes this approach, and how it relates to the QMSR.

III Scope

What software is covered, and how this builds on FDA's Software Validation guidance.

IV Definitions

Terms used, including computer software assurance.

V.A Risk framework

Identify the software's intended use, determine a risk-based approach, determine appropriate assurance activities, and establish an appropriate record.

V.B Electronic records

Considerations for electronic records requirements.

Appendix A Examples

Worked examples, showing risk reasoning and assurance activities.

Key points

• Identify reasonably foreseeable software failures, and decide whether they pose a high process risk.
• Match assurance activities to that risk.
• Scripted testing is not the only option: unscripted testing can fit lower risk.
• The record should be enough to show the work, not more.
• Leverage supplier and other existing evidence where justified.

In practice

General reading, not advice. This is drafted with AI and may not fit your situation. It does not replace the official text, your own quality system or qualified advice, and an inspector may take a different view.

• Use the worked examples to reset how teams think about test documentation.
• Agree the approach with QA before a project starts, because practices vary.
• If you are outside devices, check how far your regulator accepts this thinking before relying on it.

Read from the source document on 1 Nov 2026. This is our own description, not the official text. Check the full dated history in the change log below.