Verification and Validation for Medical Devices: What the Difference Means for Your 510(k)

Verification and validation (V&V) are the two most important words in the medical device 510(k) process, and the most commonly confused. The distinction is not semantic. A company that generates extensive bench test data without conducting any user testing has done verification. It has not done validation. FDA will ask for the validation data, and the company will face a delay.

This article explains what each requires, how they differ, where they overlap, and what FDA expects to see in a 510(k) submission.

The Regulatory Foundation

Both verification and validation are required under the QMSR (21 CFR Part 820), whose compliance date was February 2, 2026, and which incorporates ISO 13485:2016 by reference. The specific requirements are:

• ISO 13485:2016 Clause 7.3.6 (design and development verification), made applicable by 21 CFR 820.10(c)
• ISO 13485:2016 Clause 7.3.7 (design and development validation), made applicable by 21 CFR 820.10(c)

FDA's plain-language guidance on design controls, including V&V, is "Design Control Guidance for Medical Device Manufacturers" (1997, https://www.fda.gov/media/116573/download). It remains a useful reference for understanding how FDA expects each concept to work in practice, and the current governing requirements are the ISO 13485 clauses above (see the eCFR canonical text at https://www.ecfr.gov/current/title-21/part-820).

What Is Design Verification?

Design verification is confirmation that design outputs meet design inputs. Under ISO 13485 Clause 7.3.6, the manufacturer must verify the device design and confirm that design output meets design input requirements.

In plain terms: your design inputs are the requirements your device must meet (performance specifications, dimensional specifications, electrical specifications, biocompatibility requirements, sterility requirements, and so on). Your design outputs are the specifications, drawings, and documents produced during design. Verification testing confirms that the device, as built, actually meets those specifications.

Verification testing is typically objective: the device either meets the specification or it does not. Common verification activities include:

