ISO/IEC 42005 AI System Impact Assessment: An Implementation Guide
ISO/IEC 42005:2025 provides guidance for assessing the impact of an AI system on individuals, groups and society. It is not a checklist, so each organisation has to turn it into a repeatable procedure: scope the system, identify stakeholders and uses, analyse benefits and harms, assign owners, document the result and define when to reassess. The conclusions are only useful if they become controls that apply to actual AI behavior.
- 1
1. Scope the assessed system
Input: architecture, model and tool inventory, data flows. Output: a system boundary statement and version identifier. Owner: system owner.
- 2
2. Identify stakeholders and uses
Input: scope statement, user and process maps. Output: affected parties plus intended, foreseeable and out-of-scope uses. Owner: product owner with domain leads.
- 3
3. Analyse benefits and harms
Input: stakeholder and use lists, known limitations. Output: a register of potential benefits and harms with likelihood, severity and affected groups. Owner: assessment lead.
- 4
4. Decide treatments and ownership
Input: the harm register. Output: accepted, mitigated or prohibited outcomes, each with a named control owner. Owner: governance or risk committee.
- 5
5. Document and approve
Input: all prior outputs. Output: a versioned assessment record with approver, date and open actions. Owner: AI governance lead.
- 6
6. Set reassessment triggers
Input: the approved record. Output: defined events and a review interval, wired to change management. Owner: system owner.
- 7
Allow
Use falls within the assessed and approved scope.
- 8
Redact
Sensitive data is removed before it reaches a model or tool.
- 9
Block
The use or action was assessed as unacceptable.
- 10
Escalate
A consequential action waits for named human approval.
Evidence to be able to produce for each assessed system
- The versioned assessment record with scope, uses, harm register and approval trail
- A mapping from each treatment decision to a named policy rule and version
- Per-interaction records showing the action taken: allow, redact or block
- Per-tool-call records, including human approval where escalation applied
- A change history for policy rules, with approver and date
- Documented reassessment triggers and the events that invoked them
What the standard is and where it sits
ISO/IEC 42005:2025, titled AI system impact assessment, is part of the ISO/IEC JTC 1/SC 42 family of AI standards. It sits alongside ISO/IEC 42001:2023, the AI management system standard, and ISO/IEC 42006:2025, which sets requirements for bodies that audit and certify AI management systems. The distinction matters for planning. ISO/IEC 42005 is guidance on how to carry out an assessment. The audit and certification rules belong to a different document, so an impact assessment should not be described as certified or as proof of compliance.
The practical relationship is that the management system defines the organisational machinery, such as roles, records and review cycles, while the impact assessment is the system-level analysis that feeds it. Treat the assessment as an input to your management system records, and align its owners, approval points and document control with them.
Regulatory context is a second reference point, not an equivalent. Regulation (EU) 2024/1689, the AI Act, subjects high-risk AI systems to obligations that include adequate risk assessment and mitigation systems. As of November 2026, the Commission's Digital Omnibus on AI proposal would set 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for high-risk systems embedded in products, and the dates could still change. Following ISO/IEC 42005 does not by itself satisfy any AI Act obligation.
Documentation and reassessment decisions
A defensible record answers four questions without needing the author in the room: what was assessed, who was considered, what was concluded and who accepted it. Keep the system version, the list of intended and foreseeable uses, the harm and benefit analysis, the rationale for each treatment decision, and the approval trail together in one controlled document. Reference, rather than duplicate, related risk and management system records.
Reassessment is the step teams most often leave vague. Define triggers in your own procedure and tie them to events you can actually detect. Common candidates include a change of model or model version, a new tool or data source connected to the system, a new user population or use case, a material incident or complaint, and a change in applicable regulation. Add a periodic review as a backstop. Triggers that depend on someone remembering to ask will not fire reliably, so connect them to release and change workflows.
The main tradeoff is depth versus cadence. A heavyweight assessment on every change will be skipped. Many organisations use a short delta review for minor changes and a full reassessment when scope, uses or affected groups change.
Mapping outputs to the AI Act and NIST AI RMF
Impact assessment outputs are reusable evidence for other frameworks, provided the mapping is stated as your interpretation. The harm register and treatment decisions can support the risk assessment and mitigation expectations that the Commission describes for high-risk systems under the AI Act. The stakeholder analysis can feed any assessment of effects on people's rights that your legal team determines applies to a given deployment.
For the NIST AI RMF, the same record can inform how you map, measure and manage risk for a system. Keep a simple crosswalk table in your governance documentation, with one row per assessment output and the obligation or framework function it supports. Have counsel confirm which obligations apply to each system and when. The crosswalk shows traceability, not conformity.
From assessment to evidence
Scope
Define the system, its boundaries and its intended and foreseeable uses.
Assess
Analyse benefits and harms for affected individuals, groups and society.
Decide
Assign owners, approve treatments and record the decision.
Enforce and evidence
Express constraints as policy and retain records of how they were applied.
Connect assessment conclusions to enforced policy
Talk to an expert about expressing impact assessment findings as policy enforced at runtime, with audit-ready evidence for each interaction and tool call.
Talk to an ExpertHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.