5.2 Clause 8: Operational Planning, Control & Change Management

Clause 8: operation

Clause 8 is where plans become controlled activity. It does not prescribe one MLOps architecture or require every organization to operate a model-training pipeline. It requires the organization to plan, implement, and control the processes needed to meet requirements and carry out Clause 6 actions.

8.1 Operational planning and control

The organization establishes criteria for relevant processes and controls those processes in accordance with the criteria. It implements the controls determined under Clause 6.1.3 that relate to operation of the AIMS, such as development and use lifecycle controls.

The effectiveness of implemented controls is monitored, and corrective actions are considered when intended results are not achieved. Documented information is available to the extent necessary to have confidence that processes were carried out as planned.

Criteria and evidence

Operational criteria translate policy, objectives, risks, and requirements into decision rules. Examples can include:

• data acceptance and quality criteria;
• verification and validation criteria;
• deployment prerequisites;
• access and use boundaries;
• monitoring and escalation thresholds;
• supplier acceptance criteria; and
• incident or fallback triggers.

The standard does not mandate a particular precision, latency, fairness ratio, or error threshold. Criteria must fit the system’s intended use, context, risk, impact, and applicable requirements.

Evidence likewise varies. Test results, approvals, logs, completed checklists, tickets, assessment results, or interview evidence can demonstrate execution. Clause 8.1 requires enough documented information for confidence, not maximum paperwork.

Change control

Clause 8.1 requires the organization to control planned changes and review consequences of unintended changes, taking action to mitigate adverse effects as necessary.

Planned changes can include new purpose, model replacement, data-source change, workflow integration, revised automation, supplier migration, or scope expansion. Unintended changes can include shifts in input distributions, upstream service behavior, unexpected feedback loops, or environmental conditions.

Data drift is not literally a change to model weights, but it can change operational performance. The organization reviews consequences using its criteria rather than asserting that every observed distribution change automatically requires retraining.

Change controls can include impact analysis, testing, authorization, communication, staged release, rollback, or renewed assessment. These are examples selected in context. ISO/IEC 42001 does not universally require canary deployment or approval by a named AI governance board.

Externally provided processes, products, and services

The organization ensures that externally provided items relevant to the AIMS are controlled. This covers more than outsourced processes. It can include AI services, foundation models, datasets, annotation, cloud infrastructure, monitoring services, and specialist evaluation.

Control can involve defining requirements, allocating responsibilities, performing due diligence, testing, monitoring supplier changes, managing incidents, and maintaining alternatives. The organization still has to satisfy the AIMS requirements applicable to its own scope, but legal liability is not determined by this clause and should not be described as automatically “fully” assigned to one party.

Annex A.10 supplies relevant reference controls on responsibility allocation, suppliers, and customers.

8.2 AI risk assessment

The organization performs AI risk assessments in accordance with its Clause 6.1.2 process:

• at planned intervals; or
• when significant changes are proposed or occur.

It retains documented information on the results of all AI risk assessments.

Clause 6.1.1 establishes risk criteria, Clause 6.1.2 defines the assessment process, and Clause 8.2 produces current assessment results. A proposal can trigger assessment before implementation, while an unplanned significant change can trigger it after detection.

8.3 AI risk treatment

The organization implements the AI risk-treatment plan established under Clause 6.1.3 and verifies its effectiveness. When an assessment identifies new risks requiring treatment, it performs the Clause 6.1.3 treatment process for those risks. When planned treatment options are ineffective, it reviews and revalidates those options through that process and updates the treatment plan. Documented information on all treatment results is retained.

Implementation means more than listing a control in the SoA. If a selected control concerns data quality, the organization operates the relevant process and retains sufficient evidence. Ineffective treatment loops back to selection and planning; it is not handled only by leaving an unchanged control in place.

Residual risk acceptance occurs through the Clause 6.1.3 approval process. Clause 8.3 is the execution, verification, re-treatment, and evidence stage.

8.4 AI system impact assessment

The organization performs AI system impact assessments according to Clause 6.1.4 at planned intervals or when significant changes are proposed. It retains documented information on all results.

Notice the exact trigger difference: Clause 8.2 says when significant changes are proposed or occur; Clause 8.4 says when significant changes are proposed. An organization can define additional event triggers, but the guide should not alter the standard’s wording.

A connected example

A bank replaces a third-party fraud model. Under 8.1 it defines release criteria, controls the supplier integration, tests the change, updates needed documentation, and plans rollback. Under 8.2 it reassesses risks because a significant change is proposed. Under 8.4 it performs the impact assessment for consequences to customers and groups. Under 8.3 it implements treatment controls such as access restrictions, validation, monitoring, and appeal routing.

After release, the bank monitors control effectiveness. If the supplier silently changes output formats, the bank treats that as an unintended change, reviews consequences, and mitigates adverse effects. It may trigger a new risk assessment because a significant change occurred.

Clause 6 versus Clause 8