ISO 9001 Clause 8.3: Control Product and Service Design
ISO 9001:2026 clause 8.3 requires an appropriate design and development process where design is applicable to the organisation's products or services. It connects the needs being addressed with planned controls, usable outputs and controlled changes. The aim is to establish that the result meets its specified requirements and supports its intended use.
What clause 8.3 requires in practice
Clause 8.3 applies where the organisation designs and develops its products or services. It sets out six connected parts. Clause 8.3.1 asks for an appropriate design and development process. Clause 8.3.2 covers planning, including stages, reviews, verification, validation, responsibilities, resources, interfaces and customer involvement. Clause 8.3.3 deals with inputs, which must be complete, unambiguous and free of unresolved conflict. Clause 8.3.4 sets the controls: defined results, reviews, verification, validation and action on problems found.
Clause 8.3.5 covers outputs, which must meet the inputs, support later delivery, include or reference acceptance criteria and describe characteristics essential to safe and proper use. Clause 8.3.6 deals with changes during or after design, which must be identified, reviewed, authorised and controlled. Most parts expect documented information as evidence. A note explains that reviews, verification and validation have different purposes and may be combined as suits the business. Another note recognises iterative methods. The clause does not require a specific project model or stage-gate. Its output is a controlled path from need to deliverable offering, with evidence that the result fits its intended use.
8.3.1 and 8.3.2: plan controls around the design work
Establish a process suitable for the nature and complexity of the design. Planning considers stages, reviews, verification, validation, responsibility, resources, interfaces and relevant involvement of customers or users. It also considers the information needed to show requirements were met and the needs of subsequent product or service provision.
These controls can operate within an iterative development method. ISO 9001 does not prescribe one universal project model. The organisation should be able to explain how its chosen approach maintains clear inputs, accountable decisions and reliable outputs when requirements evolve or several teams contribute.
8.3.3: make the inputs coherent enough to design against
Inputs include relevant functional and performance needs, applicable obligations, information from similar designs, committed standards and the consequences of potential failure. They need to be adequate, complete and unambiguous for their purpose. Conflicting inputs should be resolved, with the required information retained.
A useful implementation practice is to identify assumptions separately from confirmed requirements. An assumption can be reasonable during early exploration but dangerous if it silently becomes an accepted customer requirement. Decide who can confirm it and at which point the uncertainty must be resolved.
Why controlling design matters to the business
Design decisions fix most of the cost, safety and usefulness of what the customer eventually receives, and mistakes made here are the most expensive to correct later. A structured process makes sure the right requirements are understood at the start, that the result is checked against them, and that it works for the intended use. That reduces redesign, delays and field failures. It also helps teams coordinate across departments and with customers, and it protects the business when someone asks why a choice was made. Controlled change prevents a late tweak from breaking something that was already approved. Where design is relevant to the scope, auditors treat this clause as a measure of how well the business turns ideas into reliable offerings.
How to implement clause 8.3
First decide whether design applies to your scope, then build controls that suit the work rather than a heavy template. One way Sterling's teams begin is to review a recent project and mark where design decisions were taken.
- Decide which activities count as design and development in your organisation, and record the reasoning for any exclusion.
- Plan each project: stages, review points, verification, validation, responsible people, resources and customer involvement.
- Collect inputs such as performance needs, lessons from similar work, legal duties and committed standards, and resolve conflicts.
- Apply controls: define expected results, hold reviews, verify outputs against inputs and validate against intended use.
- Define outputs that downstream teams can use, including acceptance criteria and the characteristics essential for safe use.
- Control changes by reviewing their effect, obtaining authorisation and recording what was done to prevent harm.
- Keep evidence of each step in proportion to the risk and complexity of the work.
Illustrative software example: a customer reporting function
A fictional software supplier develops a reporting feature for customers with different approval roles. The team confirms intended users, required outputs and the conditions under which the feature must operate. It reviews whether the proposed design addresses those inputs before investing in the full build.
Verification can examine whether the developed result meets the specified requirements. Validation considers whether it supports the intended use, for example through a suitably designed trial with representative users. A successful automated test of calculation logic does not necessarily show that users can complete the intended approval task. Evidence links the inputs, review findings, test results, user evaluation and any resulting changes.
8.3.4: distinguish review, verification and validation
Review evaluates the ability of design results to meet requirements and identifies problems. Verification checks outputs against inputs. Validation addresses the resulting product or service against its intended application or use. These activities can overlap in practice, but their purposes should remain clear.
Plan the controls and take necessary action on issues found. Retain the required evidence. Avoid defining validation as “the customer signed something” without examining what the signature establishes. Customer involvement can be valuable, but the organisation must understand the design question being answered and whether the method provides suitable evidence.
8.3.5 and 8.3.6: release usable outputs and control change
Design outputs should meet input requirements and provide what subsequent provision needs, including relevant acceptance, monitoring and measurement information. They also identify characteristics essential for intended purpose and safe, proper provision. Preserve the required design-output information so that operations do not have to reconstruct the designer's intentions.
Design changes require identification, review and control to avoid adverse effects on conformity. Retain the required information on changes, review results, authorisation and necessary actions. Consider the effect on outputs already delivered and related activities where relevant; do not assess only the changed drawing or code file in isolation.
Illustrative manufacturing example: redesigning a packaging insert
A hypothetical manufacturer changes an insert to reduce damage during distribution. Purchasing prefers a cheaper material, while operations needs reliable assembly and the customer needs the product protected under agreed conditions. The design team resolves those inputs and plans appropriate checks before approving the change.
Review may expose an assembly difficulty; verification may check the insert against its specified dimensions and material requirements; validation may examine the intended distribution application using an appropriate evaluation. The example does not prescribe a transport test. Competent personnel select methods suitable for the product and requirements. Approved outputs and change information then reach purchasing, production and release personnel.
Evidence and common mistakes
An auditor may follow one design from the initial need through approvals, evaluations and release. The useful question is whether the sequence supports the decision. Missing links, unresolved inputs, retrospective approvals and changes that bypass evaluation are more significant than the visual style of the design file.
Explore each numbered part
8.3.1 · establish a design process suited to the offering
Design and development need a process that fits what the organisation creates. This guide explains clause 8.3.1 through BPO service design and manufacturing examples, showing how decisions become a deliverable offering. It distinguishes an appropriate process from a compulsory waterfall method and explains why outsourcing or a service label does not automatically remove design responsibility.
8.3.2 · plan design around its complexity and interfaces
Design planning should explain how the work will reach a usable result. This guide examines clause 8.3.2 through software and construction-service examples, including review stages, verification, validation, resources and interfaces. It shows how to involve customers appropriately and plan evidence without imposing the same development sequence on every project.
8.3.3 · establish design inputs that can be used
Design inputs should give the team a clear basis for development and evaluation. This guide explains clause 8.3.3 through manufacturing and software examples, covering essential requirements, relevant prior learning, obligations and potential failure consequences. It shows how to manage incomplete or conflicting information without pretending that every input must be fully known at the first meeting.
8.3.4 · review, verify and validate the design
Design review, verification and validation answer different questions. This guide explains their purposes under clause 8.3.4 through software and BPO examples, including action on problems and retention of evidence. It shows how activities can be combined without losing their distinctions and why an approved specification or successful demonstration alone may not establish suitability for intended use.
8.3.5 · make design outputs usable for delivery
Design outputs must be more than a completed file. This guide explains clause 8.3.5 through construction and software examples, showing how outputs connect with input requirements, downstream processes, acceptance criteria and essential product or service information. It helps teams recognise a technically developed result that still lacks what others need to provide it correctly.
8.3.6 · assess design changes before their effects spread
Design changes can affect decisions and outputs already relied on elsewhere. This guide explains clause 8.3.6 through manufacturing and software examples, including review, authorisation and actions to prevent adverse effects. It shows how to assess affected interfaces and retain a clear evidence trail without treating every edit as an identical engineering project.
Frequently asked questions
Does outsourcing design remove clause 8.3?
Not automatically. Examine retained responsibility and applicability, then control the external contribution. The organisation may still own requirements, approval and the resulting service or product.
Must every small change repeat every original activity?
Controls should reflect the nature and possible effects of the change. A proportionate evaluation still needs a defensible basis and appropriate authorisation.
Can design validation happen through a service pilot?
A suitable pilot can contribute when it evaluates the intended use under relevant conditions. Define what it will demonstrate and preserve the results and necessary follow-up.
Bring design decisions into the QMS
Sterling can help review design interfaces and implementation evidence across teams and sites, with agreed Effivity ISO & GRC automation software and employee learning. Certification remains an independent body's decision. Enrol in Documented Information Management for related control skills, or express interest in the coming-soon ISO 9001 QMS courses.
Return to clause 8 operational control or the requirements overview; next, examine external-provider controls.