ISO 9001 clause 8.3.4: review, verify and validate the design
ISO 9001:2026 clause 8.3.4 requires controls over design and development so the intended results are defined and appropriately evaluated. Reviews, verification and validation have distinct purposes. Problems identified through those activities need necessary action, and documented evidence of the activities must be available.
What clause 8.3.4 requires in practice
This clause is about control during design. The organisation applies controls so that the results sought are defined, and so that appropriate evaluation takes place along the way. Three activities are named, each with a different job. Reviews judge whether the design results can meet requirements. Verification checks that the outputs of design satisfy the input requirements. Validation checks that the resulting product or service works for its specified application or intended use.
When any of these reveals a problem, necessary action must be taken, and documented information must be available as evidence that the activities were carried out. The accompanying note explains that the three can be done separately or in any combination that suits the organisation, but their purposes remain distinct.
In short: define what success looks like, evaluate against it at sensible points, deal with what is found, and keep proof.
Distinguish the three purposes
A design review evaluates whether the design results can meet requirements and helps identify issues needing attention. Verification examines whether design outputs meet the input requirements. Validation considers whether the resulting product or service meets requirements for its specified application or intended use.
These distinctions matter because a design can accurately reflect an inadequate input while still failing the intended use. Conversely, a convincing demonstration may not show that every important input requirement has been met. Choose controls that address the relevant questions rather than using one approval label for all of them.
Why design review, verification and validation matter
A design that passes one kind of check can still fail another. A product may match its specification perfectly and yet be unsuitable for the customer who actually has to use it. Separating the questions of review, verification and validation exposes those gaps while they are still affordable to close. For the business this means fewer field failures, fewer warranty or rework costs, and stronger customer trust in new offerings. For audits, the usual test is whether the organisation can show what each check was for, who performed it, what was found and what was done about it. Blurring the three into a single sign-off is a frequent reason findings arise.
How to implement clause 8.3.4
Build the controls into the design plan so they happen at planned moments rather than only at the end. Choose reviewers who did not do the design work where possible, because fresh eyes catch assumptions. Be clear with customers about which activities they will see and which stay internal.
- State the result each design stage is meant to achieve, in terms that can later be judged.
- Schedule reviews with the right mix of people, including those who will build, deliver or support the result, and note what each review must decide.
- Define verification as a comparison of outputs against the agreed inputs, and choose suitable means such as inspection, calculation or testing.
- Define validation around real or representative conditions of use, involving customers or users where practicable.
- Where activities are combined for efficiency, record which question each part answers.
- Log problems found, assign actions with owners, and confirm closure before the design progresses.
- Keep records of who took part, what was examined and the decisions made.
Illustrative software example: the right function in the wrong workflow
A hypothetical software team develops a reporting feature against a documented specification. Verification confirms that the output fields and calculations match the defined inputs. During a representative user evaluation, however, the team finds that the report arrives too late in the customer's workflow to support the intended decision.
The organisation treats that finding as a design issue requiring action rather than declaring success solely because verification passed. It reviews the requirement basis, changes the relevant design and evaluates the resulting effect. The example shows the distinction between meeting specified inputs and being suitable for intended use; it does not prescribe one software testing method.
Illustrative BPO example: a service process under realistic conditions
A hypothetical BPO provider designs a new exception-handling service. Review identifies a possible handover gap, and verification checks that the workflow contains the approved decision rules. A controlled evaluation with representative cases then reveals that agents cannot obtain required information at the point where the rule must be applied.
The team addresses the information interface and repeats appropriate evaluation before wider use. Evidence explains the finding, the action and the resulting decision. A visually complete workflow diagram or a successful demonstration using only easy cases would not establish the same confidence in the intended service.
Define results and address problems
The organisation should know what results the design is intended to achieve before deciding whether its controls are satisfactory. This helps reviewers recognise relevant gaps and avoids evaluating only what is convenient to test. Consider the important requirements and the consequences of an unsuitable result.
Necessary actions must follow problems found during reviews, verification or validation. Assign appropriate responsibility and ensure the issue reaches a justified resolution. A record of a problem is not equivalent to addressing it, and a closed action is not meaningful if the design's adequacy remains uncertain.
Choose proportionate activities and evidence
Methods may include analysis, examination, testing, simulation or suitable service evaluation, depending on the work. These are implementation choices. Use appropriate competence and relevant technical requirements when determining whether a method can provide the needed confidence.
Documented information must provide evidence of the activities. It should allow the organisation to understand what was evaluated and the relevant result, with sufficient connection to the design and requirement basis. The standard does not demand one universal test-report template or insist that all evidence be paper-based.
Avoid substituting signatures for evaluation
Common weaknesses include calling every meeting “validation,” verifying only easy requirements and accepting an unresolved issue because the delivery date is near. Another is keeping evidence that does not identify which design version was evaluated. These weaknesses can leave later changes or acceptance decisions unsupported.
Customer participation can contribute useful evidence, but does not automatically replace the organisation's design responsibilities. Consider what the customer's approval actually means and whether the relevant controls have been fulfilled. Technical, contractual and statutory obligations should remain clear.
Use the parent design and development guide to connect these controls with planning, inputs, outputs and changes. A dependable control sequence should help the team recognise what is known, what remains unresolved and what must happen next.
Frequently asked questions
Are verification and validation interchangeable?
No. Verification compares outputs with inputs; validation examines suitability for the specified application or intended use. Both purposes need appropriate attention.
Can one activity serve more than one purpose?
Yes, where suitable. Make clear which purposes it addresses and whether the evidence supports each, rather than relying on a broad activity label.
Does customer approval automatically complete validation?
Not necessarily. Consider what was evaluated, the intended use and the organisation's relevant responsibilities. Approval alone may not establish every required conclusion.
Strengthen the evidence behind design decisions
Sterling can review your design-control workflow, connecting responsibilities, employee learning and scoped Effivity ISO & GRC automation software. Specialist technical evaluation remains appropriately scoped, and certification decisions remain independent.
Nonconformity Management can support teams handling issues identified during design evaluation.