Repeating AI Risk Assessment and Treatment in Operation: ISO 42001 Clauses 8.2 and 8.3

Why Clauses 8.2 and 8.3 Exist at All

Most people who study ISO 42001 spend the bulk of their preparation time on the planning clauses. They work through Clause 6.1.2 on AI risk assessment and Clause 6.1.3 on risk treatment, they build their Statement of Applicability, and they feel ready. Then they get to Clause 8 and discover that the standard expects them to do it all again, operationally, at planned intervals, as a live management activity rather than a one-off planning exercise.

That is not a duplication. It is the point. AI systems change. The data they process changes. The decisions they influence change. The communities and individuals affected by those decisions change. A risk assessment conducted during implementation planning captures the risks that existed at that moment. Clauses 8.2 and 8.3 exist to ensure that your organisation keeps assessing and treating AI risk throughout the life of the system, not just at the beginning.

This article walks through what Clauses 8.2 and 8.3 actually require, why the operational context makes them different from their planning counterparts, and what auditors look for when they examine evidence of compliance. If you are implementing an AI Management System, managing one, or preparing to audit one, this is the part of the standard that tends to catch organisations off guard.

What Clause 8.2 Requires: AI Risk Assessment in Operation

Clause 8.2 of ISO 42001 requires organisations to perform AI risk assessments at planned intervals and whenever significant changes are proposed or occur. The clause cross-references the criteria and methods established under Clause 6.1.2, which means you are not inventing a new process. You are running the same process again, under operational conditions, with real system data and real operational experience informing your judgement.

Planned Intervals: What That Actually Means

The standard does not prescribe how often you must conduct operational AI risk assessments. It requires that you determine appropriate intervals and then actually stick to them. In practice, most organisations set a minimum annual cycle, but the right frequency depends on several factors.

• How rapidly is the AI system evolving? A system updated with new training data every quarter carries different risk dynamics than a stable, narrowly scoped system that has not changed in two years.
• How consequential are the decisions the system influences? An AI system that helps prioritise maintenance schedules carries lower stakes than one that influences credit decisions, hiring outcomes, or clinical recommendations.
• What does your operational experience so far suggest? If your monitoring data from Clause 9.1 is revealing unexpected outputs or user complaints, that is a signal that your risk picture has shifted and your assessment interval may need to shorten.

The key discipline here is that the interval must be documented, justified, and actually followed. Auditors will ask to see where you determined the frequency, and they will check whether the assessments were actually conducted on schedule. A policy that says annually but a record showing the last assessment was 26 months ago is a finding.

Triggered Assessments: When Change Demands a Review

Beyond planned intervals, Clause 8.2 requires assessment whenever significant changes are proposed or occur. This is where many organisations struggle, because they have not defined what counts as significant. Without that definition, the trigger mechanism does not work reliably.

Significant changes in the context of an AI system might include:

• Retraining the model on a new or expanded dataset
• Extending the system to a new use case or user group
• Deploying the system in a new jurisdiction with different regulatory requirements
• Integrating the system with a new downstream process where its outputs carry greater consequence
• A material change in the external environment, such as new legislation governing AI outputs in your sector

The connection to Clause 6.3, which covers planning of changes to the AI Management System, is deliberate. Your change management process should include a step that asks whether a proposed change triggers a new or revised AI risk assessment. If that step is missing, Clause 8.2 is not being properly implemented.

Retaining Documented Information

Clause 8.2 requires organisations to retain documented information of the results of AI risk assessments. This is not optional and it is not satisfied by a brief email summary. The documented evidence needs to show the scope of the assessment, the risks identified, the criteria applied, the likelihood and consequence ratings, and the conclusions reached. An auditor examining this evidence should be able to reconstruct your reasoning, not just see your conclusions.

For practical guidance on what a well-constructed AI risk assessment looks like, the earlier article on AI Risk Assessment Under ISO 42001: A Clause 6.1.2 Walkthrough covers the methodology in detail. The same rigour applies in operation.

What Clause 8.3 Requires: AI Risk Treatment in Operation

Clause 8.3 mirrors the planning requirement in Clause 6.1.3. Where Clause 6.1.3 required you to select and plan risk treatment options before the system went live, Clause 8.3 requires you to implement the risk treatment plan and retain evidence that you have done so.

The distinction matters. Planning a treatment and implementing it are different activities. An organisation that has a beautifully documented risk treatment plan from its implementation phase but has not reviewed or updated that plan since go-live is not conforming to Clause 8.3. The treatment plan is a living document. It needs to reflect the current risk picture, which in turn reflects the current outputs of your Clause 8.2 assessments.

