ISO 9001 Clause 6.3 Change Management: What Counts as a Significant Change, and Why Most Teams Get Cited

A practical guide to ISO 9001 Clause 6.3 — what 'planned changes' actually means, what counts as significant, what records you need, and the failure modes that produce findings.

A precision machining shop in Michigan moved one of its CNC cells from the south end of the building to the north end over a long weekend. Same machine, same operators, same program, same customer parts. The move was driven by a facility reorganization that the plant manager had signed off on in a Monday morning meeting. Nobody opened a change request. Nobody flagged it as a QMS-impacting change. The cell was producing parts again by Tuesday.

Six weeks later, an internal audit picked up that the calibration schedule for the cell's coordinate measuring machine had silently shifted because the climate-controlled area it had previously sat next to was no longer adjacent. The CMM's stated environmental conditions were no longer being met. There was no nonconformity opened on the parts because, by luck, none of the dimensional tolerances had drifted enough to fail incoming inspection at the customer. But the surveillance audit three months later picked it up immediately. The finding wasn't about the calibration. It was Clause 6.3 — a change to the QMS had been carried out without a planned approach. No documented evaluation of consequences. No record of who decided the move was QMS-neutral. No evidence the calibration impact had been considered before the move, only after a problem had nearly happened.

This is the most common Clause 6.3 failure mode in ISO 9001 audits, and it's almost entirely a documentation problem rather than a thinking problem. The team, in most cases, would have considered the calibration question if anyone had asked. Nobody asked because the change wasn't running through a process that would force the question. This guide covers what Clause 6.3 actually requires, what "significant" means in practice, and the specific failure modes that produce findings in otherwise well-run organizations.

What Clause 6.3 actually says

Clause 6.3 of ISO 9001:2015 is one of the shortest clauses in the standard. The text says that when the organization determines the need for changes to the quality management system, the changes shall be carried out in a planned manner. The organization shall consider the purpose of the changes and their potential consequences, the integrity of the QMS, the availability of resources, and the allocation or reallocation of responsibilities and authorities.

That is the entire clause — three sentences, four considerations. There is no mandated change request form. No required severity classification. No prescribed approval workflow. No definition of "significant" or "minor." The standard puts the obligation on the organization to determine when a change requires planned management and to retain enough evidence that it did.

The brevity is deliberate. TC 176 wrote 6.3 to require disciplined thinking around change without prescribing a methodology. The flexibility is real — but, as with Clause 6.1, the flexibility is also where teams get into trouble. The standard doesn't tell you how much process to apply, and applying too little produces findings just as reliably as applying none at all.

What counts as a "change to the QMS"

The clause talks about changes "to the quality management system." That phrase is broader than most teams realize when they're reading the clause for the first time, and narrower than auditors sometimes treat it once an audit is in progress.

Changes to the QMS, in the standard's intent, include changes that affect:

• A documented process or procedure within the QMS
• The structure of the organization, departments, reporting lines, or roles with QMS responsibility
• The physical infrastructure, work environment, or layout in a way that affects controlled processes
• The technology or equipment used in controlled processes
• Suppliers feeding controlled processes, particularly where the supplier is performing an outsourced process
• Customer requirements or applicable regulatory requirements where they affect QMS design
• The scope of the QMS itself, including products, services, sites, or activities included
• Quality objectives or the way they are measured

What is generally not a Clause 6.3 change is the day-to-day operational work the QMS already controls — running a process to its existing procedure, generating a record the procedure already specifies, executing a corrective action through the existing CAPA process. The CAPA itself isn't a Clause 6.3 change. A change to the CAPA procedure is.

The line gets fuzzy at the edges, and that is where most disputes with auditors live. A new fixture on an existing machine to support an existing part — is that a Clause 6.3 change, or is it operational work the existing process already covers? An organizational restructure that moves the quality team's reporting line from operations to compliance — clearly Clause 6.3. A new ERP module that replaces a manual log — almost always Clause 6.3 because the controlled record changes form. A swap from one approved supplier to another approved supplier on the AVL — usually not, unless the supplier qualification process itself defines that swap as a change requiring re-evaluation.

The reasonable test most experienced quality managers apply is: would the answer to "is the QMS still working as intended?" change as a result of this action? If yes, it is a Clause 6.3 change and needs to be carried out in a planned manner. If no, it doesn't.

"Significant" and the judgment call problem

The standard does not use the word "significant" in Clause 6.3 — but in practice every implementation of 6.3 ends up needing the word, because applying full change management process to every minor edit of a procedure would grind the organization to a halt. ISO/TC 176's own implementation guidance acknowledges that 6.3 is intended for changes meaningful enough to affect QMS performance, not every cosmetic tweak.

