Planning Changes to Your AIMS: Clause 6.3 of ISO 42001 Explained

Why Change Planning Matters in an AI Management System

If you have spent any time working with ISO management systems, you know that change is where things go wrong. A new AI model gets deployed, a process gets restructured, or a key supplier relationship shifts, and suddenly the system you audited six months ago no longer reflects what is actually happening. Clause 6.3 of ISO 42001 exists precisely to prevent that gap from opening up.

Clause 6.3 is a short clause. It does not have sub-clauses or lengthy normative requirements. But do not mistake brevity for simplicity. The planning of changes requirement sits inside the broader planning section of ISO 42001, and it connects directly to the risk and opportunity work you did in Clauses 6.1 and 6.2. Get it wrong, and your AI Management System (AIMS) becomes a document that describes how things used to work rather than how they work now.

This article walks through what Clause 6.3 actually requires, how it applies specifically to AI systems and the AIMS, common pitfalls organisations run into, and what auditors look for when they assess this clause in practice.

What Clause 6.3 of ISO 42001 Actually Says

The clause is modelled on the same Clause 6.3 that appears across the High Level Structure used in other ISO management system standards. If you have worked with ISO 9001, ISO 14001, or ISO 27001, the language will look familiar. The requirement is that when the organisation determines the need to make changes to the AIMS, those changes must be carried out in a planned manner.

The standard identifies four considerations that must be addressed when planning changes:

• The purpose of the changes and their potential consequences
• The integrity of the AIMS
• The availability of resources
• The allocation or reallocation of responsibilities and authorities

That is it. Four considerations, no prescribed procedure, no mandatory documented information. But the simplicity of the text can be misleading. Each of those four considerations carries real weight when you are dealing with AI systems, and the consequences of poorly managed change in an AI context can be significant.

How AI Makes Change Planning More Complex

The planning of changes requirement appears in many ISO standards, but the AI context adds layers of complexity that do not exist in a quality or environmental management system. Consider what a change might look like in an AIMS compared to a traditional management system.

In ISO 9001, a change might mean updating a work instruction or switching to a new supplier. The consequences are usually contained, traceable, and relatively predictable. In an AIMS, a change might involve:

• Updating or retraining an AI model on new data
• Switching from one AI provider to another
• Expanding the scope of an AI system to cover new use cases or populations
• Integrating an AI system with a new data source
• Changing the human oversight arrangements for an AI decision
• Moving from a pilot deployment to full production

Each of these changes can affect the risk profile of the AI system, the validity of the impact assessment conducted under Clause 6.1.2, the appropriateness of the controls selected under Clause 6.1.3, and the relevance of the objectives set under Clause 6.2. A change that looks administrative on the surface can fundamentally alter how the AI system behaves and what harms it might cause.

This is why the connection between Clause 6.3 and the rest of the planning section matters so much in an AIMS. When a change is planned, the organisation needs to think about whether that change triggers a need to revisit the AI risk assessment, update the AI impact assessment, or revise the Statement of Applicability.

The Four Considerations in an AI Context

Purpose and Potential Consequences

The first consideration is understanding why the change is being made and what might happen as a result. In an AI context, this means thinking beyond the immediate technical outcome. If you are retraining a model on updated data, the purpose might be to improve accuracy. But the potential consequences could include changes in how the model treats different demographic groups, shifts in the types of errors the model makes, or unintended changes in outputs that affect downstream decisions.

Organisations that handle this well typically document the rationale for the change and conduct some form of pre-change assessment. This does not need to be a full AI impact assessment every time, but there should be a structured conversation about what might change and who might be affected. If the assessment reveals material new risks, then a more thorough review is warranted before the change proceeds.

Integrity of the AIMS

The second consideration is whether the change maintains the integrity of the management system itself. This is often the consideration that organisations overlook. They focus on the technical change and forget to ask whether the AIMS documentation, policies, objectives, and controls still accurately reflect the system after the change is made.

