ISO 42001 Roles and Responsibilities: Who Owns the AI Management System

What the standard requires and what it leaves to you

ISO/IEC 42001 is a management system standard. It specifies requirements for establishing, implementing, maintaining and continually improving an AIMS, which ISO describes as a set of interrelated elements used to set policies and objectives, and the processes to achieve them, for the responsible development, provision or use of AI systems. It applies to organizations of all sizes and sectors.

Three expectations drive ownership. Top management provides leadership for the AIMS. Roles and authorities are defined and assigned. Operational controls are documented. ISO's own explainer lists defining roles and responsibilities for AI oversight among the practical first steps toward compliance.

The standard does not say which function or committee should hold the AIMS, and it does not prescribe technical controls. That decision belongs to the organization, and it has to be justified. Because ISO describes the AIMS as organization-wide, with accountability embedded across operations, ownership cannot default to one team. A security owner alone will miss impact assessment. A compliance owner alone will miss what engineering actually deploys.

Management-system ownership versus runtime control ownership

Most ownership gaps come from treating these as one job. They are different.

Management-system ownership covers the decisions that shape the AIMS: policy and objectives, scope, role assignment, risk assessment, AI system impact assessment, internal review and management review. These activities happen on a cycle, produce documents and records, and sit with top management and an AIMS owner or committee, supported by functional leads.

Runtime control ownership covers whether a written policy is applied to each AI interaction and tool call as it happens. It sits with the people who run the systems that models, agents and tools pass through, usually engineering and security. Its output is not a document but a record of what was permitted, changed, blocked or escalated.

When policies are written but not enforced at the level of individual interactions, the cause is usually that nobody was named as the runtime control owner. The AIMS owner assumed engineering handled it, and engineering assumed the policy was advisory. Naming that role explicitly closes the gap between assigned responsibility and producible evidence.

A practical responsibility matrix for the AIMS

Build the matrix with one row per accountability area. For each row, record the accountable role, the contributing functions, the clause reference from your licensed copy of the standard, and the evidence the role will produce. The rows below are a starting structure. The accountable assignments are examples to adapt, not requirements of the standard.

• Policy and objectives: Accountable: top management. Contributors: legal, compliance, security. Evidence: approved AI policy, stated objectives, records of management review.
• Roles and authorities: Accountable: top management, administered by the AIMS owner or committee. Evidence: documented role assignments, authority levels, and escalation and approval paths.
• Risk assessment: Accountable: risk or compliance lead. Contributors: security, data science, business units. Evidence: assessment records, risk criteria, treatment decisions.
• AI system impact assessment: Accountable: the owner of each AI system. Contributors: legal, data science. Evidence: completed assessments per system, with review dates and approvals.
• Operational control: Accountable: engineering and security, as runtime control owner. Evidence: documented controls plus records showing they were applied to actual AI use.
• Evidence and review: Accountable: AIMS owner or committee. Contributors: internal audit. Evidence: evidence inventory, internal audit results, corrective action records.

What can be enforced and evidenced at runtime

A runtime enforcement layer applies policy in the execution path of AI interactions and tool calls. Typical actions are allow, redact, block, rate limit and escalate for human approval. Where a control reduces to one of those actions, such as who may call a model or tool, what data may leave in a prompt, or which actions need a person's approval, enforcement can also produce a record of each decision. That record is evidence for the control it covers, and it exists because the control ran, not because someone reconstructed it later.

The limits matter for ownership. Enforcement covers controls that can be expressed as policy over an interaction. It does not set the AI policy, perform risk assessment, write the impact assessment, define role authorities or run management review. Those remain organizational processes with human owners. A responsibility matrix should mark each control as technically enforced, process-dependent, or both, and name the owner of each part.

The distinction also shapes audit conversations. Certification bodies audit AIMS under ISO/IEC 42006:2025, which sets additional requirements for those bodies. Expect auditors to compare what the matrix says each role owns with the records that role can actually produce. A runtime control with no named owner, or an owner with no records, is the kind of gap that surfaces.

Where Trussed fits

Trussed supports the operational control and evidence portion of an AIMS. It 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, at the level of individual interactions and tool calls. Enforcement generates continuous, audit-ready evidence, mapped to frameworks including the EU AI Act and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency.

Trussed does not certify an organization, replace the AIMS or assign its roles. Those remain with top management, the AIMS owner and the accredited certification body.