The judgment call about what is significant is the organization's to make and document. That is the trap most teams walk into. They make the call informally, on the day, in a hallway conversation between the plant manager and the quality engineer, and no record of the call is kept. When the auditor later asks why this change went through full evaluation and that one didn't, the answer is "we judged it not to be significant," which is a defensible answer if there's a record of the judgment and an indefensible one if there isn't.

The structural fix is simple in concept and hard in practice: every potential change runs through at least a lightweight triage step that produces a record. The record can be a single line that says "this change was evaluated against Clause 6.3 criteria and determined not to require full planning, on the basis that ___, signed by ___, dated ___." That record is what makes the judgment auditable. Without it, the organization is asking the auditor to take its word that the thinking happened. Auditors generally don't.

The four considerations the clause requires

When a change is carried out in a planned manner, Clause 6.3 says the organization shall consider four specific things. Each one has a corresponding failure mode that surfaces in audits.

Purpose and potential consequences. Why is the change being made and what could it affect? The failure mode here is changes that document the purpose ("to improve efficiency") without analyzing the downstream effects. A new layout improves material flow — and also relocates a calibration-sensitive instrument, also rebalances the inspection workload, also affects the access route the fire marshal approved last year. If the consequences analysis only covers the intended outcome and doesn't surface the secondary effects, an auditor walking the floor after the change will find the secondary effects and ask why they weren't considered.

Integrity of the quality management system. Is the QMS still coherent after the change? The failure mode is changes that are made to one part of the QMS and silently invalidate documentation, training, or controls in another part. A revised procedure references a form that the document control update didn't migrate. A reorganization moves a role's reporting line and leaves the responsibilities matrix in three different documents inconsistent. A new piece of equipment is approved without updating the calibration master list. The change happened, the system absorbed it, and parts of the documented system now contradict reality. That is a Clause 6.3 finding even if the change itself was valid.

Availability of resources. Are the people, equipment, time, and budget actually there to carry out the change without compromising existing operations? The failure mode is approval of a change that an honest resource analysis would have flagged as overcommitting the team. A line move scheduled over a weekend that requires twice the maintenance hours actually available. A procedure rollout that requires retraining 80 operators in a window that includes two weeks of vacation coverage. Auditors don't usually catch this in real time — they catch it after the change goes live, in the form of nonconformities or operator complaints that trace back to a change that wasn't resourced realistically.

Allocation or reallocation of responsibilities and authorities. Who owns what after the change? The failure mode is changes that move work without explicitly moving the authority to make decisions about the work. A process is moved from one department to another and the procedure still names a position in the original department as the approver. A new role is created without a corresponding job description or competency requirement. Two departments end up sharing responsibility for an activity in a way that isn't documented, and when something goes wrong, neither one owns the response. Clause 5.3 ties to this directly — responsibilities and authorities have to be assigned, communicated, and understood — and Clause 6.3 finishes the loop by requiring this allocation to be revisited every time the QMS changes.

What auditors actually ask

The questions that surface Clause 6.3 in an audit don't usually announce themselves as Clause 6.3 questions. They sound like:

• "When was the last time you moved equipment? Walk me through how that change was managed."
• "I see a new procedure revision dated three months ago. Show me the impact assessment."
• "Who approved the decision to outsource this process? When did the supplier qualification get done relative to the change?"
• "This org chart shows a new VP of Operations. What changed in the QMS as a result of that hire?"
• "The internal audit report from last quarter mentions a process change. I'd like to see the planning records for that change."

The auditor isn't testing whether the team has a change management procedure. They are testing whether change is happening through the procedure or around it. A team with a clean procedure and a quarter's worth of changes that didn't go through it is in worse shape than a team with no procedure and a credible explanation of how each change was thought through.

The failure modes that produce findings

The patterns that generate Clause 6.3 nonconformities are consistent enough across audits to be predictable.

Changes carried out without any documented planning. The change happened, everyone knows it happened, but there is no record that anyone evaluated the four considerations before it happened. This is the cleanest finding for an auditor to write — the clause requires a planned manner, no plan exists, the finding writes itself.

Triage decisions that aren't recorded. Changes are filtered into "significant" and "not significant" buckets, but only the significant ones leave a paper trail. The auditor asks why a particular change wasn't run through full planning, the answer is verbal, and the finding is about absence of objective evidence of the triage.

