ISO 13485 7.3.6 design verification: plans, test records and reports

A verification conclusion needs a requirement and objective evidence

Design verification establishes whether design outputs meet design input requirements through objective evidence.
A label saying “testing complete” does not explain what was demonstrated.
Readers need to identify the requirement, the design version, the method and acceptance criteria, the actual results and the resulting conclusion.

ISO 13485:2016 clause 7.3.6 addresses verification under documented plans.
These include methods, acceptance criteria and, where appropriate, statistical techniques with a rationale for sample size.
Results, conclusions and necessary actions are retained.
MDSAP describes verification evidence from testing, measurement and analysis, with acceptance criteria established before execution.[1]

The document names, identifiers, assignments and examples below are practical suggestions from MedQraft.
They do not mean that ISO requires three separate files named “plan,” “test record” and “report.”
An integrated document can work, provided planned work, actual execution and conclusions remain distinguishable and connected.

Review evaluates the design; verification establishes input conformity

Under 7.3.5, relevant participants assess the ability of design results to meet requirements and identify problems and necessary actions.
Verification under 7.3.6 establishes evidence that outputs meet inputs.
The distinction is not simply “meeting versus physical test.”
Calculation, analysis and examination of design information may also be appropriate verification methods.[1]

Consider a fictional thermometer.
A reviewer identifies a concern: a previous temperature remains on screen when a new measurement fails, potentially appearing to be a new result.
The review produces a finding and actions for revision and evaluation.
Once the input defines the required behavior and the display design is revised, verification checks implementation in the specified error conditions.
If the requirement itself changes, that change also needs appropriate control.

Verification plan: establish the scope, method and criteria before execution

A plan or protocol aligns what will be checked with how the outcome will be judged.
Organizing it around requirement identifiers helps expose missing coverage.
The following is an example structure, not a prescribed form.

For a display-behavior test, “cause an error” is insufficient.
Specify the error state and how it will be reproduced.
Does the starting configuration contain a previous valid result? Is the error introduced after a new measurement starts? Which area of the display is observed, and at what point? These choices affect interpretation.
Specific timing and limits should come from the product's controlled inputs, outputs and risk analysis; this example does not prescribe universal values.

A developer or test engineer familiar with the requirement may draft the plan.
A technical reviewer can assess whether the method actually addresses the requirement and whether the criteria and samples are justified.
An authorized approver releases it under the organization's procedure.
These are example responsibilities, not mandatory department names or a universal number of signatures.

Where intended use requires connection or an interface with other medical devices, the verification scope also needs to address input conformity in that connected configuration.[1] Evidence from standalone operation should not be presented as evidence for an untested connection.

Test records: distinguish the intended procedure from actual execution

Test records capture what happened during execution.
They should be created when work is performed and observations are made, rather than reconstructed when the report is written.
Copying expected results from the protocol into the actual-results field obscures what was observed.

A useful record structure connects the test item with the date, operator, specimen identity, device and software configuration, equipment, actual conditions and observed or measured results.
Link screenshots, logs and measurement files to the execution identifier and a retrievable storage location.
Where measurement equipment is used, connect the relevant calibration or verification status and suitability to the measurement concerned.

Suppose a screenshot shows that the previous value disappeared, but the associated log identifies a different software version.
Before assigning a pass, establish what was tested and assess the discrepancy's effect on the conclusion.
If execution used a different instrument or condition from the protocol, record the deviation, reason and assessment rather than silently treating it as planned work.

An interrupted test or a condition that could not be reproduced should have an explicit status, such as “not performed” or “conclusion pending,” under the organization's terminology.
Keep missing evidence distinguishable from a demonstrated failure.
Neither supports an unsupported pass.

Verification report: explain requirement-level conclusions and limits

The report connects the controlled plan and actual records to a conclusion about input conformity.
Identify the plan revision, tested configuration, executed scope and source records.
Summarize the comparison against each criterion and the resulting conclusion.
Technical review should check consistency with raw data and the treatment of missing work, deviations and unfavorable findings.
Approval should leave remaining actions and the scope of the conclusion clear.

