Planning of changes

ISO/IEC 42001 Clause 6.3 requires you to plan and control any change to your AI management system (AIMS) before implementation, so the system’s integrity is maintained and unintended risk doesn’t slip in. Operationalize this by running all AIMS changes through a defined change process with documented impact assessment, approvals, implementation controls, and retained evidence. ¹

Key takeaways:

• Treat AIMS changes as controlled change events, not ad hoc updates. ¹
• Require impact assessment and authorization before changes go live. ¹
• Keep a defensible audit trail: request, rationale, review, approval, implementation, and post-change verification. ¹

“Planning of changes” is one of the fastest ways auditors test whether your AI management system is real or just documentation. Clause 6.3 is short, but the expectation is not: if your organization changes how it governs AI, how it assesses and treats AI risks, how it monitors performance, how it manages third parties that affect AI, or how it controls AI lifecycle activities, you must do it in a planned manner. ¹

For a Compliance Officer, CCO, or GRC lead, this requirement is about preventing governance drift. Most AIMS failures are not caused by the initial design of the program; they happen when teams add a new AI use case, swap an AI service provider (a third party), change data sources, update policies, or reorganize responsibilities without updating the AIMS controls that keep risk bounded. Clause 6.3 pushes you to institutionalize one simple discipline: every meaningful AIMS change has an owner, a plan, a risk/impact review, an approval, a controlled rollout, and proof it happened. ¹

Regulatory text

Requirement (verbatim excerpt): “When the organization determines the need for changes to the AI management system, the changes shall be carried out in a planned manner.” ¹

What the operator must do:
You need a documented, repeatable change management method for your AIMS. It must (1) define what qualifies as an AIMS change, (2) require planning and review before implementation, (3) control execution, and (4) preserve evidence that the change was evaluated, approved, implemented, and validated. ¹

Plain-English interpretation (what Clause 6.3 means in practice)

If your AIMS is changing, you should be able to answer four questions quickly and consistently:

1. What is changing and why? (scope, rationale, trigger)
2. What could this break or worsen? (risk, compliance obligations, controls, roles)
3. Who approved it? (governance and accountability)
4. How do you know it worked? (verification and monitoring updates)

AIMS changes are broader than technical model updates. They include governance changes (committees, roles), process changes (risk assessment workflow), policy changes, tool changes (monitoring platforms), and third-party changes that alter how AI is sourced, built, deployed, or monitored. Clause 6.3 is satisfied when these changes are planned and controlled instead of improvised. ¹

Who it applies to

Clause 6.3 applies to any organization operating an AI management system, including:

• AI providers (building or offering AI systems/services)
• AI users (deploying or relying on AI in business processes)
• Organizations that govern AI across internal teams and third parties ¹

Operationally, you should treat this as applying whenever a change affects:

• AIMS scope (which AI systems/use cases are covered)
• AI risk management method (how you identify, assess, treat, and accept risk)
• Controls that support the AIMS (monitoring, incident handling, training, documentation, internal audit)
• Third-party dependencies that impact AI outcomes (AI model providers, data providers, annotation services, hosting platforms)

What you actually need to do (step-by-step)

1) Define “AIMS change” and set thresholds

Create an AIMS change definition and a simple categorization scheme. Keep it workable:

• Administrative change: wording, formatting, non-substantive updates (still logged)
• Material change: affects responsibilities, risk controls, decision criteria, scope, or assurance activities
• Emergency change: requires expedited implementation with after-the-fact review

Include triggers that commonly get missed:

• onboarding a new third party that provides AI capability or training data
• moving an AI workload to a different environment
• changing your AI risk acceptance criteria or review bodies
• changing monitoring/alert thresholds or KPIs used for AI oversight

2) Standardize intake: AIMS Change Request

Require a single intake record for every change. Minimum fields:

• description of change and rationale
• affected AIMS components (policy/process/role/control/tool/third party)
• impacted AI systems/use cases (or “none” with explanation)
• proposed implementation plan and owner
• requested date / urgency and whether it’s emergency

3) Perform an impact assessment (risk + compliance + operations)

Your review should be practical, not academic. Use a checklist format so it can be executed consistently:

• Control impact: which AIMS controls must be updated (procedures, training, monitoring, internal audit plan)
• Risk impact: new or changed AI risks; whether residual risk increases
• Third-party impact: contract/SLA changes, security/compliance assurances, exit implications
• Assurance impact: do you need additional testing, monitoring changes, or management review updates?
• Documentation impact: what policies, procedures, and records must change so they match reality

Outcome should be: approve, approve with conditions, or reject. Record conditions as explicit tasks with owners.

4) Route for approvals (make it role-based)

Define approval authority by change category. A workable pattern:

• administrative: AIMS program owner approval
• material: compliance + AI risk owner (and security/privacy as applicable)
• emergency: expedited approval by a designated accountable executive, then retrospective review

Auditors look for consistent authorization. They also look for segregation of duties where feasible: the implementer should not be the only approver for material changes.

5) Plan the implementation (tasks, dependencies, comms)

