An ISO 42001 AI impact assessment is the documented process of determining what an AI system could do to individuals, to groups of individuals and to society, then retaining that determination and connecting it to a decision. It sits under Annex A objective A.5, Assessing Impacts of AI Systems, and it is performed for real systems under the operation clause rather than described once in a procedure.
Of the nine Annex A objectives, this is the one with the least established practice behind it. Organisations arriving from ISO 27001 have a mature risk assessment habit and a methodology their auditor already accepts, so the instinct is to treat the impact assessment as the same exercise with a new label on the template. That instinct is the most common failure in this area, and the reason is structural: the two assessments have different subjects, so the inputs, the participants and the outputs all change.
Why the AI Impact Assessment Is Not a Risk Assessment
The AI impact assessment is not a risk assessment because the subject of the sentence changes. A risk assessment asks what could harm the organisation: outages, breaches, penalties, a model that embarrasses you in a press cycle. An impact assessment asks what the system could do to individuals, groups and society, whether or not any of it ever reaches the organisation as a loss.
Those questions diverge often enough that running one and calling it the other is a real gap. A credit model that declines one demographic at twice the rate of another is a serious impact and, until someone complains publicly, a negligible organisational risk. The risk register will not hold it, because nothing on the register was designed to notice it.
You cannot reuse the register's scoring either. Likelihood multiplied by business impact gives a number that means something to a risk committee. Severity to an affected person, reversibility of the harm, and whether that person can challenge the outcome are what the impact assessment turns on, and none of them map onto a loss estimate. The Annex A control objectives treat these as two separate processes for that reason.
Harms a Security Risk Assessment Never Surfaces
Four categories of harm come up repeatedly in impact assessments and almost never in a security risk assessment. They are what the exercise is for.
- Unequal performance across groups. A system accurate in aggregate can be materially worse for a subpopulation — a speech model on accented English, a classifier on scanned rather than digital inputs, a fraud model on thin-file customers. Aggregate accuracy hides this by design.
- Loss of recourse when a decision is wrong. The model will err; the question is what happens to the person on the receiving end. With no route to a human, no explanation they can act on and no record of why the decision landed, the error is permanent for them however fast you fix the model.
- Erosion of autonomy. Ranking and default-setting systems change what people choose without denying them anything. A technically advisory system becomes effectively binding once the operator has thirty seconds per case and the recommendation is pre-selected.
- Downstream effects on people who never interacted with the system. A hiring screen affects candidates filtered before they knew the role existed. A model trained on one population and applied to another affects a group that never used your product. These people have no account and appear in no input your security assessment considers.
A security risk assessment asks about confidentiality, integrity and availability. None of the four is a CIA failure, and each can occur with every security control working exactly as designed.
Running your first AI system impact assessment and unsure what it should produce?
Share your work email and we will send the impact assessment method we use with clients, including the trigger criteria for re-running one and the record structure certification bodies sample.
When to Run an ISO 42001 AI Impact Assessment
Run an ISO 42001 AI impact assessment at four points: at design, before deployment, on material change to the system or its data, and on material change to the deployment context. Writing those triggers down as criteria is itself part of what the objective asks for, because an assessor will ask how you decide when one is due and "when it seems necessary" is not an answer.
At design, the assessment is cheap and it still changes the design. This is the only point at which you can decide not to collect a field, not to use a data source, or to keep a human in the loop as an architectural property rather than a policy promise. Everything found later is a mitigation bolted onto a system shaped without it.
Before deployment, the assessment meets what actually got built, and the design-stage assumptions about who is affected and how the output is used are either confirmed or found to have drifted. Here the assessment either gates the release or demonstrates that it does not, and certification bodies read the dates to see which.
The Trigger Teams Miss: A Changed Context of Use
The trigger teams miss is a changed context of use, and it is missed because the model has not changed at all. No retraining, no new dataset, no release note. The system is identical and its impact is not.
A classifier validated to triage internal tickets gets pointed at customer complaints. A model built to prioritise a queue starts being used to close cases. A tool deployed in one country is switched on in another, with a different population and a different legal position for the people it decides about. An advisory score becomes the default action in a workflow redesign. In each case the impact changes materially and nothing a change-detection pipeline watches has moved.
So write the context triggers into your criteria explicitly: new user population, new jurisdiction, new decision weight, new integration consuming the output, and any move from advisory to automatic. Nobody files a change request for "we started trusting it more," so these get caught at a review cadence rather than by an event — in practice the same annual cycle that feeds the internal audit programme.
Who Needs to Be in the Room
The people who need to be in the room are the ones holding perspectives the technical owner does not. The system owner and an engineer who understands the model's failure modes are necessary and nowhere near sufficient: the question on the table is about effects on people, and neither of them has that information.
- Legal or privacy counsel, for the obligations attaching to the affected population and for the recourse question — whether a decision is contestable is often a legal fact before it is a design choice.
- Whoever handles complaints or support. They already know how the system fails for real people, usually in more detail than the owning team, and they are almost never asked.
- A domain practitioner from the affected context — a clinician, an underwriter, a recruiter, a case worker. They can tell you what the output will be used for as opposed to what it is for.
- A representative of the affected group, directly or through an advocacy body, where the decisions are consequential and the population identifiable.
Name a single owner accountable for the assessment being run, reviewed and acted on. Convening these people is the part that needs authority, and a committee with no named owner reliably produces a document nobody revisits.
What the Assessment Has to Produce
The assessment has to produce a documented record, retained, with a date, a named owner and a decision attached. The decision is the part that matters. An assessment that changed nothing — not the design, the deployment, the disclosure, the monitoring or the decision to proceed — is evidence that you have a process, not that you have a control.
A record that holds up contains the system and its intended purpose; who is affected, including non-users; the impacts considered, with severity, reversibility and whether the affected person has recourse; what was decided; who decided it; and when the assessment is next due. Keep the findings you rejected as well as the ones you mitigated — an assessor reading only accepted findings cannot tell whether the analysis was honest.
Then connect it to control selection. The impact assessment and the risk assessment are what justify your Annex A choices, and the Statement of Applicability is where that justification is recorded.
How ISO 42001 Annex A.5 Connects to the Life Cycle and Data Objectives
ISO 42001 Annex A.5 does not stand alone: in Annex A the life cycle objective and the data objective feed A.5 directly, and they are where the inputs to a credible impact assessment come from. A.5 asks what the system does to people. A.6, AI System Life Cycle, and A.7, Data for AI Systems, are what let you answer with something better than a guess.
Provenance and representativeness are the clearest case. If you cannot say where a dataset came from, under what terms, and which population it describes, you cannot assess unequal performance across groups — you can only assert that none exists. The data objective's provenance and quality controls are a prerequisite for the impact objective, which is why teams that defer data governance find the impact assessment stalls rather than proceeding with gaps.
The life cycle objective supplies the other half. Verification and validation results tell you where the system fails and for whom; the deployment and monitoring controls tell you whether it still operates inside the envelope it was validated for. Without those, a pre-deployment assessment has a shelf life nobody can estimate. The clauses that tie this together are covered in our clause-by-clause guide to the standard, and the normative text is available from ISO on the ISO/IEC 42001:2023 standard page.
Overlapping Obligations for EEA Deployers of High-Risk AI
An EEA deployer of a high-risk AI system has obligations under the EU AI Act that overlap substantially with this work. The Act places duties on deployers as well as providers, and for certain uses those duties include assessing the system's effects on the fundamental rights of the people subject to its decisions. Different legal instrument, own scope, own tests — but an analysis of the same shape.
So one process can produce evidence for both, provided it is designed to. A record that identifies the affected population, the impacts considered, the mitigations chosen and the human oversight arrangements answers a large part of both asks. A record that only lists technical risks to the organisation answers neither.
Do not mistake the overlap for equivalence. Certification against ISO 42001 is not compliance with the Act — our guide to ISO 42001 and the EU AI Act sets out where the management system genuinely helps and where it stops. What it buys you is a process that produces the artefacts repeatedly, rather than an evidence scramble per request.
Four Ways Impact Assessments Fail
Four failure modes account for most of the impact assessments that do not survive a close read.
- Run once at procurement, never again. The assessment cleared a purchase gate and sits at the date of that gate. The system has since been rolled out further, integrated into more workflows and trusted more, and none of it triggered a review.
- Considers only users. The affected population in the record is the set of people with logins. Candidates, claimants, patients and anyone decided about rather than served are absent — which excludes the group most exposed to the harm.
- No named owner. The assessment came out of a working group. Nobody is accountable for re-running it, and the re-run date passes without anyone noticing.
- Treating "the vendor assessed it" as sufficient. The vendor assessed the system for its intended purpose in general. You are deploying it into a specific population, a specific decision and a specific jurisdiction, none of which the vendor knew about. Where you are the deployer, the responsibility allocation under the third-party objective exists precisely so this does not fall through the gap.
AI Impact Assessment Questions Teams Ask
These are the AI impact assessment questions teams ask most often when they start on A.5 with an ISO 27001 risk process already running.
Not as the assessment itself. Reuse the machinery around it — document control, review cadence, approval route, nonconformity process — and most organisations should. What you cannot reuse is the analysis or the scoring, because the subject is different. Your risk assessment asks what could harm the organisation; the impact assessment asks what the system could do to individuals, groups and society. Likelihood multiplied by business impact does not express severity to an affected person, reversibility, or recourse.
On material change to the system, its data or its deployment context, and on a defined review cycle in the absence of change. The review cycle matters because the context trigger does not announce itself: a model can be deployed to a new population, given more decision weight, or switched from advisory to automatic without a line of code changing. Write the triggers down as criteria, context ones included, because an assessor will ask how you decide an assessment is due.
No, though they overlap where the system processes personal data. A data protection impact assessment is bounded by privacy law and concerns risks to data subjects arising from processing. An AI system impact assessment covers effects with nothing to do with personal data — unequal performance across groups, loss of recourse, erosion of autonomy. Where both apply, run them so each cites the other rather than duplicating the analysis in two templates.
Someone with the authority to stop the deployment. If the sign-off cannot withhold approval, the assessment is advisory and a certification body will read it that way. In practice that is the system owner for routine systems and an executive or governance forum for consequential ones, with accountability sitting on one named person rather than a committee.
Yes, if you are deploying it. The vendor assessed the system for its intended purpose in general; you are putting it in front of a specific population, attaching it to a specific decision and operating it in a specific jurisdiction. Their assessment is an input to yours, not a substitute. Annex A's third-party and customer relationships objective exists to make that allocation explicit in the contract rather than assumed.
Make the impact assessment a control rather than a document
Book a demo and we will show how Konfirmity holds your AI system inventory, the impact assessment record per system, the re-run triggers and the Statement of Applicability justification in one place.
Book a demo
Start With the System That Affects the Most People
Start with the system that affects the most people, not the one that is easiest to assess. The usual instinct is to begin with the internal tool where the owner is cooperative and the population is small, which produces a completed assessment and almost no information. Begin instead with whichever system shapes consequential decisions about the largest number of people, and accept that the first will take longer than planned.
What you are building is a method, not a document. Once you have run one assessment properly — the right people in the room, a population that includes non-users, a severity and recourse analysis rather than a likelihood score, and a decision attached to the record — the rest become a repeatable exercise against an AI management system you already operate.
So write the trigger criteria down before you run anything, including the context-of-use triggers nobody files a change request for. Then make the Annex A selection trace back to what the assessments found, which is what the Statement of Applicability records.
