ISO 9001 Design and Development Process: Proven Essentials

Plan. Run. Refine.

The ISO 9001 design and development process is the part of a quality management system that turns intention into product — and it is the part that most often runs on memory rather than method. Clause 8.3 exists to change that. It asks an organization to plan the ISO 9001 design and development process, define what the design must satisfy, control it as it moves, prove the result, and govern every change afterward.

Most organizations do not fail here because they lack talent. They fail because the ISO 9001 design and development process lives in the practice of two or three senior engineers and nowhere else. When those engineers are busy, on leave, or gone, the method goes with them. Everything below about the ISO 9001 design and development process is written to close that specific gap — not to restate the clause, but to describe what running it well actually looks like day to day.

This article is MSI's operational companion to the strategic pillar Design and Development Procedure: 7 Marks Most Never Meet. The pillar covers the structure of the procedure itself — the seven marks that separate a working document from a restatement of the standard. This article covers the how: the day-to-day tactics for running the ISO 9001 design and development process in practice, and what changes when the sixth edition of ISO 9001 publishes.

• The ISO 9001 design and development process lives in Clause 8.3 — six sub-clauses covering planning, inputs, controls, outputs, and changes.
• Record organization is the single most common weakness MSI observes across engineering departments after 28 years of audits.
• Nature, duration, and complexity determination arrived in the 2015 edition — many certified organizations still have nothing recorded against it.
• Design reviews are the primary control mechanism. They must be formal, recorded, and traceable to the inputs they test.
• Nonconforming outputs apply to documents and electronic files, not only physical product.
• ISO 9001 does not require a documented procedure for design — but without one, consistency across engineers is close to impossible to hold.
• The sixth edition of ISO 9001 is expected in September 2026, and its new quality-culture requirement changes who owns design discipline.

Why Does the ISO 9001 Design and Development Process Matter?

Quality. Consistency. Competitive Edge.

A well-structured ISO 9001 design and development process is not a compliance artifact. It is a proprietary business asset. Written down properly, it becomes a repeatable system that reduces product failure risk, shortens the distance between concept and launch, and gives customers a reason to believe quality was built in rather than inspected in afterward.

There is a second benefit that rarely gets named. When an organization documents how its best engineers actually work, that document becomes intellectual property the organization owns. MSI has seen this play out directly in engineering practices — the same pattern described in ISO for engineering firms, where a documented design method outlasted the individuals who invented it.

The inverse is equally true. Product problems that surface late in the ISO 9001 design and development process — a component that cannot be sourced, a specification that contradicts a customer requirement, a change nobody reviewed — can usually be traced back to a design process that was informal at the point where it needed to be explicit. Clause 8.3 exists precisely to force that explicitness.

“After 28 years of ISO consulting, one of my favorite topics to interview, draft procedures for, train on, and audit is the design process. This is not a process you just want to get by with — it's a proprietary process to be protected.”

— Diana Lynn, President, MSI

Organizations that want the process to do more than satisfy a requirement should also read ISO 9004:2018, the guidance standard on sustained success. It treats design capability as an organizational strength to be developed, not a clause to be met — a framing MSI carries into every ISO consulting engagement involving design.

What Does ISO 9001 Clause 8.3 Actually Require?

Inputs. Controls. Outputs. Changes.

Clause 8.3 covers the full lifecycle of the ISO 9001 design and development process. It is not a single requirement but a set of six interconnected sub-clauses, each carrying specific evidence an auditor will ask to see. Here is what each means in practice. The full clause text is available from ISO 9001:2015 on ISO.org.

8.3.1 — General: Does the Process Exist at All?

The organization must establish, implement, and maintain an ISO 9001 design and development process appropriate to what it produces. The standard stops short of demanding a written procedure. That permissiveness is deliberate — ISO 9001 gives organizations latitude on documentation that ISO 13485:2016 does not, since the medical device standard names design and development as a required documented procedure outright.

Latitude is not the same as advice. A process that runs six months to a year across multiple engineers, suppliers, and customers cannot stay consistent on memory. MSI's position, after 200+ audits attended, is that the organizations without a written procedure are the organizations where each project lead runs design differently — and where that difference is visible in the records long before anyone calls it a finding.

8.3.2 — Planning: Have You Defined Your Stages?

