AI Risk Treatment and Annex A: How Clause 6.1.3 of ISO 42001 Works

Why Risk Treatment Is the Real Work in ISO 42001

Most organisations spend considerable energy on risk assessment under ISO 42001. They identify AI risks, score likelihood and consequence, and produce a documented register. Then they hit Clause 6.1.3 and realise the harder question is still ahead: what are you actually going to do about those risks?

Clause 6.1.3 is where ISO 42001 moves from analysis to action. It requires the organisation to select appropriate risk treatment options, determine the controls necessary to implement those options, and then compare those controls against the reference control objectives and controls in Annex A of the standard. The clause also requires the organisation to produce a risk treatment plan and to prepare a Statement of Applicability.

If you have worked with ISO 27001, this structure will feel familiar. The mechanics are similar. But the subject matter, AI systems and their associated risks to people, society, and fairness, introduces considerations that go well beyond typical information security thinking. Understanding how Clause 6.1.3 works in practice is essential for anyone implementing an AI Management System (AIMS), conducting internal audits, or preparing for certification.

This article walks through the clause requirements in detail, explains how Annex A fits in, and gives you the practical guidance you need to make the risk treatment process credible rather than cosmetic.

What Clause 6.1.3 Actually Requires

The clause sits within the Planning section of ISO 42001 and follows directly from the risk assessment requirements in Clause 6.1.2. Once the organisation has assessed its AI risks, Clause 6.1.3 requires it to do four things.

Select Risk Treatment Options

The standard identifies the same four treatment options that appear across the ISO risk management family: modify the risk, retain it, avoid it, or share it. In an AI context, these translate into decisions like adjusting how a model is trained or deployed, accepting a residual risk that is within tolerance, discontinuing a particular AI application, or transferring risk through contractual arrangements with a third party provider.

The selection of treatment options needs to be deliberate and documented. It is not enough to say that risks have been treated. The organisation needs to show the reasoning behind the choice of treatment for each significant risk, particularly where the decision is to retain rather than reduce.

Determine Controls

Once treatment options are selected, the organisation must determine what controls are needed to implement those treatments. This is where Annex A enters the picture. The standard requires the organisation to compare the controls it has determined against the reference controls in Annex A to verify that no necessary controls have been omitted.

This comparison is not a box ticking exercise. The intent is to ensure the organisation has thought broadly about what controls are relevant to its AI systems, rather than only identifying controls that were already on its radar. Annex A acts as a prompt and a completeness check.

Produce a Risk Treatment Plan

The risk treatment plan documents what will be done, who is responsible, and when. It should be specific enough that someone could pick it up and understand what action is required, who owns it, and how progress will be measured. Vague statements like

improve AI governance

implement a human review step before any automated credit decision affects a customer

Prepare the Statement of Applicability

The Statement of Applicability (SoA) is one of the most scrutinised documents in any AIMS certification audit. It must list all the controls from Annex A, indicate which are applicable, provide justification for inclusions and exclusions, and confirm whether applicable controls have been implemented.

The SoA is the document that ties together your risk assessment, your treatment decisions, and your Annex A controls. Getting it right matters. We have a dedicated article on the Statement of Applicability in ISO 42001 that covers the document in full detail.

Understanding Annex A of ISO 42001

Annex A of ISO 42001 contains the reference control objectives and controls that organisations use to treat AI risks. Unlike ISO 27001 where Annex A contains 93 controls across four themes, the ISO 42001 Annex A is structured around ten sections that reflect the specific governance and operational challenges of AI systems.

The ten sections cover: policies related to AI, internal organisation, resources for AI systems, assessing impacts of AI systems, the AI system life cycle, data for AI systems, information for interested parties, responsible use, third party and customer relationships, and general controls.

How the Annex A Sections Relate to Risk Treatment

Each section of Annex A addresses a distinct dimension of AI risk. When an organisation is selecting controls during risk treatment, it needs to consider which of these dimensions are relevant to the risks it has identified.

For example, if the risk assessment identifies that an AI system used in recruitment may produce biased outcomes, the relevant Annex A controls would likely include those in A.5 (assessing impacts), A.6 (AI system life cycle controls, particularly around testing and validation), A.7 (data quality and representativeness), and A.9 (responsible use). The risk treatment plan would then describe the specific controls being implemented from each applicable section, and the SoA would reflect those choices.

If the organisation has determined that a particular Annex A section is not applicable, for example because it does not provide AI systems to external customers and therefore considers A.8 (information for interested parties) partially irrelevant, it must document the justification. Auditors will challenge weak exclusions, particularly where the risk profile of the AI systems in scope suggests that interested parties could be affected.

Annex A Is Not Exhaustive

One important point that practitioners sometimes miss: Annex A is a reference set, not a ceiling. The standard explicitly acknowledges that organisations may need to implement additional controls beyond those listed in Annex A to address their specific AI risks. If your risk assessment identifies a risk for which no Annex A control directly applies, you are expected to determine appropriate controls from other sources and document them in the SoA alongside the Annex A controls.

This is particularly relevant for organisations operating in regulated sectors where AI use is subject to specific legal or regulatory requirements. An AI system used in financial services credit decisions, for instance, may require controls that go beyond what Annex A specifies, reflecting obligations under Australian consumer credit legislation.

The Risk Treatment Plan in Practice

A well constructed risk treatment plan under Clause 6.1.3 should be traceable from the risk register through to specific control implementation. Here is what that looks like in practice.

Connecting Risks to Controls

Each risk in the register should have a clear link to the treatment option selected and the controls being applied. A common weakness seen in audits is a risk treatment plan that lists controls without connecting them to specific risks. The auditor cannot then verify that the treatment is proportionate to the risk, or that the controls selected actually address the identified risk scenario.