• Dimensional inspection (does the device meet its dimensional specifications?)
• Electrical safety testing (does it meet the electrical safety requirements in applicable standards, such as IEC 60601-1 for electrical medical equipment?)
• Mechanical testing (tensile strength, fatigue, pressure testing, depending on the device)
• Biocompatibility evaluation (is the device biologically safe for its intended tissue-contact type and duration, evaluated per the ISO 10993 series and FDA's biocompatibility guidance? This is a risk-based evaluation that may combine chemical characterization, literature, and testing, not testing alone.)
• Sterility and sterilization validation (does the sterilized device meet sterility specifications, using a validated sterilization process?)
• Electromagnetic compatibility (EMC) testing (does the device meet EMC standards, typically IEC 60601-1-2, for its use environment?)
• Software verification (for devices with software, does the software perform all specified functions correctly?)

All verification testing must be documented: what was tested, who tested it, what method was used, what the acceptance criteria were, and what the results were.

What Is Design Validation?

Design validation is confirmation that the device conforms to the needs of the user and intended use. Under ISO 13485 Clause 7.3.7, the manufacturer must validate the device design. Design and development validation must be performed on the product as it will be produced, using representative production units, under defined operating conditions.

Validation asks a different question than verification. Verification asks: does this device meet its specifications? Validation asks: does this device actually solve the problem it was designed to solve, for the actual users who will use it, in the actual conditions where it will be used?

Validation cannot be done in a vacuum. It requires:

• Representative production units. Validation must be done on units representative of the actual production device, not early prototypes made by a different process.
• Actual or simulated use conditions. Testing must reflect the real use environment or a credible simulation of it.
• Connection to user needs. The validation must trace back to the user needs identified at the beginning of the design process.

Validation activities include:

• Clinical evaluation. For many devices, some form of clinical evidence (bench testing, animal studies, clinical data, or a combination) that demonstrates the device performs its intended clinical function.
• Usability/human factors validation. Confirmation that the intended users can safely and effectively use the device. This is the summative evaluation described in FDA's human factors guidance. See the related article on human factors engineering for more detail.
• Software validation. For devices containing software, validation that the software performs correctly under the full range of expected conditions, including failure conditions and abnormal inputs.
• Simulated use testing. For devices where patient clinical testing would be premature or impractical, testing under simulated conditions that replicate clinical use as closely as possible.

The Critical Distinction in Plain Language

A device can pass all its verification testing and still fail validation. If the design inputs were wrong (the specifications did not actually capture what users need), the device can meet those specifications and still not serve users safely or effectively. This is why design inputs must trace back to real user needs, and why validation is not redundant with verification.

V&V and Risk Management

Both verification and validation connect to risk management under ISO 14971. Verification confirms that risk controls designed into the device are present and meet specifications. Validation confirms that risk controls are effective under actual or simulated use by representative users. For devices whose core risk is clinical performance (for example diagnostic accuracy or therapeutic effect), demonstrating that performance may require clinical or clinical-equivalent evidence, not usability testing alone.

Under ISO 13485 Clause 7.3.7 and Clause 7.1, validation and risk management are connected: the risk management file (the ISO 14971 risk file) and the validation documentation must reference each other. A device that has completed V&V but whose risk file does not reflect the validation results is incomplete.

Specifically, risk controls that were accepted based on verification results should be reviewed in light of validation results. If validation testing reveals that a risk control that works in specification testing does not work in actual use, the risk file must be updated. See our companion article on medical device risk management under ISO 14971.

Software Verification and Validation: A Special Case

For medical devices that contain software, software V&V is a substantial and separately documented program. FDA's primary software V&V guidance is "General Principles of Software Validation" (2002, https://www.fda.gov/media/73141/download). This guidance describes an activity-based approach to software validation that involves requirements specification, design, implementation, testing, and release control. FDA's 2023 guidance "Content of Premarket Submissions for Device Software Functions" (https://www.fda.gov/media/153781/download) governs what software documentation goes in a submission.

For software of unknown provenance (SOUP, a term used in IEC 62304 for software components not developed under the device manufacturer's control), additional analysis is required to establish the SOUP's behavior and assess its impact on device safety.

The international standard IEC 62304:2006+AMD1:2015 ("Medical device software: Software life cycle processes") provides a software development lifecycle framework that FDA recognizes and that many device programs use to structure software V&V.

Software verification confirms that the software performs all specified functions correctly. Software validation confirms that the software, in the actual device and under actual use conditions, supports the device's intended clinical purpose. For complex software, this can involve substantial testing across hardware configurations, operating conditions, and use scenarios.

What Goes in the 510(k) for V&V?

FDA's 510(k) review process requires performance testing data that supports the device's substantial equivalence claim. Most of this data comes from design verification. But FDA also expects evidence relevant to design validation, particularly for devices with significant software components, HFE considerations, or novel technologies.

The 510(k) submission typically includes:

From design verification:

• Performance test reports against applicable standards (IEC 60601-1, IEC 60601-1-2, ISO 10993 biocompatibility, sterility, and others)
• Software documentation (per FDA's software guidance, describing the software development process, risk analysis, verification testing, and documentation level)
• Dimensional and functional test data

From design validation:

• Clinical data or equivalent bench/animal data demonstrating the device achieves its intended clinical purpose
• Human factors/usability evaluation results (summative evaluation)
• Software validation results (for software-controlled devices)
• Simulated use data

For devices with a strong predicate case (well-established technology type with extensive literature), FDA may require less clinical data in the 510(k). For novel technologies or new intended uses, the validation evidence must be more robust.

FDA's "Acceptance of Clinical Data to Support Medical Device Applications and Submissions: Frequently Asked Questions" (2018, https://www.fda.gov/media/113864/download) and the device-specific guidance for particular device types provide additional direction on what clinical data FDA considers adequate. For biocompatibility specifically, see FDA's guidance "Use of International Standard ISO 10993-1, Biological Evaluation of Medical Devices, Part 1" on the FDA guidance documents page (https://www.fda.gov/regulatory-information/search-fda-guidance-documents/use-international-standard-iso-10993-1-biological-evaluation-medical-devices-part-1-evaluation-and).

A Practical V&V Planning Sequence

Getting V&V right is primarily a planning problem. Here is a practical sequence for structuring V&V in a device development program:

1. Write design inputs before designing anything. Every verification test must map to at least one input.
2. Identify critical performance requirements (those where failure would create patient risk) and plan for both verification testing and risk analysis for each.
3. Map out validation activities at the same time as you plan verification. Validation takes longer, because it requires representative production units and representative users.
4. Plan for software V&V separately. It runs in parallel with hardware V&V and has its own documentation requirements.
5. Conduct human factors formative evaluations during development, not after. The summative evaluation is validation; formative evaluations inform the design.
6. Confirm the risk management file is updated after each round of V&V testing. V&V results are risk evidence.
7. Assemble the 510(k) V&V sections from the V&V documentation directly. If your V&V documentation is well structured, 510(k) preparation is mostly assembly, not generation.

From V&V Evidence to Product Story

Your V&V documentation is not just a regulatory artifact. It is the source of every specific, credible claim your marketing program can make. The performance data from verification testing gives you the numbers behind accuracy and durability claims. The validation data gives you the clinical context: what the device actually demonstrated when tested by representative users under real conditions.

Buzzbox Media builds medtech marketing programs around this kind of evidence. When the clinical and performance data is solid, the marketing copy holds up to scrutiny. The companies that struggle at launch are often the ones who have the V&V data but have not translated it into language procurement directors, clinical champions, and hospital administration can use.

If your V&V program is underway and you want to start thinking about how to translate that evidence into a launch strategy, a 30-minute conversation is a practical starting point. Book at https://www.buzzboxmedia.com/book.