A planned change has a plan you can show. Require:

• implementation steps (including rollback plan if feasible)
• dependencies (training, tooling, third-party deliverables)
• communications plan (who must be informed, including impacted business owners)
• effective date and versioning for affected documentation

6) Execute with change controls

During implementation:

• update controlled documents (policies, procedures, RACI, risk methodology)
• push training/awareness if responsibilities changed
• update tooling configurations (e.g., monitoring rules) with access controls and logging
• coordinate with third parties and capture their confirmations where relevant

7) Post-change verification and closure

Before closing the change:

• verify the change occurred as approved
• confirm related documents were updated and published
• confirm monitoring and metrics still function, and incident pathways still work
• record evidence and lessons learned

A common closure discipline: “no closure without evidence.” If evidence is missing, treat the change as still open.

Required evidence and artifacts to retain

Keep a tight evidence set tied to each change ticket plus a program-level view.

Per-change artifacts

• change request record (with category and rationale)
• impact assessment checklist/results
• approvals (named approvers, date/time, conditions)
• implementation plan and completion notes
• updated documents (version history and effective date)
• verification results (tests, screenshots, meeting notes, sign-offs)
• if third-party related: updated contract exhibits, due diligence outputs, or confirmation from the third party

Program-level artifacts

• AIMS change management procedure (the “how”)
• roles/responsibilities for approving changes
• change log and periodic reporting to management review

If you use Daydream to run your compliance operations, map the AIMS change request to a controlled workflow (intake → impact assessment → approvals → implementation checklist → evidence upload → closure) so you can produce an audit-ready trail without chasing screenshots across teams.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the last material change to the AIMS and walk me through planning and approvals.”
• “How do you decide what is a material change?”
• “Where is the evidence that impacted documents were updated and communicated?”
• “How do third-party changes feed into your AIMS change process?”
• “What happens in emergencies? Show an emergency change and the retrospective review.”

Hangups that cause findings:

• teams can’t produce a change log
• approvals exist, but no impact assessment is documented
• policy versions don’t match operational reality
• changes happened in tools (monitoring/workflows), but there is no record in the AIMS

Frequent implementation mistakes (and how to avoid them)

1. Only tracking technical changes
   Fix: explicitly include governance, policy, process, and third-party dependency changes in scope.

2. “Approval” without defined criteria
   Fix: require approvers to attest that impact assessment was reviewed and conditions are satisfied.

3. No closure discipline
   Fix: block closure until evidence is attached (updated doc versions, verification notes).

4. Emergency changes become a loophole
   Fix: require retrospective review and formalization into standard documentation after the fact.

5. Changes are planned, but not communicated
   Fix: add a mandatory comms step when roles, responsibilities, or requirements change.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the available sources. Practically, Clause 6.3 is still high-risk: unplanned changes are a common root cause of control failures, inconsistent AI risk decisions, and “paper program” findings during audits. The business impact is predictable: drift between documented governance and actual operations, plus gaps in third-party oversight when AI services change hands.

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control)

• Publish a one-page AIMS Change Management Procedure with definitions and categories. ¹
• Implement an AIMS Change Request template and a central change log.
• Identify approvers by category and document who can authorize emergency changes.

Days 31–60 (make it executable across teams)

• Add an impact assessment checklist focused on control, risk, documentation, and third-party impacts.
• Pilot the process on recent or upcoming changes (policy update, role change, new AI third party).
• Set a closure rule: no closure without evidence attached.

Days 61–90 (make it auditable and durable)

• Add periodic reporting (e.g., summary of changes, overdue items) into management routines.
• Train owners (product, engineering, procurement, compliance) on what counts as an AIMS change.
• Run an internal spot-check: sample closed changes and verify evidence completeness and document version alignment.

Frequently Asked Questions

What counts as a “change to the AI management system” versus a project-level AI change?

AIMS changes alter governance, policies, processes, roles, controls, or oversight mechanisms across AI. A project-level change becomes an AIMS change if it requires updates to the way you manage AI risks or operate your AIMS controls. ¹

Do we need a separate change process for the AIMS if we already have IT change management?

Not necessarily. You can extend your existing change process if it captures AIMS-specific impact assessment, approvals, and evidence for governance and risk controls, not just technical implementation.

How should we handle emergency changes?

Allow expedited approval and implementation, but require a retrospective impact assessment, documentation updates, and formal closure evidence. Treat repeated “emergencies” as a process failure to fix.

How do third-party changes fit into planning of changes?

If a third party affects AI capability, training data, model behavior, monitoring, or compliance obligations, route the change through the AIMS change process and attach procurement/due diligence artifacts to the change record.

What evidence is most persuasive to an auditor?

A complete trace from change request to impact assessment to approval to implementation proof to post-change verification, with version-controlled documents showing what changed and when.

How strict should our “material change” threshold be?

Set it where approvals and impact assessment effort are proportional to risk. If a change affects risk acceptance, monitoring, incident handling, scope, or accountability, treat it as material.

Footnotes

1. ISO/IEC 42001:2023 Artificial intelligence — Management system