For example, if the risk is that an AI system generates outputs that discriminate against protected groups, the treatment plan should identify the specific controls addressing that risk, such as bias testing at defined intervals, human oversight of high consequence decisions, and documentation of training data provenance. Each of these should trace back to Annex A controls or to additional controls the organisation has determined are necessary.

Ownership and Timelines

The risk treatment plan must assign ownership. In AI governance, ownership questions can become complicated because AI systems often involve multiple parties: the team that developed the model, the business unit that deployed it, the IT function that maintains the infrastructure, and potentially an external provider. Clause 5.3 of ISO 42001 requires the organisation to assign roles and responsibilities for AI governance, and those assignments should be reflected in the risk treatment plan.

Timelines must be realistic. Plans that list every control as due in the first month of implementation are not credible. Prioritise based on risk level. High consequence, high likelihood risks should have short implementation timelines and early review dates. Lower priority controls can be phased.

Residual Risk Acceptance

After controls are applied, residual risk remains. Clause 6.1.3 requires that residual risks be accepted by the appropriate authority within the organisation. This is typically documented through a formal sign off by the AI governance function or top management, depending on the level of residual risk.

Auditors will look for evidence that residual risk acceptance was a conscious decision by someone with appropriate authority, not a default outcome because no one got around to reviewing it. If you have conducted a thorough AI risk assessment under Clause 6.1.2, the residual risk picture should be clear and the acceptance decision should be straightforward to document.

Common Weaknesses Auditors Find in Clause 6.1.3

Having reviewed AIMS implementations across various organisations, several recurring weaknesses appear in how Clause 6.1.3 is implemented. Being aware of these will help you avoid them.

The SoA Is Not Connected to the Risk Register

This is the most common finding. The organisation has produced a Statement of Applicability that lists Annex A controls and marks them as applicable or not, but there is no visible connection between the SoA and the risk register. When asked why a particular control is included, the response is something like

we thought it was relevant

The SoA should be a living document that reflects your risk treatment decisions. Every applicable control should be traceable to either a risk in the register or a legal or regulatory obligation. Every excluded control should have a documented justification that explains why the risk scenarios that control addresses do not apply to the organisation.

Exclusions Are Not Justified

Some organisations exclude large sections of Annex A without adequate justification. A common example is excluding A.5 (impact assessment controls) on the basis that the organisation only uses AI internally. This justification is rarely adequate. AI systems that affect internal decisions, such as performance management tools or resource allocation systems, can still have significant impacts on workers. The exclusion needs to be grounded in a genuine assessment of whether the control objective applies, not in a desire to reduce implementation scope.

Controls Are Not Implemented

The SoA may list a control as applicable and implemented, but when auditors go looking for evidence of implementation, it is absent. This is a straightforward nonconformity. The SoA is a statement of fact, not aspiration. If a control is marked as implemented, there must be evidence of implementation: documented procedures, records of activity, outputs from the control process.

The Risk Treatment Plan Is Not Maintained

AI systems change. Models are retrained, deployment contexts shift, new use cases emerge. A risk treatment plan that was accurate at the time of initial certification may become outdated quickly. Clause 6.1.3 does not explicitly require review at defined intervals, but the broader planning requirements of the standard, combined with the operational requirements in Clause 8, make clear that the treatment plan must remain current. Auditors will look for evidence that the plan has been reviewed when significant changes to AI systems have occurred.

How Auditors Approach Clause 6.1.3

When auditing Clause 6.1.3, the approach is to trace the thread from risk to treatment to control to evidence. This is not a document review exercise alone. It involves interviews, sampling of control evidence, and comparison of the SoA against the risk register.

Document Review

Start with the risk register, the risk treatment plan, and the SoA. Check that they are consistent with each other. Look for risks in the register that do not have a corresponding treatment entry. Look for controls in the SoA that are marked as applicable but cannot be traced to a risk or obligation. Check that exclusion justifications are substantive.

Sampling Control Evidence

Select a sample of controls from the SoA that are marked as implemented and look for evidence. For a control requiring human oversight of high consequence AI decisions, look for records of that oversight: review logs, escalation records, documented decision rationales. For a control requiring bias testing, look for test results, the methodology used, and evidence that findings were acted upon.

The approach here is similar to sampling Annex A controls in an ISMS audit. The principle is the same: you cannot verify every control in the time available, so you sample strategically, focusing on controls that address the highest consequence risks.

Interviews

Ask the people responsible for AI governance how they selected the controls in the treatment plan. Ask them to explain a specific risk and walk you through the treatment decision. Ask who approved the residual risk. Ask when the treatment plan was last reviewed and what triggered that review.

These questions quickly reveal whether the risk treatment process is genuinely embedded or whether it was completed once for certification purposes and has not been touched since.

Integrating Clause 6.1.3 with the Broader AIMS

Clause 6.1.3 does not operate in isolation. The risk treatment decisions made here feed directly into the operational requirements of Clause 8, particularly the operational planning and control requirements in Clause 8.1 and the AI impact assessment requirements in Clause 8.4. The controls selected during risk treatment become the operational controls that the organisation implements and monitors.

The risk treatment plan also feeds into the objectives set under Clause 6.2. If a risk treatment action involves reducing the rate of biased outputs from an AI system, that reduction target should appear as a measurable AI objective. The connection between risk treatment and objective setting is often weak in early AIMS implementations, and auditors will look for it.

Understanding how these clauses connect is important for anyone building or auditing an AIMS. If you are working towards a deeper understanding of how ISO 42001 fits together as a system, the training courses at Audit Workshop cover the standard clause by clause with practical examples drawn from real AI governance contexts. Courses are available for internal auditors and lead auditors, delivered both live and self paced, so you can build your knowledge in a way that fits your schedule.