A.10.2 Allocating responsibilities: requirements and evidence

What A.10.2 allocating responsibilities requires for AI systems

Control A.10.2 asks the organization to make sure responsibilities across the AI system life cycle are allocated between itself, its partners, suppliers, customers and other third parties. In practice, every life cycle activity, from data sourcing and model training to model updates, monitoring, incident response and retirement, needs a named party that is accountable for doing it. The risk is the gap where nobody acts: a team that buys a foundation model through one vendor, fine-tunes it on data from another source and serves it to customers may find that no one clearly owns a model update, the quality of the training data or the response when the output causes harm. Auditors look for that gap first, because it is where failures go unnoticed.

The difficulty is that responsibility moves. A model provider may update weights without notice, a data broker may change its collection terms, and a platform team may reconfigure a hosted service that the organization assumed was stable. Each change can shift who must test, document, notify or roll back. The control's output is therefore not a single policy document but a recorded split of responsibilities for each AI system, kept current as parties, models and data sources change. Before an assessment, confirm that the split covers each life cycle stage, names an accountable role inside the organization, and is reflected in contracts and a RACI chart, with dated revisions showing who approved each change. Your own legal and procurement teams should confirm the contract wording, since the standard does not prescribe it.

Which AI systems, parties and life cycle stages fall under A.10.2

Before anyone writes a RACI chart, the organization has to settle what is in scope. The decisions below determine how many systems, parties and life cycle stages must be allocated, and how many contracts must carry the split. Each one changes the amount of work A.10.2 creates, so settle them in writing before drafting responsibilities.

Provider, deployer or both

The allocation of duties starts with the organization's role. A provider builds or places an AI system on the market, while a deployer uses one under its own authority. An organization that fine-tunes a third-party model and offers it to customers usually holds both roles for that system. Record the role per system, because the same vendor relationship can mean different duties depending on which side of it the organization sits. Confirm the role with legal counsel before splitting responsibilities.

AI systems inside the AIMS boundary

The AI management system covers the AI systems named in its scope statement, so the first count is the inventory. Include internally built models, purchased AI features inside other software, and AI used by teams outside IT, such as generative tools used for drafting or screening. Each system in scope needs its own responsibility split, so an incomplete inventory produces gaps that an assessor will find. Ask for the inventory to be reviewed each time a new AI feature or vendor is introduced.

Life cycle stages each party touches

A system's life cycle runs from design and data preparation through deployment, operation and retirement. Map which stages each party controls: a model provider may own training, the cloud platform may own hosting, and the customer may own day-to-day use and monitoring. Stages with shared control create the most disputes, such as retraining, decommissioning and incident response. Write down the stage owner and the approver for each handoff, not only the party name.

Model and data suppliers

Foundation model providers, dataset vendors and labeling firms each hold a piece of the system. Their terms often set limits on training reuse, data retention, model updates and liability, and those terms decide which responsibilities the organization can actually carry. Identify each supplier that contributes a model, dataset or component, and check whether the contract states who handles vulnerabilities, version changes and withdrawal of the model. Gaps here usually show up as responsibilities nobody can execute.

Cloud platforms and integrators

Cloud providers and systems integrators run infrastructure, deploy models and often configure access and logging. Responsibility for security settings, backups and log retention can sit with the platform, the integrator or the organization, depending on the service model and the statement of work. Obtain each party's documented responsibility matrix and reconcile it with the organization's own RACI. Where an integrator builds the pipeline, confirm who owns the evidence it generates.

Customers who operate the system

When a customer runs the AI system in its own environment, or uses outputs to make decisions about people, the customer carries duties the provider cannot discharge. Define which duties sit with the customer, such as meaningful human review, input data quality and use within the intended purpose, and which sit with the organization, such as documentation and incident notice. Those splits should appear in the contract and the user documentation. Illustrative example: a provider supplies a scoring model, and the customer must decide how scores feed into hiring decisions.

How an assessor tests A.10.2 allocating responsibilities

This table compares five assessor test steps for A.10.2 with the evidence each one requests and the findings that usually come out of it. Read each row as a check the organization should rehearse before the assessment, since a gap in any one step often shows up as a finding in the statement of applicability review.

