ISO 9001 · Clause 6 · 6.3
Planning of changes
In plain words
When you substantially change your QMS — a new machine that reshuffles workflows; new software; a move; a new structure; a new line of work — this clause demands one thing only: do it in a planned way. Think ahead: why the change, and what consequences can it have? Does the QMS stay intact — documents, inspections, training, responsibilities? Are resources there? And must responsibilities be reassigned?
No form is prescribed, no change request, no board. What is demanded is a conscious approach — and that it can be retraced afterwards.
The distinction that saves confusion: 6.3 means changes to the system (processes, structure, tools of the QMS). Changes to product and running production — a revised drawing, a new manufacturing step — are governed by their own clause 8.5.6. The movement of thought is the same; the flight level is not.
Why this requirement exists
Mature systems rarely break in normal operation — they break at the change. The new machine runs, but the measuring equipment is missing; the new software is in, but nobody adapted the procedures; the refit is done, but the responsibility for the in-process check got lost in the move. Almost every major nonconformity an auditor finds has an unplanned change in its backstory.
The clause is thus the practical sister of two other places: 5.3 demands that someone watches over the integrity of the QMS through change — 6.3 is the moment that person works. And the risk thinking of 6.1 becomes concrete here: a change is a planned risk event.
What good looks like
In a company of 12 people there are two or three real QMS changes a year — and for each, half a page, often as a section of the management review or a short record: Why are we changing? What is affected — which processes, documents, inspections, trainings, roles? Who does what by when? And: how do we tell the change succeeded?
Everything below that — the normal flow of better documents — needs no 6.3 ritual: that is what document control with its versions is for. The art is the threshold: what truly shifts workflows, responsibilities or evidence gets planned.
What changes as you grow: From around 50 people a simple change log plus a checklist pays off (documents? training? measuring equipment? interfaces?). From 100–250 people, big changes get formal change management with defined approvals — but proportionality remains the yardstick: a change board for every trifle is the bureaucratic form of self-deception.
The minimum to pass
- The recent substantial QMS changes are demonstrably planned: purpose, considered consequences, owners, dates.
- The consequences were thought broadly — not just the technology, but documents, training, inspections, responsibilities.
- The planning happened before the change, not as documentation after the fact (the dates give it away).
- The affected documents and trainings were actually brought along — promptly, not months later.
What an auditor asks for
- The last real change as a story: new machine, new software, refit — “show me how you planned this.”
- The version dates of the adapted documents around the change — does the documentation trail the practice?
- Training or briefing evidence for the change.
- The 5.3 question to go with it: who watched over the integrity of the QMS in this change?
- The success criterion: how did you determine the change succeeded — and did you check?
Common traps
- Change first, document after. The planning is created retroactively for the audit — recognisable by dates that lie after the change. More embarrassing than no planning at all.
- Only the technology planned. The machine is ordered, placement and power are thought through — setup sheets, inspection plan, training and maintenance are missing. The clause’s consequence list is built exactly against this.
- The documentation trails. The new practice has run for months, the procedures describe the old one — one of the most common audit findings of all, and a fully avoidable one.
- Nobody leads. The change “happens”, but nobody is named to carry it through and bring the QMS along. See 5.3.
- Formalising everything. Routing every document correction through a change procedure — that smothers the very improvement the standard wants. 6.3 means the substantial changes.
- Confusing 6.3 with 8.5.6. The revised customer drawing is 8.5.6; migrating production planning to new software is 6.3. Whoever throws both in one pot does one of them badly.
Worked example
The 5-axis machine of Berger Präzisionsteile GmbH — already in the book as an opportunity (6.1) and a context issue (4.1) — was also its most instructive 6.3 exercise. The plan: half a page in the management review. Purpose: more complex medical parts (the annual objective from 6.2). Affected: the production process, setup and program sheets (to be newly created), the inspection plan, training of two machinists, the maintenance plan, insurance. Owner: Marco, with dates per item. Success criterion: first-series scrap below 5% within three months — met.
The punchline came later: the internal audit (9.2) found outdated setup sheets — the experienced machinist worked from memory. The root-cause analysis showed: the change plan had included creating the sheets, but no change routine — nobody was named to approve changed sheets going forward. Exactly this gap was closed as a 6.3 addendum (approval rule for setup sheets, owner: Marco). That is how it fits together: the unplanned residue of a change was found by the audit and learned by the change planning — the loop the standard means.
How easo covers it
Clause 6.3 requires no mandatory document — it does not count in the readiness denominator. In easo, change planning still has a natural home:
- The half page of planning lives as a section of the management review or as a short record of its own — released, versioned, signed; its actions as trackable tasks (what/who/by when).
- The documentation side of every change is automatically traceable: each adaptation is a signed new version with a date — whether the documentation trails the practice is not a guess in easo, but readable.
- Changes to the process registry, roles and company settings are signed commits — who changed what on the system itself, and when, is on record without anyone writing it down separately.
Stay in the loop
easo is available for macOS — the Windows version is coming soon. Leave us a note and we'll reach out the moment it lands.