Verification vs Validation in ISO 13485 Design Controls (Clause 7.3): how to execute it so audits go quiet

Teams usually understand the textbook difference between verification and validation—but still fail audits because they don’t execute the difference. Under ISO 13485 Clause 7.3, auditors aren’t looking for perfect terminology. They’re looking for a defensible, repeatable system where:

• Verification proves the design outputs meet the design inputs (requirements).
• Validation proves the device (as realized) meets intended use and user needs under representative conditions.

This post is designed to change execution: how to plan verification, write protocols, define acceptance criteria, build traceability, plan validation around intended use, and assemble DHF evidence the way auditors actually sample.

Relevant clause pages for deeper navigation:

• ISO 13485 Clause 7.3 – Design & Development
• ISO 13485 Clause 7 – Product Realization
• ISO 13485 Clause 4 – QMS & Document Control
• ISO 13485 Clauses 4–8 Clause Hub

---

Why audits blow up here (the real root cause)

Most audit pain around verification vs validation comes from one of these execution failures:

• Requirements are not measurable, so “verification” becomes subjective.
• Protocols don’t reference the requirement IDs, so traceability is broken.
• Acceptance criteria is missing or defined after results are known.
• “Validation” is used as a label for late-stage bench testing (instead of intended-use confirmation).
• The DHF is missing a clear evidence map, so retrieval during sampling is slow and inconsistent.

The fix is not a lecture. It’s a system: inputs → outputs → verification methods → reports → validation rationale → DHF index. Let’s build it.

---

Verification vs Validation (side-by-side table)

Topic	Verification	Validation
Primary question	Did we build the design outputs correctly to meet the design inputs?	Did we build the right device for intended use and user needs?
What it proves	Conformance to requirements (inputs) via objective methods.	Fitness for intended use under representative conditions.
Typical basis	Design input statements + acceptance criteria.	Intended use, user needs, use environment, clinical/workflow expectations.
Where it links in traceability	DI → (DO) → Verification method/protocol → Verification report.	User needs / intended use → Validation plan → Validation evidence → conclusions.
Methods	Test, inspection, analysis, or defined review.	Simulated use, usability activities, clinical/workflow evaluation, real-world/representative scenarios.
Acceptance criteria	Usually numeric thresholds / pass-fail criteria tied to DI IDs.	Success criteria tied to intended use tasks/outcomes and user needs (often task success, error rates, performance in use).
Timing	Throughout development as outputs mature; repeated as needed when changes occur.	When the device configuration is representative of final intended use (often later), and updated if changes affect intended use.
Common audit failure	Tests exist but don’t map to requirements; acceptance criteria missing; reports don’t show pass/fail.	Validation doesn’t represent intended use; wrong users/environment; validation scope not justified; labeled “validation” but actually bench verification.

---

How to execute verification properly (so it stays “requirements-proof”)

Verification succeeds when you can pick any design input and quickly show: “Here is the test/inspection/analysis that proves it, with acceptance criteria and results.” That requires disciplined writing and disciplined linkage.

1) Verification planning rules

• Start with measurable design inputs: each input must have acceptance criteria you can objectively test or inspect.
• Assign a verification method early: test vs inspection vs analysis (avoid vague “review” unless it’s a defined checklist review).
• Define acceptance criteria before execution: if you decide pass/fail after seeing data, you’ve lost audit credibility.
• Build a verification matrix: DI ID → method → protocol ID → report ID → status (planned/in progress/pass/fail).

2) Protocol discipline (what auditors expect)

Auditors don’t just want a report; they want to see that results came from a controlled method. Your protocol is the “how,” your report is the “what happened,” and your acceptance criteria is the “pass/fail standard.”

Key protocol features:

• Protocol references DI IDs (or the matrix cleanly links them).
• Test setup and conditions are defined (including tolerances and environmental conditions as needed).
• Sample size and rationale are stated (even if small, justify it).
• Data collection method is defined (what is measured, how, and with what equipment/software).
• Pass/fail criteria is explicit.
• Deviations handling is defined (what happens if something goes off-script).

---

Example verification test protocol outline (copy-ready structure)

This is a practical outline you can standardize for verification protocols. Keep it lean but complete.

• Protocol ID: TP-### (or VER-PROT-###)
• Title: Verification Protocol — [Requirement/System]
• Purpose: What requirement(s) this protocol verifies (list DI IDs)
• Scope: Product configuration/version under test; what is excluded
• References: DI list version; relevant DO specs/drawings/software requirements
• Responsibilities: executor, reviewer, approver
• Equipment & calibration status: what tools are used and how you ensure they’re suitable
• Test setup: fixtures, connections, preconditions
• Test conditions: environmental conditions, operating ranges
• Sample size: N and rationale
• Procedure steps: step-by-step instructions
• Data to record: fields/tables; measurement method
• Acceptance criteria: pass/fail thresholds (tie to DI acceptance criteria)
• Deviations handling: how deviations are documented and dispositioned
• Approval: signatures/dates and version control (tie into Clause 4 document control)

Execution output: a Verification Report (VR-###) that states results, deviations, pass/fail per DI, and approvals.

---

How to execute validation properly (so it stays “intended-use-proof”)

Validation succeeds when you can show: “This device, in a representative configuration, supports intended use and user needs under realistic conditions.” The word “representative” does most of the work.

1) Validation planning rules