Planning is the part of the ISO 9001 design and development process where most organizations have the thinnest evidence, especially those certified before 2015. The 2015 edition added a requirement to determine the nature, duration, and complexity of design activities. In practice that means recording a judgment: is this design new territory or a familiar variant, how long will it realistically take, and how much complexity does it carry?

That judgment then drives everything else. A low-complexity variant might justify two design stages; a genuinely novel product might need five. Planning must also define verification and validation activities for each stage, responsibilities and authorities by title, interface control between the functions involved, and the resources — internal and external — the project will consume. MSI's broader treatment of this is in product development and design planning strategies.

8.3.3 — Inputs: What Are You Designing To?

Design inputs are the requirements the product must satisfy. The standard requires them to be complete, clear, and unambiguous, and requires conflicts between them to be resolved before design work proceeds. That last part is the one organizations skip. Two inputs that contradict each other — a weight target and a material specification, a cost ceiling and a performance floor — must be reconciled on the record, not quietly traded off at the bench.

Required inputs include functional and performance requirements, applicable statutory and regulatory requirements, information from similar previous designs, and the potential consequences of failure. That last item is where risk enters design formally rather than as an afterthought.

What auditors look for: evidence that inputs were reviewed and approved before design activity began. A dated approval on the input set is the simplest way to hold that ground.

8.3.4 — Controls: How Is the Work Governed?

Controls keep the design on track. MSI uses design reviews as the primary control — formal checkpoints where the team confirms the design still meets its inputs, surfaces problems, assigns actions, and authorizes progress to the next stage.

Each review must address verification and validation appropriate to that stage. Early reviews may carry verification only; validation often cannot apply until a representative build exists. The discipline is to address both explicitly at every review, recording “not applicable at this stage” as a decision rather than leaving a blank. Blanks read as omissions. Decisions read as control.

8.3.5 — Outputs: What Does the Design Produce?

Design outputs are the documents and artifacts the ISO 9001 design and development process produces — drawings, specifications, bills of material, test reports, acceptance criteria, and the information needed for production and service provision. Outputs must be traceable back to inputs. If an input set a performance level, some output must demonstrate that level was achieved.

Traceability is where a simple matrix earns its keep. One column for each input, one row for the output that satisfies it, and the gaps become visible before anyone else finds them. The handoff from design output into manufacturing is covered in MSI's guide to the production and service provision procedure.

8.3.6 — Changes: How Are Modifications Controlled?

Once a design is released to manufacturing, changes must run through a formal Engineering Change Notice process. The standard requires records of the nature of the change, the results of the review, who authorized it, and the actions taken to prevent adverse effects.

The failure mode here is the change that nobody classified as a design change. A material substitution made in purchasing, a supplier swap that alters a tolerance, a firmware update issued as maintenance — each can move the product away from its verified state without ever entering the change process. Naming those triggers explicitly in the procedure is what closes the hole. ISO 10007:2017 on configuration management is the guidance standard worth reading alongside 8.3.6.

Does the ISO 9001 Design and Development Process Need a Written Procedure?

Optional. Advisable. Decisive.

This is the most common question MSI receives about the ISO 9001 design and development process, and the honest answer has two halves. The standard's requirement is genuinely permissive. Nothing in Clause 8.3 obliges an organization to produce a document titled “Design and Development Procedure.”

The operational reality is different. Consider what a procedure for the ISO 9001 design and development process is actually for. It is not there to satisfy an auditor. It is there so that the second project lead runs design the way the first one does — so that stage gates mean the same thing on every project, so that a design review is a defined event rather than whatever the calendar invite happened to say, and so that a new engineer can be brought to competence in a week instead of a year.

There is a further consideration for organizations that also hold or intend to hold ISO 13485. That standard predates the harmonized clause structure and requires documented procedures where ISO 9001 leaves the choice open, with design and development at Clause 7.3 rather than 8.3. An organization running one system against both standards will need the written procedure regardless — the decision is only whether to write it once, deliberately, or twice under pressure.

What Separates a Working Procedure From a Restatement

Most design procedures MSI reads during implementation are restatements. They paraphrase Clause 8.3 back at the reader, leave every threshold undefined, and hand every genuinely hard decision back to whoever picks up the work. A procedure that says design reviews “shall be conducted at appropriate intervals” has decided nothing.

A working procedure names the trigger that starts a design project, names one accountable owner with defined alternates, states thresholds as numbers rather than intentions, treats the record as the gate rather than a report written afterward, defines what happens when the normal path fails, and can be taught in one sitting. MSI's full treatment of that standard is in the seven marks of an effective ISO procedure.

