Annex A 5.2psychologyISO/IEC 42001:2023

AI System Impact Assessment Process

A repeatable method for working out who an AI system could affect and how badly, covering single people, whole groups, and the wider community, and applied again at each stage of the system's life.

A.5 Assessing impacts of AI systems Preventative Artificial intelligenceISO/IEC 42001:2023 AI Management SystemISO 42001 Annex A 5 management Privacy

record_voice_over

Plain language

This control asks you to build a standard way of working out the harms an AI system could cause before and during its use, rather than guessing case by case. The harm might land on one person (a job applicant screened out), on a group (a particular suburb or ethnic community scored more harshly), or on society as a whole (an AI that floods the public with misleading content). You run the same assessment method at each stage of the system's life (when you design it, when you train and test it, when you go live, and when you change or retire it) so a new harm introduced by a model update does not slip through unnoticed.

01 - Overview

Framework

ISO/IEC 42001:2023

Control effect

Preventative

Classifications

N/A

Official last update

01 Dec 2023

Control Stack last updated

19 June 2026

Official control statement

The organisation shall establish a process to assess the potential consequences for individuals or groups of individuals, or both, and societies that can result from the AI system throughout its life cycle.

psychologyISO/IEC 42001:2023Annex A 5.2

priority_high

Why it matters

Without a set assessment method, an AI tenancy-screening or welfare-scoring tool can quietly disadvantage a whole cohort (for example renters from a single postcode or a particular language background) and the pattern is only discovered after the people affected have already been refused. That is the kind of failure that draws an OAIC complaint or, for a NSW government project, a finding against the NSW AI Assurance Framework, and it can force the system to be switched off mid-service. The societal version is wider still: an unassessed content-generation model can degrade public information at scale before anyone is held to account.

settings

Operational notes

Treat the assessment as a living document tied to the system, not a one-off sign-off filed at launch. Re-run it whenever a life-cycle trigger fires (a new data source, a retrained model, a change in who the system is used on, or an expansion to a new cohort or region) because each of these can introduce a harm the original assessment never saw. Keep the assessment criteria, the list of affected stakeholder groups (individuals, groups, and the broader community), and the severity and likelihood scales consistent across systems so results can be compared. Where an assessed harm is judged serious, the process should name the person who must decide whether to proceed, change the design, or stop.

02 - Implement

build

Implementation tips

Write a short impact-assessment procedure that anyone introducing an AI system has to follow, setting out the questions to answer, the rating scales to use, and who approves the result, so assessments are done the same way every time rather than improvised.
For each system, map the people and communities it touches in three layers (individuals it makes decisions about, groups that might be treated differently as a cohort (for example by postcode, language, or disability), and society at large) and assess a plausible harm for each layer, not just the typical single user.
Give your assessors a simple severity-and-likelihood scale so a harm to a vulnerable group is scored higher than a minor inconvenience, and so two different teams reach comparable results; record the reasoning behind each rating, not just the score.
Tie the assessment to defined life-cycle triggers (starting design, before training data is chosen, before go-live, on any major model change, and at retirement) and require a fresh assessment at each trigger so a harm introduced by a later change is caught.
When an assessment surfaces a serious or society-wide harm, route it to a named decision-maker with the authority to require a design change, add a safeguard, or hold the launch, and capture that decision against the assessment so the outcome is traceable.

03 - Audit

fact_check

Audit / evidence tips

AskThe written impact-assessment procedure for AI systems.GoodThe procedure defines a repeatable method and names the life-cycle stages at which an assessment must be carried out or re-carried out.
AskA completed impact assessment for one named AI system.GoodThe completed assessment covers individuals, identified groups, and societal effects, with a severity and likelihood rating for each.
AskThe stakeholder mapping behind a recent assessment.GoodThe assessment names the specific individuals and groups affected and identifies wider community effects rather than referring vaguely to users.
AskRe-assessment records for a system that has changed since launch.GoodThere is a dated re-assessment using the same method, triggered by a defined change to the system.
AskA decision record arising from an assessment that found a serious harm.GoodAn accountable owner recorded a decision to change, mitigate, or pause the system in response to an assessed high-severity impact.

04 - Mappings

link

Cross-framework mappings

How Annex A 5.2 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ISO 27001

Control	Notes	Details
sync_altPartially overlaps(1)expand_less
Annex A 5.34	ISO/IEC 42001:2023 Annex A 5.2 requires assessing potential consequences of an AI system for individuals/groups and society throughout th...

ASD ISM

Control	Notes	Details
handshakeSupports(2)expand_less
ISM-0009	ISO/IEC 42001:2023 Annex A 5.2 requires the organisation to run an AI system impact assessment process to evaluate consequences for indiv...
ISM-0041	ISO/IEC 42001:2023 Annex A 5.2 requires an AI system impact assessment process across the AI system lifecycle