AI System Impact Assessment: A Clear Guide to ISO 42005

An AI system impact assessment is the document that says who could be harmed by an AI system, how, and what you did about it. ISO/IEC 42001 requires one; since 2025 there is a dedicated standard telling you how to run it — ISO/IEC 42005 — and the two are designed to be used together.

This guide covers what the assessment has to cover, how it differs from a risk assessment and from a DPIA, and when it has to be repeated.

Why it is a separate assessment

A risk assessment asks what could go wrong for the organization. An AI system impact assessment asks what the system could do to other people — individuals, groups and society — including effects the organization would happily live with.

That difference is the whole point. A recommendation engine that quietly narrows what a group of users ever sees is not an organizational risk until it becomes a news story; it is an impact from the first day it ships. ISO/IEC 42001 builds the requirement into the management system, and ISO/IEC 42005:2025 — published in 2025 by ISO/IEC JTC 1/SC 42 — provides the guidance for performing it and for integrating it with AI risk management.

They overlap and they do not substitute. An AI system processing personal data needs both an impact assessment and a DPIA, and the honest way to run them is one evidence-gathering exercise producing two documents with different framings.

What an AI system impact assessment covers

Working from ISO/IEC 42005’s structure, a defensible assessment answers these in order:

1. What the system is and what it is for. Purpose, intended uses, the decisions it informs or makes, and the degree of human involvement in each.
2. Who is affected. Not just users — the people decided about, those excluded, workers whose roles change, and third parties downstream. Naming affected groups is the step that determines whether anything else is found.
3. Reasonably foreseeable misuse. Uses outside the intent that a sensible person could predict, including the ones your sales material invites.
4. Potential impacts, positive and negative. Across fairness, safety, privacy, autonomy, access to services, economic effects and environmental cost — with severity, likelihood and who bears them.
5. Data and model considerations. Representativeness of training data, known limitations, performance disparities between groups, and what happens at the edges of the distribution.
6. Mitigations and residual impact. What you changed — design, thresholds, human review, disclosure, redress routes — and what remains after those changes.
7. Who approved it, and when it will be revisited.

The section that decides its quality

Step two. An AI system impact assessment that lists “users” as the affected party will find user-experience issues and nothing else. The impacts that damage organizations sit with people who are not users: the applicant screened out, the claimant whose payout is delayed, the small supplier deprioritized by an optimization. Write the list of affected groups before you write anything else, and have somebody outside the product team challenge it.

When to run an AI system impact assessment again

At design, before deployment, and then on change. The triggers worth writing into the procedure:

• A new intended use, market, jurisdiction or user population.
• A material model change — retraining, a new base model, a change of vendor.
• A change in the degree of human oversight, especially removing a human from the loop.
• Evidence from monitoring: complaints, disputed decisions, drift, or a performance gap between groups.
• A regulatory change that alters what counts as acceptable.

The assessment is also where AI governance meets regulation. The EU AI Act’s obligations for high-risk systems cover much of the same ground from a legal angle, and a well-run impact assessment is most of the evidence you would need — see our guide to ISO 42001 versus the EU AI Act. Our ISO 42001 controls guide covers where the assessment sits in the management system.

Frequently asked questions

Does ISO 42001 require an AI system impact assessment?
Yes — it is a requirement of the management system, and ISO/IEC 42005:2025 was published to provide the how.

Is ISO 42005 certifiable?
No. It is guidance. ISO/IEC 42001 is the certifiable management system standard; 42005 supports one of its requirements.

How is it different from a DPIA?
A DPIA addresses risk to data subjects from processing personal data. An AI system impact assessment addresses impacts of the AI system on individuals, groups and society, whether or not personal data is involved.

Who should perform it?
A group, not a person. Product, engineering, legal, privacy and someone who can represent affected groups. A single author produces a document that reflects one perspective.

How long should it be?
Proportionate to the system’s potential impact. A low-impact internal tool warrants a short record; a system making decisions about people’s access to services warrants a real one, with evidence behind each claim.

Where this leaves you

Run the AI system impact assessment as a design activity rather than a pre-launch formality. Name the affected groups first and widely, take foreseeable misuse seriously, record mitigations and what remains after them, and set explicit re-assessment triggers so the document tracks the system rather than the launch date. Use ISO/IEC 42005 for the method and keep the output inside the ISO/IEC 42001 management system, where the risk register and the monitoring data can actually reach it.

References

• ISO/IEC 42005:2025 — AI system impact assessment, the guidance standard published in 2025.
• ISO/IEC 42001 — the AI management system standard the assessment sits inside.

More on AI governance

• The AI system impact assessment — you are here
• The ISO 42001 controls
• ISO 42001 vs the EU AI Act
• The NIST Generative AI Profile

Impact assessment templates, risk records and the AI policy set are in the ISO 42001 AI Management Toolkit, or start with the free ISO templates.