Design and development controls

ISO 9001:2015 Clause 8.3.4 requires you to control design and development so outputs are clearly defined, reviewed, verified against inputs, validated against intended use, and corrected when issues are found ¹. To operationalize it quickly, set mandatory design stages, objective acceptance criteria, and documented review/verification/validation evidence tied to requirements and risks.

Key takeaways:

• Define design outputs and acceptance criteria before work starts, then manage changes against them ¹.
• Run documented reviews, verification, and validation with clear roles, pass/fail criteria, and issue closure tracking ¹.
• Keep an audit-ready “design history” pack: inputs, outputs, review minutes, test results, approvals, and change records ¹.

“Design and development controls” is an audit focus because it’s where quality failures get baked into products, software, and services. Clause 8.3.4 is simple in wording but demanding in execution: you must be able to show that design results were defined, and that you performed verification and validation. In practice, auditors look for a controlled lifecycle, decision points, objective evidence, and disciplined handling of issues and changes.

For a Compliance Officer, CCO, or GRC lead, the operational goal is not to “own engineering.” It’s to define the control requirements, require consistent artifacts, and make sure the organization can prove traceability from requirements (inputs) to delivered design (outputs), with independent checks that it was built right (verification) and that it solves the user need in real conditions (validation) ¹.

This page gives requirement-level implementation guidance you can deploy across hardware, software, service design, and regulated product environments. It also covers what evidence to retain, common audit hangups, and a practical execution plan you can run with Engineering, Product, Quality, and third parties.

Regulatory text

ISO 9001:2015 Clause 8.3.4 excerpt: “The organization shall apply controls to the design and development process to ensure results are defined and verification and validation are conducted.” ¹

Operator interpretation (what you must do):

• Apply controls across the design and development lifecycle, not just at release, so work is planned, reviewed, and approved under defined criteria ¹.
• Ensure results are defined by documenting what “done” means for each stage and for the final design output (specifications, drawings, code, service blueprints), including acceptance criteria ¹.
• Conduct verification to confirm outputs meet inputs (requirements met as written) ¹.
• Conduct validation to confirm the product/service meets intended use and customer requirements in the target context ¹.
• Take action on problems by recording issues found in review/verification/validation, assigning owners, fixing them, and retaining closure evidence ¹.

Plain-English requirement interpretation

You need a repeatable design process that prevents “we built something and hope it works.” Auditors expect you to prove:

1. you defined requirements and design outputs,
2. you reviewed the design at appropriate points,
3. you verified the design output matches the design input,
4. you validated it meets real user/customer needs,
5. you corrected issues and controlled changes ¹.

A useful mental model:

• Reviews: governance checkpoints (are we on track, are risks addressed, are decisions documented).
• Verification: “built to spec.”
• Validation: “fit for intended use.”

Who it applies to

Entities: Any organization operating an ISO 9001 quality management system that performs design and development activities ¹.

Operational contexts where this clause becomes “real work”:

• Product companies designing hardware, firmware, software, or combinations.
• Service organizations designing delivery models, onboarding flows, or customer support processes that affect quality outcomes.
• Organizations that outsource design work to a third party but retain responsibility for QMS controls and acceptance.
• Teams doing “configuration” or “customization” that materially changes requirements, risks, or performance. If your outputs can fail a customer requirement, treat the work as design/development under control.

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

1) Define your design lifecycle and control gates

Create a documented design process with named stages and required evidence per stage. Keep it simple but enforceable.

Minimum gates most auditors accept when executed well:

• Design input baseline approved (requirements locked for the stage)
• Design review(s) at meaningful milestones
• Verification complete with objective results
• Validation complete in intended-use conditions
• Release approval and change control applied after release ¹

Practical control: Put gate requirements in your QMS procedure and in your delivery tooling (ticket workflow, PLM, SDLC, etc.) so teams cannot skip evidence.

2) Define “results” (outputs) with acceptance criteria

For each design stage, define the outputs and what “acceptable” means. Examples:

• Requirements/spec: clear, testable, approved, traceable to customer/contract needs.
• Architecture/design: threat/safety/performance constraints documented; key decisions recorded.
• Implementation output: code or drawings meet coding/drafting standards; build is reproducible.
• Release package: versioned artifacts; installation/config instructions; known limitations; support readiness.

Auditor lens: If outputs are vague, verification and validation become unverifiable.

3) Run design reviews with the right attendees and records

Design reviews are decision meetings. Require:

• Agenda tied to inputs, risks, changes, and open issues.
• Attendee roles (design owner, reviewer, quality, operations; add customer input where relevant).
• Recorded outcomes: approve/approve with actions/reject.
• Action tracking to closure ¹

Common operator move: Define “independence” expectations for reviewers for high-risk designs (not the author approving their own work). ISO 9001:2015 does not prescribe how, but auditors expect credible objectivity.

4) Perform verification: prove outputs meet inputs

Verification must map back to requirements. Require:

• A requirements-to-test traceability view (matrix or tooling export).
• Verification methods appropriate to the output (inspection, analysis, test, code review).
• Objective evidence: test protocols, results, pass/fail decisions, defect tickets, re-test evidence ¹

Practical example: If a requirement states response time under defined conditions, verification includes the test setup and results that show the requirement was met under those conditions.

5) Perform validation: prove intended use is met

Validation is not the same as verification. It focuses on real usage and customer needs:

• Validation plan tied to intended use, user profiles, environment, and constraints.
• Acceptance criteria that reflect real-world success, not just internal specs.
• Evidence: pilot results, user acceptance testing sign-off, field testing reports, service dry-runs, customer feedback with documented disposition ¹

