ISO/IEC 42005: What an AI System Impact Assessment Actually Requires

Most organisations that adopt AI already run a risk assessment. Fewer run an impact assessment, and a good number believe those are the same exercise under two names. They are not, and the difference is the reason ISO/IEC 42005:2025 now exists.

A risk assessment asks what could harm the organisation. An AI system impact assessment asks who the organisation could harm. Same system, opposite direction of travel, and only one of them tells you what your AI does to the people on the other side of the screen.

ISO/IEC 42005, published in May 2025, is the first international standard devoted to that second question.

What the standard actually is

ISO/IEC 42005 defines an AI system impact assessment as a formal, documented process by which an organisation considers the impacts of an AI system on individuals, groups of individuals and societies.

Three things follow from that definition, and they are easy to skip past.

It is formal. A workshop with no output is not an impact assessment. It is documented. If it is not written down, it did not happen, which is the same evidentiary standard any auditor applies. And the subject is people, not the balance sheet.

The standard is guidance rather than requirements. It uses “should”, not “shall”, and it is not itself certifiable. It applies to any organisation developing, providing or using AI systems, regardless of size, type or nature.

Why ISO/IEC 42001 needed it

If you hold or are pursuing ISO/IEC 42001 certification, this standard is not optional reading.

ISO/IEC 42001 requires an AI system impact assessment in clause 6.1.4, and requires it to be performed at planned intervals and when significant changes occur in clause 8.4. Controls B.5.2 through B.5.5 in Annex A go further, covering the process, its documentation, and the assessment of impacts on individuals and on societies.

What ISO/IEC 42001 does not do is explain how. It tells you the assessment must exist. It does not tell you what a competent one contains.

That gap is precisely what ISO/IEC 42005 fills. Its own Annex A maps clause by clause onto ISO/IEC 42001, including 6.1.4, 8.4, and the B.5 control family. For an organisation certifying against 42001, this is the missing implementation manual.

The distinction auditors keep having to explain

Annex B of the standard sets out the relationship with ISO/IEC 23894, the AI risk management guidance, and it is worth quoting the logic.

Risk management, in the ISO 31000 sense, concerns the effect of uncertainty on the organisation’s objectives. AI system impact assessment concerns a deliberately restricted set of interested parties: individuals, groups of individuals, societies and the environment. It is oriented to concrete uses of a system rather than to business strategy, compliance posture or technology direction.

In practice we see three failure patterns when this distinction is not understood.

The relabelled risk register. An organisation renames its existing risk assessment and presents it as an impact assessment. Every entry describes exposure to the organisation. Nothing describes exposure of a person.

The privacy assessment doing double duty. A completed privacy impact assessment is offered as evidence. Privacy is one dimension of impact. It says nothing about fairness of outcomes, quality of service across demographic groups, or whether people can tell they are dealing with a machine.

The assessment that never triggers again. One assessment is completed at launch, filed, and never revisited, while the model, the data and the deployment context all change underneath it.

What a defensible process contains

Clause 5 of the standard sets out the process, and it is more demanding than a template. An organisation should determine, in advance and in writing, matters including the following.

• Timing. At what point in the life cycle assessments are performed, how often they are refreshed, and what triggers a reassessment. The standard lists changes to intended use, users, data, model complexity, performance, operating environment, applicable law, contracts, internal policy and the interested parties themselves.
• Scope. Whether the whole AI system or a component is being assessed, and the organisation’s role in the AI ecosystem, whether data provider, model provider, service provider or product provider.
• Responsibilities. Who establishes scope, allocates resources, liaises with interested parties, approves the result and escalates. The standard notes explicitly that relevant disciplines can include engineering, health and safety, human rights, ethics, and social sciences such as anthropology, sociology and psychology.
• Thresholds. This is the clause most often missing entirely. See below.
• Approval and escalation. Who signs, when a threshold breach requires sign-off, and whether external approvals apply.
• Monitoring and review. When reviews occur, who performs them, and what the review output changes.

Thresholds, sensitive uses and restricted uses

ISO/IEC 42005 introduces three terms that deserve to be adopted deliberately rather than absorbed by accident.

A sensitive use is a use of an AI system that can have a significant adverse impact on individuals, groups or societies. A restricted use is one constrained by law, organisational policy or contract. Reasonably foreseeable misuse is use the developer did not intend but which follows from readily predictable human behaviour, and the standard is careful to note that predictable behaviour includes that of the elderly, children and people with disabilities.

The standard asks organisations to define these thresholds in advance, in their own context, and to document what happens when an assessment lands in one of those categories. Its own example is direct: an AI system automating lending decisions is a sensitive use, because it produces significant financial consequences for individuals.

Deciding what counts as sensitive after you have already built the system is not a threshold. It is a negotiation.

What the documented assessment should cover

Clause 6 sets out the contents. A complete assessment describes the AI system and its capabilities, its intended uses and, separately, its unintended uses. It covers the data and data quality, the algorithms and models, and the deployment environment including geography, languages and operational constraints.

It then identifies the relevant interested parties, distinguishing those directly affected from others, and documents actual and reasonably foreseeable impacts, both benefits and harms, alongside system failures and foreseeable misuse. Finally it records the measures taken to address what was found.

Two details are worth noting because they cause friction in real assessments. An organisation deploying a third-party model may simply not hold detailed information on training data or algorithms, and the standard acknowledges this directly. And when reporting foreseeable misuse externally, organisations may omit detail that would be useful to an attacker.

The harms and benefits taxonomy

Annex C is the part most teams will use first. It provides a structured taxonomy of harms and benefits across five groupings: accountability, transparency and explainability, fairness, reliability, and security and privacy.

Under each sit specific objectives with worked examples on both sides of the ledger. Fairness, for instance, covers quality of service across demographic groups, allocation of opportunity, and minimisation of stereotyping. Transparency covers explainability, communication to interested parties, and disclosure of AI interaction, the harm there being that people interact with a system believing it is human.

The benefits column matters as much as the harms column. An impact assessment that records only risks is not an impact assessment, and an organisation that cannot articulate the benefit of a system has not made the case for deploying it.

How it fits with assessments you already run

Annex D addresses alignment with privacy impact assessments, human rights impact assessments, security impact assessments, and business, environmental and financial impact assessments.

The point is not to run six parallel exercises. It is to know which questions each one answers, and to be able to show an auditor where the AI-specific questions were asked. Where an existing assessment genuinely covers a dimension, reference it. Where it does not, the gap needs to be closed rather than assumed away.

What we look for as assessors

When we audit an AI management system, an impact assessment tends to reveal its own maturity quickly. Four questions do most of the work.

Does it describe harm to people, or exposure to the organisation? The vocabulary gives it away within a paragraph.

Were thresholds set before the assessment, or derived from its conclusions? Thresholds written after the fact tend to sit conveniently just above whatever was found.

Who was in the room? An assessment produced entirely by the engineering team that built the system will reliably miss the impacts that team is least equipped to see.

What happened next? An assessment that identified impacts but changed nothing, and triggered no approval, escalation or control, is documentation rather than assurance.

Where to start

If you are working toward ISO/IEC 42001, treat ISO/IEC 42005 as the implementation detail behind clause 6.1.4 and control B.5.2, and build the process before you build the template. If you already run AI systems without a formal process, the honest first step is a triage: decide what constitutes a high-risk system in your context, and assess those first. The standard explicitly supports a shorter triage assessment to determine whether a full one is required.

Either way, write the thresholds down first. Everything else in the standard depends on knowing, in advance, what you would consider unacceptable.