• Define intended use and user needs clearly: who uses it, for what tasks, in what environment.
• Choose representative conditions: real or simulated use scenarios that match the intended setting.
• Define success criteria tied to user outcomes: task success, error rates, time to complete, performance in workflow, or clinical-like endpoints (depending on device context).
• Use a representative configuration: correct hardware/software/labeling/IFU versions that reflect intended use (or justify differences).
• Separate validation from verification: validation is not just “another bench test.” Bench tests can support validation, but validation must answer the intended use question.

2) What “validation evidence” typically looks like

Validation evidence often includes some combination of:

• Simulated-use / usability evaluation (task-based scenarios)
• Clinical/workflow evaluation in representative environments
• Labeling/IFU comprehension effectiveness (where relevant)
• Summarized outcomes tied back to intended use and user needs

Important: Validation still needs discipline: defined plan, defined acceptance criteria, documented results, and approvals—just like verification.

---

Example validation plan outline (copy-ready structure)

• Validation Plan ID: VAL-PLAN-###
• Title: Validation Plan — [Device/Use Case]
• Purpose: Confirm intended use and user needs are met
• Intended use summary: user, environment, key tasks, critical outcomes
• Scope/configuration: device configuration (HW/SW versions), labeling/IFU versions, accessories
• Validation approach: simulated use / workflow evaluation / other representative evaluation method
• Participant profile: representative users (experience level, roles), inclusion/exclusion criteria
• Use scenarios: scenarios mapped to critical tasks and foreseeable conditions
• Success criteria: task success thresholds, error acceptability, performance thresholds in use
• Data capture: what is measured and how (observations, logs, timing, outcomes)
• Risk linkage: which high-risk use situations are evaluated and how
• Deviations handling: what happens if results deviate or safety issues are observed
• Report structure: validation report with conclusions tied to intended use/user needs
• Approvals: reviewers/approvers and controlled release

---

Traceability: the simple model that keeps V&V defensible

If your team struggles with verification vs validation in execution, it’s usually because traceability is incomplete. A simple model is:

• Design Inputs (DI): measurable requirements with acceptance criteria
• Design Outputs (DO): specs/drawings/software requirements/labeling/manufacturing specs that implement the inputs
• Verification (VER): protocols and reports that prove DI conformance
• Validation (VAL): plan and evidence that prove intended use/user needs

Mini walkthrough:

• DI-012: Device shall maintain accuracy within X range under defined conditions (acceptance criteria specified).
• DO-020: Performance specification defines algorithm constraints and calibration requirements that implement DI-012.
• TP-012 / VR-012: Bench protocol and report demonstrate DI-012 is met (verification).
• VAL-PLAN-003 / VAL-REP-003: Representative-use evaluation shows users can obtain accurate results in intended workflow conditions (validation).

Auditors love this because it shows your team knows which evidence answers which question—and where that evidence lives in the DHF.

---

Evidence map: what goes in the DHF and what auditors sample

A DHF that passes sampling doesn’t have “more documents.” It has organized evidence. Here’s a practical evidence map that fits most projects.

DHF contents (typical V&V-related artifacts)

• Design plan: identifies planned reviews, verification/validation strategy, and gate criteria
• Design inputs document: DI IDs, measurable requirements, acceptance criteria, source/justification
• Design outputs index: DO IDs and controlled artifacts (specs, drawings, BOM, SW requirements, labeling/IFU, manufacturing specs)
• Traceability matrices: DI→DO and DI→VER (and link to validation where relevant)
• Verification protocols and reports: TP-### and VR-### with approvals
• Validation plan and report: VAL-PLAN-### and VAL-REP-### with intended use and success criteria
• Design review minutes: decisions about readiness, deviations, and any required rework
• Change records: impact assessments and retest/revalidation decisions

What auditors typically sample

• One critical DI and the exact evidence that verifies it (protocol + report + acceptance criteria)
• One validation claim tied to intended use and representative conditions (plan + results + conclusions)
• One change that impacted requirements and how you decided whether to re-verify and/or re-validate
• One design review record showing decisions, actions, and closure evidence references

Retrieval matters: if your team can’t retrieve these quickly and consistently, auditors interpret that as weak control (and Clause 4 document control becomes part of the finding). See Clause 4 for the control foundation.

---

---

6–8 FAQs (verification vs validation in ISO 13485 Clause 7.3)

• What is the simplest way to remember verification vs validation?
  Verification proves you met requirements (inputs). Validation proves you met intended use and user needs in representative conditions.
• Can the same test support both verification and validation?
  Sometimes a method can contribute to both, but the intent and success criteria differ. Verification is requirement-centric; validation is intended-use-centric.
• Why do auditors care so much about acceptance criteria?
  Because acceptance criteria makes results objective. Without it, tests become opinions, and opinions don’t survive sampling.
• Is validation always “clinical”?
  Not necessarily. Validation is about intended use and user needs under representative conditions. For many devices, simulated use/workflow evaluation can be appropriate when justified.
• When should we validate?
  When the device configuration and labeling/IFU are representative of intended use. If key changes occur afterward, you need documented decisions on whether re-validation is required.
• What’s the most common audit mistake?
  Calling late verification “validation” and not showing intended-use relevance. The fix is to anchor validation planning to intended use/user needs and representative conditions.
• How do we show traceability without a massive system?
  Use unique IDs (DI/DO/TP/VR/VAL) and keep one simple matrix that links DI → verification protocol/report, plus a validation map for intended use/user needs.
• Where does product realization (Clause 7) fit in?
  Verification/validation evidence depends on controlled outputs and production-ready configuration. Clause 7 ensures transfer and production controls don’t drift from the validated configuration: Clause 7.

---

For full clause navigation, use the ISO 13485 Clauses 4–8 Clause Hub, then drill into Clause 7.3 and Clause 7 as needed.