Medical Device Software Verification vs Validation: FDA and IEC 62304 Requirements
Software verification vs validation for medical devices — FDA expectations, IEC 62304 activities, documentation, traceability, and the design control process.
The Core Distinction
Software verification and software validation are the two most commonly confused activities in medical device software development. The distinction matters because they serve different purposes, are evaluated by different criteria, and produce different evidence.
Software verification asks: Did we build the software correctly? It confirms that each software requirement has been implemented as specified.
Software validation asks: Did we build the right software? It confirms that the software, in the context of the complete device, meets the user's needs and intended uses.
This is not an academic distinction. FDA investigators and EU Notified Body auditors evaluate both separately. A device can pass verification (every requirement is correctly implemented) and fail validation (the requirements themselves were wrong or incomplete). Conversely, a device might satisfy user needs in practice but lack the documented verification evidence that regulators require.
How FDA Defines Verification and Validation
The FDA's definitions come from 21 CFR 820 (now aligned with ISO 13485:2016 under the Quality Management System Regulation, effective February 2, 2026) and the FDA's General Principles of Software Validation guidance (2002, still active as of 2026):
Design verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled (21 CFR 820.3(z) / ISO 13485:2016 §3.8.12).
Design validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled (21 CFR 820.3(y) / ISO 13485:2016 §3.8.13).
The critical differences:
| Dimension | Verification | Validation |
|---|---|---|
| Question answered | "Does the output meet the input?" | "Does the device meet the user's needs?" |
| Scope | Each requirement individually | The complete device (including software) in its intended use environment |
| Timing | Throughout development, at each phase transition | After integration, before release |
| Environment | Test environment, unit/integration/system levels | Realistic or simulated use environment |
| Evidence produced | Test reports, analysis records, review records | Validation protocols, test reports, usability data |
| Responsibility | Software development team | Cross-functional (RA, QA, clinical, software) |
How IEC 62304 Handles Verification and Validation
IEC 62304 (Medical device software — Software life cycle processes) is the international standard for medical device software development. It is referenced by both FDA (through recognized consensus standards) and EU MDR (through harmonized standards).
What IEC 62304 Covers
IEC 62304 addresses software verification explicitly through its life cycle processes. The standard defines verification activities at multiple levels:
| IEC 62304 Activity | Section | What It Confirms |
|---|---|---|
| Software requirements verification | 5.7.1 | Software requirements are traceable to system-level requirements and testable |
| Software architectural design verification | 5.7.2 | Architecture implements all software requirements; risk control measures are correctly allocated |
| Software unit verification | 5.7.3 | Each software unit meets its detailed design specifications |
| Software integration verification | 5.7.4 | Integrated software items function correctly together |
| Software system testing | 5.7.5 | The complete software system meets all software requirements |
| Software release | 5.7.6 | All verification activities are complete, documented, and acceptable |
What IEC 62304 Does NOT Cover
IEC 62304 explicitly states in Section 1.2 that the standard "does not cover validation of the medical device, even when the medical device consists entirely of software." Validation of the complete device — including whether the software satisfies user needs in the intended use environment — is outside the scope of IEC 62304.
This is a critical point that many teams misunderstand. IEC 62304 gives you the verification framework. Device-level validation, which includes software validation, falls under your overall design control process (21 CFR 820 / ISO 13485 design validation requirements).
IEC 62304 Edition 2 (Expected 2026)
The second edition of IEC 62304, expected to be published in mid-to-late 2026, proposes several changes:
- Two process rigor levels instead of three safety classes. Level I replaces Class A, and Level II replaces both Class B and Class C. Software that implements a risk control measure would be assigned Level II regardless of external controls.
- Expanded scope from "medical device software" to "health software"
- Enhanced guidance on AI/ML components within medical device software
- Updated cybersecurity expectations aligned with IEC 81001-5-1
The verification and validation framework described above remains conceptually the same, though the specific documentation requirements may change with the new edition.
The Verification Activities in Detail
Software Unit Verification
At the most granular level, each software unit (a discrete, testable piece of code) is verified against its detailed design. This typically involves:
- Unit testing. Writing and executing tests that verify each unit produces the correct output for a defined set of inputs, including boundary conditions and error cases.
- Code reviews. Peer review of source code against coding standards and detailed design specifications.
- Static analysis. Automated tools that check code for defects, security vulnerabilities, and compliance with coding standards (e.g., MISRA C for embedded systems).
Documentation: Unit test protocols, unit test reports, code review records, static analysis reports. For Class B and C software (or Level II under Edition 2), objective evidence of unit verification is required.
Software Integration Verification
After individual units are verified, they are integrated and tested as a complete software system. Integration verification confirms that:
- Software units interact correctly through their defined interfaces
- Data flows correctly between modules
- Shared resources (memory, interrupts, communication buses) are managed properly
- Risk control measures implemented in software function as designed in the integrated system
Documentation: Integration test protocols, integration test reports, integration sequence documentation.
Software System Testing
The complete software system is tested against the full set of software requirements. This is the final verification step before the software is handed off for device-level validation. System testing confirms:
- Every software requirement has at least one test case that verifies it
- All test cases pass or have documented justifications for acceptable deviations
- Risk control measures are verified in the context of the complete software system
- Performance requirements (timing, throughput, memory usage) are met
- Error handling and failure modes behave as designed
Documentation: Software system test protocol, test case matrix (tracing each requirement to one or more test cases), test results, deviation reports if applicable.
The Validation Activities in Detail
Software validation is not a separate activity from device validation — it is part of it. When the FDA says "software validation," it means demonstrating that the device (including its software) meets user needs and intended uses in the actual or simulated use environment.
Design Validation with Software
Design validation for a software-containing device includes:
- Functional testing in the intended use environment. Does the device perform its intended functions when operated by intended users in realistic conditions? This may include bench testing, simulated use testing, or clinical evaluation.
- Usability / human factors testing. Can intended users operate the device safely and effectively? IEC 62366-1 (usability engineering) applies here. If the device has a user interface (GUI, physical controls, alarms), usability testing validates that the interface supports safe use.
- Clinical evaluation. For devices requiring clinical evidence (most Class II and all Class III devices), the software's contribution to the clinical performance and safety of the device is evaluated as part of the clinical data.
- System-level integration testing. Confirming that software, hardware, and any other device components work correctly together as a complete system. This bridges the gap between software verification (software-only testing) and device validation (whole-device testing).
Key Principle: Validation Requires the Complete Device
IEC 62304 makes clear that you cannot fully validate software in isolation. Validation requires the software to be integrated into the device (or a representative test environment) and tested against user needs and intended uses, not just software requirements.
For Software as a Medical Device (SaMD) — standalone software that is itself a medical device — the "device" is the software plus its operating environment (target platform, network connectivity, user interface). Validation still requires testing the complete system in realistic conditions.
The Traceability Chain
The relationship between verification and validation is best understood through the traceability chain from user needs to verification evidence:
User Needs → Design Inputs → Software Requirements → Detailed Design → Code
↑ ↓
Validation ← System Validation ← System Testing ← Integration ← Unit Testing
(Verification)
- User needs describe what the device must do for the patient, clinician, or other intended user.
- Design inputs translate user needs into engineering requirements for the device.
- Software requirements are the subset of design inputs that will be implemented in software.
- Verification confirms that each level of implementation correctly meets the requirements from the level above.
- Validation confirms that the complete device (with verified software) actually fulfills the original user needs.
A break anywhere in this chain — user needs that are not translated into requirements, requirements that are not verified, or verified software that does not meet user needs in practice — represents a compliance gap.
Documentation Requirements
Verification Documentation (IEC 62304)
| Document | When Required | What It Contains |
|---|---|---|
| Software verification plan | Before verification activities begin | Scope, methods (testing, analysis, review), acceptance criteria, environment |
| Unit test protocols and reports | During implementation | Test cases, expected results, actual results, pass/fail determination |
| Integration test protocols and reports | After unit verification | Integration sequence, interface tests, results |
| System test protocols and reports | After integration | Complete requirements-based test suite, results |
| Traceability matrix | Maintained throughout | Mapping from each software requirement to its verification evidence |
| Verification summary report | After all verification complete | Summary of all verification activities, results, open issues |
Validation Documentation (21 CFR 820 / ISO 13485)
| Document | When Required | What It Contains |
|---|---|---|
| Design validation plan | Before validation begins | User needs being validated, methods, acceptance criteria, use environment |
| Validation protocols | For each validation activity | Detailed test procedure, intended users, use scenarios, pass/fail criteria |
| Validation reports | After each validation activity | Results, deviations, conclusions, signed approvals |
| Clinical evaluation data | For devices requiring clinical evidence | Clinical investigation reports, literature review, clinical experience data |
| Usability test report | For devices with user interfaces | Use error analysis, task performance, user feedback |
Common Mistakes
1. Confusing Verification with Validation
The most common audit finding. If your "validation" testing only checks whether the software meets its requirements (not whether the device meets user needs), you have done verification, not validation. FDA Warning Letters frequently cite companies for "design validation" that was actually design verification.
2. Incomplete Traceability
If a software requirement has no verification test case, or a user need has no validation evidence, there is a gap. Auditors follow the traceability chain. If it breaks, you will receive a finding.
3. Validating in the Wrong Environment
Software validation must be performed on the device in its intended use configuration. Testing software on a development workstation with debug tools attached is verification, not validation. The test environment must represent the actual deployment environment.
4. Skipping Software Unit Verification
For Class C software (or Level II under Edition 2), unit verification is mandatory. Some teams skip it and rely on system testing alone. This is noncompliant with IEC 62304 Section 5.7.3 and will be flagged by auditors.
5. Treating SaMD Validation Differently
Standalone software (SaMD) still requires device-level validation. The fact that there is no hardware does not eliminate the validation requirement. The "device" is the software in its operating environment, and validation must demonstrate it meets user needs in realistic conditions.
6. Not Re-validating After Changes
Any software change — bug fix, feature addition, cybersecurity patch, or library update — requires a determination of whether re-verification and/or re-validation is needed. This is assessed through your change control process. Failing to re-validate after a change that affects user-facing functionality is a common audit finding.
How Verification and Validation Fit into the Regulatory Submission
For FDA 510(k) Submissions
- Software verification evidence is summarized in the Software Documentation section of the 510(k). The level of detail depends on the software's safety classification (A, B, or C / Level I or II).
- Software validation evidence is typically described in the Design Validation section. For 510(k)s, you do not submit the full validation reports — you describe the validation activities, methods, and conclusions.
- Cybersecurity documentation (SBOM, vulnerability assessment, cybersecurity risk analysis) is now expected as part of the submission for devices with cybersecurity considerations.
For EU MDR CE Marking
- IEC 62304 compliance is assessed by your Notified Body as part of the technical file review. They will expect to see the complete verification documentation package.
- Design validation is assessed through your clinical evaluation, which must demonstrate that the device (including its software) performs as intended and is safe for its intended purpose.
- Usability validation per IEC 62366-1 is expected for all devices with user interfaces.
For PMA Submissions
- FDA expects more detailed verification and validation documentation for PMA devices. The software section of a PMA application typically includes full verification test protocols and reports, not just summaries.
- Validation data from clinical investigations is required for most PMA devices and must demonstrate clinical safety and effectiveness.
Verification and Validation After the QMSR Transition
The Quality Management System Regulation (QMSR), effective February 2, 2026, aligned FDA device quality requirements with ISO 13485:2016. This affects how verification and validation are managed:
- ISO 13485 §7.3.6 (Design and development verification) and §7.3.7 (Design and development validation) now define the FDA's expectations through the incorporation by reference.
- ISO 13485 §4.1.6 requires organizations to "monitor, measure, analyze, and evaluate" their quality management system, which includes verification and validation processes.
- The FDA's new inspection process under Compliance Program 7382.850 (replacing QSIT) evaluates verification and validation as part of the design control assessment.
The underlying activities have not changed. You still need to verify that your software meets its requirements and validate that the device meets user needs. The QMSR transition means that ISO 13485 terminology and structure now apply directly in FDA-regulated environments.
Practical Framework: Verification and Validation Checklist
Use this checklist to confirm your software V&V activities are complete before submission.
Verification Completeness
- Every software requirement has at least one verification test case
- Unit tests cover all Level II (Class B/C) software units
- Integration tests cover all software interfaces and data flows
- System tests cover all functional, performance, and safety requirements
- Risk control measures implemented in software are verified
- All verification test results are documented (pass/fail, actual vs. expected)
- Deviations are documented, investigated, and resolved
- Traceability matrix is complete from software requirements to test evidence
Validation Completeness
- User needs are documented and traceable to design inputs
- Design inputs are traceable to software requirements
- Validation protocols test the device (not just the software) against user needs
- Validation is performed in the intended use environment (or realistic simulation)
- Intended users participate in usability validation
- Clinical evaluation addresses the software's contribution to device safety and performance
- All validation results are documented with signed approvals
- Changes made during validation are documented and re-verified/re-validated as needed
Frequently Asked Questions
Is software validation the same as design validation?
Software validation is a subset of design validation. Design validation confirms that the entire device (hardware, software, accessories, packaging, labeling) meets user needs. Software validation specifically addresses the software's contribution to meeting those needs. In practice, you validate the complete device, which includes confirming that the software functions correctly in the context of the whole product.
Does IEC 62304 cover software validation?
No. IEC 62304 Section 1.2 explicitly states that the standard does not cover validation of the medical device. IEC 62304 covers software verification (requirements, architecture, unit, integration, and system testing). Validation is handled under your overall design control process per 21 CFR 820 / ISO 13485.
What level of verification is required for each safety class?
Under IEC 62304 Edition 1: Class A requires minimal verification documentation. Class B requires documented verification activities with objective evidence. Class C requires comprehensive verification with detailed test records, code reviews, and static analysis. Under the proposed Edition 2, Level II (replacing Class B and C) requires the full suite of verification activities.
Do I need to validate software that is already verified?
Yes. Verification confirms that the software meets its requirements. Validation confirms that the device (with the software) meets user needs. A device can be 100% verified and still fail validation if the requirements were incomplete, incorrect, or did not adequately capture user needs.
How do verification and validation apply to SaMD?
SaMD (Software as a Medical Device) requires the same verification and validation framework. Verification follows IEC 62304. Validation confirms that the standalone software meets its intended clinical purpose in its operating environment. Since SaMD has no hardware, the "device" for validation purposes is the software plus its target computing platform and network environment.
What happens if we find bugs during validation?
Bugs found during validation should be handled through your defect management process. After the bug is fixed, you must determine whether re-verification, re-validation, or both are needed based on the nature and impact of the change. Document this assessment. The validation protocol should specify how defects discovered during validation are managed.