ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An AI risk treatment plan is the document that turns a list of scored AI risks into decisions, owners and dates. Without it, an ISO 42001 risk assessment is just a register of worries. ISO/IEC 42001:2023 requires the plan under clause 6.1.3, and clause 8.3 requires you to carry it out, keep it current and record what you did.
This guide shows what the plan must contain, how to choose a treatment for each risk, how the plan connects to Annex A and your Statement of Applicability, and what auditors look for when they read it. It is written for the person who has finished the risk assessment and now has to decide what to do about the results.
Free gap assessment
How much of ISO 42001 could you evidence today?
Score every clause and Annex A control of the AI management standard, free, and see where the programme really sits.
Run the free ISO 42001 gap assessment → or View premium report sample
Clause 6.1.3 asks you to select appropriate treatments for the AI risks you identified, work out which controls are necessary, compare those controls with the reference controls in Annex A, and add any that Annex A does not cover. You then document the plan and get management approval for it, including acceptance of any residual risk. Clause 8.3 is the operating half: you implement the plan, review it at planned intervals, update it when new risks appear and keep records of what was done.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 38 AI risk scenarios, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
Annex A of ISO 42001 contains 38 controls. You are not obliged to adopt them all, but you must be able to justify every exclusion. Your AI risk treatment plan is where that logic lives, because each risk points to the controls chosen for it, and the Statement of Applicability then summarizes those choices across the whole system. For the standard itself, see the official listing for ISO/IEC 42001:2023 on iso.org, which gives December 2023 as the publication date.
If you have not completed the assessment step yet, start with our guide to the ISO 42001 risk assessment under clause 6.1.2, because the plan is only as good as the register that feeds it.
The standard requires you to select suitable treatment options but does not force a specific list. Most organizations use the four options familiar from general risk management practice, which keeps the plan readable for auditors and executives alike.
| Option | What it means | AI example | Evidence to keep |
|---|---|---|---|
| Reduce | Add controls to lower likelihood or impact | Human review of every automated loan decline | Procedure, reviewer log, sample of reviewed cases |
| Avoid | Stop the activity that creates the risk | Withdraw a facial-analysis feature from a hiring tool | Decision record, change ticket, removal date |
| Share | Move part of the risk to another party | Contractual warranties and indemnities from a model supplier | Signed contract clauses, supplier assurance report |
| Accept | Knowingly tolerate the remaining risk | Minor drift in an internal summarization tool | Named approver, rationale, review date |
Reduction is the most common choice for AI systems, but it is not always enough. Some risks, such as using a system outside its tested context, are better avoided than mitigated. Sharing risk through a supplier contract is useful but never removes your own accountability for outcomes affecting people, so record the residual exposure even when a contract covers part of it.
A spreadsheet is enough, provided it has the right columns. Auditors will read across a row from risk to control to owner, so each row must tell a complete story.
Two columns are worth adding beyond the minimum. A “verification method” column records how you will prove the control works, such as testing, sampling or monitoring metrics. A “linked impact” column ties the row to your impact assessment so that harm to people is not lost when the register is translated into controls. Our AI risk register guide covers the fields that should exist before you start treating.
Match the control to the cause of the risk, not to a generic list. If the risk is biased output from unrepresentative training data, a policy statement will not fix it. Data quality checks, representative test sets, fairness testing and human review will. If the risk is a supplier model changing without notice, the control lives in contracts, change notifications and regression testing. Write down why each control addresses the cause, since that explanation is what convinces an auditor the choice was deliberate.
After you select controls, compare them against Annex A and record the outcome for every one of the 38 controls in the Statement of Applicability: included or excluded, why, and where it is implemented. Any control you chose that is not in Annex A should also be recorded, so nothing operates outside the documented system.
The clean way to do this is to build the plan first and the Statement of Applicability second. Teams that work in the opposite order often tick controls to look complete and then struggle to show which risk each one addresses. Read our guide to the ISO 42001 Statement of Applicability for the full layout and common exclusions.
Every plan ends with a decision: is the risk that remains acceptable? Define your risk appetite before the exercise, with a threshold such as “residual risks rated high need executive approval”. Then apply it consistently. A plan where every residual risk is accepted at the same level by the same person looks suspicious, while one that shows some risks escalated, some sent back for more controls and some accepted with conditions looks like a working process.
Approval should come from someone with authority over the AI system and its consequences, not only from the security team. Record conditions attached to acceptance, for example “accepted until the next model release” or “accepted provided monitoring alerts remain below the agreed threshold”. Conditional approvals are normal, but they must have an expiry or a trigger.
The plan is not finished when it is signed. Clause 8.3 expects you to carry it out and update it, so build the routine into normal operations. Review open actions monthly or quarterly, update ratings when controls go live, and reopen rows when something changes: a new model version, a new data source, an incident or a supplier change. Keep the evidence trail simple, with links from each row to tickets, test results or monitoring dashboards.
Track overdue actions visibly. A treatment plan with many past-due dates and no explanation is one of the fastest ways to raise an audit finding. If a date must slip, record why, who agreed and the new date.
Building the register, heat maps and treatment plan from scratch takes time, and the layout is the part most teams get wrong. The AI Risk Assessment Report and Workbook gives you a ready structure with a risk register, heat maps, an ISO 42001 treatment plan and a live workbook you can adapt to your own systems. Use it or build your own, but keep one consistent format across every AI system you assess.
Yes. Clause 6.1.3 requires a documented plan with management approval, and clause 8.3 requires you to implement and review it.
No, but you must compare your chosen controls with Annex A and justify any exclusions in the Statement of Applicability. You may also add controls that Annex A does not contain.
You can if your risk criteria allow it and the right level of management approves it, ideally with conditions and a review date. Auditors will look for the reasoning, not just the signature.
Review it at planned intervals and whenever something material changes, such as a new model, new data or an incident. Quarterly is a common starting point.
The register records the risks and their ratings. The AI risk treatment plan records what you will do about each one, who owns it, by when and what risk remains.
September 30, 2026
