ISO 42001 Annex A 10.2 Allocating responsibilities
What it says
The organization shall ensure that responsibilities within their AI system life cycle are allocated between the organization, its partners, suppliers, customers and third parties.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDecide and write down which party (your organisation, your partners, suppliers, customers or other third parties) is responsible for each task across the life of an AI system, so no duty is left unowned.
When you build or run an artificial intelligence (AI) system, the work rarely sits with one organisation alone. A supplier might provide the model, a partner might host it, your own staff might operate it, a customer might feed in their own data, and other third parties might handle support or reviews. This control says you must agree, in writing, who is responsible for what at every stage of the AI system's life, from design and build through to running it, changing it and shutting it down. The point is that when responsibilities are split across several parties but never written down, the gaps between them are where things fail: each party assumes someone else is handling a problem, and no one acts.
Free. Save your status, tasks and notes.
Why it matters
If a shared AI system produces a harmful or unlawful result and no party was named as responsible, each side points at the other while the affected people (customers wrongly refused a service, for example) get no fix and no answer. An OAIC complaint or a regulator's enquiry then lands on your organisation, because under the Privacy Act 1988 and your contracts the accountability does not transfer to a supplier just because they built the tool. Unallocated duties also stall incident response: a model fault can sit live for weeks while the organisation and its suppliers argue over whose job it was to monitor it.
How to implement
The person who owns the AI management system should map the AI system's full life cycle (design, build, deployment, operation, change and decommissioning) and, for each stage, write the name of the single party responsible, whether that is your own organisation, a partner, a supplier, a customer or another third party.
A one-page responsibility matrix or RACI chart is usually enough to make the split visible.
When procurement or the contract owner sets up a supplier or partner agreement, they should write into it which party is responsible for each ongoing duty (monitoring the model, maintaining it, responding to incidents and decommissioning it) so accountability does not stop at the moment of delivery.
The product owner should agree with each partner and supplier, in writing, who handles customer-facing failures, so that when an AI gives a customer a wrong or harmful result there is no doubt about which party investigates and which party communicates with the affected person.
The AI or data owner should, for each external data source the AI uses, record which party is responsible for that source being accurate and lawful to rely on (the customer who supplies it, a supplier who licenses it, or your own organisation) so the duty to keep each source fit for use has a named owner rather than being assumed.
The risk or compliance owner should re-confirm the whole allocation whenever a supplier, partner or customer role changes, or the system enters a new life-cycle stage, and record who signed off the updated split so unowned gaps are caught before they cause harm.
Keep it running
Treat the responsibility allocation as a living record, not a one-off contract annex. Re-confirm who owns each duty whenever a partner or supplier is added or dropped, a customer's role in feeding or operating the system changes, or the system moves to a new life-cycle stage such as a major change or decommissioning. Pay attention to the seams between parties, such as handover points at deployment, where a duty can quietly fall between two organisations and end up owned by neither.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the document or matrix that allocates AI responsibilities across the life cycle.
Look at
Whether every stage names a specific responsible party (your organisation, a partner, a supplier, the customer or a third party) with no stage left blank.
Good evidence
Each life-cycle stage has a single named responsible party, and the split between the organisation and its partners, suppliers, customers and third parties is explicit.
- Check 2 of 5What an auditor asks for
Ask for
Request a supplier or partner agreement for an AI system.
Look at
Whether it states which party is responsible for ongoing duties such as monitoring, maintenance, incident response and decommissioning, rather than only the initial delivery.
Good evidence
The agreement assigns named ongoing responsibilities to each party across the system's life, not just who builds or sells it.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see what customers are told they are responsible for.
Look at
Whether there is a written statement covering customer duties, such as the accuracy and lawful basis of any data the customer supplies to the AI.
Good evidence
A signed or published statement sets out the customer's responsibilities and distinguishes them from those your organisation retains.
- Check 4 of 5What an auditor asks for
Ask for
Ask the AI owner to name which party is responsible for each external data source the AI relies on.
Look at
Whether each source can be traced to an accountable party for it being fit and lawful to use, rather than the question being met with uncertainty.
Good evidence
Every external data source has a named party accountable for it, and that party is recorded alongside the source.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence the allocation was reviewed after a recent change in suppliers, partners or life-cycle stage.
Look at
Whether responsibilities were re-confirmed and re-assigned at that point, with a dated record and a named approver.
Good evidence
A dated review record shows responsibilities were re-allocated after the change and signed off by a named owner.
Mappings
Closest match in ISO/IEC 27001: A.5.2, Defining information security roles and responsibilities, which partially overlaps with this control.
ISO/IEC 27001: 3 mappings
This control partially overlaps A.5.2.
Annex A 10.2 requires the organisation to allocate responsibilities across the AI system life cycle between itself and external parties (partners, suppliers, customers and third parties). ISO/IEC 27001:2022 Annex A 5.2 relates by requiring information security roles and responsibilities to be defined and allocated, which overlaps with defining who is accountable for security-related AI life-cycle activities. Annex A 5.2 is generally internal information security role allocation, while Annex A 10.2 explicitly extends allocation across external parties and the full AI system life cycle.
This control partially overlaps A.5.19.
Annex A 10.2 requires the organisation to allocate responsibilities across the AI system life cycle among internal and external parties. Annex A 5.19 supports this by requiring defined processes and procedures to manage information security risks in supplier relationships, which typically includes assigning accountability (e.g., who monitors, who approves, who remediates) across parties. Annex A 5.19 is supplier-relationship and risk-management focused, while Annex A 10.2 is broader and explicitly about responsibility allocation across the whole AI life cycle and multiple third-party types.
This control partially overlaps A.5.20.
Annex A 10.2 requires clear allocation of responsibilities across the AI system life cycle, including with suppliers and other third parties. Annex A 5.20 supports this by requiring security requirements to be established and agreed in supplier agreements, which is a practical mechanism for documenting and enforcing who is responsible for which controls and tasks. Annex A 5.20 is limited to supplier agreements and information security requirements, whereas Annex A 10.2 spans broader AI life-cycle responsibilities (including non-security responsibilities) across more stakeholder types.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-1569.
Annex A 10.2 requires the organisation to allocate responsibilities across the AI system life cycle between itself and external parties so duties are not left unowned. ISM-1569 directly relates by requiring a documented and shared supplier-customer shared responsibility model that articulates each party's security responsibilities. ISM-1569 is typically scoped to security responsibilities in supplier services, whereas Annex A 10.2 is broader and AI-system-life-cycle oriented (including partners, customers and other third parties beyond suppliers).
This control partially overlaps ISM-1738.
Annex A 10.2 requires clear allocation of responsibilities for AI system life-cycle tasks across the organisation and third parties. ISM-1738 relates because exercising a contractual right to verify compliance depends on defining which party is responsible for meeting and evidencing security requirements. ISM-1738 is narrower (assurance/audit activity in supplier agreements), while Annex A 10.2 is broader in scope (all AI life-cycle responsibilities, not only verification of supplier compliance).
This control partially overlaps ISM-1794.
Annex A 10.2 requires the organisation to allocate and document responsibilities across the AI system life cycle between the organisation and external parties. ISM-1794 relates by requiring contractual allocation of responsibility to the service provider to provide timely notification (minimum one month) of significant downstream subcontractor/arrangement changes. The overlap is in clarifying who must do what at supplier interfaces, but ISM-1794 is narrower and focused on a specific change-notification obligation rather than end-to-end AI life-cycle responsibility allocation.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 42001 training
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.
Turn this control into your AI policy
PolicyMint writes customised ISO 42001 policy documents for your business, audit-ready and exported in your branding (Word, PDF, Excel). Skip the blank page and the boilerplate that does not fit. First document free.
Draft your ISO 42001 documents