Design Verification vs. Design Validation
Design verification confirms that a device’s design outputs meet its design inputs — did we build it right — while design validation confirms that the finished device meets user needs and intended uses under actual or simulated use conditions — did we build the right thing. The two activities answer different questions, use different evidence, and both are required elements of a compliant design-controls process; conflating them is one of the most common device design-controls findings.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 19 LINKSVerification asks whether the output meets the input; validation asks whether the input was right. A programme can pass every verification test and still have built the wrong device, which is why the confusion is expensive.
06 · QUALITY MATURITY — DESIGN VERIFICATION VS. DESIGN VALIDATION, REACTIVE TO ADAPTIVE
The two words are used interchangeably. Design outputs are tested against themselves and the result is filed as both.
Verification and validation are separated in the file, but user needs were written after the design existed, so validation tests requirements rather than needs.
User needs are captured from actual users before design inputs are derived from them, and validation is performed on production-equivalent devices in the real use environment.
A design change is routed to whichever of the two it affects, so a change to an input triggers re-verification and a change in intended use triggers re-validation.
The distinction is structural rather than documentary: needs, inputs, outputs and evidence form one traceable argument, and a gap in it is visible before the file is assembled.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 3
Derived from the 3 standards SPEQ maps to this subject, across 3 regulatory bodies: FDA, ISO, EC.
RECORDS & OBJECTIVE EVIDENCE
- User needs, traceable to their source, and dated before the design inputs derived from them
- Design inputs, and the verification evidence that each output meets them
- Validation on production-equivalent devices, in or representative of the use environment
- The design history file showing the sequence and the review decisions at each stage
- Change records routed to re-verification or re-validation according to what changed
COMMON INSPECTION FINDINGS
- Validation performed on prototypes rather than production-equivalent devices
- User needs written retrospectively to match a design that already existed
- Verification results presented as validation evidence
- A design change re-verified but not re-validated where intended use moved
- Design reviews recorded as attendance with no decision or open-issue outcome
The Core Distinction
Verification is an internal, specification-driven check: does the manufactured or prototype design output — a dimension, a material property, a software function — match the documented design input requirement it was meant to satisfy? It is typically objective, measurable, and conducted against engineering specifications.
Validation is an external, use-driven check: does the finished device, under actual or simulated use conditions with actual or representative users, meet the user needs and intended uses that were the reason the device was developed in the first place? A device can pass every internal specification and still fail validation if the specifications themselves did not capture what users actually needed.
Where Each Fits in the Design-Controls Sequence
Both 21 CFR 820 and EU MDR/ISO 13485-based design-controls frameworks position verification as confirming outputs against inputs at each stage of design, and validation as a later-stage (often final) activity confirming the overall device against user needs — typically including clinical evaluation, simulated-use testing, or human factors validation for devices with a significant use-related risk profile.
Design transfer — moving the verified and validated design into production — sits after both are complete; validating a design that has not yet been verified against its own specifications, or transferring a design to manufacturing before validation is complete, are both recognised inspection findings.
Evidence and Documentation
Verification evidence is typically test data, inspection results, or analysis demonstrating conformance to a specific input requirement, traceable through a requirements-traceability matrix. Validation evidence typically includes clinical evaluation data, simulated-use study results, or human factors/usability validation data tied directly back to the documented user needs and intended use statement.
A traceability matrix that links user needs → design inputs → design outputs → verification evidence → validation evidence is the standard tool for demonstrating, in an audit or submission, that every requirement was both correctly implemented and correctly validated against its origin.
A Common Confusion
SPEQ interpretation: the confusion between the two terms is not merely semantic — a design history file that substitutes extensive verification testing for validation (on the reasoning that “we tested it thoroughly”) has not actually demonstrated the device meets user needs, because verification testing is designed to check specifications, not to check that the specifications were the right ones to write.
FREQUENTLY ASKED
Can design verification and design validation be the same test?
Occasionally a single test can generate evidence for both if it is designed to check both a specification and a user need simultaneously, but this is the exception; in most design-controls files they are distinct activities with distinct protocols, acceptance criteria, and evidence.
Does software require both verification and validation?
Yes — software verification (does the code meet its software requirements specification, addressed under frameworks such as IEC 62304) and software/device validation (does the finished device meet user needs) are both expected, and are frequently the area where the verification/validation distinction is least well understood.
What happens if validation reveals a problem after verification already passed?
The design returns to the design-controls process — the finding typically triggers a design change, updated design inputs if the original user-need understanding was wrong, and re-verification and re-validation of the affected elements before design transfer proceeds.