If validation is hard: For custom or one-off work, validate via simulated environments, representative data, controlled trials, or customer sign-off on delivered acceptance criteria. Document your rationale.

6) Control issues, changes, and re-approval

Clause 8.3.4 expects you to act on problems found. Operationalize:

• A single place to log issues from reviews, verification, and validation.
• Severity/impact assessment (quality, safety, compliance, customer impact).
• Required re-verification and re-validation triggers when changes affect requirements or intended use.
• Version control: inputs, outputs, test results, and approvals must align to a specific revision ¹

7) Extend controls to third parties

If a third party designs components, software, or processes:

• Flow down design control requirements contractually (deliverables, evidence, change notification).
• Require access to verification/validation evidence (or credible summaries with defined detail).
• Perform incoming review and acceptance based on defined criteria, not “it seems fine.” ¹

Tooling note: If you use Daydream to manage third-party due diligence and ongoing monitoring, add design-control evidence requirements as part of onboarding checklists and recurring performance reviews so you consistently collect design packs, test evidence, and change notices.

Required evidence and artifacts to retain

Auditors want objective evidence, not verbal descriptions. Maintain a “design history” pack per product/service release (or per project):

• Design & development procedure (QMS-controlled document) ¹
• Design plan (scope, stages, responsibilities, review points)
• Design inputs (requirements, customer/contract requirements, constraints)
• Design outputs (specs, drawings, code baselines, service blueprint) with versioning
• Design review records (minutes/decisions/actions/approvals)
• Verification plan, test protocols, results, defect logs, re-test evidence
• Validation plan and results, intended-use justification, acceptance sign-off
• Change control records and impact assessments
• Third-party deliverables and acceptance records where applicable ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me a recent design and walk me from inputs to outputs to verification and validation evidence.” ¹
• “How do you know verification covered all requirements?”
• “What’s your definition of validation, and where is it documented for this release?”
• “How do you control design changes after initial approval?”
• “Where are the actions from design reviews, and how do you prove closure?” ¹
• “How do you control design activities performed by third parties?”

Typical hangups:

• Teams confuse verification and validation and provide only one.
• Evidence exists but is scattered across tools with no traceability.
• Reviews occurred but decisions and action closure were never recorded.

Frequent implementation mistakes and how to avoid them

Mistake	What it looks like	How to fix it
No defined design outputs	“Done” is subjective; artifacts vary by team	Create a required deliverables list per stage; enforce templates
Verification without traceability	Tests run, but no mapping to requirements	Require a traceability matrix or tooling export for each release
Validation reduced to a demo	A happy-path walkthrough labeled “validation”	Define intended-use scenarios and acceptance criteria; capture results
Review meetings with no records	“We reviewed it in Slack”	Record decisions, attendees, and actions in a controlled record
Changes bypass re-testing	Patch shipped with no impact assessment	Define change triggers that require re-verification/re-validation and approval
Third-party design accepted on faith	No evidence from supplier	Contractually require evidence and run receiving acceptance checks

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog. Practically, the risk is operational and contractual: inadequate design controls increase the chance of nonconforming outputs, customer complaints, rework, and safety or reliability failures. In an ISO 9001 audit, weak design controls can produce major nonconformities if you cannot show defined outputs and completed verification/validation with objective evidence ¹.

Practical 30/60/90-day execution plan

ISO 9001 does not require a specific timeline; use this phased plan to get control quickly while you mature evidence quality ¹.

First phase (immediate)

• Pick one representative product/service line as your pilot.
• Draft or update the design & development procedure to require: defined outputs, reviews, verification, validation, issue closure, and change control.
• Publish minimum required artifacts (templates for inputs, review minutes, verification summary, validation summary).
• Identify where evidence will live (PLM/ALM, ticketing, document control) and require versioning.

Second phase (near-term)

• Implement gated workflows: you cannot move to release without review records and verification/validation evidence.
• Stand up traceability: requirement IDs mapped to verification methods and results.
• Train Product/Engineering/Quality on definitions and pass/fail criteria; align on what counts as validation for your context.
• Add third-party design requirements to procurement/onboarding checklists and SOW language.

Third phase (ongoing)

• Run internal audits focused on design packs: completeness, traceability, change control discipline.
• Track recurring defects back to missed requirements or weak validation scenarios; update templates and test coverage.
• Normalize “release readiness” reviews with required attendees, approvals, and action closure.

Frequently Asked Questions

What counts as “design and development” for a services company?

If you design or materially change how a service is delivered (process steps, tooling, handoffs, acceptance criteria), treat it as design/development and apply controls, reviews, verification, and validation ¹.

How do I explain verification vs validation to engineering in one line?

Verification confirms the design output meets the design input (built to requirements), while validation confirms the result meets intended use and customer needs in real conditions ¹.

Do we need a formal traceability matrix?

ISO 9001:2015 Clause 8.3.4 requires that verification and validation are conducted and results are defined; a traceability matrix is a common, audit-friendly way to prove coverage and linkage to requirements ¹.

Can customer sign-off serve as validation?

It can, if the sign-off is tied to defined intended-use acceptance criteria and you retain objective evidence of what was tested or demonstrated and the outcome ¹.

What’s the minimum evidence an auditor will accept for design reviews?

A controlled record showing what was reviewed, by whom, when, what decisions were made, and what actions were assigned and closed ¹.

How should we handle third-party designed components?

Flow down requirements for defined outputs plus verification/validation evidence, then perform your own acceptance review against criteria and retain the full design pack or an agreed evidence set ¹.

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements