ISO 42001 Annex A 5.2 AI system impact assessment process
What it says
The organization 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.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishA 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The written impact-assessment procedure for AI systems.
Look at
Whether it spells out the trigger points across the life cycle (design, training, go-live, major change, retirement) rather than describing a single launch sign-off.
Good evidence
The procedure defines a repeatable method and names the life-cycle stages at which an assessment must be carried out or re-carried out.
- Check 2 of 5What an auditor asks for
Ask for
A completed impact assessment for one named AI system.
Look at
Whether it separately considers harm to individuals, harm to groups of individuals, and harm to society, not just one customer at a time.
Good evidence
The completed assessment covers individuals, identified groups, and societal effects, with a severity and likelihood rating for each.
- Check 3 of 5What an auditor asks for
Ask for
The stakeholder mapping behind a recent assessment.
Look at
Whether the distinct cohorts the system can affect are actually named, including any group likely to be disadvantaged.
Good evidence
The assessment names the specific individuals and groups affected and identifies wider community effects rather than referring vaguely to users.
- Check 4 of 5What an auditor asks for
Ask for
Re-assessment records for a system that has changed since launch.
Look at
Whether the same assessment method was re-run after a model update, a new data source, or an expansion to a new cohort.
Good evidence
There is a dated re-assessment using the same method, triggered by a defined change to the system.
- Check 5 of 5What an auditor asks for
Ask for
A decision record arising from an assessment that found a serious harm.
Look at
Whether a named owner decided to mitigate, redesign, or hold deployment, not just note the risk.
Good evidence
An accountable owner recorded a decision to change, mitigate, or pause the system in response to an assessed high-severity impact.
Mappings
Closest match in ISO/IEC 27001: A.5.34, Privacy and protection of personally identifiable information, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.5.34.
Annex A 5.2 (ISO/IEC 42001) requires a process to assess potential AI-driven impacts on individuals, groups and society throughout the AI system lifecycle. Annex A 5.34 (ISO/IEC 27001) overlaps because privacy/PII impacts are a common and significant subset of AI impacts that should be assessed (e.g., inference, re-identification, unlawful secondary use). Annex A 5.34 is narrower to privacy and protection of PII, while Annex A 5.2 extends beyond privacy to broader human, societal, and group harms (e.g., bias, safety, economic and social impacts).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 42001 training
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.
Turn this control into your AI policy
PolicyMint writes customised ISO 42001 policy documents for your business, audit-ready and exported in your branding (Word, PDF, Excel). Skip the blank page and the boilerplate that does not fit. First document free.
Draft your ISO 42001 documents