ISO/IEC 42005 vs ISO/IEC 23894: Impact Assessment vs Risk Assessment

Two assessments, two different questions

ISO/IEC 42005:2025 is titled AI system impact assessment. ISO describes it as a framework for identifying, evaluating and documenting the impacts of AI systems, and as a methodology for assessing the effects of individual AI systems. Its subject is therefore the AI system, and ISO states that it focuses specifically on societal and human impacts.

ISO/IEC 23894:2023 is titled Guidance on risk management for artificial intelligence. ISO also describes it as covering the processes for effectively implementing and integrating AI risk management. Its emphasis is the management process around AI risk, not a single system's effects on people.

A useful working distinction for program design is this. Impact assessment asks what the system could do to the people and communities it touches. Risk assessment asks how uncertain events could affect what the organization is trying to achieve, and what to do about them. The two questions overlap, because a harm to people is often also an organizational risk. They are not the same question, and answering one does not answer the other.

ISO/IEC 42005 and ISO/IEC 23894 side by side

The rows below separate what the standards' published descriptions state from the working framing many programs use when assigning ownership and triggers.

• Title: 42005: AI system impact assessment (2025). 23894: Guidance on risk management (2023).
• Subject: 42005: the individual AI system and its effects. 23894: AI risk management and its integration into organizational processes.
• Emphasis: 42005: societal and human impacts. 23894: managing AI risk as a repeatable process.
• Role relative to ISO/IEC 42001: 42005: supplies the method for impact assessment, which 42001 makes a required part of governance. 23894: AI risk management guidance that sits alongside the management system.
• Working question: 42005: who or what could be affected, and how? 23894: what could go wrong for the organization's objectives, and how is it treated?
• Typical output in practice: 42005: documented impacts and conclusions per system. 23894: risk treatment decisions. Programs define the exact formats themselves.

How they relate to ISO/IEC 42001 and the NIST AI RMF

ISO states that ISO/IEC 42001 ensures impact assessments are a consistent and required part of AI governance, while ISO/IEC 42005 ensures those assessments are thorough, systematic and actionable. ISO also says 42005 complements ISO/IEC 42001, ISO/IEC 38507 on AI governance, and ISO/IEC 23894 on AI risk management. The standards are meant to be used together. A program that treats them as alternatives will either skip one question or ask both twice.

For teams that also use the NIST AI RMF, the NIST AI Resource Center lists community crosswalks for both ISO/IEC 23894 and ISO/IEC 42005, each dated August 14, 2025 and submitted by INCITS/AI. These are community-submitted documents, not official NIST guidance. The 42005 crosswalk was written against the draft text (ISO/IEC DIS 42005), so check any mapping against the published 2025 standard before relying on it.

Separating triggers, owners and records

Duplicated assessments usually come from unclear triggers and ownership. The standards do not prescribe a single answer, so each organization should define its own criteria and write them down.

Start with triggers. Decide which events start an impact assessment, such as a new AI system, a new use case or a change in who is affected. Decide separately which events start or update a risk assessment. Many events will trigger both, and that is acceptable as long as each assessment has a distinct purpose and a distinct output.

Next, assign owners by decision rights, not by document. Someone must be accountable for concluding what impacts are acceptable for a system, and someone must be accountable for risk treatment decisions. These may be the same function in a small program and different functions in a large one.

Finally, record which assessment produced each requirement. If a restriction on a system came from an impact assessment and a control came from a risk treatment decision, say so. That tag is what lets you trace operating evidence back to its origin later.

• Define impact assessment triggers and risk assessment triggers separately
• Assign accountability for impact conclusions and for risk treatment decisions
• Tag every requirement with the assessment that produced it
• Define what happens when a system's use, data or model changes after assessment

Turning conclusions into enforceable requirements

An assessment is a document until its conclusions change what the system is permitted to do. The gap between a completed assessment and runtime behavior is where auditors and regulators tend to ask hard questions: what did the assessment conclude, what was the system allowed to do, and what did it actually do?

Some conclusions can be written as policy applied to individual interactions and tool calls. A restriction on the data a system may process can become a rule to redact or block certain content. A limit on which tools an agent may call can become an allow or block decision at the tool call. A requirement for human oversight on consequential actions can become an escalation for human approval before the action proceeds.

Other conclusions cannot be reduced to per-interaction rules. Decisions about whether to deploy at all, how affected communities are consulted, how training data was selected, or how incidents are reviewed remain organizational and process controls. Classify each conclusion explicitly as runtime policy or process control, so nothing is assumed to be enforced when it is only documented.

This is where Trussed fits. Trussed does not perform impact or risk assessments. It enforces policy in the execution path across models, agents, tools and MCP servers, with decisions to allow, redact, block, rate limit or escalate for human approval, scoped to individual interactions and tool calls. Requirements are enforced at runtime, not reviewed after the fact.