An ISO 42001 AI risk assessment is a defined, repeatable process that identifies, analyzes and evaluates AI risks against criteria you set in advance, as required by ISO/IEC 42001:2023 clause 6.1.2 and repeated in operation under clause 8.2. Risk means the “effect of uncertainty” (definition 3.7, official preview). The method produces three records: risk criteria, a risk register and a risk treatment plan that feeds the Statement of Applicability.
An auditor does not grade your scores. The auditor checks that the method is written down, that it gives the same answer when someone else runs it, and that every risk can be traced to a decision, an owner and evidence.
What ISO/IEC 42001 requires at each step of the risk method
ISO/IEC 42001 sets the risk method up in clause 6.1 during planning and requires you to run it again in clause 8 during operation. A method write-up that stops at clause 6 misses the clause 8 repeat, which is where stale registers show up.
- Set criteria (6.1.1). Establish AI risk criteria that separate acceptable from non-acceptable risk, and plan how you will assess and treat risk.
- Assess (6.1.2). Define an assessment process that is informed by your AI policy and AI objectives and gives consistent, valid and comparable results when repeated. It identifies risks, analyzes consequences, likelihood and level of risk, and evaluates the results against your criteria to set priorities.
- Treat (6.1.3). Choose treatment options, determine the controls needed, compare them with Annex A so nothing necessary is missed, produce the Statement of Applicability, write a risk treatment plan and get it approved, with residual risk accepted.
- Assess in operation (8.2). Run the assessment at planned intervals or when significant changes are proposed or occur, and keep the results.
- Treat in operation (8.3). Implement the treatment plan, check that it works, and send new or failing treatments back through 6.1.3.
Sources: clause titles from ISO/IEC 42001:2023 (official preview); requirement wording as reproduced in published clause summaries.
This method sits at the core of planning an ISO 42001 implementation. It comes after you have a scope and a list of AI systems, because you cannot assess risk for systems nobody has recorded. The full requirement text is in the ISO/IEC 42001:2023 standard on iso.org, which is sold, not free.
Risk, control and criteria in ISO 31000 terms
ISO/IEC 42001 draws its risk vocabulary from ISO 31000 and ISO Guide 73, so your method should use the same terms. The official preview defines risk as the effect of uncertainty, notes that the effect can be positive or negative, and says risk is often expressed as a combination of consequences and likelihood. It defines a control, taken from ISO 31000:2018, as a measure that “maintains and/or modifies risk”, and adds that a control may not always have the intended effect.
That last note is why clause 8.3 asks you to verify that treatment works, not only to record it. Three more terms belong in your method document:
- Level of risk: the score from combining likelihood and consequence on your scales.
- Risk criteria: the thresholds that decide which levels you accept and which you treat.
- Residual risk: the level left after treatment, which a named owner accepts.
ISO/IEC 23894:2023, published in February 2023, is ISO’s guidance on managing AI-related risk for organizations that develop, deploy or use AI. It is guidance, so you cannot certify to it, but it is the natural reference when your method needs AI-specific risk sources. Use it to support the method, not to replace the ISO/IEC 42001 requirements. ISO/IEC 42001’s own Annex C (informative) lists potential AI-related organizational objectives and risk sources, which makes a good identification checklist.
Setting AI risk criteria before you score anything
Write your scales and acceptance thresholds before the first workshop. If criteria change after the scores are in, the results are not comparable, and clause 6.1.2 asks for comparable results. The scales below are an example to adapt.
| Score | Likelihood (example) | Consequence (example) |
| 1 | Not expected in the life of the system | Negligible: no effect on people; minor internal rework |
| 2 | Could happen once in several years | Minor: a few people inconvenienced and quickly put right |
| 3 | Could happen about once a year | Moderate: people treated wrongly but recoverable; complaints; contract issue |
| 4 | Could happen several times a year | Major: lasting harm to individuals or a group; regulator interest; material loss |
| 5 | Expected to happen regularly | Severe: serious harm to people or society; enforcement; loss of a major customer |
Source: AI Training Skool example scales. Not values from ISO/IEC 42001, which leaves scales to the organization.
Example acceptance rule: scores of 1 to 6 can be accepted by the risk owner, 8 to 12 need a treatment plan approved by the AIMS owner and residual acceptance by a senior manager, and 15 to 25 need top management approval or the activity stops. Rate consequence on the worst plausible outcome for the organization, individuals or society, whichever is highest, so harm to people cannot be averaged away.
A worked AI risk register for ISO 42001
The register below is an example for a fictional US software company with four AI systems. Scores multiply likelihood by consequence on the scales above, before and after treatment. Annex A references follow the draft-era (FDIS) crosswalk contributed by Microsoft and listed on NIST’s AI Resource Center, which numbers the matching Annex B guidance items (for example B.6.2.4, AI system verification and validation); the A numbers below assume the control carries the same number, so check each against your licensed copy. Other controls are described generically.
| ID | Risk (cause, event, consequence) | Score | Treatment | Control | Residual, accepted by | Owner | Review trigger |
| R-01 | Fine-tuning data of unknown provenance, so the support chatbot reproduces licensed or personal content | 4×4=16 | Modify | Data provenance checks and records for training data | 2×4=8, AIMS owner | Data lead | New training dataset |
| R-02 | Fraud model drifts as spending patterns change, so error rates rise unnoticed | 3×4=12 | Modify | Verification and validation before release (A.6.2.4); drift monitoring | 2×3=6, risk owner | Model owner | Monitoring threshold crossed |
| R-03 | Recruiters accept screening rankings without review, so candidates are rejected with no human check | 4×4=16 | Modify | Human oversight procedure with sample checks of overrides | 2×4=8, HR director | Talent acquisition lead | New role family or volume spike |
| R-04 | Supplier updates the underlying model without notice, so outputs change in production | 3×4=12 | Share and modify | Supplier controls in the contract (A.10.3, suppliers); regression tests | 2×3=6, procurement head | Vendor manager | Supplier release notes |
| R-05 | Prompt injection makes the chatbot reveal internal data | 3×5=15 | Modify | Input filtering and access limits, shared with existing security controls | 2×4=8, CISO | Security lead | New tool or plugin connected |
| R-06 | Chatbot states a refund policy that does not exist, so customers act on wrong information | 4×3=12 | Modify | Answer grounding in approved content; disclaimer; escalation route | 2×3=6, support director | Support lead | Policy content changed |
| R-07 | Staff paste client data into unapproved AI tools | 4×4=16 | Modify | AI policy (A.2.2) with an approved tools list; awareness | 3×3=9, AIMS owner | AIMS owner | New tool category appears |
| R-08 | Fraud model flags one customer group more often (found in the impact assessment) | 3×4=12 | Modify | Impact assessment process (A.5.2); segment error review | 2×3=6, risk committee | Model owner | Impact assessment reassessed |
| R-09 | Data, tooling and compute behind a model are not documented, so results cannot be reproduced | 3×3=9 | Modify | Resource documentation (A.4.2) | 1×3=3, risk owner | Engineering manager | New system enters scope |
| R-10 | Opportunity: AI triage could clear the support backlog faster | 3×3=9 | Pursue | Pilot with success measures tied to an AI objective | Not applicable | Support director | Pilot review date |
Source: AI Training Skool example register. Fictional systems and scores. R-01 to R-04 use the same risk titles as the example risk register in our course.
Keep one more column in the live file: the AI system’s ID from the AI register that scope and risk assessment depend on, so every risk points at a recorded system. A spreadsheet with these columns is enough for most organizations; a tool is optional.
Row R-10 is deliberate. ISO 31000 risk can be positive, and clause 6.1 covers risks and opportunities, so an auditor may ask where you record opportunities.
AI risk to the organization vs impact on people
Clause 6.1.4 of ISO/IEC 42001 requires AI system impact assessment results to be considered in the AI risk assessment, while keeping the two as separate processes (6.1.2 and 6.1.4). An AI risk assessment asks what uncertainty means for the organization and its AI objectives, while an AI system impact assessment asks what the system does to individuals, groups and societies.
In the register above, R-08 came from the impact assessment. The impact record holds the detail about the affected group; the risk register holds the organization’s exposure, treatment and owner, with a cross-reference both ways. The people side has its own process; for its steps and how it differs from a privacy review, see AI impact assessment versus DPIA.
From risk treatment to the Statement of Applicability
Risk treatment turns each scored risk into a decision, a set of controls and an approved plan. Most methods use four options: avoid the activity, modify the risk with controls, share it (with a supplier or insurer) or retain it by informed decision.
For each risk you modify or share, list the controls, then compare that list with Annex A to confirm no necessary control is missing. The Statement of Applicability records every control you need and why each Annex A control is included or excluded. The risk treatment plan records who implements which control and by when. Management approves the plan, and the residual risk owner signs.
The join between the two records is what auditors sample. Every SoA row marked “applied” should cite at least one risk ID, and every treated risk should cite SoA rows. Column design and justification wording are covered in an SoA that links each control to a risk.
When should an AI risk assessment be conducted?
Conduct an AI risk assessment during planning, then at the planned intervals your method sets and whenever a significant change is proposed or occurs (clause 8.2). In life cycle terms, that means before you buy or build, before deployment, and after deployment while the system runs.
Write the significant-change list into the method: a new AI system, a new use or user group, a model or supplier change, a new data source, a new jurisdiction, a serious incident or a monitoring result outside tolerance. The review trigger column in the register applies the same list to each risk.
Using NIST AI RMF Map, Measure and Manage as a complementary lens
The NIST AI Risk Management Framework, version 1.0, released 26 January 2023, is voluntary and pairs well with an ISO/IEC 42001 method. In the AI RMF Core on NIST’s AI Resource Center, Map “establishes the context to frame risks related to an AI system”. Measure analyzes, assesses and monitors AI risk and impacts, and Manage allocates resources to the risks mapped and measured.
| NIST AI RMF subcategory | ISO/IEC 42001 clauses the crosswalk maps it to | Use in your method |
| Map 1.5 | 6.1.1 | Set risk tolerance as criteria |
| Map 5.1 | 6.1.2 | Identify likelihood and magnitude of impacts |
| Measure 1.1 | 6.1.1, 6.1.2 | Choose measurement approaches for the risks you mapped |
| Measure 2.6 | 8.2 | Evaluate safety risks in operation |
| Manage 1.2 and 1.3 | 6.1.1 to 6.1.4 (Manage 1.2 also 9.3.3) | Prioritize and decide treatment |
Source: “NIST AI RMF to ISO/IEC FDIS 42001 AI Management system Crosswalk”, contributed by Microsoft and listed on NIST’s AI Resource Center, which notes that listing does not imply NIST endorsement. It maps to the draft-era FDIS text, not the published standard. The last column is AI Training Skool’s summary.
NIST states that AI RMF 1.0 is being revised under the White House AI Action Plan; no later version had been released when we checked. For a full function-by-clause comparison, see how ISO 42001 maps to the NIST AI RMF.
The questions an auditor asks of an AI risk method
An auditor tests an AI risk method by reading the method, then sampling register rows and tracing each one to evidence. These are typical questions, not a checklist from the standard:
- Where are your AI risk criteria, who approved them and when?
- If a second assessor scored this system, how do you know the result would match?
- How did the AI policy and AI objectives inform which risks you looked for?
- Which in-scope AI systems have no register entry, and why?
- Show me where impact assessment results entered the risk assessment.
- For this risk, which SoA rows apply, and where is the implementation evidence?
- Who accepted this residual risk, and was that within their authority?
- Which assessments have run in operation since the last audit, and what triggered them?
- Which treatment failed, and how did you handle it?
If you come from ISO/IEC 27001 work, most of this method will feel familiar; the new parts are harm to people and society, and the link to the impact assessment. That overlap is the usual starting point for moving into AI governance from GRC, privacy or audit. To practice the full chain on a case study, self-paced ISO/IEC 42001 Lead Implementer training with the exam included works through a risk register and Statement of Applicability end to end.
Frequently Asked Questions
What is an ISO 42001 risk assessment?
An ISO 42001 risk assessment is the process required by ISO/IEC 42001:2023 clause 6.1.2 for identifying, analyzing and evaluating AI risks against criteria set in advance. It must produce consistent, valid and comparable results, be repeated in operation under clause 8.2, and feed risk treatment and the Statement of Applicability under clause 6.1.3.
What is the difference between an AI risk assessment and an AI impact assessment?
An AI risk assessment under ISO/IEC 42001 clause 6.1.2 looks at the effect of uncertainty on the organization and its AI objectives. An AI system impact assessment under clause 6.1.4 looks at consequences for individuals, groups and societies. The standard keeps them separate but requires impact assessment results to be considered in the risk assessment.
Can I reuse my ISO 27001 risk assessment method for ISO 42001?
Partly. The pattern of criteria, assessment, treatment and a Statement of Applicability carries over, because ISO/IEC 42001 uses the harmonized structure common to ISO management system standards. An ISO/IEC 42001 method must add AI risk sources, consequences for individuals and societies, the link to the AI system impact assessment, and treatment checked against the ISO/IEC 42001 Annex A controls.
Is ISO/IEC 23894 required for ISO 42001 certification?
No. ISO/IEC 23894:2023, published in February 2023, is guidance on AI risk management, not a requirement. An auditor checks your method against ISO/IEC 42001:2023 clauses 6.1 and 8.2 to 8.3. Many organizations still use ISO/IEC 23894 to pick AI risk sources and shape their method because it is written for AI.
What is an AI risk assessment matrix?
An AI risk assessment matrix is the grid that combines a likelihood scale with a consequence scale, often five by five, to give a level of risk. ISO/IEC 42001 does not prescribe the matrix; it requires criteria set in advance and results that are consistent and comparable. Write the scales and acceptance thresholds into your method before scoring.
How often should an AI risk register be reviewed?
ISO/IEC 42001:2023 clause 8.2 requires AI risk assessments at planned intervals and when significant changes are proposed or occur. The standard sets no fixed frequency, so your method states one, often quarterly or annually, and lists the changes that trigger an earlier review, such as a model update or a new use.
