ISO 9001 Clause 8.3: Design and Development

Clause 8.3 of ISO 9001 covers the design and development of products and services, and it works as a chain: you define the inputs (what the design has to satisfy), you control the work through review, verification and validation, and you produce outputs that can actually be used to make or deliver the thing. Get any link wrong and the failure is baked into every unit you produce from then on.

The piece almost everyone leaves out is buried in the inputs. Clause 8.3.3 requires you to consider the potential consequences of failure due to the nature of the products and services. It is a required input, not a nice-to-have, and it is rare to open a design file and find it genuinely addressed. That is the missing piece of the puzzle, and it is the one that matters most.

Tilt-shift miniature of a collapsed bridge with engineers at a drawing board tracing the failure back to the design — A design failure is not one defect. It is a defect specified into every unit you produce until someone catches it.

First: does clause 8.3 apply to you?

Before anything else, work out whether you design at all. This gets stretched in both directions: some businesses exclude 8.3 when they clearly do design, and others get told by a consultant that everything they do is design when it plainly is not.

The arbiter is the definition. ISO 9000 defines design and development as a set of processes that transforms requirements into more detailed requirements. That is the test. Are you taking a general requirement and producing a more detailed specification that did not exist before?

Engineers, architects, drafters and product developers are doing exactly that, and 8.3 applies squarely to them.

Now take a shop assistant in a clothing store. They deal with customers, interpret what the customer wants, and select and combine garments to achieve a satisfied customer. By a loose reading that looks like “configuring a solution to customer requirements.” But nobody would sensibly call them a designer, and the reason is that they are not producing any new detailed requirements. Every garment already has its specification. The assistant is applying what exists to a customer need.

The same logic covers a great many operational businesses. If you install, assemble or set up existing equipment in known configurations to achieve an intended outcome, you are applying specifications that already exist rather than creating them. That work is properly controlled by clause 8.2, where you determine and review the requirements for the products and services you will provide, and clause 8.5, where you carry out the provision under controlled conditions using documented information that defines the characteristics and the results to be achieved. Those clauses are designed for exactly this, and they cover it well.

Where it does tip into design is when the configuration is genuinely novel: nobody has specified this arrangement before, the parameters have to be worked out rather than looked up, and the output is a new specification that others will build or deliver from. The word doing the work in “known configurations” is known. Once you are determining the configuration for the first time and it becomes the basis for provision, you are transforming requirements into more detailed requirements, and 8.3 has arrived whether you call it design or not.

So the honest position is this. Excluding 8.3 is entirely legitimate, and common, where the design has been done by someone else (the client, the manufacturer, the standard, the original designer) and you are applying it. Excluding it is not legitimate where your business is the one working out the detail that did not previously exist. Get that determination right, record the reasoning in your scope, and you will not be arguing about it at audit.

One practical warning. Auditors arrive with their own preconceived interpretation of this clause, and those interpretations vary more than they should. An auditor from a heavy-engineering background may treat almost any configuration work as design; another may accept an exclusion with barely a question. You will not change that, so do not rely on the determination being self-evident. State it clearly in your scope statement, and record the justification behind it: what you do, what you do not do, who produces the detailed specification you work from, and which clauses (8.2 and 8.5) control the work instead. A determination with reasoning attached is one an auditor has to engage with on the merits. A silent exclusion invites them to substitute their own view. Our guide to clause 4.3 sets out how to write that justification so it closes the question rather than opening it.

Design inputs: what the design has to satisfy

Inputs are the requirements the design must meet. Clause 8.3.3 asks you to determine the requirements essential for the specific type of product or service being designed, and it names what to consider:

Functional and performance requirements. What it has to do, and how well.
Information from previous similar designs. What you already learned last time, including what went wrong.
Statutory and regulatory requirements. The law, the building code, the electrical standard, the food safety requirement.
Standards or codes of practice the organisation has committed to implement.
The potential consequences of failure due to the nature of the products and services.

The first four are usually present in some form. The fifth is the one that gets skipped, and I will come back to it because it is the point of this article.