An external laboratory report also needs an internal connection.
Match its specimen and configuration, method and edition, test scope and findings to your requirement identifiers.
Explain what the report demonstrates.
Attaching the file does not justify extending its conclusion to functions or product versions that were not evaluated.

Within its scope for US premarket submissions, FDA's non-clinical bench performance testing guidance recommends information on methods, samples, acceptance criteria, results and conclusions, including the effect of protocol deviations.[2] Software verification and validation and human factors are excluded from this guidance; it is not the direct test basis for the fictional display software.
This submission guidance should not be turned into a mandatory ISO template for every product.
Internal verification records and a regulatory submission summary serve different purposes and may require different levels of detail.

Worked documentation example: follow one requirement to its conclusion

The following identifiers and content illustrate a fictional documentation structure.
They are not actual test results.
The display requirement is not a universal requirement for thermometers.

A traceability matrix can index these connections, but a “pass” cell does not replace raw data.
When one requirement covers several error conditions, retain coverage and status at the appropriate level so that a partial execution does not appear to establish complete conformity.

Which standard controls these documents and records?

ISO 13485:2016 provides the QMS framework for this documentation.
Clause 7.3.6 concerns verification, 4.2.4 and 4.2.5 concern document and record controls, and 7.3.10 concerns design and development files.
Consider 7.3.9 when designs change, and 7.6 when monitoring or measurement resources provide conformity evidence.[1][3] The following are practical ways to connect these controls to the work.

It is helpful to distinguish a protocol revision from correction of an execution record.
Changing a method changes the procedure to be applied; correcting a record addresses a fact already recorded.
Preserving the original entry together with who corrected it, when and why supports confidence in the result.
In electronic systems, implement access control, backup, change history and long-term readability through procedures and appropriate system functions.
Saving a PDF alone does not establish all these controls.

Set retention in the organization's procedures after assessing document type, device lifetime and applicable market requirements.
MDSAP distinguishes additional jurisdiction-specific retention requirements.[1] Do not prescribe one unexplained retention period for every record or assume that development completion is always the starting date.

Select technical test standards separately from QMS control clauses

ISO 13485 does not prescribe one display time, accuracy limit or sample count for every thermometer.
Select technical standards according to intended use, measurement principle, functions and target market, then establish the applicable edition, clauses and scope.
A standard number alone is less useful than a connection to the actual test item, criterion and any excluded or modified conditions and their rationale.

This fictional example addresses one display behavior, so it does not declare a specific thermometer test standard applicable to the entire product.
In an actual project, requirements related to software, usability or risk controls should connect to the relevant activity plans and applicable standards.
Demonstrating that the previous value disappears does not automatically demonstrate that intended users correctly understand the error.
Validation of the specified application or intended use has the distinct purpose addressed by 7.3.7.

Preserve the evidence chain after failures and changes

When a result misses its criterion, retain both the observation and the criterion, then assess causes, impact and necessary action.
Relaxing a criterion after execution merely to obtain a pass undermines the original judgment.
If the criterion itself is wrong, evaluate the justification for its change, the impact on requirements, risk and previous results, and the work needed to establish a new conclusion.

For a retest, identify the changed design and protocol revisions and link the earlier failure.
A change to value suppression in an error state may also affect other display states or transitions; assess those effects to determine further verification.
Neither “repeat everything” nor “repeat only the failed item” is appropriate as an automatic rule for every change.
The report should distinguish completed evidence from open actions and provide usable information for subsequent design reviews.

Related articles and sources

• 7.3.3 Design inputs: define requirements before design
• 7.3.4 Design outputs: implement requirements
• 7.3.5 Design reviews: findings and follow-up actions
• Quality and QMS articles and clause guide

[1] MDSAP Audit Approach, AU P0002.011, revision 2026-08-03.
Chapter 1 Task 8, Chapter 5 Tasks 7 and 14, and Annex 1 on design and development files.
Audit guidance is distinct from the ISO standard and national regulations.

[2] FDA, Recommended Content and Format of Non-Clinical Bench Performance Testing Information in Premarket Submissions, 2019.
Nonbinding guidance for US premarket submissions, used within its stated scope.

[3] ISO 13485:2016 official information.
This explanation connects clause purposes and does not replace the full standard or the organization's controlled procedures.
Sources checked: 2026-11-01.