Design and development changes

ISO 9001:2015 Clause 8.3.6 requires you to identify, review, and control every design and development change so product or service requirements remain met after the change. Operationalize it by implementing a formal change control workflow (intake, impact analysis, approvals, verification/validation updates, release, and records) with clear roles and documented evidence. ¹

Key takeaways:

• Treat design changes as controlled events with defined triggers, owners, and approval rules, not as ad hoc engineering updates.
• Require documented impact analysis and updated verification/validation before release when a change can affect requirements.
• Keep change records that show what changed, why, who approved, what testing was updated, and what actions were taken. ¹

“Design and development changes” is where ISO 9001 auditors look for operational discipline: can you prove that changes made during design, and after release, stay aligned with requirements and don’t create unintended nonconformities? Clause 8.3.6 is short, but it carries real execution weight because it touches engineering, product management, quality, regulatory, manufacturing, and any third parties involved in design outputs.

For a CCO, Quality leader, or GRC lead, the fastest path is to standardize the change lifecycle and the records it produces. You are building two things: (1) a repeatable control that forces review and control of changes, and (2) evidence that the control was followed consistently. This page gives you a requirement-level interpretation, a practical workflow you can implement quickly, the artifacts to retain, and the audit questions you should pre-answer in your process design.

You do not need a perfect toolchain on day one. You do need a clear definition of “design change,” a single front door for requests, explicit approval authority, and a rule that changes do not ship without the required review and documented actions. ¹

Regulatory text

Clause requirement (verbatim): “The organization shall identify, review and control changes made during or subsequent to design and development.” ¹

Operator interpretation:
You must have a defined way to (a) detect and log design/development changes, (b) review them for impact to requirements and downstream outputs, and (c) control implementation so only appropriately approved and verified changes are released. Your process must also retain documented information that shows what changed and what actions were taken to manage the change. ¹

Plain-English interpretation (what the requirement is really asking)

A “design and development change” is any modification to design inputs, design outputs, design methods, or design decisions that can affect the product/service meeting requirements. The clause applies whether the change happens mid-project (during development) or after release (post-launch fixes, enhancements, supplier-driven component substitutions, documentation updates that affect build/implementation).

Auditors typically test this by sampling recent changes and asking:

• Did you identify the change as a controlled change?
• Did you review the impact before implementation?
• Did you control who could approve it?
• Did you update verification/validation evidence as needed?
• Can you prove the above with records? ¹

Who it applies to

Entities: Any organization operating an ISO 9001 quality management system with design and development activities in scope. ¹

Operational contexts where this becomes “high friction”:

• Product engineering teams shipping frequent releases (hardware, software, firmware).
• Regulated or safety-relevant design outputs (even if regulation is not the audit basis, risk is higher).
• Multi-site design/manufacturing where changes propagate across locations.
• Design performed partly by a third party (design house, contract manufacturer, outsourced software team).
• Configuration-heavy services (implementation templates, integration mappings, or service “standard work” that acts like a design output).

Functions involved: Engineering, Product, Quality, Manufacturing/Operations, Procurement/Supply Chain, and any third party that creates or changes design outputs.

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

Implement a single, auditable change control workflow for design and development changes. Keep it simple, then harden it.

1) Define what counts as a design/development change (and what doesn’t)

Create a short definition with examples, and include explicit triggers. Examples of triggers:

• Change to a requirement, specification, drawing, BOM, code, algorithm, test method, acceptance criteria, labeling, installation procedure, or user instructions.
• Supplier component change that affects form/fit/function, performance, or compliance commitments.
• Post-release bug fix that can alter behavior tied to requirements.

Also define exclusions (administrative edits that cannot affect conformity), but be conservative. If teams debate whether something is a change, you want the default to be “log it.”

2) Establish “one front door” for change intake

Set up a standard change request record (in your QMS tool, ticketing system, PLM, or controlled form). Minimum fields:

• Unique ID, title, description of change
• Reason for change (defect, improvement, obsolescence, customer issue)
• Items impacted (documents, parts, code modules, processes, service scripts)
• Requested implementation timing and affected releases/builds
• Owner and approvers

This is the “identify” part of the requirement in operational terms. ¹

3) Require documented impact analysis before approval

Create an impact checklist that is completed for every change, scaled by risk. At minimum, assess:

• Requirements impact: which requirements could change or be newly unmet?
• Downstream outputs: drawings, BOM, manufacturing instructions, service delivery steps, training materials
• Verification/validation impact: what tests must be repeated, added, or updated?
• Third-party impact: supplier specifications, outsourced design work, customer dependencies
• Compatibility and transition: inventory, installed base, migration/rollback needs

Make the “review” explicit: the record should show the reviewer(s), date, and decision. ¹

4) Define approval authority and segregation of duties

Write approval rules that match your risk profile:

• Low-risk changes: design owner + quality review.
• Higher-risk changes: cross-functional approval (Quality + Engineering + Operations; add Procurement if supplier-related).
• Emergency changes: allow expedited approval, but require retrospective review and completion of missing evidence before the next formal release gate.

Auditors want to see that approvals are not implied. They are recorded and attributable. ¹

5) Control implementation and release

“Control” means the organization prevents unauthorized or unreviewed changes from reaching production or customers. Practical controls:

• Link change approval to document control release (only approved revisions become effective).
• Configuration management: tie code changes to an approved change request and a tagged release.
• Manufacturing/service readiness check: confirm work instructions and training updates are in place before effective date.

