TL;DR
This guide explains how to conduct AI risk assessment under ISO 42001. Every ISO 42001 risk assessment blends a planning clause with a doing clause. Clause 6.1.2 has you decide the assessment must exist. Clause 8.2 has you run it.
- ISO 31000 supplies the process: establish context, identify, analyze, evaluate, treat, monitor. ISO/IEC 23894 supplies the AI-specific content that fills each step.
- Six steps turn that process into a working assessment. You end with a documented risk register and a treatment plan mapped to Annex A.
- This is a separate exercise from the AI system impact assessment. Clauses 6.1.4 and 8.4 cover that. It looks at harm to outside people, not risk to your firm.
- Keep records: the methodology, the risk register, the treatment plans, and the management review that approved them.
- Reassess on a schedule and whenever something material changes, not just once at launch.
Sources: ISO/IEC 42001:2023 · ISO/IEC 23894:2023 · AI Incident Database, via Cybernews
What ISO 42001 requires #
ISO 42001 splits the risk assessment duty across two clauses. Mixing them up is the most common gap auditors find.
Clause 6.1.2 works at the planning level. It has you determine which AI risks matter to your management system. You plan actions to address them and fold those actions into your normal AIMS work. This clause does not demand a formal risk register on its own. It demands that you have thought through your AI risks and planned a response.
Clause 8.2 turns that plan into a documented process. Define a repeatable methodology with risk acceptance criteria. Identify risks across the AI system’s lifecycle. Analyze their likelihood and consequence. Evaluate them against your criteria. Keep evidence of the results. Repeat the exercise on a schedule, or sooner if something changes. The output of Clause 8.2 is the proof that Clause 6.1.2 happened.
A separate requirement introduces the AI system impact assessment. Clause 6.1.4 plans it. Clause 8.4 runs it. That assessment looks outward, at harm to the people your system affects. It does not look inward at risk to your firm. Auditors flag a merged document as a finding. Our guide to the AI risk assessment against the AI system impact assessment covers that process in full.
The process ISO 31000 gives you #
ISO 42001 does not invent its own risk method. It points to ISO 31000, the general risk standard, for the process. Then it layers AI-specific content on top through ISO/IEC 23894.
| ISO 31000 activity | Satisfies ISO 42001 |
|---|---|
| Establish context | Clause 8.2(a): scope, criteria, and methodology |
| Identify risks | Clause 8.2(b), using the ISO 23894 risk sources below |
| Analyze risks | Clause 8.2(c): likelihood and consequence |
| Evaluate risks | Clause 8.2(d): prioritize against your criteria |
| Treat risks | Feeds Clause 8.3: select and apply Annex A controls |
A monitoring loop wraps around all five activities. So does ongoing communication with the people the assessment affects. Neither one sits at the end and waits its turn.
What ISO/IEC 23894 adds for AI #
ISO 31000 was not written with AI in mind. ISO/IEC 23894 fills that gap. It names risk sources specific to how AI systems fail.
| Risk source | What to look for |
|---|---|
| Data and training | Biased or unrepresentative training data, poisoning, label errors |
| Model performance | Drift, distributional shift, weak accuracy on edge cases |
| Bias and fairness | Disparate outcomes by protected characteristic, feedback loops |
| Transparency | A decision you cannot explain to the person it affects |
| Safety and security | Adversarial inputs, prompt injection, model inversion |
| Human-AI interaction | Automation bias, over-reliance, miscalibrated trust |
| Third-party and supply chain | Unvetted pretrained models, opaque vendor APIs |
Check each source across the system’s full lifecycle. Cover design through retirement, not just first deployment. A risk that looks fine at launch can stop looking fine once the training data ages or the user population shifts.
A six-step method for your own assessment #
This method combines Clauses 6.1.2 and 8.2 with the ISO 31000 process and ISO 23894’s AI content.
- Establish context and profile the system. Document what the system does, who it affects, how autonomous it is, where its data comes from, and which rules apply to it. This profile feeds every risk you identify next.
- Set your risk criteria first. Define acceptance thresholds before you identify a single risk. That order stops criteria from getting reverse-engineered to fit a conclusion you already reached. Add dimensions beyond likelihood and severity: reversibility, how many people it affects, whether the population is vulnerable, and how explainable the decision is.
- Identify risks. Interview developers and end users. Review bias testing results by protected characteristic. Trace your data’s lineage. Run adversarial tests for security risks. Check the AI Incident Database for comparable systems.
- Analyze and evaluate. Score each risk three ways: inherent with no controls, current with existing controls, and target after planned treatment. Any risk that would break the law needs mandatory treatment, no matter how it scores. An EU AI Act prohibited practice is one example.
- Treat the risk and pick controls. Choose to avoid, reduce, share, or accept each risk. Then select the Annex A controls that do the work. All 38 controls across the standard’s 9 themes sit on your treatment menu. Every choice needs a written reason either way.
- Monitor and reassess. Set three kinds of trigger. Time-based means an annual full review. Change-based means retraining or a new market. Event-based means an incident or new guidance. Document a triggered reassessment the same way you document a scheduled one.
What to keep as evidence #
Clause 8.2 requires documented proof that the assessment happened. This is also the first thing an auditor, or a regulator for a high-risk system, will ask for.
| Record | Purpose |
|---|---|
| Risk assessment methodology | The process, criteria, and scoring approach you used |
| AI system inventory | Every in-scope system with its profile |
| AI risk register | Every identified risk with its analysis and evaluation |
| Risk treatment plans | Selected controls, owners, and timelines |
| Risk acceptance records | Written reasons for any risk you accepted instead of treated |
| Management review records | Proof that top management reviewed and approved the results |
Keep most of these records for three years at minimum. Keep them longer where a regulator requires it, or the system carries high risk.
Who is responsible for running it #
ISO/IEC 22989 names five organizational roles for AI governance: producer, provider, customer, partner, and subject. Skip the “provider, operator, user” shorthand you will see on many compliance blogs. It is not what the standard says. Most firms hold more than one role at once, and each role carries different assessment duties. Our guide to your organization’s role under ISO/IEC 42001 covers which role owns which part of the work.
Where this meets the EU AI Act #
ISO 42001 is not a harmonized standard under the EU AI Act. Certification alone does not clear your legal duties. It still builds most of the documentation a high-risk deployer needs. Think a risk register, a treatment plan, and monitoring records that map to the Act’s own requirements.
The Act’s penalties run in three tiers, and people misquote them often. The top tier, up to €35 million or 7% of global turnover, covers breaches of the Article 5 prohibited practices. It does not cover ordinary high-risk non-compliance. Violating a high-risk system’s provider or deployer duties caps at €15 million or 3% of turnover. Giving a regulator misleading information caps at €7.5 million or 1%.
The Act’s own high-risk deadline moved too. A Digital Omnibus agreement pushed the deadline for standalone high-risk systems from August 2026 to December 2, 2027. High-risk systems built into already regulated products now have until August 2, 2028. Regulation (EU) 2026/1744 made both dates binding when it took effect on July 27, 2026.
Frequently asked questions #
What is the difference between Clause 6.1.2 and Clause 8.2?
Clause 6.1.2 is the planning clause. It has you determine your AI risks and plan actions to address them. Clause 8.2 is the operational clause. It has you run a documented, repeatable risk assessment process and keep evidence of the results. In PDCA terms, 6.1.2 is Plan and 8.2 is Do.
How does ISO 31000 relate to ISO 42001’s risk assessment?
ISO 42001 adopts ISO 31000’s process: establish context, identify, analyze, evaluate, treat, and monitor. ISO 31000 was not written for AI. ISO 42001 pairs it with ISO/IEC 23894 for the AI-specific risk sources and lifecycle content that fill each step.
Is the AI risk assessment the same as the AI system impact assessment?
No. The risk assessment under Clause 8.2 looks at risk to your organization. The impact assessment under Clauses 6.1.4 and 8.4 looks at harm to people the system affects, outside your organization. Auditors expect two separate documents, not one merged file.
How often do you repeat the assessment?
Clause 8.2 sets planned intervals you define yourself, plus a repeat whenever a significant change occurs. Many firms run an annual full assessment, with monitoring every quarter for high-risk systems. Add a triggered reassessment after retraining, a new user population, or an incident.
Which Annex A controls apply to risk treatment?
Any of the 38 controls across the 9 Annex A themes can serve as a treatment, depending on what the risk needs. Data risks draw on A.7, lifecycle risks on A.6, and third-party risks on A.10. The Statement of Applicability still needs a written reason for every control you include or exclude.
What does the EU AI Act charge for high-risk non-compliance?
Up to €15 million or 3% of global turnover, whichever is higher, for violating a high-risk system’s provider or deployer duties. The higher €35 million or 7% tier covers the Article 5 prohibited practices only, a narrower and more severe category.
Key takeaways #
- Clause 6.1.2 plans the AI risk assessment. Clause 8.2 runs it and produces the evidence.
- ISO 31000 supplies the process. ISO/IEC 23894 supplies the AI-specific content inside it.
- The AI risk assessment and the AI system impact assessment are separate, non-mergeable documents.
- All 38 Annex A controls across 9 themes, not 6, sit on your treatment menu.
- ISO/IEC 22989 names five roles: producer, provider, customer, partner, subject, not the common “provider, operator, user” shorthand.
- The EU AI Act’s top penalty tier, €35 million or 7%, covers prohibited practices. Ordinary high-risk non-compliance caps at €15 million or 3%.
- The EU AI Act’s high-risk deadline moved to December 2027 for standalone systems under a 2026 rule change.
- Reassess on a schedule and whenever the system, its data, or its regulatory context shifts.
Build an AI risk assessment process that holds up under audit #
Nank.ai runs ISO 42001 programmes for companies in Canada and the United States, from the first risk register through Stage 2, with a dedicated compliance manager who owns the result.
