ISO/IEC 42005: the impact assessment method

Lesson 4 of 5 in AI Risk Management and Impact Assessment: ISO/IEC 23894 and 42005.

42001 clause 6.1.4 and control A.5 require an AI system impact assessment; they say strikingly little about how to do one. ISO/IEC 42005:2025 — published 28 May 2025 — fills that gap: a full method for assessing an AI system’s effects on individuals, groups of individuals, and societies.

The lens change from the last two lessons is total. Risk management asks what could go wrong, measured against our objectives. Impact assessment asks what does this system do to the people and communities it touches — including people who never chose to be touched. A job applicant screened out, a neighbourhood over-patrolled, an information ecosystem polluted: none of them appear on an organisational risk matrix until an impact assessment puts them there. And 42005 insists on symmetry: benefits are assessed alongside harms, because the honest case for a system matters when weighing what to do about its downsides.

When do you run one? At minimum: when a new AI system is proposed, and again on trigger events — a change of intended use or context, new user or affected populations, significant model or data changes, deployment into a new jurisdiction, or an incident that reveals the last assessment was wrong. 42005 also has organisations define sensitive or restricted uses — categories (children, health, credit, essential services, law enforcement) where assessment depth increases and certain uses are ruled out in advance rather than argued about system by system.

The 42005 impact assessment process

  1. Trigger

    New system, changed use or context, new population, significant model/data change, or a revealing incident. Organisations define these triggers in advance in the impact-assessment procedure (A.5.2).

  2. Document system & context

    What the system does, its intended use and foreseeable misuse, the data it consumes, where and by whom it will be deployed. An assessment of an undocumented system assesses a guess.

  3. Identify interested parties

    Individuals (users, subjects of decisions), groups (demographic subgroups, communities), and society at large. The parties most affected are routinely the ones with no seat in the room — name them explicitly.

  4. Assess benefits & harms

    Across dimensions including fairness, safety, privacy, environment, employment, human autonomy, and wellbeing — for each identified party. Benefits are claimed with evidence, not asserted.

  5. Rate severity & likelihood

    How bad, how reversible, how many people, how likely. Irreversibility and scale push severity up: a wrong movie recommendation and a wrong fraud accusation are not neighbours on any honest scale.

  6. Decide & document outcomes

    Proceed, proceed with changes and safeguards, or do not proceed. Record the reasoning — this record is what auditors sample under A.5.3 and what regulators increasingly expect to exist.

  7. Follow-up actions

    Mitigations feed the risk treatment plan; conditions feed monitoring; the assessment links into the risk register rather than filing itself away.

  8. Reassess on trigger

    The assessment is a living document with the same trigger logic as the risk register — context change reopens it.

Integration into the AIMS is exact, not vague. Clause 6.1.4 requires the impact assessment process at planning time; clause 8.4 requires performing assessments in operation — at planned intervals and on significant change, in lockstep with the risk cadence; controls A.5.2–A.5.5 make the process, its documentation, its individual/group scope, and its societal scope independently auditable. And the outputs flow back: harms identified in the impact assessment become risks in the register, mitigations become treatment actions, conditions become monitoring metrics under clause 9. One system, two lenses, shared plumbing.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.