ISO 42005: AI Impact Assessment

What ISO/IEC 42005 delivers

The standard guides the planning, execution, documentation and review of AI system impact assessments. It helps identify benefits and harms, affected people, intended and foreseeable uses, failure modes, measures and residual risk.

Its value lies in creating a shared language across business, engineering, privacy, security, legal and other stakeholders. The assessment must not become a report that gets filed away: it should shape design, deployment, usage limits and, where appropriate, withdrawal of the system.

How it differs from other assessments

They can share inventory, affected people, scenarios and measures, but each keeps its own requirements. A cross-reference matrix between assessments avoids duplicating work while leaving no gaps uncovered.

When to trigger the assessment

The organisation must define triggers that require starting an impact assessment:

• new system or use case;
• decision affecting people;
• vulnerable population;
• large scale or sensitive categories;
• increased autonomy;
• new data source;
• change of model or provider;
• expansion into another country or sector;
• incident or complaints;
• evidence of unequal outcomes.

It is also documented when the assessment is not carried out, and on what grounds.

Step 1. Governance and scope

Before analysing impacts, the following is defined:

• system, version and owner;
• organisation and role;
• purpose and decision;
• lifecycle stage covered;
• locations and population;
• assessment team;
• approvers;
• sources and level of uncertainty;
• timeline and review.

The scope is not "the model". It includes data, interface, tools, people, procedure and downstream actions.

Step 2. Describe the system

The description must make it possible to understand:

• function and capabilities;
• inputs and outputs;
• models and algorithms;
• training, testing and operational data;
• dependencies and providers;
• deployment environment;
• oversight and autonomy;
• metrics and limits;
• interaction with other systems.

Versions are recorded. An assessment of an earlier model does not automatically cover a new integration.

Step 3. Purpose, uses and limits

It is worth distinguishing between:

• intended use;
• unintended but reasonably foreseeable use;
• misuse;
• use restricted by policy;
• use prohibited by law or risk.

Example: an HR assistant intended to answer questions on internal policy could be used to infer a person's performance. Even if that is not the intended purpose, if the use is foreseeable it must be assessed and, where appropriate, blocked.

Step 4. Affected parties

Not only direct users. The assessment may affect:

• people subject to the decision;
• people whose data trains the system;
• family members or third parties;
• under-represented groups;
• staff providing oversight;
• customers and suppliers;
• communities and society.

The differential impact is analysed. An average can hide harm concentrated in a specific group.

Where appropriate, affected people or their representatives are consulted. If no consultation takes place, this is documented, along with how their perspective was incorporated through other means.

Step 5. Benefits and harms

The assessment must consider both sides. Possible benefits:

• access to services;
• time savings;
• consistency;
• error detection;
• accessibility support;
• better resource allocation.

Possible harms:

• exclusion or discrimination;
• loss of autonomy;
• surveillance;
• error and difficulty of correction;
• privacy and security;
• manipulation;
• impact on employment;
• economic or reputational harm;
• environmental impact;
• technological dependence.

Harm to one group is not automatically offset by aggregate benefits. The distribution and severity of each impact must be assessed separately.

Step 6. Impact scenarios

A clear scenario follows a simple structure:

Because of cause, the system may event, affecting people, and leading to consequence.

Example: due to incomplete historical data, a system may score applications from a specific region lower, reducing their access to employment without explanation or effective review.

For each scenario, the following is recorded:

• lifecycle stage;
• cause and evidence;
• affected people;
• likelihood;
• severity and reversibility;
• existing controls;
• uncertainty;
• initial risk.

Step 7. Methods and evidence

Evidence can include:

• quantitative testing;
• group-based evaluation;
• red-teaming exercises;
• interviews and workshops;
• literature and prior incidents;
• data audits;
• usability testing;
• legal analysis;
• provider documentation.

Observed data is distinguished from assumptions. If the provider does not supply sufficient information, uncertainty increases and may justify additional limits on use of the system.

Step 8. Measures

Measures follow a hierarchy of action:

1. avoid the use or the function;
2. reduce scope or autonomy;
3. change the data, the model or the process;
4. add technical controls;
5. introduce oversight and redress;
6. inform and monitor.

A warning does not offset an inherently harmful design.

Each measure has an owner, deadline, evidence, indicator and expected effectiveness. Residual risk is reassessed after it is applied.

Human oversight and redress

Human intervention must have sufficient information, competence, time and authority. It is defined which decisions require prior review, sampling or dual approval.

Affected people need channels to:

• obtain information;
• correct data;
• provide context;
• challenge the decision;
• receive human review;
• obtain redress where appropriate.

What is measured is whether the channel works in practice, not just whether it exists on paper.

Decision and acceptance

The outcome of the assessment can be:

• approve;
• approve with conditions;
• limit the population or the function;
• pilot in shadow mode;
• request further evidence;
• redesign;
• do not deploy.

Acceptance of a high impact must sit with the defined level of authority. It is not tacitly delegated to the technical team.

Monitoring and review

Tracking indicators:

• errors by group;
• human overrides;
• complaints;
• decisions without explanation;
• improper access;
• distribution shifts;
• incidents;
• benefit actually achieved.

Review triggers: change of system, population, data, provider, law, context or risk. The assessment is versioned like any other living document.

Integration with ISO 42001

ISO/IEC 42001 establishes the management system; ISO/IEC 42005 goes deeper into the assessment of a specific system. The AI management system (AIMS) inventory can trigger and store 42005 assessments. Their results feed into risks, objectives, controls, audit and management review.

A parallel process is not created where product management already exists. The assessment is built in as a design and change gate within the existing system.

Minimum template

The standard's annexes offer template examples; the purchased edition should always be used.

30-day plan

Week 1

Scope, system description, assessment team and affected parties.

Week 2

Uses, benefits, harms and scenarios.

Week 3

Testing, consultation, evaluation and measures.

Week 4

Residual risk, decision, internal publication and monitoring.

The timeline varies depending on the system's complexity and the evidence available.

Common mistakes

1. Assessing only the model.
2. Including only direct users.
3. Listing risks without building scenarios.
4. Ignoring benefits and their distribution.
5. Treating uncertainty as absence of risk.
6. Adding warnings instead of redesigning.
7. Consulting once everything has already been decided.
8. Not linking measures to impacts.
9. Not defining a redress mechanism.
10. Not reviewing the assessment after a change.

Checklist

• Scope and version defined.
• Purpose, foreseeable and prohibited uses.
• Direct and indirect people identified.
• Benefits and harms distributed.
• Scenarios backed by evidence.
• Likelihood, severity and uncertainty.
• Measures with an owner and evidence.
• Effective oversight and redress.
• Formal decision and conditions.
• Monitoring and review.
• Coordination with the DPIA and the FRIA.

FAQ

Is ISO 42005 certifiable?

It is a guidance standard for carrying out assessments. It should not be presented as an independent certification of a system.

Does it replace the DPIA?

No. It can provide structure and evidence, but the DPIA has its own legal requirements that must be met independently.

Must the report be published?

It depends on the applicable obligation, internal policy and risk. At a minimum, there must be adequate transparency and documentation for accountability.

Are benefits also assessed?

Yes, together with harms and their distribution. An aggregate benefit does not erase serious harm suffered by a specific group.

Summum Calidad can integrate AI impact assessment into an AI management system (AIMS) aligned with ISO/IEC 42001 and coordinate it with privacy, security and the AI Act.