What changed: from CSV to CSA
For two decades, medical device manufacturers validated production and quality system software under Section 6 of FDA’s General Principles of Software Validation. In practice that often meant heavy scripted test documentation for every function, regardless of risk. Computer Software Assurance (CSA) is FDA’s answer: a risk-based approach to establish and maintain confidence that software is fit for its intended use, with assurance effort scaled to the risk a software failure poses to product quality and safety.
Status and timeline
| Date | Event |
|---|---|
| September 2022 | Draft guidance issued |
| September 24, 2025 | Final guidance, Computer Software Assurance for Production and Quality System Software |
| February 2, 2026 | Amended 21 CFR Part 820 (the QMSR, incorporating ISO 13485:2016) takes effect |
| February 2026 | Final guidance reissued as Computer Software Assurance for Production and Quality Management System Software, superseding the September 2025 version (docket FDA-2022-D-0795) |
The guidance is issued by CDRH and CBER and supersedes Section 6 of the General Principles of Software Validation guidance. The NSF summary and Medmarc both note that the February 2026 reissue aligned the text with the QMSR.
The CSA risk framework
The guidance text walks through four steps.
- Identify intended use. Is the software, or a specific feature, function or operation, used directly in production or the quality system, or does it support those processes?
- Determine the risk-based approach. Would failure pose a high process risk, meaning it “may result in a quality problem that foreseeably compromises safety”? Medmarc notes this is a “reasonably foreseeable” judgment, not the probabilistic analysis used under ISO 14971.
- Determine assurance activities. Match rigor to risk.
- Establish the record. Capture enough objective evidence to show the software performs as intended.
Assurance activities
| Type | Description | Typical use |
|---|---|---|
| Scripted testing (robust) | Documented test cases executed manually or automatically | High process risk functions |
| Scripted testing (limited) | Fewer, targeted scripted tests | Moderate risk |
| Unscripted: scenario (ad hoc) | Testing without prescribed steps | Lower risk |
| Unscripted: error guessing | Tests based on known failure modes | Lower risk |
| Unscripted: exploratory | Tester knowledge and judgment drive testing | Lower risk |
The guidance also credits other controls that reduce the testing burden, such as vendor evaluation and existing process controls.
What the CSA record should contain
- Intended use
- Result of the risk-based analysis
- Description of the testing performed
- Issues found and their resolution, or a risk justification
- Who performed the testing and when
- Review and approval, where appropriate
FDA encourages digital records such as system logs and audit trails instead of screenshots where possible.
Examples in the guidance
Appendix A works through a nonconformance management system, a learning management system, business intelligence applications and a SaaS product lifecycle management system. Medmarc’s summary adds that general infrastructure such as networking and user authentication is not subject to Part 820 validation, and that cloud storage used only as a backup is treated differently from cloud storage that is the primary repository of quality records.
Does CSA apply to pharmaceutical companies?
Strictly, no. The guidance is issued by CDRH and CBER under 21 CFR Part 820 for medical device production and quality system software. CDER has not issued an equivalent. Many drug manufacturers nonetheless apply CSA thinking through ISPE GAMP 5 (2nd edition), which discusses CSA and supports risk-based, critical-thinking validation. When they do, their validation plans should cite the drug requirements they must meet, such as 21 CFR 211.68 and Part 11, rather than presenting the device guidance as binding. CSA does not change Part 11 obligations for electronic records and signatures.
Moving from CSV to CSA in practice
- Inventory production and quality system software and classify each feature as direct or supporting.
- Document the high-process-risk decision for each feature with a short rationale.
- Rewrite validation SOPs to allow unscripted testing for lower-risk features.
- Use vendor documentation and SaaS supplier assessments where credible.
- Switch evidence from screenshots to system logs and audit trails.
- Train QA reviewers to accept risk-proportionate records.
Common weaknesses
- Calling the process “CSA” but still writing full scripts for every feature.
- Risk decisions made at system level instead of feature level.
- No written rationale for “not high process risk.”
- Unscripted testing with no record of what was tested or found.
- SOPs still citing the superseded Section 6 or the September 2025 title.
- Pharma teams citing CSA as a regulation they must follow.
Checklist: CSA readiness
- Software inventory with intended use per feature
- High-process-risk determination documented for each feature
- Assurance activity selected and justified by risk
- Records include intended use, risk result, testing, issues, tester, date and approval
- Vendor and SaaS assessments on file and used to reduce testing where justified
- SOPs reference the February 2026 guidance title and the QMSR
- Part 11 controls assessed separately
How AskDona helps
CSA shifts the question from “how many test scripts do we have?” to “does our record justify the assurance we chose?” AskDona reads your software inventories, risk assessments and validation or CSA records against the guidance’s record elements and your SOPs, flags features without a documented risk decision or evidence, and cites the exact page. Run a sample CSA record review on one system before your next audit. AskDona shows the evidence; your quality and validation teams decide.
Editor’s note: Framework details come from the HHS-hosted copy of the guidance text, which reflects the February 2026 version. FDA’s older guidance page still showed the September 2025 title when checked, while the newer page lists the February 2026 reissue as superseding it. Summaries from NSF (a certification and consulting body) and Medmarc (an insurer) are used for context only.
FAQ
What is computer software assurance? A risk-based approach from FDA for establishing confidence that software used in medical device production or the quality system is fit for its intended use.
Is the FDA CSA guidance final? Yes. It was finalized on September 24, 2025, and reissued in February 2026 as “Computer Software Assurance for Production and Quality Management System Software” to align with the QMSR.
What is the difference between CSV and CSA? CSV often applied uniform, script-heavy validation. CSA scales assurance to risk and allows unscripted testing and leaner records for lower-risk features.
What is high process risk? A failure that may result in a quality problem that foreseeably compromises safety.
Does CSA apply to pharma? Not directly. It covers medical device software under Part 820, though many drug manufacturers adopt similar risk-based thinking through GAMP 5.
References
All pages opened and checked by October 23, 2026.
| Source | Type | Used for |
|---|---|---|
| FDA: CSA for Production and Quality Management System Software | Regulator | February 2026 status, supersession |
| FDA: CSA for Production and Quality System Software (2025 page) | Regulator | September 2025 version, scope |
| Guidance text (HHS-hosted) | Regulatory guidance | Framework, testing types, records, examples |
| NSF | Certification/consulting body | Timeline |
| Medmarc, Feb 27, 2026 | Insurer | QMSR alignment, examples, Part 11 |