Design and development of products and services

In plain words

This clause applies when you yourself determine what a product or service will be like — when you turn a requirement into a specification that did not exist before. Then 8.3 demands a controlled path: plan stages and responsibilities (8.3.2), fix the inputs first (8.3.3), steer along the way (8.3.4), deliver usable results (8.3.5) and keep changes under control (8.3.6).

The heart of the steering is two different questions: verification — does the result meet the inputs? — and validation — does it work in real use? A design can meet every specification and still fail the everyday. That is why the standard demands both checks, not one.

Before all that stands the honest question: do we design at all? Whoever manufactures exclusively to customer drawings, trades, or delivers standardised services does not design — and declares 8.3 not applicable in the scope (4.3), with reasons. This page explains both: the clause and the boundary.

Why this requirement exists

Design errors are the most expensive class of error: a mistake in the specification multiplies into every part made and every service delivered. In a review it costs an hour, in series production a recall. 8.3 forces the invisible thinking work into checkable steps — not to slow creativity, but so that errors surface while they are cheap.

And the flip side the same clause guards: whoever quietly co-designs and still excludes 8.3 gives up the safety net exactly where the risk is greatest. The exclusion question is therefore a question of honesty — the same one that begins at the scope (4.3).

What good looks like

Whoever designs plans in stages that fit the project — the standard prescribes no waterfall; agile work fulfils 8.3 too, as long as inputs, checks and approvals are recognisable. The inputs stand before solutions are built: what it must do, what law and standards demand, what previous projects taught — contradictions are resolved, not postponed. Along the way: reviews with consequences, verification against the inputs, validation in the context of use. The results are such that the next stage can work with them — with acceptance criteria. And changes after an approval pass through assessment and authorisation.

Whoever does not design keeps the boundary clean: feasibility and manufacturing knowledge flows back to the customer as a proposal and returns as their changed specification — never as a silent decision of your own.

What changes as you grow: From around 50 people — with products of your own — you need named project leads, minuted reviews and planned interfaces to purchasing and production. From 100–250 people: a development process with milestone gates, a design FMEA (a systematic failure analysis) where industry or customers demand it, configuration management. And at every size: whoever starts to design brings 8.3 into the system deliberately — that is a change to the QMS and belongs planned (6.3).

The minimum to pass

If you design:

• Per project, a plan with stages, checks and responsibilities — sized to the project.
• Documented inputs before designing starts.
• Verification and validation demonstrably done — as two questions, not one.
• Results approved; changes after that with assessment and authorisation.

If you do not design:

• A justified exclusion in the scope (4.3) — and a practice that holds up to the justification.

What an auditor asks for

• One project told end to end: the plan, the input list, a review minute with consequences, the verification record, the validation in real use.
• A change after approval — with assessment, authorisation and the way back into production or delivery.
• With an exclusion: the scope with its justification — and order documents showing that specifications come completely from the customer.
• The auditor’s cross-check: website and offers — does it say “engineering” or “design” there while 8.3 is excluded?
• In conversation: who decides at your company what the product will be like? The answer locates design responsibility — inside or outside.

Common traps

• “We only adapt.” Whoever fixes dimensions, materials or procedures the customer never approved is designing — just without control. Adaptations add up to design.
• Verification confused with validation. All tests green means: the specification is met. Whether the specification demanded the right thing, only real use shows — the most expensive errors live between the two questions.
• Moving inputs. Requirements that are never pinned down make every review worthless — the project chases a target that moves with it.
• The silent designer. Sales promises “we’ll solve that for you”, and nobody notices that 8.3 just woke up. The boundary must be known to everyone, not only QA.
• Exclusion out of convenience. Deselecting 8.3 because it looks like effort — not because it does not apply. The most expensive form of self-deception, and on the shop-floor tour the shortest-lived.
• Results without a production view. Designing what your own shop can neither measure nor make. 8.3.5 demands usable results — usable for those who work after you.

Worked example

Berger Präzisionsteile GmbH does not design — and has thought this through rather than merely claimed it. The scope carries the exclusion with its reason: manufacture is exclusively to customer-supplied drawings; feasibility checks take place within order review (8.2). The boundary is lived daily. When Marco proposed a material change for a milled part — easier to machine, same strength —, the proposal went in writing to the customer’s design office and came back as a new drawing revision; only then was it produced. Manufacturing knowledge flows in, design responsibility stays with the customer. The order-review checklist states the rule explicitly: technical proposals always go to the customer as a query, never into production as a silent deviation.

In the certification audit exactly this held up. “You did initiate a material change — is that not designing?” Frau Berger showed the correspondence and the customer’s revision: proposal yes, decision no. And should the assembly work (4.3) one day grow into a catalogue product of Berger’s own, Berger knows what happens then: the exclusion falls, and 8.3 enters the system deliberately via planning of changes (6.3). An exclusion is a snapshot of the business model — not a possession.

<!-- easo:worked_example profile=service -->

Klarwerk GmbH, by contrast, does design — for example the customer portal for its largest client. The plan: four stages (concept, two build stages, introduction), a review at the end of each — deliberately not by the one certified engineer alone, but with the second developer and the customer’s IT lead. The inputs stood before the first line of code: the requirements specification, the data-protection requirements including the deletion concept, the interface to the merchandise system, the lessons from the predecessor project. Verification ran as automated tests against the specification; validation in two pilot weeks with the customer’s real clerks — where it emerged that approving took too many clicks in daily use: an insight no test finds. The results: deployment documentation, admin manual, training material — what operations and support work with afterwards. And mid-project the change request single sign-on: assessed (effort, date, security), commissioned, stage plan re-approved — 8.3.6 instead of silent scope creep.

← All ISO 9001 topics · To the knowledge hub