ISO 42001 AI Impact Assessment: What Auditors Look For
The AI system impact assessment is the largest single piece of new work in an ISO/IEC 42001 implementation, and the one organisations get wrong most often.
Not because it is difficult. Because it is confused with three other assessments most organisations already run, and because published guidance describes what it is without saying where it stops.
If you already perform a risk assessment, a data protection impact assessment, and — in regulated sectors — a product risk analysis, the question is not “how do I do an AI impact assessment”. It is “what does this fourth document contain that the other three do not, and where is the boundary”.
This article answers that, sets out what ISO/IEC 42005 changed when it was published in 2025, and lists the three failures that show up in certification audits.
Building the assessment process rather than the assessment? The ISO 42001 Compliance Suite contains the impact assessment procedure and the per-system record, with the criteria and the trigger list already defined. €590 excl. VAT.
The question that separates it from everything else
Every other assessment you run asks some version of: what happens if this goes wrong?
Your risk assessment asks what happens to the organisation. Your DPIA asks what happens to the data subject when processing goes wrong or is disproportionate. Your product risk analysis, if you have one, asks what harm the product can cause when it fails.
The AI system impact assessment asks something different:
What are the consequences, for individuals and for societies, of this system working exactly as designed?
That single shift is the whole thing. It is why the assessment cannot be folded into the risk file, and it is why organisations that try to reuse their DPIA template produce something that satisfies nobody.
A concrete example. A model that ranks job applicants performs to specification: it predicts interview success with the accuracy claimed, across the population it was validated on. Nothing has failed. But if it consistently ranks candidates from one background lower — because the historical hiring data it learned from did — then the consequence for that group is real, and no failure-oriented assessment will surface it.
That is the territory the impact assessment covers, and only it covers.
Where each assessment starts and stops
| Asks about | Subject | Trigger | |
|---|---|---|---|
| AI impact assessment (ISO 42001, 6.1.4 and 8.4) | Consequences of the system working as designed | Individuals, groups of individuals, societies | Per AI system, before deployment and on significant change |
| AI risk assessment (ISO 42001, 6.1.2) | Threats to objectives and to the organisation | The organisation and its AI objectives | Continuous, at planned intervals |
| DPIA (GDPR Article 35) | Risk to rights and freedoms from processing personal data | Data subjects | When processing is likely to result in high risk |
| Product risk analysis (e.g. ISO 14971) | Harm arising from the product, including from failure | Patient, user, environment | Throughout the product life cycle |
The four overlap, and that is fine. What matters is that each answers its own question and that you can say which one holds a given finding.
The relationship that trips people up is between the impact assessment and the risk assessment. They run in sequence, not in parallel: the impact assessment establishes what could happen to people, and its output becomes an input to the risk assessment, where it is scored, owned and treated like any other risk.
Run the other way round — risk assessment first, impact assessment as a write-up afterwards — you get a document that reproduces conclusions already reached. An auditor spots that immediately, because the impact assessment contains nothing the risk register did not already say.
What ISO/IEC 42005 changed
ISO/IEC 42005 was published in 2025 as guidance for performing AI system impact assessments. Three things about it are worth getting right, because published summaries are vague on all three.
It is guidance, not a requirement. You cannot be certified to it. Your obligation comes from ISO/IEC 42001 clauses 6.1.4 and 8.4 and from Annex A; ISO 42005 tells you how to satisfy that obligation well. Conformity is assessed against 42001.
Certification bodies will read your assessment against it anyway. Not as a requirement, but as the reference point for what a competent assessment looks like. An assessment that departs substantially from its structure invites the question why. That is not the same as being obliged to use it, and it is a good reason to know what is in it.
It is oriented to documentation and to the life cycle. Its practical contribution is telling you when in the life cycle to assess, what the record should contain, and how the assessment stays alive across retraining and redeployment — which is where most implementations decay.
If you buy one thing alongside ISO 42001, this is the one to buy. If you do not, the requirement is still 42001’s and you can satisfy it with a well-built process of your own.
What the assessment contains
Six sections, in the order the work is actually done.
1. The system, described for someone who did not build it. What it does, what it is for, where the boundary sits between it and the human process around it. If the description takes three sentences and two of them are marketing, the rest of the assessment will be shallow.
2. Intended purpose, and foreseeable misuse. The second half is the one that gets skipped. Not malicious misuse — foreseeable use outside the validated domain. A triage tool built for adults, used on adolescents. A screening model built for one country’s population, deployed in another. Ask the people who will operate it what they expect to use it for; the answer is regularly wider than the specification.
3. Who is affected. Direct users, people the outputs are about, and people affected downstream who never interact with it. Then, specifically, groups with a claim to particular attention — minors, people with disabilities, older people, workers, patients, anyone in a dependent relationship with the organisation.
4. Consequences, positive and negative. Both, because an assessment that lists only harms is not a decision-support document. For each: how severe, how likely, how reversible, and how visible to the person affected. The last is undervalued — a consequence nobody can detect is one nobody will report.
5. What is done about it. Design changes, operating constraints, oversight, information given, monitoring. If nothing changes as a result of the assessment, either the system genuinely has no material impacts, or the assessment was performed to produce a document.
6. Conclusion and approval. Whether to proceed, with what conditions, decided by someone with the authority to say no.
Proportionality: the question nobody answers
Published guidance describes the full assessment and stops. In practice most organisations have one or two systems that warrant it and a dozen that do not, and nobody says what to do with the dozen.
The workable rule: every AI system in scope gets an assessment; the depth varies.
A short-form assessment — the six sections, one page, half an hour — is appropriate where the system does not make or materially influence decisions about people, does not operate on personal data at scale, and has a human in the loop who can and does override it.
And the short form still gets written. The conclusion that a system is low impact is itself a conclusion, reached by someone, on a date, with reasoning. That is what distinguishes a proportionate approach from an incomplete one, and an auditor will ask for the short forms specifically — they are where the shortcuts live.
The full assessment is warranted where the system influences access to something — employment, credit, care, education, a benefit — or operates on a group that cannot easily contest the outcome.
The three failures that show up in audits
The date. The assessment is dated after the system went live. This is the single most common finding and it is unarguable: clause 8.4 requires the assessment to be performed, and an assessment written after deployment did not inform the deployment decision. Nothing can be said in response.
The single author. The assessment was written entirely by the team that built the system. An auditor does not need to read it to know what it concludes. At least one assessor who did not build the system, named on the record, changes both the content and the credibility.
The dead end. The assessment identifies impacts and the risk register contains nothing that came from it. The trail is what is being tested — assessment to risk to treatment to evidence — and a break anywhere in it means the assessment was decorative.
A fourth, less common but harder to fix: the assessment that never moved. Written once before launch, unchanged through two retraining cycles and a change of purpose. ISO 42005’s contribution is largely about preventing this, and the mechanism is simple: name the triggers in the procedure, and record the next review date on the assessment itself.
What to do this week
- List the AI systems in scope. The count is usually higher than expected — the tools people signed up for individually, the AI features switched on inside software you already licence, the model behind a supplier’s service.
- Sort them: full assessment or short form. Use the rule above. Record the sorting decision, because it is itself a judgement.
- Take the highest-impact system first and work the six sections. The first one takes a day; the rest take hours.
- Check the dates on anything already deployed. If assessments are missing for live systems, write them now and record honestly when they were done — a late assessment recorded accurately is a manageable finding; a backdated one is a different category of problem.
- Connect the output to the risk register, with references both ways.
- Name the triggers that require reassessment, and put the next review date on each record.
Frequently asked questions
Is the AI impact assessment the same as a DPIA? No. A DPIA asks about risk to data subjects from processing personal data. The AI impact assessment asks about consequences for individuals and societies of the system operating as designed, whether or not personal data is involved. Where both apply they cross-reference; neither substitutes for the other.
Do we need ISO 42005 to satisfy ISO 42001? No. ISO 42005 is guidance and cannot be certified against. The requirement is in ISO 42001 clauses 6.1.4 and 8.4 and in Annex A. ISO 42005 is worth having because certification bodies use it as the reference for a competent assessment.
Does every AI system need a full assessment? Every system in scope needs an assessment; the depth is proportionate. A system that does not make decisions about people and has effective human oversight can be covered in a short form — but the short form is still written, dated and reasoned.
Who should perform it? A small group rather than one person, including at least one assessor who did not build the system. Where the system affects a specific population, involve someone who understands that population — clinicians for a clinical tool, HR for a hiring tool.
When does it need to be redone? Before deployment, and whenever a trigger fires: a change of intended purpose, a material change to the model or training data, a new deployment context or jurisdiction, a significant incident, or an interval you define. Name the triggers in the procedure rather than deciding case by case.
What does an auditor actually ask for? The assessment for a named system, its date compared with the go-live date, who wrote it, and the risk register entries that came out of it. Those four questions settle most of it.
Where to go from here
The assessment is not hard. It is unfamiliar, which is different, and the unfamiliarity is concentrated in one idea: you are assessing what the system does when it works, not what happens when it breaks.
Organisations that internalise that produce a useful document in a day. Organisations that do not produce a longer version of their risk assessment and discover the gap in the audit.
The ISO 42001 Compliance Suite contains the impact assessment procedure and the per-system record built on this structure, along with the AI system inventory that tells you which systems need one and the risk register the output feeds into. 39 files, €590 excl. VAT.
If you are earlier in the process, the readiness checklist is organised by what produces evidence rather than by clause number, and what certification involves covers the two-stage audit. The Statement of Applicability is where this assessment’s findings should show up as justification for A.5 and A.9 controls. If your AI sits inside a regulated product, what ISO 42001 adds to ISO 13485 works through the same question from the manufacturer’s side.