The Link Between Assessment and Treatment

Clauses 8.2 and 8.3 are designed to work in a cycle. The risk assessment identifies and evaluates risks. The risk treatment plan specifies how those risks will be addressed. Implementation of the treatment plan produces operational controls. Monitoring under Clause 9.1 checks whether those controls are effective. The results of that monitoring feed back into the next risk assessment. This is the PDCA cycle applied to AI risk, running continuously rather than as a project.

When auditors examine Clause 8.3, they are looking for evidence that this cycle is actually turning. They want to see:

• A current risk treatment plan that reflects the risks identified in the most recent Clause 8.2 assessment
• Evidence that the controls specified in the treatment plan have been implemented
• Records showing that treatment effectiveness is being monitored
• Documentation of any treatments that were modified because monitoring showed they were not working as intended

Annex A Controls in Operational Treatment

The risk treatment options available under ISO 42001 include selecting controls from Annex A, implementing controls from other sources, or accepting risks that fall within your defined risk acceptance criteria. In operation, the question is not just which controls you selected but whether those controls are functioning as intended in a live environment.

A control that looked adequate during planning may prove insufficient once the system is processing real data at scale. For example, a human review step designed to catch anomalous AI outputs may have been adequate when the system was handling fifty decisions per day. At five thousand decisions per day, the same human review step may be creating a bottleneck that causes reviewers to rush, reducing the effectiveness of the control. Clause 8.3 compliance requires you to notice this and respond.

For more on how the Annex A controls connect to the risk treatment process, the article on Auditing Operational Controls and Impact Assessments Under Clause 8 provides a useful audit perspective on the same territory.

How Clauses 8.2 and 8.3 Differ From Their Planning Counterparts

It is worth being direct about this, because it is a question that comes up in training regularly. If you have already done a thorough risk assessment under Clause 6.1.2 and built a solid risk treatment plan under Clause 6.1.3, why does the standard require you to repeat the exercise under Clauses 8.2 and 8.3?

The answer is context. Planning-phase risk assessment is necessarily hypothetical to some degree. You are assessing risks based on your design intent, your anticipated use cases, your expected user population, and your modelled data inputs. You are making predictions about how the system will behave and what could go wrong.

Operational risk assessment is empirical. You have actual system behaviour to examine. You have real outputs, real user interactions, real edge cases, and real monitoring data. You know things about your AI system in operation that you could not have known during planning, and some of those things will change your risk picture.

Common examples of how operational experience changes the risk assessment include:

• The system is being used for purposes slightly outside the intended scope, either because users have found it useful in those contexts or because guidance was unclear
• The input data quality is lower than anticipated, leading to outputs that are less reliable than the planning assessment assumed
• A demographic or geographic group is experiencing systematically different outcomes from the system, raising fairness and equity concerns that were not apparent in testing
• A third party that receives outputs from the system is using them in ways that amplify their impact, increasing the consequence rating for certain risks

None of these things can be discovered from a planning-phase assessment alone. Clauses 8.2 and 8.3 are the mechanism by which ISO 42001 ensures that organisations stay honest about the actual risk profile of their AI systems, not just the intended one.

The Role of the AI System Impact Assessment

Clauses 8.2 and 8.3 do not operate in isolation. They connect to the AI system impact assessment process described in Clause 8.4, which addresses broader impacts on individuals, groups, and society. The risk assessment under Clause 8.2 focuses on risks to the organisation and its objectives. The impact assessment under Clause 8.4 focuses on impacts on those outside the organisation who are affected by the system.

In practice, these two processes often draw on the same evidence base and should be conducted in a coordinated way. An operational risk assessment that reveals the system is producing biased outputs is simultaneously a risk to the organisation and a potential harm to affected individuals. Treating these as entirely separate exercises creates gaps. Treating them as complementary exercises that share evidence and inform each other produces a more complete picture.

Organisations that have implemented a mature AI Management System typically run their Clause 8.2 risk assessment and Clause 8.4 impact assessment on the same schedule, with results feeding into a combined review that informs both the risk treatment plan and the impact mitigation measures.

What Auditors Actually Look For

When auditing Clauses 8.2 and 8.3, experienced auditors are looking for evidence of a genuine, functioning process rather than a compliance exercise conducted once and filed away. The questions that tend to reveal the difference include the following.

For Clause 8.2

