Computer Software Assurance: What Changed in the 2026 CSA Guidance

Most validation teams read the September 2025 guidance, updated their SOPs, and moved on. Then FDA replaced it four months later.

On 3 February 2026, FDA issued a revised computer software assurance guidance. It superseded the September version and aligned the whole document with the QMSR, which had taken effect the day before.

This is not a cosmetic revision. Cloud models are now defined. AI and machine learning tools are named in scope. The assurance record has become more prescriptive. Below is what changed, and what to do about it.

Why the Guidance Was Updated at All

The timing explains everything, and it has little to do with computer software assurance itself. On 2 February 2026, the QMSR took effect and removed most of 21 CFR Part 820, including section 820.70, which was the clause the old guidance pointed at for software validation.

So the September guidance was citing a rule that no longer existed. FDA reissued it the next day under Level 2 procedures to point at ISO 13485 instead. You can read the current version on the FDA guidance page, and we covered the wider rule change in our post on QMSR compliance and what inspectors check first.

The title changed too. It is now Computer Software Assurance for Production and Quality Management System Software, picking up the QMSR wording.

What Computer Software Assurance Actually Is

CSA is a risk-based approach for establishing confidence that software is fit for its intended use. Rather than testing every function equally, you concentrate effort where failure could hurt someone.

FDA describes it as a least-burdensome approach, where the burden of validation is no more than necessary to address the risk. Importantly, CSA now supersedes Section 6 of the General Principles of Software Validation, so it is the controlling reference for this software.

Change 1: Cloud and SaaS Are Now Formally Defined

This is the change most computer software assurance programmes will feel first. The guidance now includes definitions of cloud computing, IaaS, PaaS and SaaS, drawn from the NIST cloud model.

More useful is the nuance FDA adds. Whether a cloud system needs validation depends on what it holds, not on what it is called.

• IaaS cloud storage that holds quality records is considered used directly as part of the quality management system. So assurance should focus on the features affecting record integrity and Part 11.
• The same storage holding production data that is not a quality record falls outside those validation requirements. You decide the appropriate level of rigour for your own business needs.

FDA also added a fourth worked example: a SaaS Product Life Cycle Management system. It walks through vendor assessment, service agreements covering security, data integrity, privacy, availability, change management and business continuity, and how to handle automatic vendor updates.

That last part matters. SaaS vendors push changes on their schedule, not yours. The example expects the vendor to supply documentation of changes and testing, and expects you to assess the impact and test proportionately.

Change 2: AI, ML and Automation Tools Are Named

The guidance now states that the risk framework can be applied to automation tools such as BOTS and automated workflows, data analytic tools, artificial intelligence and machine learning tools, and cloud computing, when used as part of production or the quality management system.

Previously teams argued about whether an AI-assisted deviation triage tool was in scope. That argument is settled. If it touches production or the QMS, the framework applies.

However, the guidance does not create a separate AI validation regime. You apply the same intended use and risk logic. For the European parallel, see our guide to EU GMP Annex 22 and the coming AI rules.

Change 3: The Risk Question Is Sharper

The heart of computer software assurance is one question, and the 2026 version states it more crisply.

A feature is high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety. If so, your assurance effort should match the medical device risk.

If failure would not foreseeably compromise safety, it is not high process risk, and effort should match the process risk instead. FDA presents this as binary, though it explicitly allows you to grade risk as moderate or low internally.

What sits outside the scope

The guidance is unusually clear here. Software for general business processes, such as email or accounting, is out. So is infrastructure not specific to production or the QMS, such as networking, user authentication, and backup and restore.

Many organisations have been validating these systems out of caution. That effort can be redirected.

Change 4: The Assurance Record Is More Prescriptive

The draft left latitude on what a record should contain. The current guidance lists it. FDA recommends the record include:

1. The intended use of the software feature, function or operation.
2. The result of the risk-based analysis.
3. A description of the testing conducted.
4. Issues found during testing, including deviations, defects and failures.
5. A conclusion statement declaring acceptability for the intended use, with resolution of any issues.
6. A record of who performed the testing and when, plus review and approval where appropriate.

There is also a clear steer on format. FDA recommends using digital records such as system logs and audit trails, rather than paper documentation, screenshots, or duplicating results the software already retains.

Change 5: Part 11 Gets Its Own Section

A new section addresses electronic records. It clarifies that Part 11 generally applies when you keep, in electronic form, a document required under Part 820.

The practical test FDA offers: consider whether the record would be necessary as evidence to document required validation. Documentation showing an enterprise system reliably checks materials before use would qualify. Routine COTS activity logs that are not needed as evidence would not.

CSA vs CSV: What Actually Differs

The shift is not about doing less. It is about moving effort from low-risk documentation to high-risk testing. Our approach to risk-based CSV and CSA follows that same logic.

The Real Problems Validation Teams Are Facing

These are the computer software assurance gaps we see repeatedly. Some will look familiar.

Is Anyone Handling This Well?

Yes. The teams doing best share a few habits.

• They re-based their framework on ISO 13485 subclauses. A one-page mapping saves a lot of awkward inspection conversations.
• They built a single cloud and software inventory, jointly owned by quality and IT, with the record question answered per system.
• They renegotiated SaaS agreements to include change notification, evidence of vendor testing, and data integrity commitments.
• They practise unscripted testing properly. Exploratory and error-guessing testing need skill and a documented objective, not an absence of preparation.

How RxCloud approaches this

We work at the intersection of validation, quality and technology, so this update landed in live projects rather than in theory.

• Risk-based CSV and CSA. We concentrate effort on the features that genuinely affect data integrity and patient safety, and we document the reasoning. More on our Computer System Validation services.
• Test automation inside validated platforms. Automated scripts produce exactly the digital evidence FDA now prefers, and they make revalidation after a SaaS update far less painful. See our test automation services.
• Audit-informed remediation. With over 500 GxP audits completed across 27+ countries, we know which validation gaps inspectors actually pursue.

We would rather understate this than oversell it. CSA works when the risk reasoning is sound and written down. Without that, a lighter approach simply looks like less evidence.

Five Actions for Your Validation Team

1. Re-map your framework to ISO 13485. Replace references to 21 CFR 820.70 with subclauses 4.1.6, 7.5.6 and 7.6, and keep the mapping document.
2. Build one cloud and software inventory. For each entry, record the service model and whether it holds a quality record. That single column drives everything else.
3. Bring AI, ML, bots and analytics into scope. Assess each against intended use and process risk, exactly as you would any other tool.
4. Rebuild vendor assessment. Use SOC reports, ISO certifications, SBOM, cybersecurity documentation and data integrity controls. Where an onsite audit is not feasible, FDA accepts a documented combination of alternatives.
5. Rewrite the assurance record template around the six elements above, and switch from screenshots to system-generated evidence.

Frequently Asked Questions

The Bottom Line

The 2026 computer software assurance update is FDA’s clearest statement yet that documentation-heavy validation is finished. Effort should follow risk, vendor work should be leveraged rather than repeated, and evidence should come from the system rather than a printer.

However, a lighter approach only holds up when the reasoning behind it is written down. Risk justification is now the load-bearing part of the file.

If your validation framework still points at 21 CFR 820.70, start there. Then build the cloud inventory. Those two steps close most of the gap.