Documented verification confirming outputs meet inputs, with methods, dates, and individuals recorded — 820.30(f) structure preserved.
Verification plan must be documented before execution; activities must trace back to planned arrangements in the design plan.
Pre-execution verification plan and input-to-output traceability matrix — ad-hoc verification protocols without a prior plan are a common finding.
Maps to
QMSR / ISO 13485: §820.30(f) Design verification.
ISO 13485: §7.3.6 Design and development verification
ISO 14971: §7.3 Residual risk evaluation
Requirement text
Design verification shall confirm that outputs meet input requirements. Results and follow-up actions shall be recorded.
Why this clause exists
Design verification answers the question: does the device as designed meet the specifications established as inputs? It is the formal checkpoint between design and the broader claim of product conformance. The requirement to verify each output against the input it addresses creates a closed loop that prevents the common failure mode of partial verification — where some inputs are confirmed and others are assumed met because the device performs acceptably in general testing. Traceability through a matrix or equivalent record is what makes verification auditable: without it, an inspector cannot determine whether a specific design requirement was verified, by what method, with what sample size, or with what result. The statistical rationale requirement is especially consequential because underpowered verification testing can produce passing results by chance; documenting the rationale creates accountability for the confidence level the manufacturer claimed. The crosswalk to ISO 14971:2019 § 7.3 (residual risk evaluation) reflects the expectation that risk controls implemented as design features have individual verification evidence — a risk control that cannot be verified to function as intended does not reliably reduce risk. Following verification, any failures trigger follow-up actions that must be documented, creating a record that design did not simply proceed past a failed gate without resolution.
What changed
§820.30(f) — Part 820 (legacy)
"Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF."
§7.3.6 — ISO 13485:2016 (current)
"Design and development verification shall be performed in accordance with planned and documented arrangements to ensure that the design and development outputs have met the design and development input requirements. The organization shall document verification plans that include methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size. If the intended use requires that the medical device be connected to, or have an interface with, other medical device(s), verification shall include confirmation that the design outputs meet design inputs when so connected or interfaced. Records of the results and conclusions of the verification and necessary actions shall be maintained (see 4.2.4 and 4.2.5)."
Δ Adds a formal verification plan requirement with acceptance criteria and sample-size rationale; interface verification now explicitly required for devices that connect with other devices.
Common gaps (what we see in audits)
- No documented verification plan prior to execution — ISO 13485 7.3.6 requires verification 'in accordance with planned and documented arrangements.' Many Part 820-era companies execute verification testing and document results without having a pre-approved verification plan or protocol that defines test methods, acceptance criteria, and sample sizes before testing begins.
- Missing statistical rationale — Verification reports lack a documented rationale for sample sizes (e.g., why n=30?). ISO 13485 §7.3.6 explicitly requires this rationale.
- Verification does not cover all design inputs — Under ISO 13485 7.3.6, verification must confirm that design outputs meet design input requirements — all of them. Some companies verify key performance requirements but do not systematically verify every design input, particularly usability requirements, regulatory requirements, or requirements derived from risk management outputs.
- Risk control measures not individually verified — With ISO 13485's integration of risk management into design controls, each risk control measure implemented as a design feature should be verified for effectiveness. Many companies verify product performance holistically without specifically confirming that individual risk controls function as intended.
- No verification plan — Verification is executed based on a protocol, but no overarching 'Plan' defines the scope of all verification activities. ISO 13485 §7.3.6 requires documented verification plans.