Design Verification vs. Validation for Medical Devices

If you work in medical device development, you have probably heard these two terms in the same sentence more than once: verification and validation. And if you’re honest, you might admit that the line between them still feels a little blurry.  

You’re not alone. Even highly experienced engineers use them interchangeably or treat them as the same regulatory checkbox. They are not. The FDA and ISO 13485 treat them as distinct activities, and mixing them up can lead to compliance gaps, failed audits, or worse, a product that doesn’t perform the way patients need it to.  

This article breaks down the difference in plain language, explains when each activity takes place in your development process, and shows you what a solid verification and validation strategy looks like in practice. 

Key Takeaways

• Verification asks: Did we build the product according to design inputs?
• Validation asks: Does the product meet user needs and intended use?
• Both are required under 21 CFR Part 820 and ISO 13485 — they are not interchangeable. 

What Is Design Verification for Medical Devices?

Design verification is the process of confirming that your product meets its design inputs — the specific, measurable requirements you defined at the start of the project.  

Think of it this way: verification is checking your work against the plan. If your design input says the device must withstand 50 Newtons of compressive force, verification is the test that proves it does.  

Under 21 CFR 820.30(f), the FDA requires that design verification be performed under defined conditions, with results documented in the design history file (DHF). ISO 13485 section 7.3.6 has the same expectation.  

Here are some common verification methods: 

• Testing: Physical, electrical, mechanical, or chemical testing against defined specifications
• Inspection: Visual or dimensional checks to confirm compliance with drawings or standards 
• Analysis: Computational modeling, simulations, or engineering calculations
• Demonstration: Showing that a feature or function works as designed under defined conditions

Verification is not a one-time event. It happens throughout development at multiple design stages and should be planned early, not bolted on at the end.  

What Is Design Validation for Medical Devices?

Design validation is where you step back from your specifications and ask a bigger question: Does this device really do what patients and users need it to do? 

While verification checks compliance with your own design requirements, validation checks alignment with user needs and intended use. These are not the same things! A device can pass every verification test and still fail in the hands of a real user.  

Under 21 CFR 820.30(g), the FDA requires validation to be performed under actual or simulated use conditions using initial production units or equivalents. ISO 13485 section 7.3.7 adds the requirement to document the rationale for the use conditions selected.  

Here are some common validation methods:  

• Usability testing with representative end-users (including formative and summative studies) 
• Clinical evaluation or clinical investigation, depending on device class 
• Simulated use testing in environments that replicate real-world conditions 
• Software validation, including validation of any automated processes or algorithms 
• Sterilization validation, biocompatibility testing, and shelf-life testing as applicable 

Important note: Validation must be completed on devices that are representative of the final design. Testing early prototypes does not count.  

What’s the Difference Between Design Verification and Validation?

The simplest way to frame it comes directly from FDA guidance: verification confirms you built the product right, and validation confirms you built the right product.  

Here’s a side-by-side comparison:

Question	Design Verification	Design Validation
What does it check?	Did we build the product right?	Did we build the right product?
Reference point	Design specifications/inputs	User needs/intended use
When does it happen?	Throughout development	Near the end of development
Who is involved?	Engineering team	Engineers and representative end-users or patients
Methods used	Testing, analysis, inspection, demonstration,	Simulated or actual use testing, usability studies, clinical evaluation
Regulatory basis	21 CFR 820.30(f) & ISO 13485 7.3.6	21 CFR 820.30(f) & ISO 13485 7.3.7
Key output	Test reports, traceability matrix	Validation protocol and report

The distinction matters because regulatory reviewers, notified bodies, and FDA auditors look at these separately. Submitting validation data where verification data is expected, or vice versa, is a common 483 observation.  

When Should Verification and Validation Happen in the Design Process?

This is where a lot of teams get into trouble. They treat verification and validation as an end-of-project activity instead of building it into their development plan from the start.  

Verification should be happening throughout your development cycle, at each design review gate, and whenever a major design change occurs. If you wait until you have a finished product to start verifying, you’re setting yourself up for expensive rework.  

Validation, on the other hand, is a later-stage activity by nature. You cannot validate against user needs until you have a device that reflects your final design intent. But the planning for validation, including writing protocols and identifying representative users, should start well before that.  

A word of caution: Changing your design after validation has started is painful. It typically means you need to update your traceability matrix, re-run affected tests, and justify the change in your design history file. The more rigorous your verification activities are early on, the less likely you are to discover fundamental design flaws during validation.  

What Does the FDA Require for Design Verification and Validation?

The FDA’s Quality System Regulation under 21 CFR Part 820 (now being harmonized with ISO 13485 through the Quality Management System Regulation, or QMSR) lays out specific requirements for both activities.  

For verification (820.30(f)), you need to:  

• Define the methods you will use and under what conditions
• Accept the testing results against predetermined criteria, not after the fact
• Document everything in the design history file
• Ensure that software used in verification is validated for its intended use

For validation (820.30(g)), you need to: 

• Validate the design using initial production units or equivalents
• Define acceptance criteria before you run the tests
• Conduct testing under actual or simulated use conditions
• Include software validation where applicable
• Validate any production processes that cannot be fully verified

Both activities need to be traceable back to your design inputs and use needs through a design traceability matrix. This document is the first thing an auditor or reviewer will ask to see.  

Regulatory tip: The FDA’s 2023 Quality Management System Regulation (QMSR) aligns 21 CFR Part 820 more closely with ISO 13485:2016. If your team has only followed one standard, now is a good time to close the gaps before your next inspection.  

What Are the Most Common Verification and Validation Mistakes in Medical Device Development?

We see a handful of the same issues across medical device programs, and most of them are preventable with better planning upfront.  

1. Starting Without Clear Design Inputs

If your requirements are vague or incomplete, you cannot verify against them. Verification is only as strong as the design inputs it references. 

2. Skipping Traceability

If you cannot show a clear link from user need to design input to verification test to validation result, your regulatory submission is going to have gaps. Build the traceability matrix as you go, not at the end. 

3. Treating Software as an Afterthought

Software used in testing, manufacturing, or as part of the device itself needs to be validated. This is its own workstream and should be planned for early. 

4. Running Validation on the Wrong Units

FDA requires validation on devices that represent your final design. Using pre-production prototypes or modified units can invalidate your results. 

5. Underdocumenting the Rationale

It’s not enough to show that a test has passed. You need to explain why the method was appropriate, who performed the test, what equipment was used, and how results were interpreted. Auditors look for substance, not just signatures.  

Need Help with Medical Device Verification or Validation?

At DISHER Engineering, we have supported medical device development across a wide range of product categories, from Class I to Class III devices, combination products, and software as a medical device (SaMD). We understand what regulators expect, and we know what it takes to build a defensible record.  

Whether you need support building your design controls framework, writing verification and validation protocols, or preparing for FDA inspection or notified body audit, our team can step in wherever you need us.  

Contact us here to get started.