ISO 42001 AI risk assessment, treatment and impact assessment
ISO 42001:2023 6.1.2 and 6.1.3 ask you to assess AI risks and decide their treatment, comparing your controls with Annex A in a Statement of Applicability. Clause 6.1.4 adds a separate AI system impact assessment of consequences for individuals, groups and society. Clauses 8.2 to 8.4 have you repeat all three as planned and on change.
The requirement in plain English
Risk criteria (ISO 42001:2023 6.1.1). When you plan the system you decide which risks and opportunities need action, taking into account the domain your AI works in and its intended uses. You set AI risk criteria that tell acceptable risk from unacceptable risk and support the assessments that follow.
AI risk assessment (ISO 42001:2023 6.1.2). You define a process, aligned with your AI policy and objectives, that gives consistent, valid and comparable results. It identifies risks that could help or stop you meeting your AI objectives, analyses the consequences for your organisation, for individuals and for society, and how likely they are, and compares the levels with your criteria to set priorities. Where it applies, it takes the results of the impact assessment into account.
AI risk treatment (ISO 42001:2023 6.1.3). You choose how to treat each risk and the controls the treatment needs, from Annex A or anywhere else. You compare them with Annex A so nothing necessary is missed and record the result in a Statement of Applicability that justifies each inclusion and exclusion and says whether each control is in place. A treatment plan follows, and the management you designate approves it and accepts the residual risk.
AI system impact assessment (ISO 42001:2023 6.1.4). You define a process to assess what developing, providing or using an AI system could do to individuals, groups of individuals and societies, in its technical and social context and the jurisdictions it works in. You document the results, may share them with interested parties, and feed them into the risk assessment. Annex A supports this with four controls on the process, its documentation, and impacts on individuals and groups and on society (ISO 42001:2023 Annex A 5.2, then controls A.5.3 to A.5.5).
Doing it (ISO 42001:2023 8.2, 8.3 and 8.4). You run the risk assessment, carry out the treatment plan and run impact assessments at planned intervals and whenever a significant change is proposed or happens, keeping the results each time.
Guidance. Annex C lists AI objectives, such as fairness, safety, privacy, transparency and accountability, and sources of AI risk, such as the level of automation, how far a model can be explained, and immature technology. It is a prompt, not a checklist. ISO/IEC 23894 and ISO/IEC 42005 give fuller guidance on AI risk management and impact assessment.
The difference between the two assessments matters. The risk assessment asks what could go wrong for the organisation and its objectives. The impact assessment looks outward, at the people and society the system touches, whether or not their harm would ever reach your balance sheet.
This is guidance to help you understand the requirement, not legal advice.
What good looks like
A 30-person insurance software company runs one risk method for its ISO 27001 and ISO 42001 systems, extended with an AI consequence scale that scores harm to individuals and to groups as well as to the business. Two assessors scoring the same scenario reach the same level, which is the consistency test.
Each AI system has an impact assessment before deployment. For its claims-triage model the assessment names the people affected (claimants, including vulnerable customers), the harms (an unfair delay or a wrong referral to fraud review), the groups that could be treated differently, and how severe and reversible each harm is. The bias and fairness results from model evaluation are attached as evidence.
The impact findings feed the risk register: a high impact on a vulnerable group becomes a risk with an owner and a treatment, such as a human review of every fraud referral. The Statement of Applicability changes with it.
The AI risk owner named for the system approves the treatment plan; top management accepts the residual risk. Both assessments are repeated when the model is retrained on new data, when a new customer segment is added, and every year regardless.
Evidence an auditor expects
- AI risk criteria and the risk assessment process (required documented information): the auditor checks the criteria separate acceptable from unacceptable risk and include harm to people.
- Risk assessment results (required): a dated register with owners, levels and the link to treatment, sampled system by system.
- Risk treatment plan and approvals (required): actions with owners and dates, approved, and residual risk accepted by named management.
- Statement of Applicability (required): traced back to the treatment and impact decisions.
- Impact assessment process and results (required): one assessment per AI system, showing affected individuals, groups and society.
- Reassessment triggers: evidence both assessments were repeated after a significant change.
Common mistakes
Reusing the security risk register unchanged
An ISO 27001 register scores harm to confidentiality, integrity and availability. AI risk needs consequences for people, such as unfair or unsafe outcomes. Extend the consequence scale before you assess.
Folding the impact assessment into the risk assessment
Auditors look for the outward view as its own exercise. Merged into the risk register, harms to people get scored only by what they cost the organisation. Keep a separate record per system and link it.
Assessing once, at launch
Clause 8.4 expects reassessment on significant change. A retrained model, a new data source or a new user group can shift the impact more than the original launch did.
Excluding the impact controls as a deployer
An organisation that only uses AI built by others still decides how it is used and on whom. The Annex A impact controls rarely justify exclusion.
Impact findings that change nothing
An impact assessment with no link to the risk register or the Statement of Applicability is paperwork. Each significant impact should end in a treatment, an accepted risk or a reasoned decision.
How Sted helps
- Under the same Risk Management Procedure (PRC-RMP) Sted’s knowledge base carries an AI Risk Assessment Record (REC-ARA) for each AI system, with a suggested annual frequency, and for medical devices a Medical Device Risk Management Plan (REC-MDRMP), Medical Device Risk Management File (REC-MDRM) and Risk Management Report (REC-RMR).
- Records are part of the Full Management System plan.
- In Sted’s knowledge base the AI system impact assessment is carried by the AI System Lifecycle Procedure (PRC-AISL), tagged to ISO 42001 6.1.4 and controls A.5.2 to A.5.5, with the Bias and Fairness Assessment Record (REC-AIBF) tagged to 6.1.4 and A.5.3 to A.5.5 and the AI Use Case Definition and Classification Record (REC-AIUC) tagged to 6.1.4.
- Records are part of the Full Management System plan.
- Risk levels are computed from likelihood and impact.
- Sted has no DPIA record template.
Sted holds the method and the records and computes risk levels. It does not identify your risks or impacts or accept residual risk; your named owners do.
Related guides and terms
- Risk assessment guide: running the assessment step by step, with an ISO 42001 example.
- Statement of Applicability guide: turning treatment decisions into justified control choices.
- ISO 42001 Annex A controls: the controls you compare your treatment with.
- DPIA guide: the data protection assessment that can share work with an impact assessment.
- EU AI Act risk classification: the legal tier your risk assessment should record for each system.
- ISO 42001 context, scope and AI policy: the scope, roles and AI policy the assessment process is aligned with.
Frequently asked questions
Is an AI system impact assessment the same as a DPIA?
No. A data protection impact assessment looks at risks to people’s rights from processing their personal data. An AI system impact assessment looks at what the system could do to individuals, groups and society, including unfair outcomes, safety and effects on people whose data it never touched. Where both are needed, one combined document can serve, if it answers both.
Do we need an impact assessment for every AI system?
Yes, for every AI system in the scope of your AI management system, though the depth should match the potential for harm. A meeting summariser may need a page; a model that helps decide insurance claims needs a full assessment with the affected groups named. Repeat it at planned intervals and when the system or its use changes significantly (ISO 42001:2023 8.4).