Design and development planning

ISO 9001:2015 Clause 8.3.2 requires you to plan design and development by defining appropriate stages and controls, scaled to the nature, duration, and complexity of the work. Operationally, you need a repeatable planning method that sets responsibilities, resources, interfaces, and verification/validation activities, plus evidence that each design project followed the plan. ¹

Key takeaways:

• Scale your design controls to risk and complexity, not a one-size-fits-all template. ¹
• Define stages, ownership, interfaces, and V&V points up front, then manage changes against that plan. ¹
• Auditors will look for objective evidence per design project: plans, reviews, V&V records, and controlled changes. ¹

“Design and development planning” is where ISO 9001 stops being abstract and becomes a build discipline. Clause 8.3.2 expects you to decide what your design process looks like (stages and controls) before you start building, and to make those decisions based on the nature of the work, how long it will run, and how complex it is. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to treat it like a governance control: define a design planning standard, require it at project kickoff, and make it auditable through consistent artifacts. This is not limited to physical product engineering. It also applies to software, configuration changes that alter requirements, customer-specific designs, and process/service design where “design outputs” affect conformity or customer outcomes. ¹

Your goal is simple: show that your organization consistently plans design work in a way that prevents missed requirements, unmanaged interfaces, and late discovery of defects. That means a documented approach plus project-level evidence that the approach was followed and kept current when changes occurred. ¹

Regulatory text

ISO 9001:2015 Clause 8.3.2 states: “In determining the stages and controls for design and development, the organization shall consider the nature, duration and complexity of the activities.” ¹

What the operator must do: define design stages and the controls applied at each stage, and make sure those stages/controls are appropriate for the specific design effort. The planning must also address practical execution needs such as verification and validation activities, roles and responsibilities, resource needs, and interface controls, because those are part of what it means to “determine the stages and controls” in an auditable way. ¹

Plain-English interpretation (requirement-level)

You must plan design work before and during execution. The plan must:

• Break the work into stages you can manage (e.g., concept, requirements, detailed design, build/configure, test, release).
• Specify controls at each stage (reviews, approvals, verification, validation, change control).
• Assign accountable owners and required resources.
• Identify and control interfaces (handoffs between teams, third parties, customer inputs, manufacturing, DevOps, regulatory, etc.).
• Match the rigor of the plan to how risky/complex/long the work is. ¹

Auditors typically interpret this as “show me you didn’t improvise your design governance.” The clause does not force a specific methodology (waterfall, agile, stage-gate), but it does force you to define how your method produces controlled outcomes. ¹

Who it applies to (entity and operational context)

This requirement applies to any ISO 9001-certified (or ISO 9001-aligned) organization that performs design and development activities affecting product or service conformity. ¹

Common operational contexts:

• Product companies: new product introductions, product line extensions, changes that affect form/fit/function, safety, labeling, or performance.
• Software and SaaS: feature development, architecture changes, security-impacting changes, and releases that alter customer requirements.
• Services organizations: design of service delivery models, customer onboarding processes, or tooling/configuration that affects service outputs.
• Regulated supply chains and third parties: outsourced design steps, contract manufacturers providing design input, or third-party software components embedded into your product. You still own the plan and interface controls. ¹

What you actually need to do (step-by-step)

1) Define your standard “design planning” procedure

Create a documented procedure or work instruction that answers:

• What qualifies as “design and development” in your QMS scope.
• Who can approve design plans and stage transitions.
• The minimum required planning elements (stages, controls, V&V, responsibilities, resources, interfaces).
• How changes to the plan are controlled once work starts. ¹

Practical tip: keep the procedure stable and push variability into project-level design plans.

2) Create a scalable design plan template (with a scaling rule)

Build a template that teams can fill in quickly. Include:

• Project scope and design objectives
• Defined stages and entry/exit criteria per stage
• Required reviews and approvers
• Verification activities (what proves outputs meet inputs)
• Validation activities (what proves the result meets intended use)
• Roles (RACI works well) and resource plan
• Interfaces and handoffs (internal and third party)
• Configuration management and change control approach
• Required records and where they live (system of record) ¹

Then add a scaling rule so rigor matches complexity:

• Low complexity: fewer formal reviews, simpler V&V, lighter documentation.
• High complexity or long duration: more defined gates, stronger interface control, deeper V&V planning, more frequent formal reviews.

Your scaling rule can be qualitative (risk tiers) as long as it is consistently applied and auditable. ¹

3) Make planning a required gate at kickoff

Operationalize with a “no plan, no build” expectation:

• Require an approved design plan before requirements baselining or sprinting begins.
• Require explicit ownership for interfaces (e.g., Design-to-Manufacturing, Product-to-Security, Engineering-to-Quality, Engineering-to-third party). ¹

If you run agile, treat the design plan as a “release plan + control plan” that stays current, not as a static document.

4) Tie verification/validation to stages (and make it testable)

Clause 8.3.2 expects you to determine controls. In practice, V&V are the controls auditors can see. Map:

• Verification to requirements and design outputs (reviews, inspections, unit tests, static analysis, peer review, design calculations).
• Validation to intended use (user acceptance tests, field trials, simulations representative of use, customer acceptance criteria).

Document who signs off, what “pass” means, and what happens on failure (rework loop and re-approval). ¹

5) Control interfaces, especially with third parties

Interface failures cause missed requirements and late defects. Your plan should list:

• Inputs/outputs exchanged with each team or third party
• Timing expectations (when handoffs occur in stages)
• Acceptance criteria for each handoff
• Ownership for resolving interface issues (single-threaded owner) ¹

If third parties contribute to design, ensure you define what you accept as objective evidence from them (design review minutes, test evidence, traceability, etc.).