What Is the Biggest Weakness MSI Sees in the ISO 9001 Design and Development Process?

Records. Organization. Consistency.

After 28 years of implementing and auditing the ISO 9001 design and development process — supporting 80+ certifications and attending 200+ audits — the pattern MSI sees most often is not a missing procedure or a skipped design review. It is disorganized records.

“The biggest weakness I have observed throughout my years is the lack of organization in records and a lack of consistency across engineering departments.”

— Diana Lynn, MSI

Projects inside the ISO 9001 design and development process run three weeks or eighteen months. Across that span, drawings move between engineers, suppliers send specification sheets, customers revise requirements, and regulatory documents get updated underneath the work. Without a consistent electronic filing structure, reconstructing what happened becomes archaeology — and the reconstruction usually happens at the least convenient moment.

MSI's recommendation is deliberately simple: organize electronic design files using the major headings of the standard as the folder structure. Planning. Inputs. Reviews. Verification. Validation. Outputs. Changes. When someone asks for design planning documents, everyone knows where to look — including the person asking.

The second half of the weakness is consistency. Two project leads, two methods, two record sets that do not resemble each other. That is a documentation problem wearing an engineering costume, and it resolves the same way every time — by writing the method down and training against it.

What Are the Best Practices for the ISO 9001 Design and Development Process?

Plan. Control. Document.

The six practices below come from MSI's audit-attended experience running the ISO 9001 design and development process across 80+ certifications. Each targets a pattern MSI has seen repeat across surveillance cycles.

1. Define Your Stages Before Any Design Begins

Establish the formal stages of your ISO 9001 design and development process company-wide — feasibility, definition, design, prototype, final review, or whatever terminology fits the work. Make them consistent across projects. Exceptions for specific designs are fine when justified in the planning document, but the default set belongs in the procedure so every engineer starts from the same framework rather than inventing one.

2. Run a Design Plan on Every Project

A design plan is a living document capturing every planning element: nature, duration, and complexity; responsibilities by title; resources; interface control; risk identification; the input set; and approval to proceed at each stage. It looks heavy on first reading. It prevents the most common problems before they happen, and it should be updated before every design review rather than reconstructed after the project ends.

MSI develops this plan with clients during implementation engagements. Organizations building the system themselves can start from the same architecture — the ISO 9001 procedure templates and guides package includes the design procedure template alongside the full editable Word library, so the plan structure and the procedure that governs it arrive already reconciled with each other.

3. Run Formal Design Reviews — Not Just Team Meetings

There is a real difference between a team meeting about a design and a formal design review inside the ISO 9001 design and development process. A formal review has a published agenda, documented attendance, an explicit statement of verification and validation status, action items assigned to owners with due dates, and a record retained as a controlled document.

Practical tip: use the management review agenda format as the starting point for design review minutes and reformat it for the design context. The structure — topics, discussion, decisions, actions — transfers directly.

4. Separate Verification From Validation Deliberately

These two terms are confused more often than any other pair in Clause 8.3. Verification confirms the output matches the input: the drawing calls for 10mm and the part measures 10mm. Validation confirms the product works as intended in its actual use environment — it fits, it functions, it performs under the conditions the customer will impose on it.

Both are required. Both must be addressed at each stage, even when the honest answer at an early stage is “not applicable yet.” Organizations that record only one of the two nearly always turn out to be doing verification and calling it validation.

5. Treat Documents as Nonconforming Outputs Too

The 2015 edition expanded nonconforming outputs beyond physical product. A drawing that fails to address purchasing requirements is a nonconforming output. A bill of materials carrying an eighteen-month lead-time item that makes the design unbuildable is a nonconforming output. When one is identified, mark the electronic file unmistakably — rename it with OBS or HOLD — so nobody downstream uses it as a source document while corrections are in progress.

6. Carry Risk Through Every Review, Not Just the First

Risk identification is not a kickoff activity in the ISO 9001 design and development process. The risk register should be reviewed at every design review, updated when new risks emerge, and cross-referenced in corrective action records when a risk materializes. If a corrective action addresses something already on the register, note the linkage. If it reveals something new, add it.

Device organizations carry a heavier version of this obligation through ISO 14971:2019 and its risk management file. For the measurement side of design discipline, see MSI's work on design control metrics, and for the wider improvement frame, optimizing the product design process.

How Will ISO 9001:2026 Affect the ISO 9001 Design and Development Process?