Test step	Evidence requested	Common findings
Each life cycle stage has an allocated owner for each party	RACI or responsibility matrix covering design, data, build, deployment, operation, monitoring and retirement, with a named owner per party	Stages such as retirement or decommissioning have no owner, or one role is marked responsible for every stage with no accountable party
Sample AI systems and trace each to a contract or RACI entry	Inventory of AI systems in scope, plus the contract clause or RACI row linked to each sampled system	A supplier-operated model appears in the inventory but no contract or RACI entry names who handles its updates or incidents
Partner and customer responsibilities match what the contract says	Signed contract schedules, service descriptions and the matching RACI rows, compared side by side	A responsibility listed in a contract is missing from the RACI, or the RACI assigns a task to a customer that the contract places on the organization
Allocation is reviewed when systems or suppliers change	Change records for model swaps, supplier changes or new customer terms, with dated RACI revisions and review sign-off	The supplier changed its model version or hosting location, but the responsibility split was never revisited and the RACI shows the old owner
Link to the statement of applicability	Statement of applicability entry for A.10.2 with its justification, cross-referenced to the contract and RACI evidence	The control is marked as included with no evidence reference, or it is excluded without a justification that matches how responsibilities are actually shared

How to allocate AI responsibilities step by step

This sequence turns the A.10.2 intent into a written split of duties across the AI system life cycle, so every activity has one accountable owner and every outside party knows what it is responsible for. The output is a signed-off allocation record that auditors can trace back to contracts and RACI charts.

Inventory AI systems and their life cycle stages
Start with a register of every AI system the organization builds, buys, integrates or operates, including internal tools, vendor features and models used through APIs. For each system, record its purpose, the stages it moves through (design, data preparation, development, deployment, operation, change and decommissioning) and the business owner. This inventory is the scope for everything that follows. The step is done when every system has an entry and the business owner has confirmed it in writing.
Identify every party involved at each stage
For each system and stage, list every party that touches it: internal teams, model providers, data suppliers, cloud and platform vendors, integrators, customers who configure or feed the system, and any other third party with a role. Include parties that are easy to miss, such as annotation contractors, hosting providers and open-source maintainers whose releases you deploy. The output is a party list per system that the allocation work can reference, reviewed by someone who knows the contracts.
Define the activities within each stage
Break each life cycle stage into concrete activities such as design decisions, training data sourcing, model evaluation, deployment approval, production monitoring, incident handling, user communication and decommissioning. Use the same activity list across systems so gaps are visible when you compare them. Record the activity list as a controlled document with a version number. The step closes when the list covers all stages in the inventory and has been reviewed by engineering, security and legal.
Assign one accountable owner and supporting roles
For each activity, name exactly one accountable owner, who may be internal or external, and list any supporting roles. Accountability cannot be shared on one line, because an audit will ask who answers for a failure. Where a supplier performs the work, the organization still owns the accountability decision and should record how it oversees the supplier. The output is an allocation table in which every activity has one accountable owner and documented approval from each named owner.
Write the allocation into contracts and terms of use
Transfer the agreed split into the instruments that bind the parties: supplier agreements, data processing terms, customer contracts, and acceptable use terms for users. Each allocated duty should map to a clause, a service description or an attached responsibility schedule. Involve legal counsel early, since the terms you can obtain depend on the bargaining position of each counterparty. Confirm with each party which of its duties it has accepted in writing, and store the signed text where the compliance team can retrieve it.
Build the RACI chart from the allocation
Convert the allocation table into a RACI chart that marks each activity and party as responsible, accountable, consulted or informed. Check that each activity has exactly one A, that every R is backed by a contract or internal role, and that no party is left without a defined role in an activity it touches. Publish the chart in the same controlled space as the policies so it can be versioned and compared over time. The chart is complete when every row passes these checks and the owners have signed it.
Set review triggers and retain the record
Define the events that reopen the allocation, such as a new model version, a change of supplier, a new customer segment, a serious incident, a regulatory change or a decommissioning request. Record who monitors each trigger and how often the RACI is checked against the inventory. Keep the version history of the allocation, contracts and RACI together so an assessor can see how responsibilities changed. The step closes when the triggers are documented and assigned, and the first review date is in the calendar.

Evidence that passes an A.10.2 responsibility review

An assessor reviewing A.10.2 looks for one connected story: which AI systems exist, who owns each life cycle stage, where that split is written down, what the organization tells customers, and whether the split was revisited when something changed. Each artifact below answers one part of that story, and each should carry a version, an owner and a date so it can be shown as current at audit time.

AI system and life cycle inventory