Inputs need to be adequate, complete and unambiguous, and conflicting inputs have to be resolved. That last requirement matters more than it sounds: a design brief that says “lightest possible” and “maximum durability” without resolving the tension between them pushes the decision down to whoever is drawing it, usually without a record of why they went the way they did.

The three controls people mix up

Clause 8.3.4 requires controls over the design process. Three of them get used interchangeably in conversation and they are not the same thing at all.

Review asks: is this design capable of meeting the requirements? It is a checkpoint at a planned stage to evaluate whether the design results are able to meet the requirements, and in engineering practice it is typically the peer review of the design files at a hold point, before the drawings are released for construction or manufacture. Its job is to catch problems while they are still cheap to fix.

Verification asks: did we build it right? It confirms that the design outputs meet the input requirements. It is an internal comparison: here is what we were asked to achieve, here is what we produced, do they match? Calculations checked, drawings reviewed against the spec, test results compared to the performance requirement.

Validation asks: did we build the right thing? It confirms that the resulting product or service is capable of meeting the requirements for the specified application or intended use. Verification compares the design to the brief. Validation compares the finished thing to reality: does it work in the customer’s actual conditions, with their actual users, doing the actual job?

A design can pass verification and fail validation. That is the expensive scenario: you built exactly what the specification said, and the specification was wrong. Anyone who has delivered a technically compliant system that the client could not use has lived this.

The example running through the table below is a steel mezzanine storage platform designed for a warehouse, with a design load of 5 kPa and people and plant working underneath.

Control	The question it answers	What it compares	Example: mezzanine platform
Review	Is this design capable of meeting the requirements?	The design as it stands, against the requirements, at a planned stage	Before the drawings are issued for construction, a competent peer reviews the design files: the model, the calculations and the drawing set. Comments are raised, actions assigned and closed out, and the drawings do not go to IFC status until they are resolved.
Verification	Have all the design inputs been addressed, and do the outputs achieve them?	Design outputs against design inputs	A check that every input has been carried through and met: the 5 kPa live load, the deflection limit, the applicable structural standards, the stair and handrail requirements, and the extra rigour called for by the consequences of failure. Recorded as a dated, signed verification against the design brief.
Validation	Does the resulting product or service meet the requirements for its specified application or intended use?	The completed product or service against its real intended use	Activities that confirm the installed platform is fit for the use it was designed for: engineering certification of the completed work, the relevant building certification or occupancy certification where the work requires it, and confirmation in service that it suits the actual application.

Review, verification and validation are three separate controls with three separate records.

Validation is the step most often dropped, usually because the design passed verification and everyone assumed the job was done. But verification only proves you built what the brief asked for. If the brief said 5 kPa and the client’s actual stock loads one corner to 7 kPa, the design is verified and wrong, and no amount of calculation checking will reveal it. Only testing against reality will.

Retained documented information on all three is required. In practice that means dated review records with comments and their close-out, verification records showing which inputs were checked against which outputs and by whom, and validation evidence that the finished thing is fit for its intended use, which may be certification, commissioning results, trials or confirmation in service. Clause 8.3.4 also notes that the three have distinct purposes and can be conducted separately or in any combination, so one activity can satisfy more than one control provided each purpose is genuinely addressed and evidenced.

Design outputs: what has to come out the other end

Clause 8.3.5 requires outputs that:

meet the input requirements
are adequate for the subsequent processes for provision of products and services
include or reference monitoring and measuring requirements, and acceptance criteria
specify the characteristics of the products and services that are essential for their intended purpose and their safe and proper provision

The third and fourth points are where design connects to the rest of your system. If the output does not say how the thing will be checked and what “good” looks like, then your production or delivery team is inventing acceptance criteria on the fly, and your inspection records are measuring against a standard nobody agreed.

“Safe and proper provision” is a quiet phrase carrying a lot of weight. It is the standard asking you to design for how the thing will actually be made, installed, used, maintained and eventually disposed of, not just how it performs on paper.

Design changes: where control quietly disappears

Clause 8.3.6 requires you to identify, review and control changes made during, or subsequent to, the design and development, to the extent necessary to ensure there is no adverse impact on conformity.

