ISO 42001 Clause 6.3: Plan Changes to the AI Management System

What clause 6.3 requires in practice

Clause 6.3 is one sentence long. When the organisation determines that the AI management system needs to change, the changes must be carried out in a planned manner. The clause does not name a change form, an approval sequence or a record. It simply asks that changes to the system be deliberate rather than accidental.

The subject is the management system, not the AI technology. A new scope, revised risk criteria, a different approval route, a redistribution of responsibilities or a replaced information system would each fall within it. An update to an AI model is an operational matter handled under operational control, although it may reveal that the management system itself needs to change. In practice, planned means that someone considered why the change is needed, what it affects, who must be prepared, how the transition will work and how the result will be checked. The depth of planning can reflect the consequence of getting the change wrong.

Recognise a management-system change

Changes to scope, assessment criteria, responsibilities, approval routes or information arrangements can alter the AIMS. An AI model update is an operational change that may trigger assessment; it may also expose a need to change the management system. Keep the two questions connected without assuming they are identical.

As an original planning method, describe why the change is needed, which processes and people it affects, how work will transfer and how the new arrangement will be checked. These are practical prompts rather than a new ISO-prescribed list.

Why planned change matters to the business

Management systems rarely fail because of a bad design; they fail during the transition. A new approval route may leave requests in limbo between the old and new arrangements, or a changed assessment method may make this year's results incomparable with last year's. Planning changes protects continuity of decisions, keeps records accessible and prevents people from working to two versions of a process. It also shows auditors and customers that improvement is managed, not improvised. For businesses growing into new markets or absorbing acquisitions, the ability to change the system in a controlled way is a practical condition of keeping governance credible as the organisation evolves.

How to implement clause 6.3

Scale the planning to the importance of the change. A small correction does not need a project, while a redesign of risk acceptance authority does.

1. Write down why the change is needed, for example a finding from management review, a new scope or a changed regulatory expectation.
2. Identify the processes, roles, records and people the change touches.
3. Decide how work in progress will move to the new arrangement so that requests are not lost between versions.
4. Prepare people through communication and, where needed, learning, rather than sending only a revised document.
5. Run a trial on an ordinary case and an exception to find gaps, such as a manager who cannot raise a concern that does not fit the new form.
6. Confirm that records created during the transition remain retrievable and that instructions in use are the current ones.
7. Review after the change whether the intended result was achieved, and adjust through an authorised decision.

Illustrative software example: changing the risk method

Illustrative BPO example: centralising approval

A BPO group moves AI-use approval from local operations to a central governance team. Local supervisors previously responded to urgent client requests; the central team works in a different time zone. The change can create a gap even if the new responsibility chart looks clear.

Planning addresses how requests arrive, who handles urgent uncertainty, what local authority remains and how approved conditions reach delivery teams. A pilot can reveal whether the route works during actual service hours. The organisation also considers requests already in progress so they do not become lost between the old and new arrangements.

Control the transition, not just the launch date

A transition can leave two versions of a process operating at once. Determine how people identify the applicable arrangement and which records explain a decision made during the change. Update relevant instructions and access where needed. Communicate what changes in practice instead of sending only a revised document link.

For important changes, checking an ordinary case and an exception can reveal gaps. Can a new employee follow the process? Can a local manager raise a concern that does not fit the form? Such checks are suggested techniques; their depth should fit the consequences of failure.

Evidence and relationships to other clauses

Common mistakes