AI Risk Assessment and Treatment Methodology - Template
An editable AI risk methodology and risk register structure. Replace the bracketed placeholders with your own details.
This document sets out how [Organization] identifies, analyzes, evaluates and treats the risks arising from the AI systems it develops, provides or uses. It exists so that two people assessing the same AI system reach a comparable answer, and so that the reasoning behind every treatment decision can still be shown a year later, after the model, the data or the people have changed.
1. Purpose
This methodology defines the repeatable process [Organization] uses to assess and treat AI risk, in support of ISO/IEC 42001:2023 clauses 6.1.2 AI risk assessment and 6.1.3 AI risk treatment. It is the method; the decisions it produces are recorded in the AI Risk Register, and the controls it selects are recorded in the AI Statement of Applicability.
It assesses risk to [Organization] and to the objectives it has set for its AI systems. The consequences of an AI system for individuals, groups of individuals and society are assessed separately, in the AI System Impact Assessment, and its results are used as an input to this assessment.
2. Scope
This methodology applies to every AI system [Organization] develops, provides or uses within the scope of its AI management system, including AI features built into third-party software and AI services reached through a supplier's platform or API.
It covers each AI system across its life cycle, from design or procurement through deployment, operation and change to retirement. It applies to scheduled assessments and to assessments triggered by change. The AI systems in scope are listed in [the AI system inventory].
3. Roles and responsibilities
This methodology is owned by [role, for example the AI Governance Lead], who runs the assessment process and maintains the AI Risk Register.
Each AI system has an AI risk owner: [the individual accountable for the system or the business process it supports]. The AI risk owner supplies the facts about the system, its data and its intended use, agrees the treatment and makes sure it is carried out by its due date.
[Approver role] approves this methodology and its risk acceptance criteria, approves risk treatment plans, and formally accepts any residual risk that remains above the acceptance criteria. Approval sits with a role senior enough to accept the consequence, and never with the person who performed the assessment.
4. Risk criteria: the likelihood scale
Every AI risk is rated on the same five-point likelihood scale. Rate the likelihood over [the next 12 months], for the system as it is actually deployed and used today, given the controls actually in place rather than the controls intended.
| Level | Rating | What it means |
|---|---|---|
| 1 | Rare | Almost never happens. No realistic path to it with the system as deployed and the controls in place. |
| 2 | Unlikely | Could happen but is not expected. Not seen in this system's testing, monitoring or use. |
| 3 | Possible | May happen. Seen in testing, reported for similar systems or models, or the conditions for it exist. |
| 4 | Likely | Probably will happen during the period if nothing changes, because the conditions for it occur in normal use. |
| 5 | Almost certain | Expected to happen in normal use, or already happening. |
5. Risk criteria: the consequence scale
Consequence is rated on the same five-point scale, as the effect on [Organization] and its objectives, including the legal, contractual and reputational effect of harm to the people an AI system affects. Rate the most likely serious outcome, not the worst imaginable one. Where a risk has several kinds of consequence, use the highest.
| Level | Rating | What it means |
|---|---|---|
| 1 | Negligible | Minor inconvenience, corrected quickly. No faulty output reaches a customer or a decision, and nothing is reportable. |
| 2 | Minor | A faulty or unsuitable output reaches a small number of people or decisions and is corrected with limited effort. Short-lived disruption to one team. |
| 3 | Moderate | Noticeable harm and some cost to correct. A group of customers or staff is affected, decisions have to be revisited, or a formal complaint is raised. |
| 4 | Major | Significant damage and substantial cost. A privacy breach, unfair or unsafe outcomes affecting many people, a contractual failure, or the AI system has to be withdrawn. |
| 5 | Critical | Severe damage. Regulatory action, widespread harm to individuals or groups, serious loss of trust, or [Organization]'s ability to operate is at risk. |
5.1 Working out the risk level
Multiply likelihood by consequence, both rated 1 to 5, and read the band off the matrix below. The same matrix is used for the inherent risk, before treatment, and again for the residual risk after the chosen treatment is in place.
| Likelihood \ Consequence | Negligible (1) | Minor (2) | Moderate (3) | Major (4) | Critical (5) |
|---|---|---|---|---|---|
| Almost certain (5) | Medium (5) | High (10) | High (15) | Critical (20) | Critical (25) |
| Likely (4) | Low (4) | Medium (8) | High (12) | High (16) | Critical (20) |
| Possible (3) | Low (3) | Medium (6) | Medium (9) | High (12) | High (15) |
| Unlikely (2) | Low (2) | Low (4) | Medium (6) | Medium (8) | High (10) |
| Rare (1) | Low (1) | Low (2) | Low (3) | Low (4) | Medium (5) |
5.2 Risk acceptance criteria
The band decides what has to happen next. These criteria are approved by [approver role] and are not changed without that approval.
| Band | Score | What must happen |
|---|---|---|
| Low | 1 to 4 | Accepted as it stands by the AI risk owner. Record it; no treatment is required. |
| Medium | 5 to 9 | Monitored, and treated where a control is proportionate. Record the decision either way. |
| High | 10 to 16 | Must be treated. A new AI system, or a change to an existing one, is not deployed until the treatment plan is approved. |
| Critical | 17 to 25 | Must be treated, and reported to [approver role] without delay. The AI system is not deployed, or its use is suspended, until the risk is reduced below Critical or [approver role] accepts it in writing. |
6. AI-specific risk sources
Alongside the sources of risk any system carries, every AI system is considered against the sources below. Record which ones apply to each system and why; a source that does not apply is noted as such, with the reason.
| Risk source | What to ask about the AI system |
|---|---|
| Data quality and bias | Is the data used to train, tune or prompt it accurate, current and representative of the people and cases it will meet? Could it produce systematically worse results for some groups? |
| Lack of transparency or explainability | Can we explain how it reached an output, to the degree its use requires? Do the people affected know AI is involved? |
| Model drift and performance degradation | Will accuracy fall as real-world data moves away from the data it was built on? Would we notice, and how quickly? |
| Misuse or use outside the intended purpose | Could it be used for a purpose it was not designed or assessed for, deliberately or by accident? |
| Security threats | Could it be manipulated through its inputs, for example by prompt injection, or through its training data, for example by data poisoning? Could it disclose information it holds? |
| Third-party model or supplier dependency | What happens if the provider changes the model, its terms or its availability without notice? What do we actually know about how it was built and tested? |
| Privacy | Does it process personal information, including in prompts, logs or training data? Could it reveal or infer personal information it should not? |
| Over-reliance on output | Will people accept its outputs without the review the decision needs? Is human oversight real, or a step that gets skipped? |
| Change in the operating environment | Have the users, the volume, the connected systems or the legal and contractual obligations around it changed since it was last assessed? |
7. Risk identification for each AI system
Risks are identified for each AI system in scope, for its intended purpose and at its current life cycle stage. The same model used for two purposes is two assessments. Each risk is written as a cause, an event and an effect, so that it can be assessed and treated rather than merely named.
"Bias" is not a risk. "Historical data used to train [AI system] under-represents [customer group], so it gives that group less accurate [recommendations], leading to complaints and a breach of [contract or obligation]" is.
- The AI system inventory, with each system's intended purpose and the people it affects
- The results of the AI System Impact Assessment for that system
- Model, data and testing documentation, including what suppliers provide
- Testing, evaluation and monitoring results
- AI incidents, complaints, near misses and audit findings since the last assessment
- Changes to the system, its data, its supplier or the way it is used
- Legal, regulatory and contractual obligations that apply to the system
8. Risk analysis
Each identified risk is assigned an AI risk owner, then rated for likelihood and consequence using the scales above, first as the inherent risk before any new treatment is applied.
The rating, the reasoning and the evidence behind it are all recorded, for example the test result that supports a likelihood. Where no evidence exists, the reasoning says so. A score with no reasoning cannot be reviewed, and cannot be defended once the person who gave it has moved on.
9. Risk evaluation
Risks are compared against the acceptance criteria in section 5.2 and placed in priority order by score. Where two risks score the same, the one with the higher consequence is treated first.
The output of this step is a list of risks that require treatment and a list of risks accepted as they stand, each with the reason recorded.
10. Risk treatment options
For each risk requiring treatment, the AI risk owner and [role] select one or more of the options below and record why. The option chosen is recorded in the AI Risk Register against the risk.
- Modify: apply controls that reduce the likelihood, the consequence, or both, for example human review of outputs, further testing, data quality checks or input filtering
- Avoid: do not deploy the AI system, withdraw it, or narrow its intended use so that the risk no longer arises
- Share: transfer part of the consequence, through insurance or contract terms with a model provider or supplier, noting that [Organization] remains accountable for how it uses the system
- Retain: accept the risk as it stands, within the acceptance criteria, with the acceptance recorded and approved
11. Determining controls and the AI Statement of Applicability
Controls are chosen because they treat an identified AI risk, not because they appear on a list, and they may come from any source. Once the necessary controls are determined, they are compared against the controls in Annex A of ISO/IEC 42001:2023 to confirm that nothing necessary has been left out.
That comparison produces the AI Statement of Applicability: each Annex A control, whether it is included, the justification for including or excluding it, and whether an included control is implemented. An exclusion states the fact about [Organization]'s AI systems that makes the control unnecessary; "not applicable" on its own is not a justification.
The controls chosen for each risk, with their due dates and owners, form the AI risk treatment plan, which [approver role] approves.
12. Residual risk and approval
After the chosen treatment is in place, the risk is rated again using the same scales and matrix. That residual rating is recorded alongside the inherent one, so the effect of the treatment is visible.
The AI risk owner confirms the treatment has been carried out, and [approver role] accepts the residual risk where it remains above the acceptance criteria. The AI Risk Register records who approved what, and when.
13. The AI Risk Register
Every AI risk, treated or accepted, is recorded in the AI Risk Register, one row per risk carrying its whole life cycle. Each row has the columns below.
| Column | What it records |
|---|---|
| Risk ID | A unique reference, for example [AIR-001] |
| AI system | The system from the AI system inventory, its intended purpose and its life cycle stage |
| Risk source | The source or sources from section 6 that give rise to the risk |
| Risk description | Cause, event and effect, in one or two sentences |
| AI risk owner | The role accountable for the risk |
| Impact assessment reference | The AI System Impact Assessment the risk draws on, where there is one |
| Existing controls | The controls already in place when the risk was rated |
| Inherent rating | Likelihood, consequence, score and band, with the reasoning and evidence |
| Treatment option | Modify, avoid, share or retain, and why |
| Controls and SoA reference | The controls chosen, with their AI Statement of Applicability entry |
| Treatment owner and due date | Who carries out the treatment, and by when |
| Residual rating | Likelihood, consequence, score and band after treatment |
| Approval | Who approved the treatment plan and accepted the residual risk, and the date |
| Status and next review | Open, in treatment, accepted or closed, and the date the risk is next reviewed |
14. When the assessment is repeated
[Organization] performs a full AI risk assessment at least [annually], in line with clause 8.2 AI risk assessment, and implements the resulting treatment plans under clause 8.3 AI risk treatment. An AI system is reassessed before a change to its model, its data or its intended use goes live, and whenever monitoring shows its performance outside [agreed threshold]. Between full assessments, individual risks are also reassessed whenever one of the triggers below occurs, and the register is updated rather than left until the next cycle.
- A new AI system, or a new intended use for an existing one
- A change to a model, including retraining, fine-tuning or a new version from a supplier
- A significant change to the data a system is trained on, tuned with or given
- Monitoring that shows drift or performance below [agreed threshold]
- An AI incident, complaint or near miss
- A change of model provider or supplier, or to their terms
- A new or changed legal, regulatory or contractual obligation
- An audit finding, internal or external, or a change to the scope of the AI management system
15. Records and review
Records produced by this methodology - the AI Risk Register, the AI Statement of Applicability, treatment plans and approvals, and residual risk acceptances - are retained for [period] and are available to internal and external auditors.
This methodology is reviewed [annually] and whenever the scales, the acceptance criteria or the scope change. Changes to the criteria are approved by [approver role] before they are used, and the reason for the change is recorded. Owned by [role]. Approved by [name], [title], on [date]. Version [x.x]. Next review [date].
This template is a starting point, not legal or audit advice. Replace every bracketed placeholder, delete what does not apply, and have it approved before you rely on it. If you change the scales or bands, check that every matrix cell still agrees with them. ISO/IEC 23894 gives further guidance on AI risk management. A methodology on its own is not an AI management system: ISO 42001 also expects the AI policy, the AI System Impact Assessment, the AI Statement of Applicability and the records that show the system operating.
