Two words come up in every design plan, and they are often used as if they meant the same thing. They do not. Verification checks the design against the requirements the team wrote for it. Validation checks the device against the need it is meant to meet. A device can pass one and fail the other, and each failure costs a different kind of rework.
Two questions
ISO 13485:2016 covers both in clause 7.3. Clause 7.3.6 is design and development verification. Clause 7.3.7 is design and development validation. Since 2 February 2026 the US Quality Management System Regulation incorporates ISO 13485:2016 by reference, so the same two clauses now apply to Class II and Class III devices and some Class I devices sold in the US. The FDA describes the difference in its training material in short form: verification confirms that the outputs meet the inputs, and validation confirms that the device meets the requirements for its intended use. The FDA training material puts it in short form: one is making the device correctly and the other is making the correct device.
The earlier US rule, 21 CFR 820.30, said the same in its own terms. It defined validation as establishing by objective evidence that the specifications conform with user needs and intended uses. That is why the intended use statement matters so much: it is what validation is measured against.
Design review is a third activity and it is separate from both. A review is a systematic look, by an appropriate team at suitable stages, at whether the design results can meet the requirements, and at what actions follow. Verification and validation produce test evidence. Review is a separate step: the team examines the design at suitable stages and records the actions that follow.
What each one asks of the plan
Both are planned before they are run. ISO 13485 asks for documented plans and procedures, and the FDA training material says the plans must record the methods, the acceptance criteria and the statistical techniques. Both must also confirm any connection or interface with other devices or systems. The table sets the two side by side.
| Verification (7.3.6) | Validation (7.3.7) | |
|---|---|---|
| The question | Do the outputs meet the inputs? | Does the device meet its intended use? |
| Checked against | The design input requirements | The intended use and the user needs |
| What is checked | The design outputs, for example a built device and the documents to make it | Representative product |
| Examples of evidence | Measurable means, such as test reports | Actual or simulated use; clinical evaluation where the rules require it |
| The plan | Documented, with methods and acceptance criteria | Documented, and completed before the device is released |
The FDA material also says that validation must be done on representative product, and that clinical evaluations must meet the applicable regulatory requirements. The earlier US rule was more specific about the conditions. It called for validation under defined operating conditions, on initial production units or their equivalents, and under actual or simulated use. A hand-built prototype that differs from what will be manufactured is a weak base for a validation claim.
An example with an imaginary device
Take a hand-held device for a hospital ward. The example is for illustration only. One user need is that a nurse can carry it between beds without help. The team turns that need into design inputs a test can decide: a maximum mass, a handle position, and a reach limit.
- Verification. Weigh the built units on a calibrated scale. Measure the handle. Compare each result with the limit in the input. This shows the output meets the input.
- Validation. Give production-equivalent units to nurses and ask them to move the device on a simulated ward round. This shows whether the input itself was enough. The mass can be inside the limit while the handle still makes the device hard to carry.
- The gap. If validation fails here, verification was not wrong. The input was. The fix goes back to the requirement, and the design review should ask that question.
The same split can be applied to software. EU MDR Annex I, section 17.2, asks that software be developed in line with the state of the art, taking into account the development life cycle, risk management and verification and validation. As a rough guide, testing the code against its specification is verification. Showing that the finished function works for its intended users is validation.
Where the evidence goes
The EU MDR asks for both kinds of result in the technical documentation. Annex II, section 6, asks for the results and critical analyses of all verification and validation tests and studies that show conformity with the general safety and performance requirements. The pre-clinical part names engineering, laboratory, simulated use and animal tests, and it also asks for software verification and validation. In a design history file, the same records sit under verification and validation, each linked to the input or the intended use it answers. Write inputs that can be tested. ISO 13485 asks that inputs be complete and unambiguous, and able to be verified or validated.
Common mistakes
- Writing inputs that cannot be tested. "Easy to carry" cannot be verified until it becomes a measurable limit.
- Treating passed bench tests as validation. Every requirement can pass while the device still fails its user.
- Validating on units that differ from production. The claim then covers a device that will never be sold.
- Setting acceptance criteria after the run. The plan must record them first, or the result cannot be trusted.
- Leaving validation to the end. It has to be complete before release, and a late failure sends the team back to the inputs.
- Forgetting the interfaces. Connections to other devices and systems must be confirmed as part of both.
What to do at the start
Write a short V&V plan as soon as the inputs exist. For each input, name the verification method and the acceptance criterion. For each user need and each part of the intended use, name the validation method and the users, and say which units will be used. Review the plan when the inputs change. A plan drawn up early shows which inputs cannot be tested, while they are still cheap to rewrite.
Sources: US FDA, Quality Management System Regulation training material, Design and Development, clauses 7.3.3 to 7.3.7 of ISO 13485:2016 as summarised there, and the QMSR page on fda.gov (effective 2 February 2026, 21 CFR 820.10); US FDA, Design Controls training material on 21 CFR 820.30(f) and (g); Regulation (EU) 2017/745, Annex I section 17.2 and Annex II section 6 (EUR-Lex). This article is a general guide, not a regulatory determination for any device.