This is the register of every AI system the organization develops, provides or uses, with each system's life cycle stages listed against the party that performs them. For A.10.2, the assessor checks that no system is missing and that third-party components such as hosted models, datasets and platforms are named, not assumed. Keep it current by adding an entry before any new AI system or supplier goes live. Confirm with your own environment whether shadow AI use by business teams falls inside the inventory's scope.

RACI chart for life cycle stages

A RACI chart assigns each life cycle activity, such as data sourcing, model validation, deployment, monitoring and decommissioning, to who is Responsible, Accountable, Consulted and Informed. The assessor checks that every activity has exactly one accountable party and that partners and suppliers appear where they perform work. A common gap is a chart that lists internal roles only, while a supplier quietly owns retraining. Version the chart and reissue it whenever a role changes hands.

Allocation clauses in supplier and customer contracts

Contract clauses are the binding form of the responsibility split. Look for language that states who performs model updates, incident notification, data quality checks, output monitoring and end-user disclosure, and who bears the cost of failures. The assessor compares these clauses with the RACI chart and flags any activity the chart assigns to a party the contract does not mention. Have counsel confirm the wording, since this page does not give legal advice.

Terms of use and shared responsibility statements

Customers and users need a plain statement of what the organization controls and what they control, such as configuration, input data, human review of outputs and permitted uses. The assessor reads the published version and checks that it matches the contracts and the RACI chart. Mismatches between marketing claims and the operational split are a frequent finding. Keep a dated archive of each published version so you can show what a customer saw at a given time.

Review log of responsibility changes

The review log records each time the allocation was revisited, why, who approved the change and which artifacts were updated as a result. Triggers include a new supplier, a model replacement, a material incident, a change in regulation or a contract renewal. The assessor checks that the log is complete and that the review happened on the stated cycle, not only after an incident. Store the log in a version-controlled wiki or document system so edits and approvals are traceable.

Link to the statement of applicability

The statement of applicability explains which Annex A controls the organization includes or excludes under clause 6.1.3. For A.10.2, the assessor checks that the inclusion decision cites the responsibility artifacts above and that any exclusion has a documented justification. A control marked as not applicable while the organization clearly shares life cycle work with suppliers invites questions. Review this link at each change cycle so the statement and the artifacts never describe different organizations.

What meeting A.10.2 costs in money and effort

This table compares the main cost components of allocating AI life cycle responsibilities, showing who does the work, whether the cost is one-time or recurring, what pushes it up or down, and how to keep it contained. Read it as a checklist for scoping and quoting, not as a price estimate. The main takeaway is that open-source records tools can remove license spend, but the people time for mapping responsibilities and drafting contract language stays with the organization and its advisers.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Inventory and mapping effort	One-time, then recurring when systems change	Number of AI systems, models, datasets and third-party services in scope, and how well existing asset records are kept	Start from an existing asset register, limit scope to systems in production first, and assign one owner per system
Contract review and drafting by legal	One-time per contract, recurring at renewal	Number of suppliers and customers, and whether standard terms already address model updates, data use and incident duties	Build a standard clause set for AI responsibilities and reuse it across contracts
RACI workshops with engineering and product	One-time, with occasional follow-up sessions	Number of life cycle stages covered and how many teams hold part of each decision	Prepare a draft RACI before the workshop and limit each session to one life cycle stage
Tooling or licenses	Recurring if commercial, one-time for setup	Choice between commercial governance software and self-hosted open-source wiki or GRC tools, plus hosting and backup needs	Self-hosted open-source records tools can remove license spend, but hosting, administration and access setup still need budget
Periodic review effort	Recurring	How often responsibilities change, such as new suppliers, model swaps or product launches, and whether change triggers are defined	Tie reviews to change events and to the management review cycle instead of ad hoc requests
External review of contract language	One-time, plus recurring for major renewals	Complexity of cross-border data terms, liability caps and the number of jurisdictions involved	Ask counsel to review the standard clause set once, then limit external review to deviations
Auditor sampling effort	Recurring at each audit cycle	Number of AI systems and contracts the auditor samples, and whether records show who decided what and when	Keep the RACI and contract register current so samples can be pulled quickly

Open-source tools that hold the A.10.2 records

A.10.2 is only as useful as the records behind it. The three tools below cover different parts of that record: a compliance workspace that links the control to its evidence, a versioned wiki for the allocation text and RACI, and a permissioned knowledge base that controls who can change it. Each one needs confirmation against your own environment before you rely on it for audit evidence.

Track the control and its evidence

