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

Two standards, two different questions

ISO/IEC 42005:2025 is titled "AI system impact assessment". ISO/IEC 23894:2023 is titled "Guidance on risk management" for artificial intelligence, and ISO describes it as setting out processes for the effective implementation and integration of AI risk management. Both sit in the ISO/IEC JTC 1/SC 42 catalogue, and ISO lists both among its top AI standards.

Enterprises building programs aligned to ISO/IEC 42001 often fold both into a single "AI assessment" step. That tends to produce one of two failures. Either the same system is assessed twice by different teams with different templates, or one view is skipped and the gap only appears when someone asks for evidence.

The distinction below is a practitioner's working model, not a quotation from either standard. Impact assessment takes the perspective of those affected by the system: individuals, groups and society. Risk assessment takes the perspective of the organization: how uncertainty could affect its objectives, and what it will do about that. A single AI use case can carry a modest organizational risk and a significant impact on a particular group, or the reverse. Neither view substitutes for the other.

Side-by-side: how the two assessments differ in practice

The table summarizes the working model across the dimensions that matter for workflow design. Confirm exact scope, terms and expected outputs against the text of each standard before building templates around them.

• Assessment subject: Impact assessment: the AI system and its effects on individuals, groups and society. Risk assessment: uncertainty that could affect organizational objectives.
• Core question: Impact assessment: who could be affected, and how? Risk assessment: what could go wrong for the organization, how severe and how likely, and how will it be treated?
• Timing: Impact assessment: before deployment and again when the use, population or context changes materially. Risk assessment: continuing activity within the risk management process that ISO/IEC 23894 describes.
• Typical inputs: Impact assessment: intended use, affected parties, data and deployment context. Risk assessment: risk criteria, organizational objectives, existing controls and impact findings.
• Typical outputs: Impact assessment: documented impacts and mitigation requirements. Risk assessment: risk entries, owners, treatment decisions and accepted residual risk.
• Link to runtime: Impact assessment: conditions on data, users, use cases and human oversight. Risk assessment: access limits, thresholds and escalation criteria.

Which findings can become runtime policy, and which cannot

Runtime enforcement operates on individual interactions and tool calls. It can act only on conditions that are specific and machine-checkable: the type of data in a prompt or response, which tool an agent is calling, the role of the user, or a threshold on an action. Findings that fit that shape can be written as policy with outcomes such as allow, redact, block, rate limit, or escalate for human approval.

Examples of translatable findings: "personal health data must not leave a defined boundary" becomes a redact or block condition. "Payments above a set value need a person to approve" becomes an escalation. "This assistant may not call a given external tool" becomes a block. These can come from either assessment, so each rule should carry a reference to the finding behind it.

Many findings will not translate. Judgments about societal effect, fairness across groups, or whether a use case should exist at all are qualitative. They need human review, design changes or management decisions. A runtime layer should not be presented as covering them. It also does not replace performing either assessment, because the assessments sit outside the execution path.

Evidence follows the same logic. Each enforced decision can be recorded against the interaction or tool call, with the policy version applied, the assessment finding it traces to, and any human approval outcome. That lets a reviewer see which conclusion governed a decision at the time it was made. Evidence for the findings that cannot be enforced, such as review minutes or acceptance decisions, must still be kept in the assessment process itself.

Ownership and regulatory context

Neither standard settles who in your organization owns what, so this is a design decision. A common split is that the AI system owner and a product or ethics function lead the impact assessment, while risk management leads the risk assessment, with security and compliance owning the controls that result. Whatever the split, assign one owner for the shared intake record and one for the mapping from findings to enforced policy. Unowned handoffs are where the weak linkage to runtime evidence appears.

On EU timing, as of November 2026, the Digital Omnibus on AI has entered into force, on 27 July 2026. It moved the application dates for the AI Act high-risk rules to 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI embedded in products. The AI Act can also be amended by delegated and implementing acts, so regulatory references in your assessment templates should carry a review date.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, scoped to individual interactions and tool calls. It applies allow, redact, block, rate limit and escalate for human approval at runtime, not after the fact, and generates audit-ready evidence from that enforcement, mapped to frameworks including the EU AI Act and NIST. It does not perform impact or risk assessments. Its role begins once an assessment has produced conditions specific enough to enforce.