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. 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 the wider rule change on the QMSR overview.
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.
One point often missed: CSA does not cover software that is itself a medical device. Software in a Medical Device and Software as a Medical Device follow separate design validation rules.
Change 1: Cloud and SaaS Are Now Formally Defined
This is the change most teams 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.
· An IaaS cloud storage solution that stores 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 IaaS 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 EU angle on AI in GMP, our post on EU GMP Annex 22 covers the parallel developments in Europe.
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.
For anyone still printing screenshots into a validation binder, that sentence is the whole point of the guidance.
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.
There is a trap here worth flagging. The long-standing Part 11 enforcement discretion for validation of computerised systems does not apply to validation required under ISO 13485 subclauses 4.1.6, 7.5.6 and 7.6. Teams that leaned on that discretion should re-check their position.
CSA vs CSV: What Actually Differs
| Aspect | Traditional CSV | Computer Software Assurance |
| Starting point | The system | The intended use of each feature |
| Testing effort | Broadly equal across functions | Scaled to process and device risk |
| Preferred method | Scripted testing throughout | Unscripted testing where risk allows |
| Unscripted options | Rarely accepted | Scenario, error guessing, exploratory |
| Vendor work | Often repeated in-house | Leveraged as a starting point |
| Evidence | Paper, screenshots, binders | Digital records, logs, audit trails |
| Volume of evidence | More is safer | No more than the risk requires |
| Cloud and SaaS | Ambiguous | Defined, with a worked example |
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 gaps we see repeatedly. Some will look familiar.
Problem 1: SOPs still cite 820.70
It is a small thing that reads badly in an inspection. If your validation procedures reference a clause that was withdrawn in February, the document has not been reviewed since the change.
Problem 2: Nobody owns the cloud inventory
Quality knows the eQMS. IT knows the infrastructure. Very few organisations hold one list showing every cloud system, its service model, and whether it stores a quality record. Without that list, you cannot apply the guidance.
Problem 3: SaaS updates arrive unannounced
Vendors push releases continuously. If your change control assumes you schedule upgrades, it does not match reality. The guidance expects a service agreement that obliges the vendor to document changes, and a process for you to assess them.
Problem 4: AI tools crept in without assurance
Analytics dashboards, automated triage, workflow bots. Many were adopted as productivity tools and never entered the validation inventory. They are now explicitly in scope.
Problem 5: CSA became a label, not a method
Some teams renamed the validation SOP and carried on scripting everything. Others swung too far and dropped rigour on genuinely high-risk functions. Both misread the guidance.
Problem 6: The record is still paper-shaped
Screenshots pasted into Word, printed, signed and filed. FDA has now said plainly that it prefers the system’s own digital evidence.
Is Anyone Handling This Well?
Yes. The teams doing best share a few habits.
· They rebased 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.
· Audit-informed remediation. With over 1500 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
7. 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.
8. 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.
9. Bring AI, ML, bots and analytics into scope. Assess each against intended use and process risk, exactly as you would any other tool.
10. 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.
11. Rewrite the assurance record template around the six elements above, and switch from screenshots to system-generated evidence.
Frequently Asked Questions
What is computer software assurance?
Computer software assurance is FDA’s risk-based approach to establishing confidence that software used in production or the quality management system is fit for its intended use. Instead of testing every function equally, you scale assurance effort to the risk that a failure could compromise product quality or patient safety.
What changed in the February 2026 CSA guidance?
The 3 February 2026 version superseded the September 2025 final guidance and aligned it with the QMSR. It re-points validation at ISO 13485 subclauses rather than the withdrawn 21 CFR 820.70, adds formal definitions for cloud, SaaS, PaaS and IaaS, names AI and machine learning tools in scope, adds a SaaS PLM worked example, and lists the elements of an assurance record.
Is CSA mandatory, or is it just guidance?
The guidance itself is non-binding and describes FDA’s current thinking. However, the underlying validation requirement is not optional. CSA is now the controlling reference for production and quality system software, because it supersedes Section 6 of the General Principles of Software Validation.
How is CSA different from CSV?
Traditional CSV applied similar rigour across a system and leaned on scripted testing and paper evidence. CSA starts from the intended use of each feature, scales testing to risk, accepts unscripted methods such as exploratory and error-guessing testing where risk allows, leverages vendor work, and prefers digital records over screenshots.
Does CSA apply to cloud and SaaS systems?
Yes. The 2026 guidance defines cloud service models and treats them within scope when used as part of production or the quality management system. The deciding factor is intended use. Cloud storage holding quality records is treated as used directly in the QMS, while storage holding non-record production data may fall outside the validation requirement.
What must an assurance record contain?
FDA recommends six elements: the intended use, the result of the risk-based analysis, a description of the testing performed, any issues found, a conclusion declaring acceptability for the intended use, and a record of who tested and when, with review and approval where appropriate.