Linking ISO/IEC 42005 AI System Impact Assessments to the ISO/IEC 42001 AI Risk Assessment Process

How the two standards relate

ISO/IEC 42001:2023 is a management system standard. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and it encourages organizations to run AI risk assessments and define risk treatment activities at regular intervals. ISO/IEC 42005:2025 is guidance for AI system impact assessment. It focuses on how an AI system and its foreseeable applications may affect individuals, groups or society at large.

ISO describes the two as designed to work hand in hand: 42001 supplies the organization-wide policies, procedures and accountability, and 42005 supplies a framework for identifying, evaluating and documenting AI system impacts. ISO also states that 42005 complements 42001, ISO/IEC 38507 and ISO/IEC 23894.

The NIST crosswalk to 42001 lists AI risk assessment, AI risk treatment and AI system impact assessment as separate reference items. That separation is useful. It means the impact assessment is its own process, and the link to the other two has to be designed deliberately rather than assumed. When it is not designed, the usual result is separate templates, separate owners and a risk register that never sees the impact findings.

Where scope and perspective differ

The two exercises answer different questions, which is why one cannot simply replace the other. The table summarizes the distinction that the integration has to respect.

• Primary question: Impact assessment: how could this AI system affect people and society? Risk assessment: how could AI risks and opportunities affect the organization's objectives?
• Perspective: Impact assessment: individuals, groups and society. Risk assessment: the organization and its management system.
• Unit of analysis: Impact assessment: a specific AI system and its foreseeable applications. Risk assessment: the portfolio of AI activities, with entries that may span systems.
• Typical output: Impact assessment: stakeholders, potential harms, severity and likelihood considerations, mitigations. Risk assessment: rated risks, a treatment plan and selected controls.
• Lifecycle role: Impact assessment: design through post-market monitoring, updated as needed. Risk assessment: repeated at regular intervals within the Plan-Do-Check-Act cycle.

Triggers, ownership and cadence

ISO/IEC 42005 recommends assessing throughout the AI system lifecycle, from design and development through deployment and post-market monitoring, and updating the assessment as needed. The phrase "as needed" has to be made concrete locally. Examples of triggers worth defining are a new use case, a material change to the model or its configuration, a new category of data, a new user population, a change in deployment context, and an incident, complaint or monitoring finding. Each trigger should name who raises it and who decides whether the impact assessment, the risk assessment, or both must be redone.

Ownership should sit inside the accountability structure the management system already defines. A workable split is that the system owner owns the impact assessment, the risk function owns the register and rating method, and a named person owns the hand-off between them. Decide in advance how disagreements about ratings are resolved and who has the final call. Document the escalation path so it is not improvised during an audit.

On cadence, set the impact reassessment interval to match or precede the risk review cycle, so the register is never reviewed against stale impact findings. No interval is mandated in the material this guide draws on, so choose one based on system criticality and record the rationale. Official implementation guidance for 42001 (ISO/IEC AWI 42003) is still under development as of November 2026, so your own documented reasoning matters.

Keeping ratings consistent and traceable

Inconsistent ratings are a common symptom of running the two exercises apart. If impact severity uses a five-point numeric scale and the risk register uses red, amber and green, the same harm can land at different levels depending on who rated it. NIST guidance describes a typical approach of combining impact and likelihood into a risk score, and notes that impact assessments help in understanding the severity of mapped risks. Adopting one shared scale, or a documented conversion between scales, is a sound design choice. It is an inference from that guidance, not a requirement of either ISO standard.

The tradeoff is that organizational risk and human impact are not the same thing. A harm to individuals may carry a modest organizational rating yet still demand treatment. Record both the impact severity and the organizational rating on the register entry, and require a stated justification when the treatment decision follows the lower of the two.

Published crosswalks, such as the one between ISO/IEC 42005 and the NIST AI RMF and the NIST crosswalk to 42001, are reasonable starting points for vocabulary. Treat them as indicative, not as authoritative clause mappings, and verify against the standards' full text before using them as audit artifacts.

Where runtime enforcement fits as a treatment

Some identified impacts can be treated by enforcing policy on individual interactions and tool calls while the AI system is running. Examples include redacting personal data before it reaches a model, blocking a category of tool call, rate limiting, or requiring human approval before a high-impact action proceeds. Others, such as design changes, data quality work or stakeholder consultation, cannot be treated this way and need different controls.

For the impacts that can, Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It can allow, redact, block, rate limit or escalate for human approval, and the enforcement itself generates audit-ready evidence. That evidence is what a register entry can point to as proof that a selected control operated on real traffic. Trussed does not perform impact assessments or maintain the risk register, and it does not provide transaction-level governance across tasks and agents. Its role is the control and evidence step at the end of the chain described above, scoped to individual interactions and tool calls.