Planning of changes

ISO 9001:2015 Clause 6.3 requires you to plan changes to the quality management system (QMS) before you implement them, so change is controlled rather than accidental. Operationalize it by running every QMS-impacting change through a documented change plan that evaluates purpose, consequences, resources, and responsibilities, then retains evidence of approvals and outcomes. ¹

Key takeaways:

• Treat “QMS changes” broadly: process, documentation, tooling, suppliers, org structure, and competency can all trigger Clause 6.3.
• Use a single change intake and review workflow with defined roles, impact assessment, approval, communication, and post-change verification.
• Keep auditable artifacts: change request, impact/risk assessment, approvals, updated documents, training/communications, and effectiveness evidence.

“Planning of changes” is where many ISO 9001 programs become real operations instead of binders. Clause 6.3 is short, but the expectation is not: if you change the QMS, you must do it deliberately, with forethought, and with accountability. The standard’s intent is to prevent changes that unintentionally break process controls, create nonconforming outputs, or confuse people about “the right way” to do work. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to compliance is to define what counts as a QMS change in your organization, then put a lightweight change planning workflow in front of it. You are not trying to slow the business down. You are trying to ensure changes are reviewed for downstream consequences, resourced appropriately, assigned to named owners, communicated, and verified after implementation. ¹

This page gives requirement-level guidance you can implement immediately: who owns what, the minimum workflow steps, what auditors typically ask for, and the evidence set that proves you plan changes rather than react to incidents.

Regulatory text

ISO 9001:2015 Clause 6.3: “When the organization determines the need for changes to the quality management system, the changes shall be carried out in a planned manner.” ¹

What the operator must do:
You must have a repeatable method to plan and control changes that affect the QMS. In practice, that means you (1) identify a proposed change, (2) assess why you’re doing it and what it could affect, (3) confirm resources and assign responsibilities, (4) approve and implement in a controlled way, and (5) confirm the change achieved its intended outcome without unintended harm. ¹

Plain-English interpretation (what this requirement means)

Clause 6.3 expects discipline around change. If you modify the processes, tools, responsibilities, or documented information that make your QMS work, you should be able to show:

• what you changed and why,
• what you expected to happen,
• what could break (and how you mitigated it),
• who approved it and who did the work,
• what artifacts were updated (procedures, forms, work instructions),
• how you confirmed the change works as intended. ¹

A useful operator test: If an auditor asked “How did you ensure this change didn’t create a quality problem?” you should have evidence ready.

Who it applies to

Entities

• Any organization operating a QMS that aligns to ISO 9001:2015. ¹

Operational context (what counts as “a change to the QMS”)

Treat these as likely Clause 6.3 triggers because they alter how quality is planned, executed, controlled, or evidenced:

• Process changes: new steps, removed checks, changed acceptance criteria, revised sampling/inspection approach.
• Organizational changes: role/accountability changes, reorganizations affecting process ownership, new sites or production lines.
• Documented information changes: procedures, SOPs, work instructions, forms, templates, quality plans.
• Tooling/system changes: QMS software, ERP/MES changes affecting traceability, complaint handling, CAPA workflow.
• Competence/training model changes: new qualification requirements, revised onboarding, new certifications.
• Third party changes: switching critical suppliers/outsourcers, changing service scope, altering incoming inspection reliance. (“Third party” includes vendors, contractors, and outsourced process providers.)

If you are unsure whether something is a QMS change, decide using impact: Does it affect conformity of products/services, customer requirements, or your ability to run/measure processes? If yes, route it through change planning. ¹

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

Below is a pragmatic workflow that satisfies Clause 6.3 while staying operationally light.

1) Define your “QMS change” intake and threshold

• Create one intake mechanism: a form, ticket type, or controlled template.
• Define categories (examples): documentation-only, process, system/tool, org/roles, supplier/outsourced process.
• Define a threshold for review rigor (simple vs. significant change). Keep it principle-based: impact to conformity, compliance obligations, customer commitments, or measurement/control. ¹