This is where a controlled design most often comes undone. The original design goes through the full process, then three months of site changes, client requests and “we had to substitute that fitting” happen informally. Every one of those changes is a design decision, and each one should be re-verified against the original inputs. Retained information on the changes, the results of reviews, the authorisation and the actions taken to prevent adverse impacts is required.

If you audit one thing in your own design process, audit the changes. The original design is usually fine. The changes are where the risk lives.

The missing piece: consequences of failure

Now back to clause 8.3.3.

The standard requires you to consider, as a design input, the potential consequences of failure due to the nature of the products and services. In plain terms: before you design it, work out what happens if it fails, and let the answer shape how much rigour you apply.

This single input is what should drive everything else in the clause. A failure that means a customer is mildly annoyed justifies a light-touch design process. A failure that drops a load, contaminates a batch, exposes personal data, collapses a structure or injures the person using it justifies far more: more review, independent verification, physical validation, tighter acceptance criteria, and controls on every subsequent change.

Most design files I audit apply the same level of control to everything, because nobody ever asked the question. That is how businesses end up over-engineering the trivial and under-engineering the dangerous.

Asked properly, it is a short conversation with a long payoff:

What are the realistic failure modes of this design?
Who is harmed, and how badly, if each one occurs? Consider the user, workers, the public, the environment and the customer’s own operations.
How likely is it, and would we detect it before it caused harm?
Given those answers, how much review, verification and validation is proportionate?
Which characteristics are so critical that they must be specified as essential for safe and proper provision, and inspected every time?

For higher-risk designs this becomes a formal exercise: an FMEA, a HAZOP, a design risk assessment, whatever suits your industry. For most businesses, a documented conversation at the start of the project, revisited at each design review, is enough to satisfy the clause and vastly improve the outcome.

In Australia this is not just conformity, it is compliance

There is a second reason to take the consequences-of-failure input seriously, and it has nothing to do with your certificate. In Australia, safe design is a legal duty, not just a clause in a quality standard. Under the model Work Health and Safety Act, a person conducting a business or undertaking that designs plant, substances or structures must ensure, so far as is reasonably practicable, that what they design is without risks to the health and safety of the people who will construct it, use it, maintain it, and eventually demolish or dispose of it, and of anyone in the vicinity. The Act also requires that any necessary calculations, analysis, testing or examination be carried out, and that adequate information about the design, its intended purpose and the conditions necessary for safe use be passed on to whoever receives it. Safe Work Australia’s Safe Design of Structures Code of Practice sets out how regulators expect that duty to be discharged.

Read those duties next to clause 8.3 and the overlap is obvious. The safe-design risk assessment is the consequences-of-failure input. The calculations, analysis and testing are verification. The information you must pass on about intended purpose and safe use is the clause 8.3.5 output that specifies the characteristics essential for safe and proper provision. So a design process built properly for ISO 9001 is largely the same process that discharges the WHS duty, which is worth knowing, because a weak one exposes you on both fronts at once: a non-conformity at audit, and a regulator asking what you did as a designer if someone is hurt. If you want the wider picture on how those safety duties reach individuals, see our guide to officer due diligence and director liability, and our ISO 45001 work.

Why design failures cost more than any other kind

A design failure is not one defect. It is a defect specified into every unit you produce until someone catches it.

A process failure produces a bad batch. A design failure produces a bad product line, and it is discovered late, usually by the customer, often after hundreds or thousands of units have shipped or after the thing has been installed and commissioned. By then the remedies are recall, retrofit, rework, redesign, warranty claims, contractual damages, regulatory attention and reputation, and none of those are cheap. It is the clearest illustration of the cost of poor quality there is, and the reason design deserves more control than the effort most businesses give it.

The controls in clause 8.3 all exist to move the point of discovery earlier. Every one of them is an opportunity to find the problem while it is still a drawing rather than a fleet.

Clause 8.3: FAQs

What is the difference between verification and validation in ISO 9001?

Verification confirms the design outputs meet the design inputs: did we build it right? Validation confirms the resulting product or service meets the requirements for its specified application or intended use: did we build the right thing? A design can pass verification and still fail validation if the original requirements were wrong.