In practice, this means checking whether the AI policy under Clause 5.2 still applies to the changed system, whether the roles and responsibilities defined under Clause 5.3 are still appropriate, whether the documented information required by Clause 7.5 needs to be updated, and whether the operational controls under Clause 8.1 remain effective. A change that is technically well-managed but leaves the AIMS documentation out of date is still a failure of Clause 6.3.

Availability of Resources

The third consideration is whether the organisation has the resources to implement the change properly. Resources in this context include people with the right competencies, infrastructure, time, and budget. In an AI context, this is particularly important because the skills required to manage AI systems are often specialised and not always available internally.

If an organisation is planning to expand the use of an AI system to a new business area, they need to consider whether the people in that area have the awareness and competence to work with the system appropriately. If they are switching AI providers, they need to consider whether their team has the technical knowledge to evaluate the new provider's system against the AIMS requirements. Resource gaps identified at the planning stage can be addressed before the change creates problems. Resource gaps discovered after the fact are much harder to manage.

Allocation or Reallocation of Responsibilities and Authorities

The fourth consideration is whether the change affects who is responsible for what. This is closely connected to Clause 5.3, which requires the organisation to assign and communicate roles, responsibilities, and authorities for the AIMS. When a change occurs, those assignments may need to be revisited.

For example, if an AI system that was previously managed by the IT department is being transferred to a business unit, the responsibilities for monitoring performance, managing incidents, and conducting impact assessments need to follow the system. If no one explicitly picks up those responsibilities, they fall through the gap. Clause 6.3 requires the organisation to think about this before the change happens, not after.

What Triggers a Change Under Clause 6.3

One of the practical questions organisations ask is how to know when Clause 6.3 applies. The standard says it applies when the organisation determines the need to make changes to the AIMS. That phrasing is deliberately broad. It covers both planned changes, which the organisation initiates deliberately, and reactive changes, which are driven by external circumstances.

Common triggers in an AIMS context include:

• Changes to the AI systems in scope, including updates, retraining, or replacement
• Changes to the organisational context identified under Clause 4.1, such as a new regulatory requirement or a shift in the competitive environment
• Changes to the needs and expectations of interested parties identified under Clause 4.2
• Changes arising from management review outputs under Clause 9.3
• Changes required to address nonconformities identified through internal audit under Clause 9.2
• Changes driven by the results of AI impact assessments under Clause 8.4
• Changes in the organisation's AI objectives under Clause 6.2

Not every minor update to an AI system will require a formal Clause 6.3 process. Organisations need to develop a sense of materiality, distinguishing between routine maintenance and changes that genuinely affect the risk profile or the AIMS. The key question is whether the change has the potential to affect how the AIMS delivers on its intended outcomes.

Documented Information and Clause 6.3

ISO 42001 does not explicitly require documented information as evidence of change planning under Clause 6.3. This is consistent with the approach taken in other High Level Structure standards. However, the absence of a mandatory document does not mean documentation is unnecessary.

In practice, auditors will look for evidence that changes were planned rather than simply implemented. That evidence might take many forms: a change request record, a pre-change review meeting agenda and minutes, an email chain showing that responsibilities were discussed and agreed before the change proceeded, or an updated risk assessment that was completed ahead of the change going live.

Organisations that manage this well tend to have a change management process that captures the four considerations in some form, even if it is lightweight. A simple change register with fields for purpose, consequence assessment, resource check, and responsibility allocation will satisfy most auditors and, more importantly, will protect the organisation from the kind of drift that happens when changes are made without adequate thought.

How Clause 6.3 Connects to the Rest of the AIMS

Clause 6.3 does not sit in isolation. It is part of a planning section that includes risk and opportunity management, AI risk assessment, AI risk treatment, and objective setting. When a change is planned, the organisation should consider how it affects each of those elements.

