ISO/IEC 42005 Impact Assessment Roles and Responsibilities: Ownership, Sign-Off and RACI

What the standards fix and what your organization decides

ISO/IEC 42005:2025 is the standard for AI system impact assessment. ISO describes it as a methodology for identifying, analyzing and documenting the effects of individual AI systems on people and society, and it recommends performing assessments from design and development through deployment and post-market monitoring, updating them as needed. It applies to any organization that develops, provides or uses AI systems, regardless of sector or size.

ISO positions ISO/IEC 42001 as the management-system layer. In ISO's framing, 42001 makes impact assessment a consistent and required part of AI governance, while 42005 makes the assessment thorough, systematic and actionable. The two link organizational oversight with system-level evaluation. 42001 also expects defined responsibilities for AI use and defined roles and responsibilities for AI oversight.

Neither description gives you job titles. Which function owns the assessment, who approves it and how authority is delegated are organizational choices. Make them deliberately and write them into AIMS policy. NIST AI RMF GOVERN 3.2 points the same way, calling for policies and procedures that define and differentiate roles and responsibilities for oversight of AI systems.

Separate accountability for the assessment from accountability for the system

Two accountabilities are often collapsed into one, and that is where sign-off problems start. The AI system owner, typically a product or business owner, is accountable for the system: its purpose, its deployment and the decision to operate it. The assessment owner is accountable for the quality of the assessment: that scope is right, impacts are identified with a broad set of perspectives, analysis is defensible and conclusions are documented.

When the same person holds both, the assessment tends to justify a decision already made. When the system owner has no role at all, the assessment becomes disconnected from deployment decisions. A workable pattern is for an AI governance or risk function to own the assessment, the system owner to be responsible for supplying system facts and implementing mitigations, and a separate approver to accept residual risk.

NIST AI RMF states that the decision to commission or deploy an AI system should rest on a contextual assessment of risks, impacts, costs and benefits, informed by a broad set of interested parties. The assessment feeds the deployment decision, but it does not replace it.

A starting RACI by assessment lifecycle stage

The table below is a template. A = accountable, R = responsible, C = consulted, I = informed. Rename roles to match your organization, and keep exactly one A per stage.

• Scoping: A: AI governance or risk lead. R: AI system owner. C: legal, privacy, security. I: executive management. Scope should include downstream and third-party components such as plugins.
• Stakeholder and impact identification: A: AI governance or risk lead. R: assessment team with technical, human factors and socio-cultural expertise. C: legal, privacy, affected-party representatives. I: AI system owner.
• Analysis: A: AI governance or risk lead. R: assessment team. C: security, compliance, technical leads. I: AI system owner. Evaluate likelihood and magnitude of each identified impact.
• Mitigation decisions: A: AI system owner. R: engineering, security, privacy. C: AI governance or risk lead, legal, compliance. I: approver.
• Approval: A: approver with delegated authority over residual risk. R: AI governance or risk lead, who prepares the approval package. C: legal, compliance. I: executive management, AIMS owner.
• Monitoring and reassessment: A: AI system owner for monitoring, AI governance or risk lead for the reassessment decision. R: operations, security. C: legal, privacy, compliance. I: approver.

Sign-off authority, escalation and what approvers need to see

Approval authority should be explicit and delegated, not assumed. NIST Playbook questions ask which roles, responsibilities and delegated authorities apply to personnel in design, development, deployment, assessment and monitoring. Use them as a checklist when naming approvers. Define the level of residual risk each approver can accept, and what happens when a conclusion exceeds that level. A common escalation path runs from the system-level approver to a risk committee or executive management, with the decision recorded in the AIMS.

The approver should never be asked to sign a conclusion they cannot examine. Require a package that lets them stand behind the result. Where an item is missing, the approver should return the assessment, not sign with caveats nobody tracks.

• Scope statement covering the system, its intended use and its downstream and third-party components
• Stakeholder input and the list of identified impacts, with who was consulted
• Analysis of likelihood and magnitude for each impact, and the reasoning behind it
• Mitigation decisions with named owners, and the residual risk that remains
• Monitoring plan, review frequency and defined reassessment triggers
• Record of consultation outcomes from legal, privacy, security and compliance

Assign reassessment triggers and monitoring in policy

Because 42005 recommends updating assessments as needed, someone must decide when an update is needed. Put that decision on a named role, and write the triggers into policy rather than leaving them to judgment in the moment. The specific triggers are yours to define. Typical candidates include a change in intended use, a material change to the system or its components, a new third-party plugin or tool, reported errors or incidents affecting people, and findings from monitoring.

NIST guidance supports this structure. MEASURE 1.2 calls for regularly assessing the appropriateness of metrics and the effectiveness of existing controls, including reports of errors and potential impacts on affected communities. The GenAI profile asks for periodic review of the risk management process, with roles and the frequency of review clearly defined. Assign monitoring to the system owner, since they operate the system, and assign the reassessment decision to the assessment owner, so that a team under delivery pressure does not decide alone that nothing has changed.

Connecting assessment conclusions to controls that run with the system

The weakest point in many programs is the gap between a signed assessment and what the system does in production. A mitigation written in a document is a commitment, not a control. The mitigation decisions stage should therefore record, for each mitigation, how it will be enforced and who is responsible for it, and the monitoring stage should check that it is operating.

This is where runtime policy enforcement is relevant. Trussed enforces policy in the execution path for models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls. A mitigation such as "personal data must not leave the system" or "this tool call requires human approval" can be expressed as policy that is enforced at runtime, not reviewed after the fact. Escalation to human approval also gives the RACI a concrete operating point for the roles you named.

Enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST and the EU AI Act. Approvers can examine it when deciding on reassessment, and auditors can examine it to see what the system was allowed to do and what it did. Trussed does not perform or replace the impact assessment. The assessment remains your organization's judgment, owned and approved by the roles above.