ISO 42001 risk assessment, clause 6.1.2
The mechanics are the ones you already know from information security. The difference is who counts as harmed, and it is the difference that decides whether your register passes a stage 2 audit or reads as a security register with the word model pasted into it.
Clause 6.1.2 of ISO/IEC 42001 requires a defined AI risk assessment process with documented risk criteria, applied so that repeated assessments give consistent and comparable results, producing identified risks with an analysed consequence and likelihood, evaluated against your criteria and prioritised for treatment. That is the same shape as clause 6.1.2 of ISO 27001. The substantive difference sits one clause later: the results of the AI system impact assessment required by clause 6.1.4 feed into this, so the harm you are assessing extends past your organization to the individuals, groups and societies the system touches.
An auditor tests this by picking three rows from your register and asking who is harmed in each. If the answer is always the company, the impact assessment has not made it into the risk work and you have an ISO 27001 register with AI in the title.
How is this different from an ISO 27001 risk assessment?
| ISO 27001, clause 6.1.2 | ISO 42001, clause 6.1.2 | |
|---|---|---|
| What is at risk | Confidentiality, integrity and availability of information | Achievement of AI objectives, plus consequences for people affected by the system |
| Who can be harmed | The organization, and information owners | The organization, individuals, groups of individuals, and society |
| Unit of assessment | Assets, processes, or risk scenarios in the ISMS scope | AI systems, and often a specific deployment context of one system |
| What feeds it | Asset and supplier inventory, threat sources | AI system inventory, your role per system, and the clause 6.1.4 impact assessment |
| Reference risk sources | None in the standard. Threat catalogues are external | Annex C lists AI-specific risk sources and organizational objectives |
| Output document | Risk treatment plan and Statement of Applicability against 93 Annex A controls | Risk treatment plan and Statement of Applicability against 38 Annex A controls |
Everything else transfers. If you already run a working ISO 27001 risk method, extend it rather than build a second one: add the affected-party dimension to your consequence scale, add AI systems as assessable objects, and add the Annex C sources to your identification prompts. Two parallel risk registers is a maintenance cost you pay every quarter forever, and it is the most common structural mistake in a second certification. The information security method it extends is set out on the ISO 27001 risk assessment page.
What are the Annex C risk sources?
Annex C is informative rather than normative, which means you are not required to use it and an auditor will still ask whether you considered it. It holds two lists. The first is potential organizational objectives for AI, which are the things your risk criteria should be protecting. The second is risk sources, which are the prompts that stop your identification exercise from finding only the risks you already worried about.
- Level of automation
- How much of the decision happens without a person. The higher it goes, the more the residual risk depends on your monitoring rather than on human judgement catching the bad case.
- Lack of transparency and explainability
- Whether you can say why the system produced a given output. This is a risk source and, where Law 25 applies to an exclusively automated decision, it is also a legal exposure, because you owe the individual the principal factors behind the decision.
- Complexity of the environment
- The gap between the setting you tested in and the setting the system is deployed into. Most production failures live here rather than in the model.
- Risk sources related to machine learning
- Training data quality and representativeness, the training methodology, drift between training distribution and live traffic, and the evaluation design that decides whether you would notice.
- System life cycle issues
- Requirements that were never written, undocumented design decisions, a release that skipped validation, and models still in production after the team that owned them moved on.
- Technology readiness
- Whether the technique is mature enough for the use, and whether you are the one finding out.
The organizational objectives list runs alongside it: accountability, availability and quality of training data, environmental impact, fairness, maintainability, privacy, reliability, safety, security, transparency and explainability, and the level of AI expertise you actually hold. Use it to write your risk criteria, because criteria expressed only in dollars will not let you evaluate a fairness risk against anything.
A method that survives a stage 2 audit
- Fix the unit first. Assess per AI system and deployment context, not per model. The same model behind an internal drafting tool and a customer-facing decision is two entries with different answers.
- Write the criteria before the register. What consequence scale, what likelihood scale, what counts as acceptable, and who can accept a risk above the line. Doing this after the register means the criteria get written to fit the answers.
- Identify using prompts, not memory. Walk the Annex C sources, then the affected populations from your impact assessment, then your own incident history. Identification quality decides everything downstream.
- Analyse consequence twice. Once for the organization, once for affected people. A model that embarrasses you is not the same as a model that costs someone a job, and one scale cannot carry both.
- Evaluate and prioritise. Against your criteria, with the ordering recorded. Auditors check that treatment order follows evaluation order rather than engineering convenience.
- Feed clause 6.1.3. Determine treatments, compare against the 38 Annex A controls as a completeness check, and record every decision in the Statement of Applicability.
What does a good register row look like?
These are illustrative rows for a fictional Canadian company running a customer support triage model and a document summarizer. They show the level of specificity that survives questioning, which is the only thing worth copying from an example register.
| Risk | Annex C source | Who is harmed | Treatment | Residual |
|---|---|---|---|---|
| Triage model routes accounts with non-standard English to the slowest queue, and nobody notices because the aggregate service level is met | Training data representativeness, lack of transparency | Customers in that group, unevenly | Queue-time monitoring segmented by language signal, threshold that opens a review, quarterly evaluation on a held-out set | Medium. The monitoring is new and has not yet caught anything |
| Summarizer produces a confident summary that omits a contractual obligation, and the account manager sends it to a customer unread | Level of automation, complexity of environment | The customer, and the organization contractually | Output labelled as a draft, source passages linked, sending blocked without an explicit confirmation step | Low, provided the confirmation step is not removed for speed |
| Model provider changes the underlying model version with no notice and behaviour shifts in production | Technology readiness, third-party dependency | All users of the feature | Version pinning where the contract allows it, a canary evaluation run before promotion, contractual notice terms requested at renewal | Medium. The supplier will not commit to notice periods and the risk is accepted at the owner level |
| An automated eligibility decision affecting a Quebec resident cannot be explained on request within the required timeframe | Lack of transparency and explainability | The individual, and the organization in law | Decision logging with model version, inputs and principal factors retained, a documented human review route | Low once logging is verified. Currently open, owner named, due date set |
Two things auditors look for in a register
The first is a risk that was accepted rather than treated, with a named person who accepted it and a date. A register with no accepted risks reads as a register nobody used. The second is a row whose residual rating is worse than the inherent rating of something else you treated first, which shows the prioritisation is decorative. Both are cheap to get right and both are found in the first twenty minutes of a stage 2 audit.
How often does this have to be redone?
Clause 6.1.2 asks for the process to be applied at planned intervals and when significant changes occur, which in practice means an annual full pass plus a trigger-driven reassessment. Sensible triggers are a new AI system, a retrain or model version change, a new deployment context or jurisdiction, a change in the degree of automation, and any incident. The interval matters less than the triggers actually firing, and the way to make them fire is to put them in the change process rather than in the risk policy.
When a formal AI risk assessment is not the right spend
If you run no AI systems that affect anyone outside the company, and nobody has asked you to demonstrate governance, a structured risk assessment is process for its own sake. The honest minimum is an inventory of what you run and a note on each of what it would take for it to matter. That position holds until the first customer-facing AI feature ships or the first questionnaire arrives, and it is the same argument made at length on who needs ISO 42001.
What is not defensible is running the assessment and then not treating what it finds. A register with four high risks and no owners is worse than no register, because it establishes that you knew. That is true under the standard and it is true in front of a regulator or a court.
Get help building an AI risk method
Tell us what your AI systems do and whether you already run an ISO 27001 risk process, and we will match you with firms that extend it rather than replace it.
Get matchedCommon questions
Can we reuse our ISO 27001 risk assessment for ISO 42001?
You can reuse the method, the scales, the tooling and the governance around it, and you should. What you cannot reuse is the content, because the consequence dimension has to reach individuals, groups and society, and your information security register does not assess that. Extend one process rather than run two, and add AI systems as assessable objects.
Is Annex C mandatory?
No, Annex C is informative. It lists potential AI-related organizational objectives and risk sources as prompts for your assessment. Auditors will not require you to use it, and they will ask how you satisfied yourselves that risk identification was complete, at which point having walked a published list of AI risk sources is a much better answer than having brainstormed.
What is ISO 23894 and how does it relate?
ISO/IEC 23894 is the guidance standard for AI risk management. It applies the general risk management structure of ISO 31000 to artificial intelligence and gives worked examples of AI risk sources and treatments. It is guidance, not requirements, so you cannot be certified against it, and it is the most useful companion document if you are building an AI risk method from nothing.
Do we need a separate risk register for AI?
A separate view, not a separate system. Most organizations add AI risks to the existing register with a flag or a category, which keeps one review cycle, one set of owners and one management review agenda item. A genuinely separate register tends to be reviewed by different people on a different cadence, and it drifts within two quarters.
How does the impact assessment relate to the risk assessment?
The impact assessment required by clause 6.1.4 identifies consequences for individuals, groups and society, and those results feed the risk assessment under clause 6.1.2. In practice you run the impact assessment on a system, then carry its findings into the register as risks with owners, treatments and residual ratings. The detail of what an impact assessment contains is on the impact assessment page.
Who signs off AI risk acceptance?
Whoever your risk criteria say can, and the criteria should name a level rather than a person, so it survives someone leaving. For risks with consequences for individuals outside the organization, acceptance sitting below the executive who owns the product is the pattern that gets questioned, because the accountability clause 5 requires has to be visible somewhere.