When I wrote Part 1, Computer Software Assurance (CSA) was a draft the FDA had released for comment. It is now final. The FDA issued the final guidance on September 24, 2025, then reissued it on February 3, 2026 to align with the Quality Management System Regulation (QMSR) — the amended Part 820 that took effect the day before. For production and quality-system software, CSA is now the controlling reference, and it supersedes Section 6 of the FDA's 2002 software-validation guidance.
Part 1 walked through the draft's philosophy. This installment covers what the final guidance changed from that draft, and — more usefully — what it actually requires: when software has to be validated, and how much.
- Sept 13, 2022Draft published for comment — the version Part 1 explained.
- Sept 24, 2025Final guidance issued (90 FR 45945), superseding Section 6 of the 2002 software-validation guidance.
- Feb 3, 2026Reissued current — retitled and re-cited to align with the QMSR, which took effect February 2, 2026.
What changed from the draft
The Federal Register notice for the final guidance lists three substantive revisions from the draft: a definitions section, updated examples of manual and automated testing, and additional examples applied to different types of software. Reading the final against the draft, that holds. The framework is the same one Part 1 described, but it now ships with defined terms and worked examples — including four full case studies in the appendix (a nonconformance system, a learning management system, business-intelligence applications, and a Software-as-a-Service product-lifecycle system).
Two changes matter more than the examples:
- It is binding. As final guidance, it supersedes Section 6 of the 2002 General Principles of Software Validation for production and quality-system software. Part 1's conditional language — that it would supersede that section once finalized — now reads in the present tense.
- It is aligned to the QMSR. The February 2026 reissue updates the guidance for the new quality regulation. The title changed from "Quality System Software" to "Quality Management System Software," and the citations moved from the old Part 820 (including the software-validation requirement at 820.70) to the corresponding subclauses of ISO 13485:2016 — 4.1.6, 7.5.6, and 7.6 — which the QMSR now incorporates by reference. This is an update to terminology and citations, not to the method.
What the guidance actually requires
Reduced to its logic, the guidance runs in four steps: identify the software's intended use, determine the risk it carries, choose assurance activities proportionate to that risk, and keep a record. The point of the risk-based approach is that the effort scales — and at the low end, it can fall away entirely.
First: is the software even in scope?
The threshold question is whether the software is used as part of production or the quality management system at all. Software for general business operations — email, accounting — and infrastructure not specific to production or quality — networking, user authentication, backup and restore — falls outside the validation requirement. Only software used directly in, or in support of, production or the QMS has to be validated under ISO 13485 subclauses 4.1.6, 7.5.6, and 7.6.
Then: how much assurance? Start with process risk.
For in-scope software, the guidance sorts process risk into two buckets: high process risk, where a failure could foreseeably compromise safety, and not high process risk, where it could not. Assurance for high-process-risk software should be commensurate with the resulting medical-device risk — more rigor, more objective evidence. For everything else, assurance is commensurate with the lower process risk.
The guidance gives a pair of ERP examples. A system that automatically orders and delivers production materials is intermediate — not high — process risk when a qualified person checks the materials before they're used: that human step would catch a mix-up before it reached the product. The same automation without the human check is high process risk, because a failure could reach the device.
Same feature, different risk — determined by the controls around it. That is why the guidance pushes you to assess risk at the level of individual features and functions, not whole systems.
Match the testing to the risk
Because assurance scales with risk, so does testing. For high-process-risk software, the guidance points to scripted testing — recorded test cases with the repeatability, traceability, and auditability the risk warrants. For not-high-process-risk software, it explicitly endorses unscripted testing: scenario (ad-hoc) testing, error-guessing, and exploratory testing, with no formal test script required.
This is what changes about handling changes. Validation and revalidation effort are meant to be proportionate to the risk of the change — not fixed at full-scripted for everything. A change to a low-risk feature can be adequately assured by unscripted testing and a short record; a change to a high-risk feature warrants scripted testing and fuller evidence. For in-scope software the question is not whether to validate a change, but how much.
Credit for the controls you already run
The guidance also lets you reduce assurance effort by leaning on controls that already exist:
- Vendor evaluations and purchasing controls — a supplier's software-development practices, ISO certifications, Service Organization Control (SOC) reports, and software bill of materials (SBOM). For lower-risk supporting software, a solid vendor assessment plus installation and configuration may be all the assurance you need.
- Downstream process controls — inspections or reviews that would catch a software failure before it affected the product.
- Continuous monitoring — data the software collects to detect its own issues or anomalies after release.
- Development tooling you already have — bug and anomaly tracking, requirement-traceability tools, and testing done in iterative cycles across the life cycle.
Keep a record — digital by preference
Finally, keep an appropriate record: the intended use, the risk analysis, the assurance activities performed, any issues found and how they were resolved, a conclusion on acceptability, and who did the work and when. The guidance is explicit that this should be no more evidence than necessary for the risk, and that manufacturers should prefer digital records — system logs, audit trails, and other data the software already generates — over screenshots and duplicative paper.
Electronic records and Part 11
One point the final guidance addresses directly, because it has long confused teams, is 21 CFR Part 11. Part 11 governs electronic records and signatures that a predicate rule requires; for production and QMS software, that predicate rule is Part 820. If you keep a Part 820-required record electronically — for example, the documentation demonstrating that a system was validated — Part 11 generally applies to it. Routine logs a system happens to generate, which aren't required as evidence, generally fall outside it.
The clarification worth internalizing: the FDA's long-standing enforcement discretion over Part 11's validation requirement — from the 2003 Part 11 Scope and Application guidance — does not relieve you of the obligation to validate production and QMS software. That obligation comes from Part 820 / ISO 13485 (4.1.6, 7.5.6, 7.6), independently of Part 11. You can't lean on Part 11 discretion to skip validating this software; the requirement is coming from the quality regulation, not from Part 11.
In Part 1 I described CSA as a three-step approach: calculate risk, execute assurance, document. The final guidance makes explicit a step that comes first — identifying the software's intended use — so the framework really runs in four: intended use, risk, assurance, record.
The order matters. Intended use is what determines whether the software is in scope at all, and what its failure would actually affect — every later step depends on getting it right.
Where the FDA is headed
Part 1 floated a hypothesis: that CSA was the first in a series of moves pushing the FDA's software expectations toward a risk-based, least-burdensome approach. The final guidance is consistent with that. It extends the framework beyond conventional software to automation tools and bots, data-analytics tools, AI/ML tools, and cloud computing — defining Infrastructure-, Platform-, and Software-as-a-Service, and working a SaaS product-lifecycle system as a full example.
The treatment of AI/ML is still thin: the guidance says the approach can be applied to these tools, without AI-specific expectations. That is the space to watch. As more production and quality workflows run on models and cloud services, this is where the next round of detail is likely to land.
For teams building or modernizing a quality system now: work from the February 2026 guidance, use the intended-use question to keep out-of-scope software out of scope, match testing rigor to process risk, and capture assurance evidence from the systems you already run.
Where to learn more
- Current guidance: Computer Software Assurance for Production and Quality Management System Software (Feb 3, 2026).
- The final-guidance notice: 90 FR 45945 (Sept 24, 2025).
- The new quality framework: Quality Management System Regulation (QMSR).
- The guidance CSA supersedes in part: General Principles of Software Validation (2002).
Bringing a quality system up to the QMSR?
I help health-tech teams shift quality evidence left into the pipeline, so assurance is a byproduct of building well rather than a tax on it. If risk-based software assurance is on your plate, let's talk.
Get in touch