The connection to the AI impact assessment process is particularly important. The AI impact assessment concept is one of the features that sets ISO 42001 apart from other management system standards. If a planned change alters the nature of an AI system, its deployment context, or the populations it affects, the impact assessment may need to be repeated or updated. Clause 6.3 is the point in the system where that determination should be made.

Similarly, changes to AI systems can affect the Statement of Applicability, which documents the controls from Annex A that the organisation has selected and the justification for those selections. If a change introduces new risks or removes existing ones, the controls selected may need to change, and the Statement of Applicability should reflect that. The Statement of Applicability is one of the most examined documents in any ISO 42001 audit, and keeping it current through the change management process is essential.

Common Nonconformities Against Clause 6.3

Based on how similar clauses play out in other management system audits, the most common issues organisations face against Clause 6.3 of ISO 42001 are likely to follow familiar patterns.

The first is changes being implemented without any documented consideration of the four criteria. The AI system gets updated, a new use case gets added, or a provider gets changed, and there is no record of anyone asking whether the AIMS still holds up. When an auditor asks how the change was planned, the answer is a blank look or a reference to a technical change management process that does not connect to the AIMS at all.

The second is AIMS documentation that does not keep pace with changes. The AI policy, the risk assessment, the impact assessment, and the documented information all reflect the system as it was when the AIMS was first established, not as it exists today. This is a failure of the integrity consideration in Clause 6.3.

The third is responsibility gaps. A change has been made, but no one has been formally assigned responsibility for the new or changed elements of the AI system. The auditor asks who is responsible for monitoring the performance of the expanded AI system and gets three different answers from three different people.

The fourth is resource gaps that were not identified at the planning stage. The organisation expanded an AI system into a new business area without ensuring that the people in that area had the awareness or competence to work with it appropriately. This shows up in awareness interviews during the audit, where staff in the affected area cannot explain what the AI system does, what its limitations are, or what to do if something goes wrong.

What Auditors Look For in Practice

When auditing Clause 6.3, an experienced auditor will typically start by identifying what changes have occurred to the AIMS or to the AI systems in scope since the last audit. This might come from a review of change records, from the management review outputs, from conversations with the AI system owners, or from comparing the current AIMS documentation against previous versions.

Once changes have been identified, the auditor will trace each significant change back to evidence that it was planned in accordance with the four considerations. They will ask questions like:

• How was the decision to make this change made, and what was the rationale?
• What assessment was done of the potential consequences before the change was implemented?
• Was the AI risk assessment or impact assessment reviewed as part of the change planning?
• Were resources confirmed as available before the change proceeded?
• Were responsibilities clearly allocated for the changed system?
• Was the AIMS documentation updated to reflect the change?

Auditors will also look for evidence that the change planning process is embedded in how the organisation actually works, not just a paper exercise that happens after the fact. The best evidence of this is a consistent pattern of change records that show the four considerations being addressed before changes go live, not after.

Building a Practical Change Management Process for Your AIMS

If your organisation is implementing or maintaining an AIMS, building a practical change management process does not need to be complicated. The goal is to create a reliable way of ensuring that the four considerations in Clause 6.3 are addressed every time a material change is planned.

A practical approach might include a simple change request form or template that prompts the person proposing the change to address each consideration. The form does not need to be long. A few targeted questions about purpose, consequences, resources, and responsibilities will usually be enough to capture what is needed.

The process should also include a trigger to review the AI risk assessment and impact assessment whenever a change affects the nature, scope, or deployment context of an AI system. This connection between change management and the risk assessment process is what keeps the AIMS accurate over time.

Finally, the process should include a step for updating AIMS documentation after a change is implemented. This is often the step that gets skipped when people are busy. Building it into the change management process as a required close-out activity helps ensure that documentation drift does not accumulate over time.

For those looking to build genuine competence in auditing and implementing AI management systems, training as an ISO 42001 auditor provides the structured foundation needed to navigate clauses like 6.3 with confidence. Audit Workshop offers practical, experience-led training across ISO 42001 and other management system standards, designed for practitioners who need to apply what they learn from day one.