ISO/IEC 42005 vs NIST AI RMF Map Function: Impact Assessment Crosswalk

What each framework is and how they relate

ISO/IEC 42005:2025, "Information technology — Artificial intelligence (AI) — AI system impact assessment", is a numbered ISO/IEC standard from JTC 1/SC 42. ISO describes it as a practical framework and detailed methodology for identifying, evaluating and documenting the impacts of individual AI systems. Its unit of analysis is the system.

The NIST AI Risk Management Framework (AI RMF 1.0) is intended for voluntary use. Its stated aim is to improve the ability to incorporate trustworthiness considerations into the design, development, use and evaluation of AI products, services and systems. Map is one function of its Core. The practices for mapping AI risks are described in the NIST AI RMF Playbook, which offers suggested actions rather than requirements.

ISO also positions 42005 alongside ISO/IEC 42001. In ISO's framing, 42001 makes impact assessments a consistent and required part of AI governance, and 42005 makes them thorough, systematic and actionable. An organization running 42001 can therefore treat it as the process that triggers and governs assessments, and 42005 as the method for performing them. Neither framework is presented here as a legal requirement. As of November 2026, whether either applies to a given organization depends on whether it adopts it.

Crosswalk by assessment element

The rows below follow the order of a typical impact assessment. The mapping note on each row says how to treat the correspondence. Map has a direct documented counterpart where the framework text says so, and elsewhere the row is a working hypothesis to confirm against the primary text of both documents.

• System description: Both expect the system to be described well enough to assess. Map anchors this in context establishment, including prospective settings of deployment. Mapping note: treat as an overlap, and record version and configuration of the system assessed.
• Intended use and context: MAP 1.1 covers intended purposes, potentially beneficial uses, context-specific laws, norms and expectations, and prospective deployment settings, all to be understood and documented. Mapping note: the clearest direct counterpart for a 42005 intended-use section.
• Affected stakeholders: An impact assessment must name who the system can affect, not only who operates it. Mapping note: link each stakeholder group in the 42005 output to the Map subcategory that addresses stakeholder consideration, and mark rows with no counterpart.
• Impact categories: The assessment records benefits and potential harms by category, such as individuals, groups and organizations. Mapping note: Map identifies impacts as part of mapping risk, so align category lists and flag categories one side omits.
• Risk determination: Both require a reasoned judgment about the significance of impacts. Mapping note: record the scoring or rating method used, since the two documents may not share one, and do not assume equivalence.
• Documentation outputs: 42005 produces documented assessments at system level. Map expects its outcomes to be documented, with the Playbook suggesting actions. Mapping note: for each output, list the Map outcomes it evidences.

Overlaps, gaps and structural differences

The overlap is strongest where Map asks for understood and documented context. System description, intended use and deployment setting can usually be satisfied by one well-kept record that cites both frameworks. Duplicating those sections is the most common source of wasted effort.

The differences are mostly structural. 42005 is a standard with a defined method, written around a single system. Map is a function within a risk management framework that organizations adopt voluntarily, and it points to the Playbook for suggested actions. A Map outcome can therefore be met in several ways, while a standard's method tends to prescribe how the work is done. Map sits beside Govern, Measure and Manage, so some of what an assessment produces will be used outside Map.

Crosswalks also have a stated limit. NIST's AIRC page lists a community-submitted ISO/IEC 42005 and AI RMF crosswalk dated August 14, 2025, and notes that listing does not imply NIST endorsement or that either resource comprehensively covers the other. Use it as a cross-check, not as the basis. In your own crosswalk, record which Map statements have a direct 42005 counterpart and which do not. Those unmatched rows are your gaps, and an auditor can read them as an honest scope statement.

Building a working crosswalk

A crosswalk is a maintained artifact with an owner. These steps keep it usable by an auditor.

• Start from primary texts: Work from ISO/IEC 42005:2025 and AI RMF 1.0 with the Playbook, not from third-party summaries.
• Fix the row structure: Use the assessment elements above so each row has one owner and one evidence location.
• Map outputs to outcomes: For every assessment output, list the Map outcomes it supports. Mark direct, partial or none.
• Treat the Playbook as suggestions: Cite Playbook actions as implementation choices, not obligations.
• Connect to 42001 where it exists: Record what triggers an assessment and who approves it.
• Version everything: Re-assess and update the crosswalk when the system, its deployment context or either framework changes.

What a documented assessment can and cannot show

An impact assessment records what was understood and decided at a point in time: the intended purpose, the settings in which the system will be deployed, who may be affected and how significant the potential harms are. That is valuable, and it is what both frameworks ask teams to produce.

It does not show that the system behaved as assessed once it ran. This is analysis rather than a requirement of either framework. A document cannot demonstrate that a prohibited data type never reached a model, that a high-impact action was reviewed by a person, or that a limit on use was respected in a given interaction. Reviewers of regulated AI systems tend to ask for both: the design-time reasoning and the runtime record. Keeping those two layers distinct in the crosswalk prevents an assessment from being offered as evidence of operation.

Turning findings into runtime policy and evidence

This section is the publisher's own educational analysis, not a framework requirement. Assessment outputs that Map expects to be documented, such as intended purpose, deployment setting and applicable laws and norms, are natural inputs for scoping runtime policy conditions. A finding that a system is approved for a stated purpose becomes a rule that allows matching interactions. A finding that a data category must not leave a given setting becomes a rule to redact or block. A finding that an action carries material impact on people becomes a rule to escalate for human approval before it proceeds.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions including allow, redact, block, rate limit and escalate for human approval. Its scope is individual interactions and tool calls. It is enforced at runtime, not reviewed after the fact, and the enforcement itself generates continuous audit-ready evidence mapped to NIST, among other frameworks. Trussed does not perform impact assessments. The assessment remains your process, and enforcement applies its conclusions.

For the crosswalk, add a column that links each assessment finding to the policy that implements it and to the evidence that policy produces. An auditor can then trace a documented harm to a rule, and the rule to records of its decisions.