Documents revised without parallel updates to dependent documents. The procedure is updated, the work instruction it references is not. The form changes, the master list still shows the old form. The job description is rewritten, the competency matrix doesn't reflect it. Each gap is a separate finding under Clause 7.5 document control, but the root cause is a Clause 6.3 failure to consider QMS integrity during the change.

Changes that go live before the planning is finished. The procedure is in draft. The training hasn't happened. The supplier qualification hasn't been completed. The risk re-assessment is open. But operations need the new process running by Monday and it goes live anyway. Auditors look for the date of the change going into effect compared to the dates on the supporting records. If operations beat the planning, that's a finding.

No retrospective evaluation of whether the change worked. The change was planned, executed, and never looked at again. Clause 6.3 doesn't explicitly require effectiveness review the way Clause 6.1 does for risk actions, but Clause 9 does — and an organization that can't show whether its changes achieved their stated purpose is an organization where management review and improvement processes are missing inputs.

Changes driven by individuals with no organizational record. The plant manager, the engineering lead, a customer's quality contact — someone with authority makes a decision that propagates into the QMS without going through change planning. Often these are the most consequential changes, and often they are the ones the auditor finds easiest to flag because they're the ones the team is least prepared to defend.

Customer-driven changes treated as outside Clause 6.3. A customer mandates a change to a process or specification, and the team treats the customer mandate as authority to skip the planning step because "we had no choice." Customer-driven changes are still Clause 6.3 changes. The "no choice" is about whether to make the change, not about whether to plan the implementation. Auditors at IATF 16949 sites in particular look for this gap and it is one of the more common findings against suppliers responding to PPAP-related customer change requests.

Reorganizations and personnel changes treated as HR matters. A leadership change moves the quality function under a different VP. A department is dissolved. A site is added or closed. These are some of the most QMS-significant changes an organization can make, and they are the ones most often handled entirely outside the change management procedure on the theory that they belong to HR or executive operations. The Clause 5.3 / Clause 6.3 connection means they don't.

Where the records have to live

A working Clause 6.3 system has to do something that most spreadsheet-and-folder QMS architectures struggle with. It has to capture the decision to call something a change, the evaluation of the four considerations, the approvals, the planned actions, the dependent document updates, the training and resource allocation, the go-live date, and — ideally — the post-change effectiveness check, all linked together and all retrievable in the order an auditor asks for them.

Most teams approximate this with a change request log on SharePoint, a few procedure templates in Word, training records in a separate system, and a working assumption that the email threads and meeting minutes will be reconstructable if anyone asks. They are not always reconstructable. Email gets archived. Files get moved. The version of the procedure that was in effect on the day the change went live is not always still recoverable from a folder where the latest revision overwrote it. The signature on the change approval is sometimes a name typed into a Word document by someone other than the person whose name it is.

The structural problem is that Clause 6.3 is a multi-document, multi-person, multi-stage record-keeping requirement running on top of a tooling stack that wasn't built to retain that kind of trail. When the auditor asks to see the planning records for the line move six months ago, the answer requires the change request, the impact assessment, the approval signatures, the dependent document revisions in their pre-change and post-change state, the training records of who got trained on what when, and the verification that the change achieved its purpose. If any one of those is in a folder somebody cleaned up, an inbox somebody emptied, or a spreadsheet whose version history was overwritten, the trail breaks and the explanation becomes harder than the finding.

This is the same record-keeping problem that surfaces under Clause 6.1, Clause 7.5, and Clause 10.2 — and it is the same problem CAPA and supplier qualification run into. SheetLckr exists to close this specific gap: a compliance-grade spreadsheet platform with built-in version history, approval workflows, and a tamper-evident audit trail, so the change request, the impact assessment, the approvals, the dependent updates, and the effectiveness check live in one connected record that survives the trail an auditor will walk. Clause 6.3 isn't passed or failed at the change request form — it's passed or failed at whether the records can show the planning actually happened, in the right order, before the change went live.

Clause 6.3 is one of the cheapest places in the standard to pick up a finding because the requirement is short, the methodology is unprescribed, and the discipline involved is mostly procedural. Teams fail it by undermanaging changes that should have been planned, by overmanaging trivial changes and burning out on the process, or by running the planning informally and not retaining records that prove it. The clause that takes three sentences in the standard ends up requiring a working system across the organization — change identification, triage, evaluation, approval, execution, integration, and verification, all with a paper trail. The teams that handle it well treat every change, no matter how minor, as a triage decision that produces a record. The teams that handle it badly treat the procedure as something that applies to other people's changes. Auditors can tell the difference, and they will ask about the changes you didn't think you had to document.