CISO Assistant ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2 and the EU AI Act family, and runs audits and assessments with automatic mapping between frameworks. For A.10.2, you can record the control, link the responsibility split to the contract clauses and RACI pages that prove it, and track its assessment status. The license is AGPL-3.0-only, so confirm with counsel what modifying and hosting it for internal users requires. Also confirm whether its catalog includes ISO/IEC 42001 and how complete its AI governance coverage is before you rely on it.

Version the allocation text

XWiki keeps every change to a page under version control, recording what changed, when and by whom. You can compare any two versions and roll back to an earlier one. This suits the written allocation of responsibilities and the RACI narrative, where an assessor will ask who agreed a split and when it changed. Evidence produced: a dated change history per page. The license is LGPL-2.1-or-later, which governs distribution of modified library code, so review it with your legal team if you change the software itself.

Restrict who edits the records

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. For A.10.2, this lets you keep the RACI editable by the AI governance owner while legal and procurement have read-only access to the contract summaries. Evidence produced: a record of which roles hold edit rights to each responsibility page, which you can export and show in an audit. BookStack is MIT licensed, so the main caveat is operational: confirm that your role model matches the accountable owners named in your RACI.

Who owns the split, who prepares it, and who tests it

Your organization owns the allocation. Its leaders decide which party carries each life cycle responsibility for an AI system, and those decisions bind the company in front of customers, regulators and assessors. Several functions must contribute, and each one owns a specific part of the split.

Accountable AI governance owner: Holds the final decision on the split and signs off the RACI chart. This role should be named in the AI policy and in the roles defined under A.3.
Legal: Writes or approves contract clauses that assign model, data, incident and change responsibilities, then checks that the wording matches what engineering actually does.
Engineering: Documents technical handovers, such as who patches a hosted model, who owns the monitoring pipeline and who responds when a deployment fails.
Procurement: Records which suppliers and platforms sit in the chain and makes sure supplier terms pass the agreed responsibilities down to them.

Before sign-off, check that every named owner can point to the contract clause or runbook that supports their role.

Where A.10.2 responsibility splits usually break down

Responsibility splits for AI systems rarely fail in the org chart. They fail in the gaps between what people agreed verbally, what the contract says, and who actually runs the system day to day. The cards below cover the gaps that most often leave an assessor asking who owns a control, and what to put in place to close each one.

Verbal agreements missing from contracts

Teams often agree in meetings that a vendor will handle model evaluation, bias testing or output monitoring, then never write it into the statement of work or data processing terms. Under A.10.2 the split has to be recorded, not remembered. Check each life cycle stage (design, data, deployment, operation, retirement) against the signed contract and flag any responsibility that exists only in email or meeting notes. Close the gap by amending the contract or by documenting the allocation in an internal RACI that both parties sign off.

Model updates with no owner

When a supplier changes a foundation model version, the change can alter behavior, safety filters and data handling without anyone inside the organization reviewing it. A vendor-side update often falls between the product team, the platform team and procurement. Ask who receives change notices, who decides whether a new version is accepted, and who re-runs the impact checks. Record that owner in the RACI and in the supplier terms, including what happens if the supplier retires a version you depend on.

Customer-operated systems without a boundary

Where a customer configures, prompts or fine-tunes an AI system you supply, responsibility for outputs can drift to whoever is closest to the decision. Illustrative example: a SaaS provider assumes the customer controls prompt content, while the customer assumes the provider filters harmful outputs. Document the boundary in a responsibility matrix that names configuration, intended use, monitoring and incident triggers for each party, and link it to the customer agreement so both sides can point to the same text.

RACI charts left stale after reorganization

A RACI chart written before a merger, team split or vendor consolidation often names people who have left or teams that no longer exist. Assessors test whether the chart reflects current practice, so a stale chart is weaker evidence than none. Set a review trigger for reorganizations, supplier changes and new AI deployments, and record the date and approver of each revision. Confirm that the named roles match the current people and that each accountable party has actually performed the task in the review period.

Fine-tuned components with unclear data and incident ownership

A system built on a third-party model, a licensed dataset or an open-weight component that the organization then fine-tunes creates overlapping claims. The supplier may claim the base model, the organization may own the adapted weights, and neither may own the training data provenance or the incident response when outputs cause harm. Map each component to its owner for data rights, security patching, evaluation and incident reporting. Ask suppliers to confirm in writing what they will notify you of and within what timeframe, and confirm the terms with counsel.

Questions buyers ask about A.10.2 cost, effort and outside help

How much effort does allocating AI responsibilities under A.10.2 take?