6) Manage the plan as a controlled record and keep it current

Treat the design plan as living governance:

• Update the plan when scope, interfaces, or V&V approach changes.
• Record approvals for material changes.
• Keep evidence that changes were assessed and controlled. ¹

If you use tools like Daydream for compliance work management, set up a standard workflow: design plan intake, approval routing, evidence collection tasks per stage, and an audit-ready evidence binder per project.

Required evidence and artifacts to retain

Auditors generally want objective evidence at two levels: your system and your projects.

System-level artifacts

• Design and development planning procedure/work instruction ¹
• Design plan template and scaling criteria
• Role definitions / responsibility assignments for design governance
• Document control evidence (versioning, approvals)

Project-level artifacts ¹

• Approved design and development plan (initial and revised versions) ¹
• Stage gate records: reviews, decisions, signoffs
• Verification records mapped to requirements/design outputs
• Validation records mapped to intended use/customer acceptance
• Interface control records (handoff checklists, integration reports, third-party deliverables acceptance)
• Change records (what changed, impact assessment, approvals)
• Traceability where applicable (inputs → outputs → V&V evidence)

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you decide which design stages and controls apply to this project.” ¹
• “Where is the approved design plan, and who approved it?”
• “How did you account for complexity or a long duration project?”
• “Show evidence of verification and validation planned and performed.”
• “How were interfaces controlled, especially between Engineering and Operations, or with third parties?”
• “How do you control changes to design plans and design outputs?” ¹

Hangups that trigger findings:

• Planning exists only as tribal knowledge.
• Projects skip formal planning because they are “just a change.”
• V&V is performed but not planned or tied to stage controls.
• Interfaces are assumed rather than assigned and verified.

Frequent implementation mistakes (and how to avoid them)

1. One template, no scaling.
   Fix: define a scaling decision (risk tier, novelty, number of interfaces). Apply it consistently and record the rationale. ¹

2. Confusing verification and validation.
   Fix: require both sections in the plan and train teams on the distinction with internal examples tied to your products/services. ¹

3. Design plans created after work starts.
   Fix: make plan approval an entry criterion for the first execution stage (requirements baseline, sprint 1, prototype build). Enforce through workflow gates. ¹

4. Interface control ignored.
   Fix: add an “interfaces and handoffs” table to the plan and require acceptance criteria for each handoff, including third-party deliverables. ¹

5. Changes made without re-planning.
   Fix: define what counts as a “material change” that triggers plan update and re-approval (scope, intended use, key requirements, test strategy, major supplier). ¹

Enforcement context and risk implications

ISO 9001 is a certifiable standard rather than a regulator, so the practical “enforcement” mechanism is certification audit nonconformities and customer consequences (lost bids, escalations, corrective actions, or contractual issues). The risk is operational: poorly planned design produces rework, delayed releases, misbuilt products, and failures that show up as customer complaints and nonconforming outputs. Clause 8.3.2 is a front-end control that reduces those downstream issues by forcing deliberate stages and controls scaled to complexity. ¹

A practical 30/60/90-day execution plan

First 30 days: establish the minimum viable control

• Confirm what “design and development” means in your scope (include software/service design if applicable). ¹
• Publish a short design planning procedure and a one-page design plan template.
• Define qualitative scaling criteria (e.g., low/medium/high complexity) and required controls per tier.
• Pick a system of record for design plans and evidence (QMS, ticketing system, or Daydream workspace).

Next 60 days: embed it into delivery workflows

• Roll out training for Engineering, Product, Quality, and Operations on how to complete and approve a plan.
• Implement stage gate approvals and evidence tasks in your workflow tool.
• Pilot the process on active projects, including at least one with third-party interfaces.
• Start internal spot checks: confirm each project has an approved plan and V&V mapped to stages. ¹

By 90 days: make it audit-ready and repeatable

• Run an internal audit or readiness review on several projects: plan existence, scaling rationale, stage records, V&V evidence, controlled changes.
• Fix gaps with corrective actions: missing approvals, weak interface definitions, unclear entry/exit criteria.
• Standardize an “audit packet” per design project: plan, changes, reviews, V&V, interface evidence.
• If using Daydream, standardize a project workspace template so every design effort produces consistent evidence without manual chasing.

Frequently Asked Questions

Does ISO 9001 Clause 8.3.2 require a stage-gate lifecycle?

No specific lifecycle is mandated. You must define stages and controls appropriate to the nature, duration, and complexity of your design activities, and keep objective evidence that projects followed that plan. ¹

We do agile development. What counts as a “design plan”?

An auditable plan can be a release plan or delivery plan that defines stages, controls, responsibilities, interfaces, and V&V approach, and is kept current through change control. The key is that controls are determined up front and evidenced during execution. ¹

How do we prove we “considered nature, duration, and complexity”?

Document a scaling rationale in the plan (for example, a selected complexity tier with brief justification) and show that the selected controls match that rationale. Consistency across projects matters more than perfect wording. ¹

Are verification and validation required in the planning step?

Clause 8.3.2 expects you to determine stages and controls, and the plain-language interpretation includes planning for verification and validation as core controls. Auditors typically expect V&V to be planned and then performed with records. ¹

What if a third party performs part of the design?

You still need interface controls in your design plan: what the third party provides, acceptance criteria, and what objective evidence you require to accept their work. Keep records of review and acceptance in your system of record. ¹

How detailed do entry/exit criteria need to be?

Detailed enough that another qualified person can tell whether the stage is complete and whether controls were applied (reviews done, V&V executed/planned, interfaces accepted). Overly generic criteria is a common audit finding because it cannot be objectively verified. ¹

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements