An ISO 42001 program stalls most often not because nobody understands the standard, but because nobody can say, without checking, who owns the AI risk register, who signs the Statement of Applicability, or who is accountable when an Annex A control lapses. ISO/IEC 42001:2023 requires an organization to assign roles and responsibilities for its AI management system directly, under Clause 5.3, but the standard does not hand over an org chart. Building that operating model is the organization’s job, and getting it wrong is one of the most common reasons an AIMS looks complete on paper and falls apart the first time an auditor asks who actually does the work.
This article builds a practical RACI structure for an AIMS, clarifies what ISO 42001 itself requires versus what is common implementation practice, and walks through where ownership typically breaks down when this is left informal.
What ISO 42001 Actually Requires on Roles
ISO/IEC 42001 follows the same Harmonised Structure used across ISO management system standards, with Clauses 4 through 10 forming the mandatory requirements and Annex A providing a reference set of controls organizations select based on applicability. Clause 5.3, Roles and Responsibilities, sits inside the Leadership section of that structure, and it requires top management to assign and communicate responsibilities and authorities for roles relevant to the AI management system. That is the extent of what the standard mandates directly: assign the roles, communicate them, and make sure they are understood. It does not name specific titles, and any org chart implementing this clause is the organization’s own design choice, not a template copied from the standard’s text.
A Requirement Unique to ISO 42001
One clause-level requirement is worth calling out specifically because it does not have a direct equivalent in ISO 27001 or most other management system standards. As part of establishing the AIMS scope, an organization must formally determine its own role with respect to the AI systems inside that scope, distinguishing whether it is developing, providing, or using AI, since the obligations attached to each of those roles differ. This organizational role determination is a separate question from the individual roles and responsibilities Clause 5.3 requires internally, and conflating the two is a common early mistake. Get the organizational role wrong at the scoping stage, and the internal RACI built on top of it inherits the error.
Where This Article’s RACI Terminology Comes From
The role titles used through the rest of this article, AI Governance Body, AI Risk Owner, AIMS Program Owner, and Control Owner, are common implementation practice, not verbatim language pulled from the standard’s text. ISO 42001 requires that these functions exist and are assigned; it does not require these specific names. An organization already using different titles for equivalent functions does not need to rename anything to satisfy Clause 5.3, provided the underlying accountability is clear and documented.
Building the AIMS RACI: Roles Defined
A workable AIMS RACI needs a small number of clearly bounded roles rather than a long list that dilutes accountability. Five roles cover most of what a mid-sized organization’s AIMS actually requires.
Top Management
Top management holds ultimate accountability for the AIMS under Clause 5.1, including approving the AI policy, committing resources, and demonstrating leadership commitment during management review. This role cannot be delegated away entirely, even in organizations that appoint a dedicated AI governance lead, because certain accountabilities, particularly policy approval and resource commitment, are explicitly leadership functions under the standard’s structure. Demonstrating that commitment in practice means more than a signature on the policy document. It shows up in management review meetings where leadership actually engages with risk treatment status and audit findings rather than rubber-stamping a summary slide, and in resourcing decisions that follow through when the AI Governance Body identifies a genuine gap requiring budget or headcount to close.
AI Governance Body
Most organizations implementing ISO 42001 establish a cross-functional body, sometimes a committee, sometimes a smaller working group depending on organizational size, that holds day-to-day oversight of the AIMS on top management’s behalf. This body typically owns the AI policy’s ongoing currency, coordinates the risk assessment and treatment process, and serves as the escalation point when a control owner identifies a gap that needs a decision above their own authority. In smaller organizations, this function sometimes collapses into a single AIMS Program Owner rather than a formal committee, which is acceptable as long as the accountability is documented rather than assumed.
AI Risk Owner
The AI Risk Owner, which may be an individual or a role held collectively by the governance body depending on organizational scale, is accountable for the AI risk assessment and treatment plan Clause 6.1 requires, including ensuring identified risks are tracked to resolution rather than logged and forgotten. This role is distinct from a control owner, because a risk can span multiple controls and multiple systems, and someone needs to own the risk itself rather than only the individual mitigations underneath it.
AIMS Program Owner
The AIMS Program Owner runs the operational machinery of the management system: maintaining the Statement of Applicability, scheduling and tracking internal audits, preparing management review inputs, and keeping the documented information the standard requires current and accessible. This role is often the actual day-to-day driver of certification readiness, even though it typically does not hold the same authority as top management or the governance body to make policy-level decisions.
Control Owners
Each applicable Annex A control needs a named owner accountable for that control’s operation and evidence, not a general statement that “the team” is responsible. Control ownership is where AIMS programs most often go vague, because a control like lifecycle management or data governance can plausibly involve several functions, and without a single named owner, evidence collection becomes nobody’s specific job when an audit approaches.
The RACI Matrix Across Key AIMS Activities
The table below maps the five roles against the recurring activities an AIMS generates, using standard RACI notation: Responsible for doing the work, Accountable for the outcome, Consulted before a decision, and Informed after it.
| Activity | Top Management | AI Governance Body | AI Risk Owner | AIMS Program Owner | Control Owners |
|---|---|---|---|---|---|
| AI policy approval | A | R | C | I | I |
| AI risk assessment and treatment | I | A | R | C | C |
| Statement of Applicability | I | A | C | R | C |
| Annex A control operation | I | I | C | C | R/A |
| Internal audit | I | I | I | R/A | C |
| Management review | R/A | C | C | C | I |
Reading this table, a few patterns are worth naming directly. Top management is Accountable for the policy but Responsible for very little day-to-day work, which is correct: their job is commitment and decision-making at the highest level, not execution. The AIMS Program Owner is Responsible for the Statement of Applicability but only Consulted on individual risk decisions, because maintaining the document is different from deciding what belongs in it. Control Owners carry both Responsible and Accountable for their own controls, which is the design choice that prevents evidence gaps: a control without a single accountable owner is a control an audit will find undocumented.
Where This Differs by Organization Size
A small organization pursuing its first ISO 42001 certification often cannot staff five distinct roles with five distinct people, and that is not a failure of the model. The AI Governance Body function frequently collapses into the AIMS Program Owner in smaller organizations, and a single person may hold both the AI Risk Owner role and several Control Owner assignments simultaneously. What matters is that the RACI is documented explicitly even when roles are combined, so that an auditor can see the accountability was assigned deliberately rather than left implicit because the organization is small.
Mapping Ownership Across Annex A’s Nine Control Categories
Annex A organizes its 38 controls into nine categories, and a RACI built only around the five governance roles above still needs to answer a more specific question: who actually owns each category of control day to day. This is where the RACI stops being an abstract governance exercise and becomes a working document that survives contact with an audit.
Where Functional Ownership Typically Sits
Annex A’s categories span AI policies, internal organization, resources for AI systems, assessing impacts of AI systems, AI system life cycle, data for AI systems, information for interested parties, use of AI systems, and third-party and customer relationships. In practice, ownership of these categories rarely sits with a single function. Policy and internal organization controls tend to sit closest to the AI Governance Body itself, since they are governance artifacts rather than technical implementations. Life cycle and data controls usually sit with the engineering or data science function actually building and operating the AI systems, because that function holds the operational knowledge needed to produce credible evidence. Third-party and customer relationship controls often sit with procurement or legal, since they govern contractual and vendor-facing obligations rather than technical configuration.
Why Cross-Functional Categories Need a Single Named Owner Anyway
A control category that spans multiple functions is exactly where the temptation to leave ownership vague is strongest, and exactly where a single named owner matters most. Impact assessment controls, for example, may require input from legal on regulatory exposure, from the AI Governance Body on risk tolerance, and from engineering on technical feasibility of proposed mitigations. None of that shared input changes the fact that one person needs to be accountable for the impact assessment actually getting completed on schedule and the evidence actually being retained. Splitting Responsible across several contributors while keeping a single Accountable owner, the standard RACI discipline, is what prevents a genuinely cross-functional control from becoming an orphaned one.
Documenting and Communicating the RACI
Clause 5.3 requires that roles be communicated, not only assigned, and this is the step organizations most often shortcut. A RACI that lives in a governance document nobody outside the compliance function has read does not satisfy the clause in substance, even if it technically exists in writing.
What Communication Actually Requires
Communicating a role assignment means the named individual can describe, in their own words, what they are accountable for and what evidence they need to produce or maintain. This is a meaningfully higher bar than sending a document for acknowledgment. A practical way to confirm this bar has been met is to ask each control owner, independently of the governance team, to describe their own control and its evidence trail. If the description matches what the RACI says on paper, the communication requirement is genuinely satisfied. If it does not, the RACI exists as documentation but not as operating reality, and that gap is precisely what an internal audit should be designed to catch before an external assessor finds it first.
Revisiting the RACI as the Organization Changes
A RACI documented once at initial certification and never revisited is a RACI that quietly decays as people change roles, teams reorganize, or new AI systems enter scope. Building a fixed trigger for RACI review, tied to management review cycles, personnel changes in named roles, or the addition of a new AI system to the AIMS scope, keeps the document from becoming stale between formal reassessments. This is a small addition to an existing management review agenda, not a separate program, and it is one of the lowest-cost ways to keep the operating model matching organizational reality.
Where Ownership Breaks Down in Practice
Three failure patterns show up repeatedly in AIMS programs that have a documented RACI on paper but weak accountability in practice.
The Committee That Owns Everything and Nothing
An AI Governance Body that is listed as Accountable for every activity in the RACI, rather than a specific accountable individual within it, tends to diffuse responsibility rather than assign it. A committee can hold collective oversight, but each specific deliverable, the policy, the risk treatment plan, the SoA, still benefits from one named individual inside that body who an auditor can ask directly. Committees are good for decisions that need multiple perspectives; they are weak at being the single point of contact for a specific document’s currency. The practical fix is simple to state and easy to skip under time pressure: every line in the RACI where the governance body appears as Accountable should also carry the name of the specific person inside that body who holds it, updated whenever committee membership changes.
Control Owners Who Do Not Know They Are Control Owners
A surprisingly common gap is a control owner assignment that exists in a spreadsheet somewhere but was never actually communicated to the person named. Clause 5.3 requires that responsibilities be communicated, not just assigned on paper, and an internal audit that asks a named control owner about their control and receives a blank look is finding exactly this gap. Communicating the assignment, confirming the person understands what evidence they are accountable for, and revisiting that confirmation when roles change inside the organization is not optional overhead. It is the difference between a RACI that functions and one that exists only as documentation.
Risk Ownership That Never Transfers From the Original Assessment
An AI Risk Owner assigned during the initial risk assessment sometimes remains the named owner indefinitely, even after that person changes roles or leaves the organization, because nobody built a process for reassigning risk ownership when personnel change. A risk with no living, current owner is a risk that stops getting reviewed, which surfaces exactly when a management review or an internal audit asks for an update nobody can provide. Internal audit planning for the AIMS is one of the more reliable ways to catch this gap before an external assessor does, since a competent internal audit program checks not just whether risks are documented but whether the named owner can speak to them currently.
Connecting the RACI to the Rest of the AIMS
A RACI matrix is not a standalone artifact. It only functions when it connects to the actual documents and processes the AIMS produces.
From Roles to Policy Sign-Off
Several AIMS policies require explicit executive sign-off under the standard’s leadership requirements, and knowing which policies require that sign-off is a direct extension of getting the top management row of the RACI right. A RACI that assigns policy approval to top management only has teeth if the organization also knows precisely which documents that approval requirement actually covers.
From Roles to Implementation Sequencing
Building the RACI is not a step that happens in isolation before implementation begins. It belongs inside the broader seven-step implementation process an organization works through when building its AIMS from scratch, ideally early enough that role assignments are in place before the risk assessment and control selection work begins, rather than retrofitted onto work that already happened without clear ownership.
From Roles to Governance, Not Just Tooling
An AI governance tool can track who is assigned to what, but the tool does not create accountability on its own. Where tool-only approaches to ISO 42001 fail is almost always in this exact gap: a platform shows a RACI matrix populated with names, but nobody actually confirmed those individuals understand and accept the responsibility the matrix assigns them. The tool can support the operating model. It cannot substitute for the organizational work of building it.
Starting From an Honest Baseline
An organization building its first RACI for an existing AI governance effort, rather than a brand-new AIMS, benefits from an honest gap analysis of the current program before assigning new ownership, since roles built on top of an inaccurate picture of what already exists tend to require rework once the real state of the program becomes clear during certification preparation.
Elevate helps organizations design an AIMS operating model that satisfies Clause 5.3 in substance, not just on paper, with role assignments that hold up when an internal or external auditor asks a named individual to speak to their own accountability. To build a RACI structure that fits your organization’s size and AI governance maturity, book a readiness call with an Elevate advisor.
Conclusion
ISO 42001 requires roles and responsibilities to be assigned and communicated, but it leaves the actual operating model to the organization building it. A RACI that names five clear roles, ties each recurring AIMS activity to a specific accountable person, and gets revisited when people change roles or leave, is what keeps an AIMS functioning between audits rather than only appearing functional during them. The organizations that get this wrong tend to discover it the same way: an auditor asks a specific person a specific question about their own accountability, and the answer reveals that the RACI on paper never actually reached the person it named.
Getting the operating model right early saves the far more expensive work of untangling ownership confusion after a nonconformity has already been raised. It also pays off well before certification, since a governance body and set of control owners who genuinely understand their accountability make every subsequent step of implementation, from risk assessment through internal audit, move faster and produce more defensible evidence than a program still figuring out who is supposed to be doing what.
Elevate builds AIMS operating models designed to survive that exact test. Book a readiness call to work through what ownership should look like for your program.
Key Takeaways
- Clause 5.3 requires roles to be assigned and communicated, not just documented. A control owner who does not know they hold that accountability is a gap an internal audit or external assessor will find.
- ISO 42001 also requires the organization to determine its own role with respect to the AI systems in scope. This organizational-level determination is separate from the individual roles and responsibilities Clause 5.3 covers internally, and confusing the two is a common early mistake.
- A five-role structure, top management, AI governance body, AI risk owner, AIMS program owner, and control owners, covers most organizations. Smaller organizations can combine roles, but the accountability should stay explicit even when one person holds multiple assignments.
- Committees are weak substitutes for named individual accountability on specific deliverables. A governance body can hold collective oversight while still needing one named person accountable for each document or process an auditor might ask about directly.
- A RACI only functions when it connects to the AIMS’s actual documents and processes. Role assignments built in isolation from policy sign-off requirements, implementation sequencing, and internal audit planning tend to require rework once certification preparation exposes the gaps.
FAQs
Does ISO 42001 require a specific organizational structure for AI governance? ISO 42001 requires, under Clause 5.3, that roles and responsibilities relevant to the AI management system be assigned and communicated by top management. It does not mandate a specific organizational structure, committee, or set of job titles. Organizations design their own operating model to satisfy this requirement, which means terminology like AI Governance Body or AI Risk Owner reflects common implementation practice rather than language taken directly from the standard.
What is the difference between an AI Governance Body and an AI Risk Owner in an AIMS? The AI Governance Body typically holds broader oversight of the AI management system on behalf of top management, including the AI policy’s ongoing currency and coordination of governance decisions. The AI Risk Owner is accountable specifically for the AI risk assessment and treatment plan required under Clause 6.1, ensuring identified risks are tracked to resolution. In smaller organizations these functions sometimes combine into a single role, but the underlying accountabilities are distinct even when one person holds both.
Who should own the ISO 42001 Statement of Applicability? The Statement of Applicability is typically owned operationally by an AIMS Program Owner, who maintains the document and keeps it current, while the AI Governance Body holds accountability for the decisions the document reflects, such as which Annex A controls are applicable and why. Having a single person responsible for the document itself, distinct from who is accountable for the applicability decisions within it, prevents the document from drifting out of date between formal reviews.
What happens if Annex A controls do not have named owners? A control without a named, accountable owner tends to produce weak or missing evidence during an audit, because no single person is responsible for maintaining that evidence or noticing when the control lapses. This is one of the most common gaps auditors identify in ISO 42001 programs that have documented a RACI on paper but never confirmed that named control owners actually understand and accept their assignments.
How does the ISO 42001 role requirement differ from ISO 27001? Both standards follow the same Harmonised Structure and require roles and responsibilities to be assigned under an equivalent leadership clause. ISO 42001 adds a requirement that does not have a direct equivalent in ISO 27001: as part of scoping the AIMS, the organization must formally determine its own role with respect to the AI systems in scope, distinguishing whether it is developing, providing, or using AI, since the standard’s obligations differ depending on which role applies.