The effort depends mostly on how many AI systems are in scope, how many external parties touch their life cycle, and how many contracts already define who does what. A single internally built model used by one team needs a short allocation table. A product that relies on third-party models, hosted AI platforms, data suppliers and customer-configured features needs a split for each life cycle stage: design, data, development, deployment, operation, monitoring and retirement. Before estimating anything, ask the vendor or auditor what evidence they expect, and ask your own legal team how many existing contracts already address AI. Those two inventories usually determine the size of the work.

How long does the work take, and what does it need from legal and engineering?

No supplied fact gives a duration for this work, so confirm timing against your own inventory of systems and contracts. The work has two parallel tracks. Engineering documents who operates each component, who patches it, who monitors its outputs and who can disable it. Legal reviews contract terms with suppliers and customers, including liability, data use, model updates, incident notification and audit rights. Each track needs named owners who can make decisions, not only review drafts. Expect the most time in negotiations you do not control, because a supplier may refuse terms that a customer has asked for.

Can we allocate AI responsibilities in-house without outside help?

Yes, if you have people who understand both the AI systems and the contracts that govern them. The organization owns its controls and must make the allocation decisions itself, whether or not it hires help. Organizations that lack a clear AI owner, have undocumented model dependencies or have many inherited supplier contracts often find internal teams spend most of their time discovering facts rather than deciding responsibilities. An outside partner can help gather that information and organize it into a RACI chart and evidence pack. The decisions, signatures and interpretation of contract terms remain with your staff and counsel.

What should a written scope for A.10.2 work include?

A written scope should list the AI systems covered, the life cycle stages in scope, the parties to be mapped, and the documents to be produced. Ask for each of these items in writing:

The inventory of AI systems, models, datasets and third parties included, and what is excluded
The RACI chart format, the roles it covers and who approves it
The contract clauses or contract reviews included, and whether drafting or negotiation is excluded
The evidence pack delivered, its storage location and the version control approach
Named responsibilities for your staff, dependencies and acceptance criteria
Whether any ongoing review or retainer support is included after delivery

A fixed scope agreed in writing before work starts makes the price and timeline traceable to these items. DeployOpen works to written scope, and quotes follow from it.

Can an implementation partner draft our AI RACI chart, and what must it not do?

An implementation partner can draft a RACI chart and the supporting documentation from information your staff provide, and keep it organized as the system changes. The partner must not decide who is accountable for AI risk, sign off on the allocation as if it were approved, or represent the chart as an audit result. Accountability must sit with named people in your organization, and those people must review and approve the draft. Contract terms must be reviewed by your counsel. An auditor or certification body is the only party that issues reports or certificates, so the partner should be clear that its role is preparation and evidence.

Is A.10.2 alone enough for ISO/IEC 42001 certification?

No. A.10.2 is one control among the 38 Annex A controls, and certification depends on the whole management system, including the clause 4 to 10 requirements and the controls your statement of applicability includes. Clause 6.1.3 requires a statement of applicability that lists the necessary controls and justifies each inclusion or exclusion, so a control can be excluded only with a reason. Allocating responsibilities supports A.10.3 and A.10.4, which cover suppliers and customers, and it depends on A.3 roles and A.6 life cycle records. Confirm with a certification body how it will assess the full set of controls in your scope.

How DeployOpen scopes and prepares A.10.2 evidence

DeployOpen helps organizations prepare the systems and records that show how AI life cycle responsibilities are split between the organization, its partners, suppliers, customers and other third parties. The organization keeps ownership of its controls and its contracts, and an independent certification body makes any certification decision.

How we scope

Agree in writing which AI systems and third-party relationships fall within the A.10.2 engagement.
Inventory the life cycle stages where responsibilities shift between your organization and each external party.
Confirm with your legal and procurement teams which contracts and RACI charts will be reviewed and produced.

How we build

Draft a responsibility matrix that maps life cycle activities to named owners in your organization and each partner.
Configure a self-hosted wiki or documentation platform to hold the RACI chart, contract references and approval records.
Test that responsibility records are versioned, reviewable and linked to the AI systems they describe before handover.

How we hand over

Deliver the responsibility records, version history and access model as documented, client-owned artifacts.
Walk your control owners through how to update the RACI chart when a supplier, model or customer relationship changes.
Provide a summary of gaps you must resolve with contract counterparts before an independent assessment.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and periodic reviews of responsibility records are available as a retainer.
Confirm with your certification body which evidence it expects for A.10.2 before finalizing the scope.