Documentation Practice

Verification, Validation & Traceability

Verification shows the product was built to its requirements. Validation shows those requirements were the right ones. Traceability is how both are demonstrated.

Verification: Objective evidence that outputs meet the specified requirements
Validation: Objective evidence that the device meets user needs and its intended use
Traceability: Documented links between needs, requirements, design, risk controls and tests
Where required: ISO 13485 clauses 7.3.6 and 7.3.7; IEC 62304 clauses 5.5 to 5.7 and 5.1.1; ISO 14971 for verification of risk controls; and in the evidence for FDA and EU submissions

In short

The two words are often used together and mean different things. Verification compares what was built against what was specified. Validation compares the finished device against what users actually need it to do. A product can pass every verification test and still fail validation, if the requirements were wrong.

Verification

Activities. Reviews of requirements, design and code; static analysis; unit, integration and system tests; regression testing after change.
Criteria come first. Pass and fail criteria are defined before the test is run.
Records. What was tested and at which version, by whom, when, the result, and any anomalies found.

Validation

On the real thing. Performed on the finished device or an equivalent, in actual or simulated conditions of use.
With real users where it matters. Includes summative usability evaluation (IEC 62366-1) and, where regulations require it, clinical or performance evaluation.
Before release. Software validation is part of validating the device as a whole.

Traceability

There are two chains. The first runs from user need to design input, to design output, to the test that verifies it. The second runs from hazard to risk control measure, to the requirement that implements it, to the evidence that the control is in place and effective. A trace matrix should answer four questions:

Is every requirement tested?
Does every test trace back to a requirement?
Is every risk control implemented and verified?
What is affected if this requirement changes?

On a software project

Write requirements that can be verified. A requirement nobody can test shows up late as a gap in the trace.
Keep the links where the work happens. Trace links held in the issue tracker and test management tool, with the matrix generated from them, stay current. A spreadsheet maintained by hand does not.
Verify a baseline. Formal verification runs on an identified build. Anomalies found are recorded and evaluated, not only fixed.
Justify the regression scope. Impact analysis decides what is re-run after a change, and the reasoning is recorded.
Automated tests are evidence if the tooling is controlled. Tools that produce quality records fall under ISO 13485 clause 4.1.6 and need validating in proportion to their risk.
Close out anomalies deliberately. Anything unresolved at release is listed and assessed for its effect on safety. Both IEC 62304 and FDA submissions ask for that list.

Worth knowing

IEC 62304 covers software verification up to system testing. Validation of the finished device is outside its scope.
Terminology differs between sources. The FDA’s General Principles of Software Validation uses “software validation” broadly, for the activities across the whole life cycle, where IEC documents would say verification.

Official sources

A summary for orientation. It is not regulatory or legal advice, and it is no substitute for the standard or regulation itself. Requirements change: confirm the current edition before relying on anything here. Last reviewed November 2026.