What is a design review?

A checkpoint at a planned stage of the design to evaluate whether the design results are able to meet the requirements, involving the people who need a say. Its purpose is to catch problems while they are still cheap to fix, and the results and any necessary actions must be retained as documented information.

Can you give an example of design review, verification and validation?

Take a steel mezzanine platform designed to carry 5 kPa. The review is the peer review of the design files (model, calculations and drawings) at a planned hold point before the drawings are issued for construction, with comments raised and closed out first. The verification confirms every design input has been addressed and achieved in the outputs: the 5 kPa live load, the deflection limit, the applicable structural standards and the statutory requirements, signed and dated against the design brief. The validation confirms the completed platform is fit for its specified application: engineering certification of the completed work, the relevant building or occupancy certification where required, and confirmation in service that it suits the actual use.

Is a peer engineer signing off drawings review or verification?

It depends on how your organisation has defined its design stages, and the standard deliberately leaves you that latitude. In most engineering practice, an independent peer reviewing the design files at a hold point before issue for construction is the design review: it evaluates whether the design is capable of meeting the requirements. The verification is the separate confirmation that every design input has been addressed and achieved in the outputs, which is often what the “checked by” signature on a drawing actually represents. Clause 8.3.4 includes a note making the position clear: review, verification and validation have distinct purposes, and they can be conducted separately or in any combination to suit your products and services. So the same peer, in the same sitting, may satisfy more than one control. What matters at audit is that each distinct purpose has been addressed and that you retain the records to show it, not which label you attach.

What are the required design inputs under clause 8.3.3?

The requirements essential for the specific type of product or service, considering functional and performance requirements, information from previous similar designs, statutory and regulatory requirements, standards or codes of practice you have committed to, and the potential consequences of failure due to the nature of the products and services.

Can we exclude clause 8.3 if we do not design anything?

Yes, and many organisations legitimately do. The test comes from the ISO 9000 definition: design and development transforms requirements into more detailed requirements. If the detailed specification already exists and you are applying it, that is not design. Installing or setting up existing equipment in known configurations is controlled by clause 8.2 (determining and reviewing requirements) and clause 8.5 (provision under controlled conditions), not 8.3. Record the reasoning for the exclusion in your scope.

We configure equipment for customers. Is that design?

Usually not, if the configurations are known and the specifications already exist. A useful comparison is a shop assistant who interprets what a customer wants and selects and combines garments to suit: they are applying existing specifications, not creating new ones, so they are not designing. It becomes design when the configuration is genuinely novel, the parameters have to be determined rather than looked up, and the result is a new specification that others will build or deliver from.

Do we have to do a formal FMEA?

No. The standard requires you to consider the potential consequences of failure, not to use a specific technique. For higher-risk designs a formal FMEA, HAZOP or design risk assessment is appropriate; for many businesses a documented discussion at the start of the project and revisited at each design review satisfies the requirement and delivers most of the benefit.

Where do most organisations fail a design audit?

Design changes. The initial design usually follows the process, then subsequent changes get made informally without review, verification or authorisation. Clause 8.3.6 requires those changes to be identified, reviewed and controlled, with the records retained.

How Streamline can help

Streamline designs, implements, audits and mentors practical ISO management systems for Australian businesses. If clause 8.3 applies to you, we will build a design process that fits how your business genuinely develops products and services, with the level of control matched to the consequences of failure rather than applied uniformly. We also provide the independent internal audit that tests whether your design controls survive contact with a real project. See our management system design services, or read more about ISO 9001.

Speak with an experienced ISO auditor

For help with clause 8.3 or any part of your management system, contact us. Email hello@streamline.business or call Brisbane 07 3667 8280, Sydney 02 8315 7780 or Melbourne 03 9034 3990.

General guidance only. This article is general information, not legal, financial, safety or compliance advice, and it does not take account of your specific circumstances. Streamline ISO Consultants are ISO management-system consultants, not lawyers or licensed advisers. Standards, laws and regulator guidance change, and details were correct only at the time of writing. Always seek professional advice before acting. See our full Disclaimer.