If you have third parties implementing changes (contract manufacturing, outsourced dev), include a contractual or procedural requirement that they cannot implement changes without your authorization and that they provide change records back to you.

6) Update verification/validation and acceptance evidence

When the impact analysis indicates risk to requirements, require updated verification/validation evidence appropriate to the change. Keep it pragmatic:

• Add or rerun tests tied to impacted requirements.
• Update test protocols where acceptance criteria changed.
• Record results and link them to the change record.

The goal is traceability: change → impact → required actions → completed actions → approval to release. ¹

7) Close the loop and retain documented information

A change is not “done” when engineering finishes work. It is done when:

• All required actions are completed (docs updated, tests run, training delivered if needed),
• Approvals are recorded,
• Effective date/version is controlled,
• The change record is closed with links to supporting artifacts. ¹

Practical tooling note: Many teams start with a basic workflow in Jira/ADO + controlled document repository, then mature into PLM/QMS tooling. If you need an audit-friendly way to centralize change requests, approvals, evidence links, and exceptions across internal teams and third parties, Daydream can act as the system of record for change control evidence and audit requests while you keep engineering execution in existing tools.

Required evidence and artifacts to retain

Keep these artifacts in a retrievable, audit-ready format:

• Design change procedure/work instruction defining triggers, roles, approvals, and required records.
• Change request records (IDs, descriptions, rationale, impacted items).
• Impact analysis (completed checklist or narrative assessment).
• Review/approval evidence (names/roles, dates, decision, conditions).
• Updated design outputs (revised specs/drawings/BOM/code release notes) under document control.
• Verification/validation updates (test plans, test results, review sign-offs) tied to the change.
• Implementation/release evidence (effective date/version, deployment record, manufacturing readiness).
• Third-party communications when a third party is involved (authorizations, supplier change notices, acceptance evidence). ¹

Common exam/audit questions and hangups

Auditors typically press on consistency and traceability:

• “Show me your last several design changes. How did you decide what testing to redo?”
• “Where is the evidence that Quality reviewed this change before release?”
• “How do you prevent an engineer or a third party from pushing an unapproved change?”
• “How do you handle emergency fixes? Where is the retrospective review record?”
• “How do you ensure downstream documents and training were updated?” ¹

Hangups you can preempt:

• Changes are logged, but impact analysis is missing or superficial.
• Approvals exist in chat/email but are not controlled records.
• Verification evidence is disconnected from the change request.
• Supplier-driven changes are treated as “procurement only,” not design changes.

Frequent implementation mistakes (and how to avoid them)

1. Treating software releases as “outside QMS.”
   Fix: define software/firmware/configuration as design outputs when they affect requirements, then route changes through the same control.

2. No clear threshold for “what needs re-validation.”
   Fix: build a simple decision rule tied to impacted requirements. If a requirement could be affected, require verification evidence linked to that requirement.

3. Approvals happen after deployment.
   Fix: enforce a release gate where document control or deployment requires an approved change ID.

4. Third-party changes bypass your controls.
   Fix: require written authorization for design changes by third parties, and require return of change evidence as a deliverable.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak design change control increases the likelihood of nonconforming outputs, customer escapes, and inconsistent builds across sites or third parties. For ISO certification, the risk is a nonconformity if you cannot demonstrate identification, review, and control with documented information. ¹

Practical execution plan (30/60/90)

First 30 days (stabilize the control)

• Publish a one-page design change definition and triggers.
• Stand up a single change request template and repository.
• Assign RACI: change owner, required reviewers, final approver.
• Pilot the workflow with one product line/team; require evidence links.

By 60 days (make it auditable)

• Add an impact analysis checklist and approval rules by risk tier.
• Tie change approvals to document control and release processes.
• Train engineering, quality, operations, and procurement on “what must be logged.”
• Begin internal sampling: pick recent changes and verify traceability end-to-end.

By 90 days (scale and reduce bypass)

• Extend to third parties: contractual language/procedure updates and evidence return.
• Add metrics that don’t require statistics to be meaningful: backlog of open changes, aging exceptions, missing-test flags.
• Run a mock audit: have someone unfamiliar with the change find the record and prove conformity from the artifacts alone.
• Consider consolidating evidence collection and audit response tracking in Daydream if your current records are spread across tools.

Frequently Asked Questions

What counts as a “design and development change” under ISO 9001?

Any change made during or after design and development that can affect meeting requirements should be treated as a controlled change. If a change could impact specifications, acceptance criteria, performance, or user-facing instructions, log it and run impact review. ¹

Do we need a formal change control board (CCB)?

ISO 9001 does not mandate a board, but it requires review and control with clear authority. Many organizations meet the requirement with defined approvers by risk level and documented decisions in the change record. ¹

How do we handle emergency fixes without failing the requirement?

Allow expedited approval for emergency changes, but require documented review and completion of required testing and documentation updates as part of retrospective closure. Keep the exception path written and consistently followed. ¹

Can approvals in email or chat count as evidence?

They can demonstrate intent, but they are often hard to control, retrieve, and audit. Convert them into controlled records by capturing the approval in the change request system with attributable sign-off and links to supporting messages if needed. ¹

What if a supplier changes a component or process?

Treat it as a potential design/development change if it can affect conformity to requirements. Require supplier notification, perform impact analysis, and document your approval and any required verification before accepting the change. ¹

We release software weekly. How can we keep this lightweight?

Use a standardized change template, automate linking commits/builds to approved change IDs, and define “pre-approved” low-risk change categories with clear guardrails. Keep impact analysis and testing expectations short but mandatory. ¹

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements