MUbase

Explore apps

QMS | base9 min readUpdated:

Change management in the QMS: controlling changes

Change management in the QMS: request, review, approve and implement changes. With a worked example, checklist and notes on ISO 9001.

Editorial team KMU | base – technically reviewed by an HR specialist from the founding team with experience in accounting and auditing

By emailLinkedIn
Signpost with coloured directional arrows

A new device, a changed procedure, a revised form: something is always changing in a business. Change management makes sure that such changes do not happen on the side and without control, but are planned, reviewed and approved. This guide shows how an SME can set up change management in its quality management system (QMS) simply and traceably, what role ISO 9001 plays in it and where the law requires an adjustment anyway.

What change management achieves

A change to the QMS or to processes can have consequences that the person requesting it cannot oversee alone: a new machine requires a new work instruction, training and perhaps a different inspection. If one of these is forgotten, a contradiction arises between what is documented and what happens in the business. Before implementation, change management therefore answers four questions: What changes and why? Which processes, documents and people are affected? What resources are needed? Who decides?

ISO 9001 requires, in substance, that changes to the quality management system are carried out in a planned manner and that changes affecting production or service provision are reviewed and controlled so that conformity is maintained. In the 2015 edition these requirements were in clauses 6.3 and 8.5.6. Since 16 September 2026 the 6th edition, ISO 9001:2026, has applied; it replaces the 2015 edition. According to certification bodies, the requirements for managing changes to the quality management system have been strengthened in clause 6.3 of the new edition. The text of the standard is protected by copyright and is not reproduced here; check the numbers in your copy of the standard. For safety at work, the current ISO 45001:2018 contains, in substance, a separate section on the control of changes (clause 8.1.3 of the 2018 edition).

When a change is formally requested

Not every trifle needs a request. Decide for yourself when a change is formally requested; this is an operational decision, not a statutory requirement. A request has proved its worth when a change

  • affects a process or the people responsible for it,
  • changes several documents or forms at the same time,
  • requires training, investment or the time of several people,
  • touches customers, suppliers, products or safety.

Correcting a typing error or adjusting a single checklist, by contrast, goes through normal document control.

In two areas the legal system expressly prescribes that changes trigger a review:

  • Occupational safety: If buildings, parts of buildings, work equipment or work procedures are changed or new substances are used, the employer must adapt the protective measures and protective devices to the new circumstances (Art. 3, para. 3 of the Ordinance on the Prevention of Accidents and Occupational Diseases, VUV).
  • Food: The review of the HACCP procedures must be carried out regularly and without delay if a change in the production process could impair the safety of the food produced (Art. 79, para. 3 of the Foodstuffs and Utility Articles Ordinance, LGV).

A change request is a suitable place to record this review.

The process from request to completion

The process is deliberately simple. It follows the principle that the person making the request neither reviews it nor approves it themselves; ideally, review and approval are in addition distributed across two people:

StepWhoResult
Record the requestRequesterDraft with reason, impact and resources
SubmitRequesterRequest is ready for review
ReviewSecond personImpact and effort are assessed
Approve or rejectResponsible personDecision, with reasons if rejected
ImplementPerson responsibleActions are done, the change is completed

The decision at the end is important: a rejected request remains traceable with the reasons, and an approved request too is only completed once all follow-up tasks are done. After completion, check whether the change brings the expected benefit; this effectiveness check is practice and not a statutory requirement.

What belongs in a change request

A usable request manages with a few details:

  • Title and description: What is to change?
  • Reason: Why? For example customer request, complaint, new regulation, investment.
  • Impact: Which processes, documents, rooms, devices and people are affected?
  • Resources: Time, budget, training, external help.
  • Planned date: When is it to be ready?
  • Follow-up tasks: Who does what by when?

Anyone who is honest on these points saves discussions later. For larger changes, it is worth looking at the risk register, as described in the guide Risk management for SMEs.

Typical stumbling blocks

Three mistakes keep recurring in small businesses. First, approval becomes a formality: the request is nodded through without anyone reading the impact on other processes. Second, documents are left behind: the machine is already running, but the work instruction still describes the old procedure. Third, changes are brought forward in daily work because time is short, and the request is created only afterwards. A clear threshold, a fixed place for all requests and the principle that a change counts as completed only when documents, training and records are updated help against this. For changes in emergencies you can agree a fast variant internally, for example verbal approval with written confirmation on the next working day. That is an operational rule and not a requirement of the standard.

Practical example: Holzbau Muster AG

Holzbau Muster AG is a fictitious company with 28 employees. In December 2026 it wants to commission a CNC joinery line that replaces manual cutting to size. On Monday, 2 November 2026, the production manager records the change request “New joinery line”. As the reason he gives shorter lead times, as impact two affected processes (cutting to size and material inspection) and three affected documents (two work instructions and the inspection plan). As resources he names the training of two employees. The quality manager reviews the request on Wednesday, 4 November. She adds that the protective measures under Art. 3, para. 3 VUV must be reviewed for the new line. The managing director approves on Friday, 6 November.

The production manager then creates four tasks:

TaskResponsibleBy
Rewrite work instruction “Cutting to size”Production manager20 November 2026
Adjust inspection planQuality manager20 November 2026
Instruct two employeesProduction manager27 November 2026
Review and record protective measuresSafety officer27 November 2026

On Monday, 30 November 2026, all tasks are done; the production manager completes the change. The line goes into operation on 1 December. Requester, reviewer and approver are three different people, and everything an audit or a customer might later want to know is in one place.

Checklist

  • Threshold defined for when a change must be requested
  • Request completed with reason, impact and resources
  • Affected processes and documents named
  • Review and approval by someone other than the requester
  • For work equipment, procedures or substances: protective measures reviewed (Art. 3, para. 3 VUV)
  • For food: HACCP procedures reviewed on a change of the production process (Art. 79, para. 3 LGV)
  • Follow-up tasks recorded with persons responsible and dates
  • Change completed only after the tasks are done
  • Result checked after some time

How KMU | base helps

In QMS | base you run the process under Management system › Changes. The menu item belongs to the “Management system” group, which you expand as needed.

1. Record the request. With “New” you plan a change to the QM system: with title, description, reason, effects, resources, the affected processes and documents and a planned date. Each request receives a sequential number with the prefix AE-. As long as it is a draft, only the requester sees it.

2. Review and approve. The request passes through the stages Draft, Submitted, Reviewed and Approved. The four-eyes principle applies: whoever makes a request can neither review nor approve it. Review and approval can be taken on by the same person. If only one person approves in your business, you can switch off the four-eyes principle in the QMS settings. A request can be withdrawn or rejected; rejection requires a reason. The quality management lead receives a notification on submission and on review, the requester on the decision. Requesting and reviewing and approving are separate rights.

3. Implementation. To an approved change you attach implementation actions and then complete it as implemented. The actions also appear in the list of actions. Note the limit: when you complete the change, the software does not check whether all actions are done. That remains the task of the responsible person. There is no separate effectiveness check for the change; for that you create an action.

4. Your own forms. With the form designer under Operations and records › Forms (in the area “More”) you build your own forms with text, multi-line text, number, date, selection, multiple selection and yes/no, with required fields and help text, for example a checklist for assessing changes. Creating new forms requires the right for the QMS settings. Such a form is not automatically linked to a change request.

If you would like to try it yourself, take a look at the demo or open a trial account. You will find current terms under Pricing; if you have questions, the contact page will help.

Sources

This guide does not replace legal or tax advice. Information as at 27 October 2026.

Back to top

Collaboration ×

The next step starts with a conversation.

What does your business need?