Computer Software Assurance for Production and Quality Management System Software
FDA CSA Guidance is FDA's final guidance on Computer Software Assurance for production and quality management system software. The current version is dated February 2026 and supersedes the final guidance of the same subject issued 24 September 2025, which itself followed a 2022 draft; the title changed from "Quality System" to "Quality Management System" software, tracking the QMSR transition. Verified against FDA's guidance page on 2026-08-26. It sets a risk-based assurance framework for computers and automated data-processing systems used in medical-device production or the quality system under 21 CFR 820 and the QMSR. The guidance shifts effort from exhaustive documentation toward least-burdensome assurance driven by critical thinking, with testing proportionate to a feature's process risk — unscripted, ad-hoc or scripted. It supplements the 2002 General Principles of Software Validation and supersedes Section 6 of that document, covering on-premise and cloud systems.
What this does not cover
stated in the document's own scope- It applies to software used in production and the quality system, not to software that is itself a medical device (SaMD/SiMD) or device firmware — see IEC 62304 for device software lifecycle.
- It supersedes only Section 6 of the 2002 GPSV; the rest of that guidance still applies.
- It is guidance, not regulation; the enforceable requirement remains 21 CFR 820 / the QMSR.
- It does not replace Part 11 electronic-records and signatures obligations, which apply independently.
Always verify against the current published text before relying on it for a submission or inspection.
Overview
FDA CSA Guidance (2025) reframes how device makers assure the software they use to run production and their quality system. Rather than validating every function with the same exhaustive documentation, it asks manufacturers to think first about intended use and process risk, then apply assurance effort — and testing rigour — proportionate to that risk. Issued as final guidance on 24 September 2025 by CDRH and CBER, it supplements the 2002 General Principles of Software Validation and supersedes that document's Section 6. It covers on-premise and cloud software (IaaS, PaaS and SaaS) used in production or the quality system, and it emphasises critical thinking and least-burdensome evidence over paperwork volume.
Legal basis & how it acquires force
FDA guidance is not binding law; it states FDA's current thinking and describes one acceptable way to meet the underlying regulation. The binding requirement is 21 CFR 820 (now the Quality Management System Regulation, QMSR), whose software-validation provisions the CSA framework interprets — chiefly the requirement to validate computers and automated data-processing systems used as part of production or the quality system. Where records are involved, 21 CFR Part 11 also applies. CSA describes a compliant approach; the CFR is the enforceable rule.
Document structure
| Part | Covers |
|---|---|
| Scope and background | Software used in production or the quality system; relationship to the GPSV. |
| Computer software assurance framework | Intended use, risk determination and assurance activities. |
| Risk-based analysis | Direct vs indirect impact on quality and the resulting assurance effort. |
| Assurance activities and testing | Unscripted (ad-hoc, error-guessing), scripted and combined approaches. |
| Documentation of assurance | The least record needed to establish confidence. |
| Examples | Worked scenarios illustrating proportionate assurance. |
Key requirements
- Identify the intended use of each software feature or function used in production or the quality system.
- Determine whether the feature has a direct or indirect impact on product quality or the quality system, establishing its risk.
- Assign an assurance effort proportionate to that risk, escalating rigour as potential harm increases.
- Select an appropriate testing activity — unscripted (ad-hoc or error-guessing), scripted, or a combination — matched to the risk.
- Apply critical thinking to leverage vendor activities, prior use and existing evidence rather than duplicating documentation.
- Record the assurance activities and results with the least documentation needed to establish confidence.
- Maintain the assured state through the software lifecycle as features, configuration or use change.
Implementation tips
- Start from intended use and process risk, then let the risk determine test rigour, rather than testing every function to the same depth.
- Leverage supplier testing and prior production experience as assurance evidence, documenting the rationale for relying on it.
- Reserve scripted testing for high-risk features and use unscripted or ad-hoc testing where the risk is low, keeping records lightweight.
Where this control fails
live FDA enforcementLive FDA recalls SPEQ maps to this standard’s topics — a SPEQ interpretation, not an FDA classification.
International alignment
The CSA guidance aligns FDA's expectations with the risk-based, critical-thinking philosophy already reflected in ISPE GAMP 5 (second edition) and in ICH Q9(R1) quality risk management. It sits on top of the 2002 General Principles of Software Validation, superseding only Section 6, and interprets the software-validation obligation in 21 CFR 820 as carried into the QMSR, which harmonises US device requirements with ISO 13485. It does not change the CFR; it modernises the method.
FDA CSA Guidance (2026): frequently asked questions
Quick answers to common questions about FDA CSA Guidance (2026).
When was the FDA CSA guidance finalised?
FDA issued the final Computer Software Assurance guidance on 24 September 2025, following the draft published on 13 September 2022.
What does CSA supersede?
It supplements the 2002 General Principles of Software Validation and supersedes Section 6 of that document, while the rest of the GPSV remains in effect.
Does CSA apply to cloud software?
Yes. It applies to on-premise and cloud deployments (IaaS, PaaS and SaaS) used for production or quality-system activities.
What kinds of testing does CSA describe?
Unscripted testing (ad-hoc and error-guessing), scripted testing, or a combination, chosen so the rigour matches the software feature's process risk.
This standard in practice
Recall domain is a SPEQ mapping of this standard’s topics, not an FDA classification.