4.4 Clause 6.3 Planning of Changes
Key Takeaways
- Clause 6.3 requires that changes to the AIMS be carried out in a planned manner, considering purpose and potential consequences, integrity of the AIMS, resource availability, and allocation or reallocation of responsibilities.
- AI-specific changes—model retrains, foundation-model or provider swaps, data-pipeline changes, and AIMS scope expansion—are high-risk change types that auditors should sample deliberately.
- Planned change is not the same as informal MLOps push-to-production; auditors test change records for impact on risk, impact assessment, SoA, objectives, and competence.
- Integrity of the AIMS means the management system remains complete and coherent after the change—not only that the model’s accuracy metric improved.
- Common nonconformities include emergency production changes with no retrospective assessment, vendor swaps without control re-evaluation, and scope growth without Clause 4/6 updates.
4.4 Clause 6.3 Planning of Changes
Auditor focus: When the AIMS or AI systems change, are changes planned—or shipped first? Sample retrains, provider swaps, and scope expansions. Test purpose, consequences, AIMS integrity, resources, and responsibilities (or prompt retrospective assessment for emergencies).
Clause 6.3 requires that when the organization needs changes to the AIMS, they are carried out in a planned manner. In AI environments change is continuous (retrains, prompt edits, vendor API updates). Without 6.3 discipline, 6.1 treatments and 6.2 objectives become snapshots of a system that no longer exists.
What Clause 6.3 Requires
The organization shall carry out changes to the AIMS in a planned manner, considering:
- The purpose of the changes and their potential consequences.
- The integrity of the AIMS.
- The availability of resources.
- The allocation or reallocation of responsibilities.
These four considerations are the auditor’s checklist. “We have a change ticket” is not enough if the ticket never addresses AIMS integrity or residual risk consequences.
| 6.3 consideration | Questions auditors ask | Weak answer |
|---|---|---|
| Purpose & consequences | Why change? What could go wrong for the system, people, and AIMS? | “Engineering wanted a newer model.” |
| Integrity of the AIMS | Will processes, controls, SoA, competence, and documented information still form a coherent system? | “Accuracy improved, so we’re fine.” |
| Resources | Are compute, people, test data, monitoring, and budget available? | “We’ll figure it out in production.” |
| Responsibilities | Who approves, implements, verifies, and owns residual risk after the change? | “The on-call ML engineer decided.” |
What Counts as a Change to the AIMS?
Not every code commit is an AIMS change, but 6.3 covers changes that affect the management system’s ability to achieve intended outcomes:
A. Changes to AIMS processes and governance
- Restructuring AI governance committees or risk-owner roles.
- Replacing the AI risk methodology or impact-assessment procedure.
- Major updates to AI policy, objectives, or SoA structure.
- Outsourcing internal audit of the AIMS or changing certification scope processes.
B. AI-specific technical and operational changes (high yield for sampling)
| Change type | Why it threatens AIMS integrity | Typical required re-checks |
|---|---|---|
| Model retrain / fine-tune | New weights can alter bias, safety, and performance; training data may shift | Re-validation, impact re-assessment triggers, residual risk update, monitoring baselines |
| Foundation model or API provider swap | Different failure modes, data handling, subprocessors, contractual controls | Third-party risk (A.10), SoA, security/privacy review, transparency notices |
| Prompt / system-instruction change (genAI) | Behavior can change without “model version” bump | Evaluation harness, content-safety tests, change approval |
| Data pipeline / feature store change | Labels, leakage, quality, and lineage effects | Data quality controls (A.7), drift monitors, access controls |
| Automation level increase (more auto-decisions) | Higher stakes for individuals; human oversight reduced | 6.1.4 impact assessment, A.9 use controls, redress processes |
| AIMS scope expansion (new BU, geography, AI system class) | Context, interested parties, risks, and controls no longer complete | Clause 4 updates, new risk/impact assessments, SoA refresh, competence |
| Decommission / model retirement | Residual data/models may still create impacts | Secure disposal, communication, inventory update |
C. Emergency changes
Incidents may force emergency production changes. Auditors allow urgency but test emergency-change rules and retrospective risk/impact/SoA assessment within a defined window.
Integrity of the AIMS — A Precise Auditor Concept
“Integrity of the AIMS” means the management system remains complete, consistent, and capable after the change. Indicators of lost integrity:
- Scope statement no longer matches inventory or operations.
- SoA still claims controls that were removed or never re-implemented for a new provider.
- Risk register versions lag months behind production model versions.
- Objectives and KPIs measure the old system’s behavior.
- Competence matrix still lists skills for a technology no longer used (or lacks skills for the new one).
- Documented information (model cards, evaluation reports) does not match deployed versions.
Higher average accuracy can still damage AIMS integrity if fairness gates, impact assessment, and residual acceptance were skipped.
Auditor Tests of Change Records
Sample production releases, MLOps histories, vendor notices, and governance minutes.
Suggested sampling approach
- Inventory plus last 3–6 months of model/prompt/provider changes.
- Stratify: retrain, provider swap, scope/automation increase, emergency change (if any).
- For each sample: purpose/consequence analysis, risk/impact updates, validation/approvals, SoA/control review (A.6, A.7, A.10), resources/responsibilities, post-implementation/rollback.
- Trace monitoring coverage for the new version.
Evidence quality table
| Evidence | Strong | Weak |
|---|---|---|
| Change ticket | States purpose, impact on AIMS/controls, approvers, links to risk ID | “Deploy v3” with auto-merge |
| Risk/impact update | Versioned assessment linked to system ID | Silent assumption “same as before” |
| Validation | Subgroup, safety, robustness tests for the change type | Accuracy on a convenience set only |
| SoA/control check | Documented review of affected Annex A controls | No SoA touch after provider swap |
| Post-release | Enhanced monitoring period, rollback plan | No owner watching drift after release |
Scenario: Provider swap without planning
A team switches a support chatbot from Provider A to B for cost. Procurement updates contracts; prompts are lightly edited. Hallucination complaints rise and data residency shifts to a new region.
Gaps: no 6.3 consequence/integrity analysis; no A.10 re-evaluation; no 6.1.4 impact re-check; residual acceptance and transparency notices unchanged. Likely 6.3 NC with linked 6.1, 8, and A.10 findings.
Scenario: Controlled retrain
A fraud model retrain for concept drift records purpose, customer false-positive consequences, updated risk scores, fairness re-tests, dual approval (model owner + risk owner), temporary post-release review staff, model-card/monitoring updates, and escalation if residual risk rises—planned manner in practice.
Integration with PDCA and Multi-Clause Trails
| Clause | Change-related expectation |
|---|---|
| 4.3 Scope | Scope expansions/reductions planned and documented |
| 6.1 | Risk/impact reassessed when changes can alter risk |
| 6.2 | Objectives/plans updated if change invalidates targets |
| 7 | Resources and competence adjusted; documented information controlled |
| 8 | Operational planning and lifecycle controls executed for the change |
| 9–10 | Performance effects reviewed; nonconformities corrected |
Common nonconformities
- Continuous deployment used to skip AIMS change planning.
- Model versioning treated as sufficient without consequence/integrity analysis.
- Scope creep without Clause 4/6 updates.
- Risk owners no longer match production reality after reorganizations.
- Security patches managed; AI ethics/safety changes unmanaged.
Record objective evidence: change IDs, versions, missing assessments, and broken responsibility chains. Clause 6.3 findings often expose the gap between a paper AIMS and live AI delivery.
Which four considerations must be addressed when carrying out changes to the AIMS under Clause 6.3?
A team swaps a generative-AI API provider in production to reduce cost. Contracts are updated, but risk assessment, impact assessment, SoA third-party controls, and monitoring baselines are unchanged. Which conclusion is most appropriate?
In an AI context, what does “integrity of the AIMS” most nearly mean for a lead auditor evaluating a model retrain?
Which sample is most useful when testing Clause 6.3 during a Stage 2 AIMS audit?