2) Document purpose and intended outcome

For every change request, capture:

• the reason (problem, improvement, customer requirement, corrective action, risk treatment),
• what “done” looks like (clear acceptance criteria).
  This is the anchor for your post-change verification. ¹

3) Perform an impact and consequences assessment (the core of Clause 6.3)

Minimum considerations to record:

• Process impacts: upstream/downstream steps, interfaces between teams, handoffs, inspections/controls.
• Customer/regulatory impacts: customer-specific requirements, contractual SLAs, labeling/traceability expectations where applicable.
• Risks and unintended consequences: what could fail, what could be missed, what might become inconsistent.
• Data and records impacts: what records change, retention/traceability effects.
• Third party impacts: changes to supplier specs, outsourced process controls, incoming verification. ¹

Practical tip: Use a short checklist rather than a blank page. Operators answer checklists faster and more consistently.

4) Confirm resources and competence

Record:

• required people/skills,
• training needed before go-live,
• tooling or budget dependencies,
• time constraints driven by customers or operations (state the constraint; avoid guessing durations if you can’t support them). ¹

5) Assign responsibilities and approvals

Define roles for:

• Change owner: accountable for delivery and evidence pack.
• Process owner: approves process impacts.
• Quality/QMS function: confirms QMS integrity (document control, measurement, auditability).
• Impacted functions: operations, engineering, customer support, procurement, IT, as relevant.
• Final approver: depends on scope (for significant changes, a designated QMS authority or leadership). ¹

Make approvals explicit. Auditors often look for clear decision rights, not informal “everyone knew.”

6) Update documented information (and control the versions)

Before implementation (or concurrently with controlled cutover), ensure:

• procedures/work instructions reflect the new method,
• forms/templates are updated,
• obsolete versions are removed or clearly marked,
• the document control log shows review and approval. ¹

7) Communicate and train

Evidence to produce:

• who was notified (target groups),
• training completion or read-and-understood attestations for impacted roles,
• go-live notes or release communications where tooling is involved. ¹

8) Implement with a controlled cutover plan

Include, when relevant:

• pilot vs. full rollout decision,
• back-out/rollback plan if the change causes defects,
• temporary controls during transition (extra inspection, dual-running forms). ¹

9) Verify effectiveness after the change

Tie verification to the intended outcome from Step 2:

• confirm process performance measures still work and are being recorded,
• check first-run outputs (first articles, initial service tickets, early batches),
• confirm no new nonconformities were introduced and that responsibilities are clear. ¹

10) Close the change with a complete evidence packet

Closure criteria should include: all documents updated, training done, verification completed, and any follow-up actions assigned and tracked.

Tooling note (Daydream): If your current state is spreadsheets and shared drives, Daydream can act as the system of record for change requests, approvals, document updates, and evidence attachments. The goal is not “more workflow.” The goal is one place to prove planned change with complete, consistent artifacts.

Required evidence and artifacts to retain

Auditors will accept different formats, but they look for the same story. Retain:

• Change request/intake record (unique identifier, submitter, scope)
• Impact/consequences assessment (checklist + notes)
• Risk notes and mitigations (even qualitative)
• Resource/competence confirmation (training needs, dependencies)
• Approval record (names/roles, dates, conditions)
• Updated controlled documents (with revision history)
• Communication/training evidence (rosters, attestations, LMS records)
• Implementation/cutover notes (including rollback plan if applicable)
• Post-change verification record (results vs. acceptance criteria)
• Closure record and follow-up actions (if any) ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me an example of a recent QMS change and how it was planned end-to-end.”
• “How do you decide what needs formal change planning versus an informal update?”
• “Where is responsibility assigned for QMS changes?”
• “How did you ensure people were trained on the new method before go-live?”
• “What evidence shows the change achieved the intended result?”
• “How do you control document versions so old instructions aren’t used?” ¹

Hangups that trigger findings:

