RegulationsFDA
Computer Software Assurance final guidance, explained for eQMS teams
Computer Software Assurance (CSA) is FDA's risk-based approach to establishing confidence that software used in medical device production or in the quality management system is fit for its intended use. FDA finalized its Computer Software Assurance guidance on September 24, 2025. FDA issued the current version, Computer Software Assurance for Production and Quality Management System Software, on February 3, 2026, retitled and aligned to the Quality Management System Regulation (QMSR). It is written for medical device manufacturers. It supplements FDA's General Principles of Software Validation and supersedes Section 6 of that guidance. Like all FDA guidance, it is nonbinding and describes FDA's current thinking.
Bring one workflow. We'll show you QMSdesk running it. Or download the principle-by-principle checklist, or see how QMSdesk is validated.
9 requirements, each with the QMSdesk control, its evidence and what you still own.
What the Computer Software Assurance final guidance recommends, in four steps
FDA describes Computer Software Assurance as a least-burdensome approach: the validation effort should be no more than the risk requires. At the core of its risk framework are four steps (guidance §V.A.1, §V.A.2, §V.A.4 and §V.A.6). Two further parts cover software changes (§V.A.3) and additional considerations for assurance activities (§V.A.5).
1. Identify the intended use
Look at each feature, function or operation, not just the product as a whole. Software used directly in the quality management system (automating quality processes or maintaining a quality record) and software that supports it (development and test tools, general record-keeping) both need validation. Email, accounting and general infrastructure generally don't. The guidance names IaaS, PaaS and SaaS explicitly, so a cloud eQMS is in scope.
2. Determine the risk-based approach
The question is whether a failure could cause a quality problem that foreseeably compromises safety. If it could, the feature is "high process risk", and assurance scales with the medical device risk. If not, assurance scales with the process risk. FDA's own examples of functions that are generally not high process risk include CAPA routing, automated complaint logging and tracking, automated change control management and automated procedure management. FDA also keeps this analysis separate from ISO 14971 risk analysis of the device itself.
3. Determine the assurance activities
Higher-risk functions may call for more rigor, such as robust or limited scripted testing, or a mix of scripted and unscripted testing. Lower-risk functions can often use unscripted testing: scenario testing (also called ad hoc testing), error guessing and exploratory testing. FDA notes these pairings are not exclusive. You can build on what already exists: the vendor's development and validation work as a starting point, your own process controls, the software's monitoring data, and iterative testing across the life cycle.
4. Establish the appropriate record
FDA recommends a record of the intended use, the result of the risk analysis, a description of the testing, the issues found, a conclusion declaring the software acceptable for its intended use, who tested and when, and review and approval where appropriate. It prefers digital evidence, such as system logs and audit trails, over screenshots and paper.
One point often missed: FDA's Part 11 enforcement discretion on computer system validation does not extend to validating production and quality management system software under ISO 13485. That validation is required.
CSV vs CSA: what actually changes
The obligation is software validation for intended use, and it still stands. Under QMSR, it comes from ISO 13485:2016 subclauses 4.1.6, 7.5.6 and 7.6, incorporated by reference in 21 CFR Part 820. CSA is FDA's recommended way to meet it for production and quality management system software.
What changes is how you size and prove it. Effort follows the risk of each function. Unscripted testing becomes a first-class method for lower-risk functions. Supplier evidence can be your starting point. And the record captures what you tested and why, without duplicating evidence the system already keeps.
eQMS validation under CSA: what you can reuse, and what stays yours
What you can reuse from QMSdesk. QMSdesk's core platform is validated under a QA-approved Validation Summary Report. We'll walk you through the full record under a mutual NDA.
What stays yours. Your intended use, your risk determination, the assurance activities for your configuration, your record and its conclusion. Your system is validated by you, for your intended use. Every engagement includes a written validation scope that sets out what our validation covers and what stays yours.
The CSA principle map
| CSA principle (paraphrased) | How QMSdesk supports it | What you still own |
|---|---|---|
| Validate for intended use (ISO 13485 §4.1.6, §7.5.6, §7.6 via QMSR). FDA recommends looking at each feature, function or operation (guidance §V.A.1) | A signed System Boundary Statement, available at any time, shows which modules you run in QMSdesk. If you run Audits or Suppliers elsewhere, they read "managed outside QMSdesk". Your written validation scope names what our validation covers. | The intended-use statement for each function you use, and the decision that it forms part of your quality management system. |
| Decide whether each function is high process risk (guidance §V.A.2) | Keep your risk determination for each function as a controlled document, with signed review and approval. | Your risk determination, for your processes and your products. FDA's examples are a guide, not your conclusion. |
| Build on the vendor's work (purchasing controls) (guidance §V.A.5) | QMSdesk's core platform is validated under a QA-approved Validation Summary Report. We'll walk you through the full record under a mutual NDA. | Your supplier assessment, your acceptance of our evidence, and the purchasing-control record. |
| Assess the vendor's data-integrity controls (guidance §V.A.5) | Every audit-trail entry is SHA-256 hash-chained, and the database keeps the log insert-only. Daily jobs re-verify every chain and check that every signature still resolves to its record. Signatures require re-authentication and record their meaning. Access is governed by granular permission keys. Records are never hard-deleted, and retention floors run to 7, 10, 15 or 30 years. | Confirming these controls meet your requirements, and running the procedures around them, such as access reviews and periodic audit-trail review. See the Trust Center. |
| Use unscripted testing where it suits the risk (guidance §V.A.4) | Implementation Mode in your real tenant: once implementation testing opens, every module you run works, so your people can run scenario, error-guessing and exploratory tests on their own workflows. The test records are kept as evidence and are left out of your live KPIs by default. | The test objectives, pass/fail criteria and the testing itself. |
| Consider scripted testing for higher-risk functions (guidance §V.A.4) | The same tenant, the same configuration you'll go live on. Go-live readiness checks are drawn from the audit trail, for example a workflow step exercised for each event type you've switched on. | The testing approach for each function you rate high risk (scripted, unscripted or a mix), and approval of the test plan where appropriate. |
| Establish the record, digitally where you can (guidance §V.A.6) | The audit trail records who did what and when. Two separately signed go-live attestations cover technical and quality readiness. Keep your validation plan and summary as controlled documents, with signed review and approval. | The conclusion statement declaring the software acceptable for your intended use, and its approval. |
| Keep the validated state (guidance §V, §V.A.3) | After go-live, a validation-affecting setting can't be written until an approved change control reaches implementation, and the revalidation flag clears only by a recorded decision when that change control closes. Workflows are versioned definitions that administrators can't edit. | Assessing each QMSdesk update, and each of your own changes, against your intended use. For PMA or HDE devices, deciding whether a software change needs a 30-day notice or an annual report. |
| Part 11 generally applies to Part 820 records you keep electronically (guidance §V.B) | Controls for electronic records and signatures, detailed on our 21 CFR Part 11 page. | Your procedures, and the §11.100(c) certification to FDA that the electronic signatures in your system are intended to be the legally binding equivalent of traditional handwritten signatures. |
Akatalyst validation services, and CSA360™
QMSdesk™ is an Akatalyst platform. Akatalyst's Comprehensive Validation Services are built to reduce over-validation and increase defensibility with risk-based execution: computerized system validation and Computer Software Assurance, SaMD and medical-device validation, cloud and infrastructure qualification, and process and equipment lifecycle qualification. The Validation Acceleration Program delivers CSA and CSV execution with reusable evidence patterns. Akatalyst's advisory practice is led by a founder with 25 years in regulated life-sciences quality.
CSA360™ is Akatalyst's risk-based Computer Software Assurance decision engine. It is designed to help regulated organizations right-size validation and document the reasoning behind each decision.
Kept current
What changed recently
September 13, 2022
FDA publishes the draft guidance for comment. Federal Register 2022-19763
September 24, 2025
FDA issues the final guidance, Computer Software Assurance for Production and Quality System Software. Federal Register 2025-18468
February 2, 2026
QMSR takes effect: 21 CFR Part 820 now incorporates ISO 13485:2016 by reference. FDA QMSR
February 3, 2026
FDA issues the current version, retitled Computer Software Assurance for Production and Quality Management System Software, superseding the September 2025 text. Its validation references now point to ISO 13485:2016 subclauses 4.1.6, 7.5.6 and 7.6 in place of the former 21 CFR 820.70(i). FDA guidance page
PDF and Excel
Regulation checklist
The tables from this page, with a column for your own evidence. No form to fill in.
Computer Software Assurance FAQ
Is FDA's Computer Software Assurance guidance final?
Yes. FDA finalized it on September 24, 2025 and issued the current version on February 3, 2026, under the title Computer Software Assurance for Production and Quality Management System Software. Like all FDA guidance, it is nonbinding.
Does CSA replace computer system validation?
No. Validation is still required. CSA is FDA's recommended, risk-based way to do it for production and quality management system software: effort in proportion to risk, unscripted testing where it fits, and records without duplicate evidence.
Does the CSA guidance apply to pharma and biotech?
It is written for medical device manufacturers, by CDRH and CBER in consultation with CDER. Other GxP teams may find its risk-based approach useful, but your own regulators' expectations, such as EU GMP Annex 11, still apply to your systems.
Can we reuse our eQMS vendor's validation?
As your starting point, yes. FDA says you can build on the vendor's development and validation work. It doesn't replace your validation of your intended use and configuration. QMSdesk's core platform is validated under a QA-approved Validation Summary Report. We'll walk you through the full record under a mutual NDA, and your written validation scope shows what remains yours.
Is an eQMS "high process risk" under CSA?
FDA's examples place CAPA routing, automated complaint logging and tracking, automated change control management and automated procedure management among functions that are generally not high process risk. The determination is yours, function by function, for your processes and products.
Reviewed by a practitioner
Abdul Azam, Founder & CEO, 25 years in regulated life-sciences quality. Last reviewed September 26, 2026. Next review December 2026. This guide is general information, not legal or regulatory advice.
Primary sources
- FDA, Computer Software Assurance for Production and Quality Management System Software (February 2026)
- Federal Register, notice of availability of the final guidance (September 24, 2025)
- Federal Register, notice of availability of the draft guidance (September 13, 2022)
- Federal Register, Quality System Regulation Amendments final rule (February 2, 2024)
Bring one workflow. We'll show you QMSdesk running it.
Bring the function you're least sure how to rate. We'll show you QMSdesk running it, and walk you through our validation record under a mutual NDA.
Bring one workflow. We'll show you QMSdesk running it. Or download the principle-by-principle checklist, or see how QMSdesk is validated.