• Show me your documented AI risk assessment methodology. Is it the same methodology used during planning, or has it diverged?
• When was the most recent operational risk assessment conducted? What triggered it, planned interval or a change event?
• What risks were identified in the most recent assessment that were not present or rated differently in the previous assessment? What changed?
• How do you determine whether a proposed change to the AI system is significant enough to trigger a new assessment?
• Walk me through a specific risk that emerged from operational experience. How did you identify it, and how did it change your treatment approach?

For Clause 8.3

• Show me your current risk treatment plan. When was it last updated, and what prompted the update?
• For each treatment in the plan, what is the evidence that the treatment has been implemented?
• How do you verify that your risk treatments are effective in practice, not just in design?
• Has any treatment been modified or replaced because it proved ineffective in operation? Walk me through that process.
• How does the output of your Clause 9.1 monitoring feed back into your risk treatment decisions?

The auditors who find nonconformities in this area are usually looking at the same failure pattern: the organisation treated Clauses 6.1.2 and 6.1.3 as the real requirements and Clauses 8.2 and 8.3 as administrative confirmation that the planning work was done. That misreading produces a system where the risk assessment is a historical document rather than a live management tool.

Common Nonconformities Against Clauses 8.2 and 8.3

Based on how similar requirements play out in other ISO standards, particularly the parallel requirement in ISO 27001 Clause 8.2 which has been in place since 2013, the most frequent nonconformities against these clauses fall into predictable categories.

• No defined interval for operational risk assessment. The organisation has conducted an assessment but has not documented when the next one is due or what criteria would trigger an earlier review.
• Assessment conducted but not updated after changes. The system has been retrained, extended, or modified, but no risk assessment was triggered because the change management process did not include a risk assessment trigger.
• Treatment plan not updated to reflect current risks. The risk treatment plan references risks identified during implementation planning but does not reflect risks identified in subsequent operational assessments.
• Insufficient documented evidence of treatment implementation. The treatment plan specifies controls but there is no evidence that those controls are actually in place and operating. The plan and the reality have diverged.
• No feedback loop from monitoring to treatment. The organisation is conducting monitoring under Clause 9.1 but the results are not being used to inform risk treatment decisions. The two processes are running in parallel without connecting.

Practical Steps to Get This Right

If you are implementing or reviewing your AI Management System, the following practical steps will help ensure that Clauses 8.2 and 8.3 are genuinely embedded rather than nominally addressed.

1. Document your assessment interval and your justification for it. Do not just write annually. Write why annually is appropriate given the nature of your system, its rate of change, and the consequences of its outputs. If those factors change, revisit the interval.
2. Build the change trigger into your change management process. Every proposed change to the AI system should pass through a question: does this change require a new or revised risk assessment? Document the answer, even when the answer is no.
3. Keep your risk treatment plan as a live document. Version control it. Date every update. Record what changed and why. An auditor should be able to see the history of how your treatment approach has evolved as your operational experience has grown.
4. Create an explicit feedback mechanism from monitoring to treatment. Define how the results of Clause 9.1 monitoring are reviewed against the risk treatment plan. Assign responsibility for that review. Document the outcomes.
5. Retain evidence of treatment implementation, not just treatment planning. For every control in your treatment plan, there should be evidence that the control exists and is operating. That evidence might be a procedure, a configuration record, a training record, a monitoring log, or an inspection record, depending on the nature of the control.

For those who want to understand how the Statement of Applicability connects to the operational risk treatment process, the article on Checking the Statement of Applicability Against the AI Risk Treatment Plan covers that relationship in detail.

Building the Competence to Do This Well

Implementing Clauses 8.2 and 8.3 effectively requires more than procedural compliance. It requires people who understand AI systems well enough to identify meaningful risks in operational conditions, who understand risk assessment methodology well enough to apply it consistently, and who understand the ISO 42001 framework well enough to connect operational findings to management decisions.

That combination of competencies is not common yet, because ISO 42001 is a relatively new standard and the auditing profession is still building its depth of expertise in AI governance. If you are a quality manager, compliance professional, or auditor who wants to develop genuine capability in this area, structured training is the most direct path.

Audit Workshop offers training across ISO 42001 and the broader ISO auditing framework, designed by practitioners who have conducted hundreds of real-world audits across multiple standards and industries. The courses are built for people who need to apply what they learn, not just pass an exam. Whether you are building an AI Management System, preparing to audit one, or expanding your professional scope into AI governance, the training is practical, specific, and grounded in real audit experience. You can explore the available courses at auditworkshop.com.