• no consistent evidence trail,
• approvals are verbal,
• documents updated after the fact with no transition control,
• training is assumed rather than evidenced.

Frequent implementation mistakes (and how to avoid them)

1. Treating Clause 6.3 as “document control only.”
   Fix: Route process/tool/role/supplier changes through the same intake, even if documents don’t change.

2. No defined threshold for “significant change.”
   Fix: Define significance by impact areas (conformity, compliance obligations, measurement/control, customer commitments). Keep it short and enforce it.

3. Impact assessment stops at the local team.
   Fix: Require sign-off from upstream/downstream process owners when interfaces change.

4. Training evidence is missing.
   Fix: Make training completion a closure gate. If training isn’t needed, record why.

5. No effectiveness check.
   Fix: Define at least one verification method per change (metric check, first-run review, internal audit spot check). ¹

Enforcement context and risk implications

No public enforcement cases were provided for ISO 9001 Clause 6.3 in the source catalog, and ISO 9001 itself is a certifiable standard rather than a regulator. Your practical risk is certification-related: poorly controlled change often shows up as nonconformities because it creates inconsistency between “what you say you do” (documents) and “what you actually do” (operations). It also increases operational risk: process drift, unclear responsibilities, and avoidable nonconforming outputs. ¹

A practical 30/60/90-day execution plan

Use this as a rollout structure; adjust to your internal change volume and complexity.

First 30 days (establish the minimum viable control)

• Define what counts as a QMS change for your scope and document it.
• Stand up a single change request template with mandatory fields: purpose, impacts, resources, responsibilities, approvals, verification.
• Assign RACI for approvals (Quality/QMS, process owner, impacted functions).
• Pick a system of record (ticketing tool, QMS platform, or Daydream) and decide where evidence lives.
• Run the workflow on a small set of active changes to test friction points. ¹

Next 60 days (make it consistent and auditable)

• Create an impact assessment checklist tailored to your processes and third parties.
• Add closure gates: document updates, training evidence, verification results.
• Train managers and process owners on when to submit a change and how approvals work.
• Start a simple change register and make it reviewable by Quality. ¹

Next 90 days (make it durable and inspection-ready)

• Perform an internal audit or focused review of a sample of changes for completeness.
• Tighten thresholds (what is “significant”) based on what you learned.
• Add reporting: open changes, overdue verification, recurring impact types.
• Align management review inputs so leadership sees change themes and resource needs. ¹

Frequently Asked Questions

What is considered a “change to the QMS” under ISO 9001 Clause 6.3?

Any change that affects how quality is managed, controlled, measured, or evidenced can qualify. If it changes a process, responsibility, tool, documented procedure, or control over a third party that affects conformity, route it through planned change. ¹

Do minor document edits need full change planning?

Not always, but you should define a threshold. If a document edit changes “how work is done” (steps, criteria, responsibilities), treat it as a QMS change with impact review and training considerations; if it is purely editorial, record it as such under document control. ¹

Can we plan changes inside our existing IT change management process?

Yes, if it captures Clause 6.3 elements: purpose, consequences/impacts, resources, responsibilities, approvals, and effectiveness verification. Many teams map QMS change requirements onto existing change tickets and add a Quality approval step for QMS-relevant changes. ¹

How do we show “planned manner” to an auditor?

Provide a complete example: the change request, documented impact assessment, approvals, updated controlled documents, training/communications, and post-change verification results tied to the intended outcome. The auditor is looking for traceability from decision to outcome. ¹

What if we had to make an emergency change?

Record the change as soon as practical, including what drove urgency and what interim controls you used. Then complete the missing planning elements retrospectively (impact review, document updates, training, effectiveness check) and capture approvals for the final state. ¹

How should we handle third party changes (supplier switches, outsourcing scope changes)?

Treat them as QMS changes when they affect product/service conformity or process control. Your change plan should cover specification updates, incoming verification changes, communication to the third party, and how you will confirm performance after the switch. ¹

Footnotes

1. ISO 9001:2015 Quality management systems — Requirements