What A.3.2 AI roles and responsibilities asks for and why auditors check it
A.3.2 asks the organization to define and allocate roles and responsibilities for AI according to its own needs. It extends clause 5.3 of ISO/IEC 42001, which requires top management to assign and communicate responsibilities for the AI management system, down to the activities that touch AI systems themselves. For a compliance lead or CISO facing an audit or a customer questionnaire, the test is simple: for each AI system and each AI decision, can the organization name the person or function that owns it, and show that the assignment was made, communicated and accepted? An AI decision with no named owner is a control gap, even when the policy text is perfect.
The hard part is not drawing an org chart. Auditors look for named people, or precisely described functions, for five activities: owning AI risk, carrying out impact assessment, directing development, exercising oversight and approving operation. Each needs an accountable owner with the authority to stop or change a system, and the owner for oversight should not be the same person who builds the system if the organization can avoid it. Confirm with your own structure whether one role can hold several of these, and record where it does. Confirm also how your organization's existing roles map to these activities, since many AI decisions currently sit with product managers, data science leads or procurement staff without anyone recorded as accountable.
Evidence for this control is usually a responsibility assignment record, such as a matrix that lists each AI system against each activity, with the named role, the deputy, the date of assignment and the approver. Keep the version history of that record, because an assessor will ask who changed an assignment and when. Ask your certification body or auditor, before stage 1, which format they expect and how they sample assignments. The organization owns these assignments. An implementation partner can help structure the records and test whether they match how work actually flows, but only the organization can appoint people and only an independent certification body can judge conformity.
Which AI systems, teams and third parties fall inside A.3.2 scope
The roles an organization defines under A.3.2 only work if they match what the AI management system actually covers. Scope is set by the organization's own statement of applicability under clause 6.1.3, which lists the Annex A controls it includes or excludes and why. The cards below are the scoping decisions that most often change who owns what.
AI systems and their life cycle stages
Start with an inventory of the AI systems in use, in build and in retirement, then decide which of them the AIMS covers. A role is only meaningful if someone can be named for each system and each stage, from design through operation and decommissioning. Check whether pilots, proofs of concept and internal tools sit in scope, because they often have no named owner. Record the decision and its justification in the statement of applicability.
Business units and legal entities
Decide which business units, subsidiaries and product lines fall inside the AIMS boundary. A group with several entities may need roles that cross them, or separate roles for each entity that uses AI differently. Confirm who in each unit holds authority to start, change or stop an AI system, since that person is usually the one the role definitions must name. Unit leaders who are outside the boundary still need to know which decisions now route to the AIMS.
Internally built AI systems
For systems the organization builds, roles usually span data science, engineering, product and the business owner. Define who makes design decisions, who signs off on training data and evaluation, and who can release a model into production. Separate the builder from the reviewer where the organization can do so. Ask whether developers can approve their own release, because that gap is what assessors tend to probe when they test whether responsibilities were allocated deliberately.
Purchased AI and third-party models
Roles for bought AI need a clear owner for the vendor relationship, for the configuration the organization controls, and for the risk the vendor cannot transfer. Decide who reviews vendor documentation, who approves a model change the vendor pushes, and who monitors use against the intended purpose. Responsibilities allocated under A.10 for suppliers should be consistent with these A.3.2 assignments. Confirm that each third-party AI system has a named internal owner, even when the vendor runs the model.
Shared roles and conflicts of interest
A product owner who also approves the risk of their own product is a common arrangement, and it weakens oversight when the same person sets priorities and accepts residual risk. Decide which combinations of roles are acceptable and which need a second approver. Document any shared role in writing, name the person's authority for each decision, and set an escalation path for disagreements. Assessors look for evidence that the combination was a deliberate choice, not an accident of staffing.
Scope changes and the statement of applicability
Scope is not fixed at the start. When a new AI system is added, a business unit is acquired or a control is excluded, the roles and the statement of applicability need to be updated together. Assign an owner for keeping scope current and for recording each change with its reason. Ask your certification body or internal auditor how they expect scope changes to be evidenced, since the answer shapes how you version the role register.
How an assessor tests AI role assignments
This table compares what an assessor does, what evidence they ask for and where organizations usually fall short when testing A.3.2 AI roles and responsibilities. Read each row as a step in the audit: the test approach shows what is checked, the evidence column shows what to have ready, and the findings column shows where gaps tend to appear.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Review documented role definitions | AI roles register or RACI, role descriptions covering AI risk, impact assessment, development, oversight and operation | Roles defined in policy but no matching role description or register entry |
| Sample named AI systems and trace each activity to an owner | Inventory of AI systems with named accountable owner for each lifecycle activity, plus sign-off records | Roles defined but unassigned; a system has no named owner for impact assessment or oversight |
| Check that the owner has authority for the role | Delegation of authority, job descriptions, escalation paths and decision logs showing the owner acted | Owners who lack authority to stop, change or approve an AI system in practice |
| Check that assignments were communicated | Acknowledgment records, onboarding or training materials, intranet publication, communication to contractors | No evidence of communication; staff unaware of who owns which AI decision |
| Check that roles reflect change over time | Version history of the register, records of reassignments after staff departures or reorganizations | Register unchanged after staff moved on; former owners still listed as accountable |
| Check that the Statement of Applicability justifies A.3.2 | Statement of Applicability entry for A.3.2 with inclusion reason, linked to the roles register | Control marked applicable with no supporting roles evidence, or excluded without justification |
How to define and allocate AI roles step by step
This sequence turns the open-ended requirement of A.3.2 into a set of named, documented assignments that match how each AI system is actually built, run and overseen, so an assessor can trace every activity to a responsible person.
Map AI activities across the life cycle
Start by listing every activity that touches each AI system, from identifying a business need and sourcing data through development, deployment, operation, monitoring and retirement. Include activities done by third parties and by internal teams using a purchased AI product. Work with the system owners, engineering leads and procurement to build this list. The output is an activity inventory per AI system, which becomes the baseline every later assignment must cover without gaps.
Define role descriptions for each function
Write a short description for each role the organization needs, covering AI risk ownership, impact assessment, development, independent oversight and day-to-day operation. Keep oversight separate from development where the organization's size allows, and state what each role decides, reviews or signs off. Confirm the wording with the relevant executives and with legal or privacy staff. The output is an approved role catalog that names each function and its responsibilities in plain language.
Assign named owners and deputies per AI system
For each AI system in scope, appoint a named accountable owner for each role and a named deputy who can act when the owner is unavailable. Use people, not only job titles or teams, and confirm each person accepts the assignment. Check that no single person holds conflicting duties, such as approving their own impact assessment. The output is a RACI matrix per AI system that shows who is responsible, accountable, consulted and informed for each life cycle activity.
Record authority limits and escalation paths
Document what each role may approve alone, what requires a second signature, and what must go to top management or a governance committee. Specify spending, deployment, data use and shutdown authority where relevant. State how a role-holder escalates a disagreement or a risk above their limit. The output is an authority matrix attached to each assignment, so an assessor can see the boundary of each person's decisions without interviewing them.
Communicate assignments and collect acknowledgment
Send each assignment to the named person with the role description, authority limits and deputy details, and ask them to acknowledge it in writing. Brief the wider teams that interact with the system so they know who to contact. Store acknowledgments with the assignment record. The output is a signed or electronically acknowledged assignment record for every named role, which evidences that responsibilities were communicated as well as allocated.
Set the review trigger and version the records
Define the events that require the assignments to be revisited, such as a new AI system, a material change in purpose, a reorganization, a departure of a role-holder, or a serious incident. Set a periodic review cycle chosen by the organization and confirm it with the auditor's expectations for its management system. Keep each version of the RACI and assignment records under version control so changes and their dates are traceable. The output is a documented review procedure and a change history for the assignment records.
Who owns the roles, who can help, and where independence ends
Accountability for A.3.2 sits with your organization. Clause 5.3 requires top management to assign and communicate responsibilities for the AI management system, and A.3.2 carries that expectation into the activities that build, provide and use AI systems. Your leadership decides which roles the organization needs, who holds each one, and what authority comes with it. A named person should be able to answer for each assignment without relying on an outside party.
- Role decisions: Management decides which AI roles exist, such as risk owner, impact assessment lead, system owner and oversight reviewer, and whether one person may hold several.
- Named assignments: Each role has a named individual, a deputy where the work is critical, and a reporting line to someone with authority to act.
- Authority and resourcing: Owners receive the time, budget and decision rights to do the work, recorded in the same place as the assignment.
- Communication: Assignments are communicated to the people affected and acknowledged, so that the record shows awareness, not only intent.
- Periodic confirmation: Leadership reviews the roster when teams, systems or vendors change.
Before you accept any draft from outside, confirm that your own managers can explain each assignment and have approved it.
An implementation partner can help you prepare the material behind A.3.2. This includes a draft role model, a responsibilities matrix, role descriptions, and the records that show who holds each role and when it was assigned. DeployOpen is one example of such a partner. It prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and it does not take on the roles themselves. The partner's work is a draft for your decision, not a substitute for your ownership.
- Drafting: The partner can propose a role model based on the systems and processes you describe, which you then adjust and approve.
- Record setup: The partner can configure where assignments and approvals are kept, so they are dated and traceable.
- Gap review: The partner can compare current assignments against the roles your AI activities require and flag unassigned tasks.
- Not allowed: The partner should not hold a role on your behalf, sign off assignments as your management, or stand in for your AI risk owner.
- Scope in writing: The scope, deliverables and handover of the role documents should be agreed before work starts.
Ask the partner which parts of the role model it drafted, which parts you must approve, and who will maintain the records after the engagement ends.
The certification body is independent of you and of any partner that helped you prepare. ISO does not certify organizations; external certification bodies do, and accreditation of those bodies is voluntary. ISO/IEC 42006:2025 sets additional requirements on top of ISO/IEC 17021-1 for bodies certifying AI management systems. A certification body that designed your roles would be auditing its own work, which removes the independence that gives the certificate its value. For this reason, the auditor should review your assignments, not write them.
- Independent testing: The auditor checks whether roles are defined, allocated, communicated and evidenced, using records you produce.
- No design role: The certification body should not draft your role model, assign people or maintain your records as a consultant.
- Conflict check: Ask any certification body how it manages conflicts when it has also advised, or has a relationship with, your organization.
- Accreditation status: Confirm that the body is accredited for ISO/IEC 42001 through the relevant accreditation body, since accreditation is voluntary.
- Clear boundary: Agree in writing which activities a consultant and the certification body may each perform.
Before engaging a certification body, check its accreditation scope for ISO/IEC 42001 and get its conflict-of-interest policy in writing.
Evidence that satisfies A.3.2 and how to keep it current
An auditor testing A.3.2 wants to see that AI roles were defined, assigned to named people, and communicated, and that the record still matches how the organization works today. The cards below cover the artifacts that show this, and the review habits that keep them accurate between audits.
Approved role and responsibility definitions
This is the master document listing each AI role, its purpose, its decision rights and the people or functions that hold it, such as AI risk owner, impact assessment lead, system owner, development lead and operations owner. It should be approved by top management, which ties it to the responsibilities clause in ISO/IEC 42001 (clause 5.3). Check that every role named in your AI policy and impact assessment procedure appears here, and that no role is defined without an owner. Store it under version control so the approval date and the previous wording remain retrievable.
Per-system RACI records
A RACI matrix for each AI system shows who is Responsible, Accountable, Consulted and Informed for activities such as data sourcing, risk assessment, model validation, deployment approval, monitoring and retirement. The purpose is to show that each AI system has a clear accountable owner, not only a function that covers it in general. Check that each record names individuals or roles, not just departments, and that the accountable party for each activity can actually make the decision.
Appointment and delegation letters
Where a role is filled by a named person, a signed appointment letter or delegation record confirms the scope of their authority, the start date and any limits. Delegations matter when an AI risk owner is out of office or when a system owner passes responsibility to a platform team. Check that each appointment has an effective date, an end or review date, and a named approver, and that expired or superseded delegations are archived rather than deleted.
Authority matrix and escalation paths
An authority matrix sets the thresholds at which decisions move up the chain, for example which AI risks the system owner may accept alone and which must go to the AI governance committee or top management. It shows auditors how roles interact with the risk acceptance and impact assessment processes. Check that thresholds match the risk criteria in your AI risk assessment, and that the matrix names a deputy for each approver so that escalation does not stall.
Communication and acknowledgment records
Evidence that people know their AI responsibilities includes distribution lists, training attendance, and signed or electronically recorded acknowledgments of role descriptions. Keep the record of who received each version and when, so that you can show the message reached the right people at the right time. Check that new joiners, contractors and staff who move into AI-related roles receive the same communication before they take on responsibility.
Change history and review cadence
Reorganizations, new AI systems, staff departures and changes in regulation all make role records drift from reality. Set a review cadence for the role definitions and RACI records, and trigger an earlier review on any org change, system retirement or new AI product launch. Keep a dated change log that records what changed, who approved it and why. Auditors often sample the log to confirm that the records were maintained between audits, not rewritten shortly before one.
What meeting A.3.2 costs in money and effort
This table compares the main cost components of assigning AI roles and keeping that assignment evidenced, who is paid for each, and what drives it up or down. Most of the cost is leadership and role-holder time, while the tooling cost is small when open-source wiki software is self-hosted. No prices or durations are given because none were supplied, so use the quote questions to get figures for your own environment.
| Cost component | One-time or recurring | Cost drivers | How to reduce it |
|---|---|---|---|
| Internal leadership time to agree roles | One-time, then recurring on review | Number of AI systems, number of business units, how many decision-makers must agree on risk ownership | Start from a short list of roles, decide on AI risk ownership first, and reuse the existing governance forum |
| Tooling for role records | One-time setup, recurring hosting and upkeep | Choice of wiki or register, hosting location, integration with identity and access management | Self-hosted open-source wiki tools carry no license fee, so cost shifts to hosting and administration time |
| Role-holder training | One-time for new roles, recurring for turnover | Number of named role-holders, complexity of impact assessment and AI life cycle duties, staff turnover | Give role-holders short briefings tied to their specific duties and record attendance as evidence |
| Evidence upkeep after reorganizations | Recurring | Frequency of restructuring, staff departures, new AI products or vendors, gaps in change control | Assign an owner for the role register, set a review trigger on org changes, and keep version history of each assignment |
| Internal review of role assignments | Recurring, usually tied to management review | Size of the AI portfolio, depth of internal audit sampling, number of unresolved gaps | Run a single review cycle that covers roles, responsibilities and authorities together |
| External review or auditor sampling | Recurring at each certification or surveillance audit | Auditor sample size, quality of role records, whether assignments can be traced to actual decisions | Prepare sample-ready records in advance and ask the certification body how it samples role evidence |
| Outside help to draft roles | One-time, optional | Team's prior governance maturity, scope of the AI management system, need for an independent view | Scope the work in writing with fixed deliverables, and keep ownership of final assignments internal |
Keeping role records version-controlled and traceable
A role assignment under A.3.2 is only useful as evidence if you can show who held it, when it changed and who approved the change. A self-hosted wiki or documentation platform can hold the role register, the RACI-style definitions for AI risk ownership, impact assessment, development, oversight and operation, and the named individuals against each. The key requirement for an assessor is a change history that records what changed, when and by whom. *XWiki* describes this kind of page-level version control: every change is kept, two versions can be compared, and an earlier version can be restored. Confirm in your own deployment that the version history is enabled on the role pages, that it cannot be turned off by page editors, and that your retention settings do not prune older revisions that cover past assignments.
Version history shows what happened, but it does not stop an unauthorized edit from being made in the first place. Permissions decide who can change the register. *BookStack* assigns abilities through the roles given to each user, and those permissions can be overridden at the shelf, book, chapter or page level. For a role register, a practical pattern is to restrict edit rights on the assignment pages to the owner of the AI management system and a small set of approvers, while keeping read access wider so that staff can see who is accountable. Check in your environment that page-level restrictions behave as you expect, and test them with a non-administrative account before you rely on them in an audit.
Traceability also depends on how assignments are linked to the rest of your evidence. Ask the implementation partner to agree on a fixed template for each role record, with fields for scope, authority, the date of assignment, the approver and a review date, and to confirm how the platform's history is exported or backed up for the auditor. Keep the platform's audit log, if it has one, separate from the wiki content, and decide who reviews both. Note that the platform is only a record of your decisions. The organization owns the role allocation, and an independent auditor will judge whether the records are adequate.
Questions teams ask about A.3.2 roles and responsibilities
How much effort does defining AI roles and responsibilities take?
The effort depends mostly on how many AI systems the organization builds, buys or operates, and how many teams touch them. A company with one AI-enabled product and a small team can usually define roles in a focused working session plus written drafts reviewed by leadership. An organization with many models, several business units and external suppliers needs more time to map who decides what for each system. The main one-time work is agreeing the role catalogue and mapping it to people. The recurring work is keeping assignments current when staff leave, teams reorganize or new AI systems enter service. Ask any consultant to break its quote into discovery, drafting, review and handover so you can see what is one-time and what you will maintain yourselves.
Can one person hold several AI roles at once?
Yes, ISO/IEC 42001 does not prohibit one person from holding several roles, but the organization must show that the combination still works. A single person may act as AI system owner and also handle operational monitoring in a small team. Problems arise when the same person approves a system and also reviews its impact assessment or incident response, because that removes independent oversight. Where roles are combined, document the reason, name a deputy for each responsibility, and check that the person has the competence and authority the role needs. Keep an eye on separation of duties for high-impact systems, since an assessor will ask how decisions are challenged.
Can an implementation partner define our AI roles for us?
A partner can help draft the role model, propose responsibility matrices and document the assignments, but the organization must decide who holds each role and accept accountability for it. ISO/IEC 42001 places responsibility inside the organization, and an independent auditor will test whether leadership actually owns the assignments. In practice, the partner prepares the draft and the evidence, while named executives approve the roles, confirm the people involved and sign off the final documents. Ask the partner to show which decisions remain with your staff, how the handover works, and who maintains the matrix after the engagement ends. Any scope should be written down before work starts.
What does defining AI roles need from leadership?
Leadership must make the decisions that the standard assigns to top management: approving the AI management system scope, naming accountable owners and making sure those owners have the authority and resources to act. Clause 5.3 requires top management to assign and communicate responsibilities, so an executive sponsor needs to confirm the role model and tell the organization about it. Leaders also need to resolve conflicts, such as which function owns AI risk when product, legal and security all have a stake. Expect to commit time for a few review cycles and to confirm that the roles are reflected in job descriptions and performance expectations. Without visible sponsorship, role assignments tend to stay on paper.
Is a wiki page enough evidence for AI roles and responsibilities?
A wiki page can serve as evidence if it is the controlled record of the assignments and shows who approved it, when, and what changed. Wiki platforms with version history help here. For example, XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare versions and roll back. A role matrix stored in a wiki with that history, a named approver and links to the relevant AI system records can support A.3.2. Pair it with evidence that roles are communicated and understood, such as acknowledgement records or training attendance. Access control on the wiki matters too: BookStack, for example, derives user abilities from assigned roles and allows permissions to be overridden at shelf, book, chapter or page level, so you can restrict who edits the matrix. Confirm with your auditor which record they will accept.
How do AI roles relate to clause 5.3 of ISO/IEC 42001?
Clause 5.3 covers roles, responsibilities and authorities for the AI management system as a whole and requires top management to assign and communicate them. Control A.3.2 narrows the focus to AI system activities, asking the organization to define and allocate roles and responsibilities for AI according to its needs. In practice, the clause 5.3 assignments set the governance structure, and A.3.2 adds the detail for who owns risk, impact assessment, development, oversight and operation of each AI system. The NIST AI RMF crosswalk maps related guidance, including GOVERN 2.1 on documented roles and lines of communication, to the guidance for this control, which can help you structure the evidence. Read the standard's own text and the statement of applicability together to confirm how your organization interprets the link.
Gaps that cause A.3.2 findings and how to close them
Auditors rarely fail A.3.2 because an organization has no AI policy. They fail it when the roles on paper do not match the people, authority and records that exist in practice. The cards below cover the gaps we see most often and the fix for each, so the assignments can be shown to hold under testing.
Roles without named individuals
A role such as AI risk owner or model owner is listed in a document, but no person is named against it, or the name is a team alias with no accountable member. A.3.2 asks for responsibilities to be defined and allocated, so an unfilled role is a visible gap. Fix it by naming one accountable person and at least one deputy for each role, with the date of assignment. Check that the named people still work in the role and that the register is updated when staff change.
AI systems with no accountable owner
Some AI systems, especially vendor tools adopted by a business unit, have no single owner for their life cycle, risk and day-to-day operation. Responsibility is split between the team that bought the tool and the team that runs it, so nobody answers when an impact assessment is due. Fix it by keeping an inventory of every AI system with one named owner per system, plus named contacts for development, oversight and operation where those differ.
Owners without authority to stop deployment
A role may be named as responsible for AI risk, yet the person cannot pause a release, withdraw a model or require changes before go-live. Under A.3.2 the allocation should match the decisions each role must make. Fix it by writing down the decision rights for each role, including who can halt deployment, who approves exceptions and who escalates when the owner and the delivery team disagree. Test it by asking the owner to describe a case where they stopped a launch.
Roles that exist only in policy
The AI policy lists roles, but the people doing the work have never seen them, were not trained on them and do not follow the defined hand-offs. Clause 5.3 requires top management to assign and communicate responsibilities, so a policy that is never applied is hard to defend. Fix it by mapping each policy role to real tasks in the workflow, such as the ticket, review or sign-off that proves the role is used. Ask a sample of staff to name their AI responsibilities.
No record of communication
Assignments are made verbally or in email, and no dated record shows that the person accepted the role or that the wider organization was told who holds it. An assessor asking for evidence of allocation will find nothing to sample. Fix it by keeping a version-controlled register of roles, with assignment dates, acceptance and change history. Versioned wiki pages keep a record of who changed each entry and when, and role-based permissions in a documentation tool can restrict who edits the register.
How DeployOpen helps define and evidence AI roles
DeployOpen helps organizations turn the A.3.2 AI roles and responsibilities control into a written allocation of AI risk, impact assessment, development, oversight and operation, with records that show who holds each role. The organization keeps ownership of its controls and decisions, while DeployOpen prepares the systems, documentation and evidence that support them. An independent auditor or certification body assesses the result.
How we scope
- Review the current AI systems, teams and suppliers to identify which AI roles already exist and which are unassigned.
- Agree in writing which roles, documents and systems fall inside the fixed scope before work begins.
- Confirm with the organization which decisions must stay with named executives, such as AI risk acceptance and deployment approval.
How we build
- Draft a role register that maps each AI responsibility to a named owner, deputy and escalation path.
- Configure the self-hosted wiki or documentation platform so role assignments, approvals and changes are versioned and attributable.
- Set up access groups in the self-hosted platforms so permissions reflect the documented roles, and test them against the register.
How we hand over
- Deliver the role register, responsibility matrix and assignment records as documented evidence the organization owns.
- Walk the internal owners through the records so they can explain each assignment to an auditor without relying on DeployOpen.
- Provide a list of open items the organization must confirm, such as role acceptance signatures and competence records.
How we support
- Offer ongoing support as a retainer to update role records when staff, systems or AI suppliers change.
- Include periodic reviews of access settings against the role register as part of an agreed support scope.
- Ask your auditor early which assignment records they expect, and confirm the evidence format with them before handover.