Stable. Sharpened. Owned.

The revision has moved through its full development cycle. The Final Draft International Standard was released to ISO/TC 176/SC 2 members for ballot, with the ballot closing on 9 July 2026. At FDIS stage only editorial changes remain possible, so the technical content is settled. ISO's own project page for the revision anticipates publication in September 2026.

For organizations running an ISO 9001 design and development process, the practical message is reassuring and slightly uncomfortable at the same time. Reassuring, because nothing in the sixth edition asks anyone to dismantle a working ISO 9001 design and development process. Planning, inputs, controls, outputs, and change control survive as the architecture they have always been. An organization with clean design records today will have clean design records after transition.

The Culture Requirement Lands on Design First

The uncomfortable part is the new leadership obligation around quality culture. Culture requirements sound soft until you ask where they get tested, and design is where they get tested first — because the ISO 9001 design and development process is where schedule pressure and quality discipline collide most directly.

A design review skipped to hold a launch date is a culture signal. A stage gate approved with an open action nobody intends to close is a culture signal. A material substitution waved through because the alternative was a four-week delay is a culture signal. None of those show up as a Clause 8.3 problem on paper. All of them show up in the product eventually, and under the sixth edition leadership is expected to be able to speak to them.

MSI's practical guidance is to start recording the decisions, not just the outcomes. When a stage gate is approved with conditions, write the conditions and the rationale. When a review is deferred, record who authorized the deferral and against what risk. Those records are the evidence a culture requirement is actually met — and they cost nothing to create if the design plan already has a place for them.

A transition period is expected once the standard publishes, with confirmation to follow from the accreditation community. ANAB and the wider accreditation network — now unified into Global ACI, which replaced IAF and ILAC — will publish transition guidance for certification bodies as it becomes available. Nothing about the current edition changes before then: ISO 9001:2015 remains the version organizations are certified against today.

Who Should Be Involved in the ISO 9001 Design and Development Process?

Leadership. Engineering. Quality.

The standard requires responsibilities and authorities for the ISO 9001 design and development process to be defined — by title, not by name. People change roles and leave organizations. A procedure that says “John Smith approves design releases” creates a problem the day John leaves. “Engineering Director” transfers automatically.

Typical roles in a mid-size organization include the President or VP of Engineering at key approval junctions, a Design Project Lead, design engineers, the Quality Manager, Procurement, and — where the product touches them — Marketing and a customer representative. External resources such as testing houses, prototype suppliers, and regulatory specialists belong in the design plan too, named by function.

One role in the ISO 9001 design and development process deserves particular attention: the person who can stop a design from advancing. If nobody holds that authority explicitly, stage gates become formalities. Naming the stop authority by title, and naming the alternate for when that person is unavailable, is one of the highest-value lines in the whole procedure. The relationship between that authority and organizational habit is explored in aligning design and development procedures with company culture.

How Often Should You Audit Your ISO 9001 Design and Development Process?

Frequently. Formally. Thoroughly.

If an organization designs products or services, the ISO 9001 design and development process is a key process and deserves proportionally more internal attention than processes carrying less risk. Annual is the floor, not the target. Where multiple design projects run concurrently, a mid-cycle look at one active project tells you more than a comprehensive review of a project that closed last year.

MSI's internal audit services are structured around exactly this kind of process-level scrutiny, and MSI's ISO 9001 overview shows where Clause 8.3 sits relative to the rest of the system.

Improvement of the ISO 9001 design and development process belongs in management review. Set a quality objective tied to design — on-time completion of design stages, first-pass verification rate, or the proportion of changes originating after release — and track it over time. A design process that is measured tends to become a design process that improves. ASQ's ISO 9000 resources and the accreditation requirements published by ANAB for quality management system certification bodies both help frame what independent scrutiny is looking for.

ISO 9001 Design and Development Process: Common Questions

Answered. Clearly. From Experience.

The eight questions below are the ones MSI hears most often from organizations building or improving their ISO 9001 design and development process. Each answer is drawn from engagements rather than from the standard's wording.

Does ISO 9001 require a written design and development procedure?

What is the difference between design verification and design validation?

Does Clause 8.3 apply to every organization?

How many design stages does ISO 9001 require?

How does the ISO 9001 design and development process differ from ISO 13485?

What records should the design process produce?

Will ISO 9001:2026 change Clause 8.3?

Where do most design and development findings actually come from?