Verification vs. validation: the distinction that actually matters
Practice · Regulated Quality Assurance
Verification proves you built the thing right and validation proves you built the right thing, and a 100% passing test suite in your V&V report evidences only the first, so IEC 62304 and 21 CFR 820 audits catch teams that treat it as both.
What is the difference between verification and validation?
Verification proves you built the thing right: a design output meets its design input. Validation proves you built the right thing: the finished software meets user needs and its intended use.
Verification proves you built the thing right — that a design output meets its design input. Validation proves you built the right thing — that the finished software actually meets the user's needs and its intended use. Confusing them is the single most common way a team mis-scopes its own evidence, because a passing test suite only ever proves the first one.
Two questions, not one
Verification asks: did we build the design output correctly, against the design input? It's checkable against a specification. Validation asks: does the finished software actually do what the user needs, in its intended use environment? It's checkable only against real (or realistically simulated) use — a spec cannot validate itself.
Worked decision table
| Question you're actually asking | This is | Typical evidence |
|---|---|---|
| "Does this unit's output match its documented spec?" | Verification | Unit test results, code review records |
| "Does the integrated system meet its architecture's interface contracts?" | Verification | Integration test results (IEC 62304 §5.6) |
| "Does the finished device do what the clinician actually needs it to do?" | Validation | Usability/clinical validation study, human factors evidence |
| "Did we implement the requirement as written?" | Verification | Requirements-to-test traceability record |
| "Was the requirement itself the right one to write?" | Validation | User needs analysis, stakeholder acceptance evidence |
Why the confusion is costly, not just semantic
For MedTech software under IEC 62304, a 100%-passing verification test suite is real evidence of exactly one thing: internal consistency between what you specified and what you built. It is zero evidence that what you specified was correct in the first place. MedTech teams that treat a green test suite as "we're validated" are the ones an IEC 62304 audit catches — because the validation evidence, a validation summary report, was never produced, only implied.
A simple test to apply to your own evidence
function classify(evidence) {
if (evidence.comparesAgainst === "specification") {
return "verification"; // built it right
}
if (evidence.comparesAgainst === "userNeedOrIntendedUse") {
return "validation"; // built the right thing
}
return "insufficient — evidence doesn't state what it was compared against";
}If you can't say which side of that function your evidence falls on, it isn't finished evidence yet — regardless of how many tests passed.
Engineering reference only. Not formal regulatory counsel. Consult your own quality system for a specific regulatory determination.
Useful next step
Provenance & review state
- Last reviewed
- Sources
-
- IEC 62304:2006+AMD1:2015 — International Electrotechnical Commission
- ISO 9000:2015 — International Organization for Standardization
- Ingested from
-