If there's one clause in ISO 9001:2015 that causes more confusion — and more audit nonconformances — than any other, it's Clause 8.3: Design and Development of Products and Services. In my eight-plus years working with 200+ clients across manufacturing, software, healthcare, and professional services, I've seen organizations either over-engineer this process to the point of paralysis or dangerously under-document it and get burned in audit.
This guide cuts through the noise. I'll walk you through every sub-clause of 8.3, explain what auditors actually look for, and give you a practical, step-by-step process you can implement and sustain.
What Is ISO 9001 Clause 8.3 and Does It Apply to You?
ISO 9001:2015 Clause 8.3 governs the design and development of products and services. It requires organizations to establish, implement, and maintain a design and development process that ensures the subsequent provision of products and services meets requirements.
The first question most organizations ask is: "Does this clause even apply to us?"
Here's the short answer: If your organization determines the design characteristics of a product or service — even partially — Clause 8.3 applies to you.
Many organizations incorrectly attempt to exclude Clause 8.3 under Section 4.3 (scope exclusions), but ISO 9001:2015 only permits exclusions when the requirement genuinely cannot be applied and its exclusion does not affect the organization's ability or responsibility to ensure conformity of products and services. Auditors scrutinize these exclusions carefully — and rightfully so.
Citation hook: ISO 9001:2015 permits scope exclusions of Clause 8.3 only when an organization neither designs nor develops products or services and when that exclusion does not affect its ability to deliver conforming outputs.
The Six Sub-Clauses of ISO 9001 Clause 8.3 at a Glance
Clause 8.3 is structured across six sub-clauses, each representing a stage or aspect of the design and development lifecycle:
| Sub-Clause | Title | Core Requirement |
|---|---|---|
| 8.3.1 | General | Establish and maintain a D&D process |
| 8.3.2 | Planning | Define stages, controls, and responsibilities |
| 8.3.3 | Inputs | Identify and manage all design inputs |
| 8.3.4 | Controls | Apply reviews, verification, and validation |
| 8.3.5 | Outputs | Ensure outputs meet input requirements |
| 8.3.6 | Changes | Control changes throughout and after D&D |
Understanding this structure is the foundation. Now let's go step by step through how to implement each one effectively.
Step 1 — Clause 8.3.1: Establish Your Design and Development Process (General)
The standard requires that you establish, implement, and maintain a design and development process. This is your framework — and it needs to be documented to the extent necessary to give you confidence that processes are carried out as planned (per Clause 4.4.2).
What this means in practice: - Create a documented procedure or process map for design and development - Ensure the process is appropriate to the nature, duration, and complexity of your D&D activities - Make the process known to everyone involved
Common mistake: Many organizations write a generic procedure that doesn't reflect their actual practice. Auditors will interview your design engineers — if what they describe doesn't match your documented process, that's a nonconformance.
My recommendation: Keep your procedure lean and accurate rather than exhaustive and aspirational. A two-page flowchart that people actually follow beats a 30-page manual that sits in a drawer.
Step 2 — Clause 8.3.2: Design and Development Planning
Planning is where most organizations struggle because the standard lists nine specific factors you must consider. ISO 9001:2015 Clause 8.3.2 requires you to determine:
- The nature, duration, and complexity of D&D activities
- Required process stages, including applicable D&D reviews
- Required verification and validation activities
- Responsibilities and authorities in D&D
- Internal and external resource needs
- The need to control interfaces between people involved
- The need for customer and user involvement
- Requirements for subsequent product/service provision
- The level of control expected by customers and other interested parties
What auditors look for: A Design and Development Plan (or equivalent documented information) that addresses these nine factors for each project or product family. This doesn't need to be a 50-page document — it can be a structured template that's completed at the start of each D&D project.
Citation hook: ISO 9001:2015 Clause 8.3.2 requires organizations to determine the nature, duration, and complexity of design and development activities and to document the controls, responsibilities, and verification activities specific to each project.
Practical tip: Create a Design and Development Plan Template with sections mapped directly to the nine factors above. For simple, recurring projects, a one-page form may be sufficient. For complex, multi-phase projects, expand accordingly.
Step 3 — Clause 8.3.3: Design and Development Inputs
Before any design work begins, you must identify and document the inputs. Clause 8.3.3 requires that inputs be:
- Adequate for the intended purpose
- Complete — no critical gaps
- Unambiguous — no contradictions
The standard specifies that inputs shall include: - Functional and performance requirements - Applicable statutory and regulatory requirements - Information derived from previous similar designs - Standards or codes of practice the organization has committed to follow - Potential consequences of failure due to the nature of the product/service
Why this step is critical: Design inputs are the foundation of your entire D&D process. If inputs are vague or incomplete, every downstream activity — from verification to validation — is compromised. In my experience consulting with over 200 clients, poorly defined inputs are the root cause of the majority of design-related quality escapes.
What auditors look for: Documented evidence that inputs were identified, reviewed for adequacy, and approved before design work commenced. This is typically captured in a design input specification, requirements document, or a populated design plan template.
Pro tip: Inputs should be version-controlled and reviewed whenever they change. Link your input documents to your document control process (Clause 7.5) to maintain integrity.
Step 4 — Clause 8.3.4: Design and Development Controls
This is the heart of Clause 8.3 and covers three critical control activities:
Design Reviews (8.3.4a)
Reviews are structured assessments conducted at defined stages of D&D to evaluate whether requirements are being met and to identify problems. Key requirements: - Conducted at suitable stages (you define what "suitable" means for your process) - Participants must include representatives of functions concerned with the design stage being reviewed - Results, including actions, must be documented
Verification (8.3.4b)
Verification confirms that design outputs meet design input requirements. This is an internal check — does what you designed match what you were asked to design?
Examples include: - Engineering calculations and analysis - Prototype testing against specifications - Design reviews comparing output to input - Simulation and modeling
Validation (8.3.4c)
Validation confirms that the resulting product or service meets requirements for the specified application or intended use. This is the real-world test — does it work for the customer?
Examples include: - Customer pilot programs - Field trials - Usability testing - Clinical evaluations (for medical devices/pharma)
The critical distinction between verification and validation:
| Activity | Question Answered | Performed By | Timing |
|---|---|---|---|
| Verification | "Did we build it right?" | Internal team | During D&D |
| Validation | "Did we build the right thing?" | End users or customers | Before release |
| Review | "Are we on track?" | Cross-functional team | At defined stages |
Citation hook: ISO 9001:2015 distinguishes verification — confirming design outputs meet design inputs — from validation, which confirms that the final product or service meets the requirements of its intended application or use.
Documented information required: Records of reviews, verification results, and validation activities are all required. These records are your audit evidence — without them, you cannot demonstrate conformance.
Step 5 — Clause 8.3.5: Design and Development Outputs
Once design work is complete, the outputs must be documented and controlled. Clause 8.3.5 requires that outputs:
- Meet the input requirements
- Are adequate for the subsequent processes of provision of products and services
- Include or reference monitoring and measuring requirements
- Specify the characteristics of the product/service essential for its intended purpose (including safe and proper use)
Typical design outputs include: - Engineering drawings and specifications - Material lists and bills of materials (BOM) - Manufacturing instructions and process specifications - Acceptance criteria and test procedures - Software code and documentation - Service delivery protocols - Product labeling and user documentation
What auditors look for: That outputs are approved before release, are linked back to the inputs they address, and include sufficient information for production or service delivery to proceed correctly without ambiguity.
Common mistake: Organizations release outputs without formal approval. Establish a gate or sign-off process — even a simple digital approval workflow — to ensure outputs are reviewed and authorized before they flow downstream.
Step 6 — Clause 8.3.6: Design and Development Changes
Design doesn't end at first release. Products and services evolve, customers change requirements, and regulations get updated. Clause 8.3.6 requires that changes made during or after design and development be:
- Identified, reviewed, and controlled
- Documented as retained information
- Reviewed for adverse effects on conformity and impact on already-delivered products/services
- Authorized before implementation
What this means in practice: - Every design change — no matter how small — must go through a controlled change process - Changes must be assessed for impact (what else does this change affect?) - Authorization must be documented
Engineering Change Orders (ECOs) or Change Requests are the typical mechanism for managing design changes. Ensure your ECO process is tied to your document control process and that change records are retained.
Regulatory note: For organizations in regulated industries (FDA, aerospace, pharma), Clause 8.3.6 overlaps significantly with regulatory change control requirements. Aligning your ISO 9001 design change process with regulatory change control procedures reduces duplication and audit burden significantly.
Documented Information Required Under Clause 8.3
One of the most common audit failures under Clause 8.3 is missing or inadequate documented information. Here's a consolidated reference of what the standard explicitly requires you to retain:
| Required Record | Sub-Clause |
|---|---|
| Design and development plan | 8.3.2 |
| Design inputs (adequate, complete, unambiguous) | 8.3.3 |
| Design review results and actions | 8.3.4 |
| Verification activity results | 8.3.4 |
| Validation activity results | 8.3.4 |
| Design outputs (approved before release) | 8.3.5 |
| Design change records (identification, review, authorization) | 8.3.6 |
What Auditors Actually Look For in Clause 8.3
Having guided 200+ organizations through certification and surveillance audits with a 100% first-time pass rate at Certify Consulting, I can tell you exactly what auditors zero in on:
-
Traceability from input to output. Can you demonstrate a clear line from what was required to what was designed? Auditors will pull a design file and trace it end to end.
-
Evidence of reviews at defined stages. Meeting minutes, review checklists, or sign-off records — auditors want to see that reviews actually happened with the right people in the room.
-
Distinction between verification and validation. Many organizations conflate these. Auditors will probe whether you understand the difference and whether your records reflect distinct activities.
-
Change control rigor. Post-release design changes are a major audit focus. Auditors will look for unauthorized changes or changes implemented without impact assessments.
-
Competency of D&D personnel. Under Clause 7.2, personnel performing design activities must be competent. Auditors may ask to see training records or qualifications for key design staff.
Practical Implementation: Building Your Clause 8.3 System
Here's a practical roadmap for organizations implementing or improving their Clause 8.3 compliance:
Phase 1: Foundation (Weeks 1–2)
- Determine scope applicability — do you design products or services?
- Identify all current D&D activities and product/service families
- Map the existing (informal) design process
Phase 2: Documentation (Weeks 3–4)
- Develop your Design and Development Procedure (or process map)
- Create a Design and Development Plan Template (covering all 9 factors of 8.3.2)
- Develop Input Specification and Output Approval templates
Phase 3: Controls (Weeks 5–6)
- Define review stages and establish cross-functional review teams
- Separate and document verification vs. validation activities
- Build or align your Engineering Change Order process for 8.3.6
Phase 4: Integration and Training (Weeks 7–8)
- Train all D&D personnel on the new process
- Integrate D&D documentation into your document control system (Clause 7.5)
- Run a mock internal audit against Clause 8.3 before certification
Clause 8.3 in Context: How It Connects to Other Clauses
Clause 8.3 doesn't operate in isolation. Understanding its connections to other clauses is essential for building a coherent QMS:
- Clause 4.4 (QMS Processes) — D&D is one of your key operational processes
- Clause 6.1 (Risk Management) — Design risk should feed into your 6.1 risk register
- Clause 7.1.6 (Organizational Knowledge) — Lessons learned from D&D are a key source of organizational knowledge
- Clause 7.2 (Competence) — D&D staff must be competent; document their qualifications
- Clause 7.5 (Documented Information) — All D&D records fall under your document control system
- Clause 8.5 (Production/Service Provision) — D&D outputs feed directly into 8.5 processes
- Clause 9.1.2 (Customer Satisfaction) — Validation results are a direct input to customer satisfaction monitoring
For a deeper look at how risk management connects to design, see our guide on ISO 9001 Clause 6.1 Risk-Based Thinking.
Industry-Specific Considerations for Clause 8.3
Manufacturing
Design outputs must include all specifications needed for production — drawings, tolerances, material specs, and acceptance criteria. Prototype testing is a common validation method.
Software Development
Agile and iterative development models are fully compatible with Clause 8.3. Map your sprints or iterations to D&D stages, and ensure user acceptance testing serves as your validation activity.
Professional Services / Consulting
Even service design falls under 8.3. If you're designing a new service offering — defining its scope, deliverables, and pricing structure — that's design and development. Your "output" might be a service description document or standard operating procedure.
Healthcare and Life Sciences
Clause 8.3 requirements map closely to FDA 21 CFR Part 820 design control requirements and ISO 13485:2016 Clause 7.3. If you're pursuing dual certification, aligning these processes early saves significant effort.
Key Statistics on Design and Development Quality
- According to ASQ research, approximately 70–80% of quality problems in manufacturing are attributable to design — not manufacturing execution. A robust Clause 8.3 process directly addresses this root cause.
- Studies in the product development field consistently show that fixing a design defect in production costs 10x more than catching it during the design phase, and up to 100x more after delivery to the customer.
- ISO Survey data indicates that over 1.1 million organizations worldwide are certified to ISO 9001:2015, and Clause 8.3 nonconformances remain among the top 10 most cited findings in third-party audits.
- Research published in the International Journal of Quality & Reliability Management found that organizations with formalized design review processes experienced up to 40% fewer post-launch design failures compared to those without structured review gates.
Final Thoughts: Get Your Clause 8.3 Process Right From the Start
Clause 8.3 is not just a compliance checkbox — it's one of the most powerful levers you have for building quality into your products and services from the ground up. A well-implemented design and development process reduces warranty claims, customer complaints, and costly re-work, while building the kind of confident, audit-ready quality culture that sustains certification long-term.
If you're unsure whether your current Clause 8.3 implementation is audit-ready, or if you're starting from scratch, I'm happy to help. At Certify Consulting, we've guided 200+ organizations across industries to first-time certification success — and we bring that same precision to every D&D process we help build.
For more on how to build your overall QMS documentation framework, explore our ISO 9001 Documentation Requirements guide.
Last updated: 2026-04-09
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.