FDA's General Principles of Software Validation (GPSV) dates from January 2002 and is still the reference for validating software that is a medical device or part of one. On 3 February 2026, the day after the QMSR took effect, FDA issued a new version of Computer Software Assurance for Production and Quality Management System Software (CSA). It supersedes the CSA version of 24 September 2025.
"FDA software validation guidance" is therefore not one document. Which one applies depends on what the software does. This article maps the documents, their status, the ISO 13485 clauses behind them, and what each means for device software and for quality system tools.
Which guidance covers which software
| Guidance | Covers | Status |
|---|---|---|
| General Principles of Software Validation (GPSV) | Software that is a device or part of one, and software used to design, develop or manufacture devices | Final, January 2002. Section 6 (automated process equipment and quality system software) is superseded by CSA |
| Computer Software Assurance (CSA) | Computers and automated data processing systems used in production or the quality management system | Final, February 2026; supersedes the September 2025 version |
| Content of Premarket Submissions for Device Software Functions | What to include in premarket submissions for device software functions | Final, June 2023; replaces the May 2005 guidance |
Source: FDA guidance pages.
None of these is a regulation. The binding requirements are in 21 CFR Part 820, the QMSR, which incorporates ISO 13485:2016 by reference. Guidance explains how FDA currently reads those requirements, and a different, justified approach can satisfy them.
Before any of this, decide whether the software is a medical device at all. Our article on software as a medical device covers that question.
Device software: GPSV and design and development
GPSV defines software validation as confirmation, by examination and objective evidence, that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled. Verification checks that each development stage meets its inputs; validation checks the finished software in its actual or simulated use environment.
Under the QMSR, design and development requirements come from ISO 13485 clause 7.3. According to 21 CFR 820.10(c), they apply to Class II and Class III devices and to Class I devices automated with computer software. Clause 7.3.7 covers design and development validation, including completion before release. Our article on 21 CFR Part 820 explains how the QMSR works.
In our view, a device software validation file needs at least four records:
the intended use, tied to the claims made for the device;
a traceability matrix from user needs through requirements to tests;
a validation protocol, approved before execution;
a validation report showing what passed, what failed and what changed.
Every software change needs reverification and revalidation in proportion to risk. Our articles on IEC 62304 and software recalls cover change control and its consequences.
Premarket documentation levels
The June 2023 premarket guidance sets two documentation levels:
| Level | When it applies |
|---|---|
| Basic | Device software functions where Enhanced does not apply |
| Enhanced | Where a failure or flaw of the device software function could present a hazardous situation with a probable risk of death or serious injury, assessed before risk controls are applied |
Source: FDA, Content of Premarket Submissions for Device Software Functions, June 2023.
The sponsor decides which level applies and documents why. A Pre-Submission can confirm the choice with FDA. The guidance also allows a Declaration of Conformity to the FDA-recognised version of IEC 62304 in place of some software lifecycle documentation. Our article on 510(k) vs PMA covers the submissions themselves.
Quality system tools: CSA
CSA applies to computers and automated data processing systems used as part of production or the quality management system, including cloud services (SaaS, PaaS and IaaS). It does not cover device software functions. The legal basis is ISO 13485 subclauses 4.1.6 (quality management system software), 7.5.6 (production process validation) and 7.6 (monitoring and measuring equipment).
CSA distinguishes:
| Category | Examples | Validation |
|---|---|---|
| Used directly in production or the QMS | eQMS modules for complaints, CAPA and document control; software controlling production equipment | Required; depth follows process risk |
| Used to support production or the QMS | Tools that support, but do not perform, production or quality activities | Required, often with less effort |
| Not specific to production or the QMS | Email, accounting, general infrastructure | Validation requirements of 4.1.6, 7.5.6 and 7.6 do not apply |
Source: FDA, CSA guidance, February 2026.
Software outside CSA is not unregulated. Quality records that pass through it are still subject to record control. Our article on 21 CFR Part 11 covers electronic records and signatures.
How much assurance a quality tool needs
CSA ties the effort to process risk. FDA considers a feature, function or operation to be high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety. For simplicity, the guidance treats process risk as binary: high or not high.
Process risk is not the same as device risk under ISO 14971. A complaints module can carry high process risk even when the device it supports is low risk.
Assurance activities range from scripted testing, where each step is written in advance, to unscripted testing such as scenario-based, error-guessing and exploratory testing. Scripted testing fits high process risk functions; unscripted testing is often enough for the rest. The CSA guidance includes worked examples, including a SaaS product lifecycle management system.
In our view, the validation record for each tool should show its intended use, the process risk decision for each function, the assurance activities chosen and why, and the results. Without the reasoning, the testing cannot be judged.
A hypothetical example
Hypothetical example: a Dutch manufacturer prepares a 510(k) for image-analysis software and runs complaints and CAPA in a cloud eQMS.
Device software: GPSV supplies the validation approach, clause 7.3.7 the requirement through 21 CFR 820.10(c), and the premarket guidance the documentation level. The manufacturer chooses Basic or Enhanced, records why, and confirms it in a Pre-Submission.
eQMS: complaint and CAPA records are direct quality records, so the tool falls under CSA. The manufacturer assesses process risk per function and chooses scripted or unscripted testing accordingly.
Two evidence sets: the device software validation sits in the design and development file; the eQMS validation sits in the quality system records. They follow different guidance and different clauses.
Conclusion
Device software follows GPSV and the premarket guidance; production and quality system tools follow CSA. The binding requirements sit in the QMSR and the ISO 13485 clauses it incorporates.
In our view, start with an inventory: each system, its function, whether it is used directly, in support or not at all for production and quality, and the guidance that applies. Check the FDA guidance pages before each validation cycle, as CSA was reissued within five months of its first final version.
If you need help with software validation planning, our software lifecycle management team can help, or contact MedQAIR.
Frequently asked questions
Is General Principles of Software Validation still valid?
Yes, except Section 6, which CSA supersedes for production and quality system software.
Is FDA guidance legally binding?
No. The binding requirements are in 21 CFR Part 820 and the ISO 13485 clauses it incorporates. A justified alternative approach can satisfy them.
Does CSA apply to software as a medical device?
No. CSA covers software used in production or the quality management system. Device software functions follow GPSV and the premarket guidance.
Who decides between Basic and Enhanced documentation?
The sponsor, using the criteria in the June 2023 premarket guidance. A Pre-Submission can confirm the choice.
Does an eQMS need validating?
Yes, where it is used directly for quality records such as complaints and CAPA. The depth of assurance follows process risk.
Which ISO 13485 clauses require software validation?
Clause 7.3.7 for device software, and subclauses 4.1.6, 7.5.6 and 7.6 for quality system, production and monitoring software.
