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

What each standard covers

ISO/IEC 42005:2025 is titled AI system impact assessment. ISO says it gives guidance to organizations that carry out these assessments, and describes it as a methodology for identifying, analyzing and documenting the effects of individual AI systems. ISO also says it focuses specifically on the societal and human impacts of AI.

ISO/IEC 23894:2023 is guidance on risk management. ISO describes it as setting out processes for the effective implementation and integration of AI risk management. It is a process standard for managing AI risk. It is not a method for documenting what one system does to the people it touches.

Regulated enterprises often merge the two. The usual results are duplicated work, gaps where each team assumes the other has the topic covered, and no clean answer when an auditor asks how the two records relate. A useful working distinction, which is our reading rather than standard text, is that impact assessment looks outward at effects on individuals, groups and society, while risk assessment looks at what could go wrong for the organization's own objectives. Both can name the same hazard, such as a biased output, but they ask different questions and produce different records.

Side-by-side comparison

The rows on focus and relationship follow ISO's descriptions. The rows on unit of analysis, output and ownership reflect common practice rather than standard text, and should be adapted to your own management system.

• Primary question: 42005: What effects does this system have on people and society? 23894: What risks arise, and how are they managed against our objectives?
• Perspective: 42005: Outward, on societal and human impacts. 23894: Organizational, through a risk management process.
• Unit of analysis: 42005: An individual AI system. 23894: A process applied across the organization and its AI systems.
• Typical output: 42005: Documented impact findings per system. 23894: Risk register entries, treatment decisions and monitoring records.
• Typical owner: 42005: Product or system owner with domain and affected-party input. 23894: Risk function with control owners.
• Relationship to ISO/IEC 42001: 42005: Method for meeting the impact assessment requirement. 23894: Complementary risk management guidance.

How both relate to ISO/IEC 42001

ISO's own characterization is that ISO/IEC 42001 ensures impact assessments are a consistent and required part of AI governance, while ISO/IEC 42005 ensures they are thorough, systematic and actionable. In practice, 42001 sets the expectation at the management system level and 42005 supplies the system-level method for meeting it. ISO/IEC 23894 sits alongside as the risk management guidance, and ISO lists all three, with ISO/IEC 38507 on AI governance, as complementary.

That layering shapes how to present the work to an auditor. The management system should show that impact assessment is required and who is accountable for it. Each system should then carry its own impact record and its own risk record. The auditor's question is usually about the links: which impact findings fed the risk assessment, which risks prompted a closer look at impact, and which requirement each record satisfies. Teams that already align to the NIST AI RMF can also find public crosswalks for both standards, submitted by INCITS/AI in August 2025, though these should be reviewed before being relied on.

Sequencing, ownership and reassessment

The standards as described by ISO do not prescribe an order, so the following is editorial judgment. Start with impact screening when a system is scoped, because it identifies affected parties and the kinds of harm that matter. Carry those findings into the risk assessment as inputs, where they are rated, treated and assigned to control owners. Then feed risk treatment decisions back so the impact record reflects what was actually mitigated.

Ownership should be explicit for each record, with a defined path for disagreements. Impact and risk views will sometimes diverge, and a harm that is tolerable to the organization may still be unacceptable to the people affected. Reassessment should be tied to events, not only calendars. Material changes to the model, data, purpose, user population or connected tools are the obvious candidates, along with incidents. Use the criteria below to judge whether your program is ready.

• Both records use the same system identifier, so they can be retrieved together.
• Each assessment has a named owner and a stated escalation path.
• Findings are cross-referenced in both directions between impact and risk records.
• Reassessment events are defined, including material change and incidents.
• Every finding has a recorded disposition: accept, mitigate, or do not proceed.
• Each mitigation is classified as design-time, procedural, or enforceable at runtime.

From assessment output to runtime policy and evidence

The following mapping is inference, not text from either standard. Some findings translate directly into requirements that can be enforced while a system operates. A finding that certain data classes must not reach a model becomes a redaction or block requirement. A finding that a tool must not take a particular action becomes a block rule. A finding that a consequential action needs a person's sign-off becomes an escalation for human approval. Other findings cannot be enforced at runtime. Whether to deploy a use case at all, how training data was composed, and how affected parties were consulted remain design and governance matters.

There is a tradeoff in the translation. Impact assessment works at the level of a system, while runtime policy acts on individual interactions and tool calls. Some nuance is lost when a finding becomes a rule. Keep the rule traceable to the finding it came from, so a reviewer can follow the chain from assessment to control.

As general practice, auditors look for the assessment records, the approvals and decisions that followed, and proof that controls operated as intended. A policy that exists only in a document is weak evidence. A policy that was applied at runtime, with a record of each decision, is stronger. Judge your own outputs on one test: for each finding that claims a runtime control, can you show the rule, the version in force, and what it did on a given date?

Where Trussed fits

Trussed does not perform impact assessments or risk assessments. It acts on their outputs. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions that include allow, redact, block, rate limit, and escalate for human approval. The scope is individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact.

That enforcement produces continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. It has run in continuous production in a regulated enterprise for 18+ months and supports 100+ models under one policy plane. For a risk leader, the practical role is narrow: once your assessments produce requirements that can be enforced, Trussed applies them in the path and records what was allowed and what happened.