8.2 Control Objective A.10: Third-Party & Customer Relationships

Annex A.10: third-party and customer relationships

AI value chains distribute data, models, infrastructure, integration, use, and support across organizations. A.10 ensures the organization understands and allocates responsibilities and appropriately addresses value-chain risks when third parties participate at any lifecycle stage.

The group has three controls: A.10.2, A.10.3, and A.10.4.

A.10.2 Allocating responsibilities

The organization ensures responsibilities across the AI system lifecycle are allocated among the organization, partners, suppliers, customers, and other third parties.

Allocation should address the actual relationship. Relevant responsibilities can include:

• requirements and intended-use definition;
• data acquisition, quality, provenance, and preparation;
• design, development, verification, and validation;
• deployment, integration, monitoring, support, and event logging;
• user information and incident communication;
• changes, vulnerabilities, and end-of-service planning; and
• risk and impact evidence.

A responsibility matrix, contract schedule, service description, architecture record, or operating procedure can provide evidence. No single “shared responsibility model” applies to all AI services.

Responsibility allocation does not itself decide legal liability. Contracts cannot erase duties imposed by applicable law, and ISO/IEC 42001 does not declare the customer or provider automatically “fully liable” for every outcome.

A.10.3 Suppliers

The organization establishes a process to ensure that use of services, products, or materials supplied by others aligns with its responsible-development and responsible-use approach.

The process can include selection criteria, due diligence, contractual terms, acceptance testing, monitoring, change notification, incident coordination, data handling, assurance evidence, and exit planning. Depth should be proportional to risk and dependency.

The control does not mandate every contract to include model-weight disclosure, zero retention, unlimited audit rights, financial penalties, or a particular SLA. Those can be appropriate requirements in a specific context.

Supplier examples

• A hosted model can change behavior or interface. The organization may require notice, regression testing, monitoring, and rollback or alternative arrangements.
• An open-source model can introduce license, provenance, security, or support issues. The organization may verify packages, isolate execution, evaluate documentation, and manage updates.
• A data-labeling provider can create confidentiality and quality risks. The organization may define instructions, access, competence, sampling, and incident requirements.

Supplier certification to ISO/IEC 27001 or 42001 can be relevant evidence but does not replace evaluation of the supplied product and intended context.

A.10.4 Customers

The organization ensures that its responsible approach to AI development and use considers customer expectations and needs.

When supplying an AI product or service, relevant customer needs can involve intended use, limitations, documentation, integration, support, performance, security, privacy, accessibility, incident reporting, changes, and responsibility allocation.

The control does not require disclosure of proprietary source code or a guarantee of 100 percent accuracy. It requires customer expectations and needs to inform the responsible approach.

A provider can define customer duties in contracts or acceptable-use terms. Those duties should be realistic, communicated, and consistent with the provider’s own responsibilities.

Relationship to other controls

A.10 connects to:

• Clause 4.2 interested-party requirements;
• Clause 8.1 control of externally provided processes, products, and services;
• A.4 resource documentation;
• A.6 technical documentation and lifecycle operation;
• A.8 user and interested-party information; and
• A.9 responsible use and intended use.

A supplier performs part of the lifecycle, but the certified organization still needs its own process and evidence. Conversely, a provider should not assume customers will discover limitations without adequate information.

Example: hosted foundation model

A financial organization uses a hosted foundation model for document classification.

Under A.10.2, it allocates responsibilities: the supplier maintains base infrastructure and model service; the organization defines document types, configures integration, validates performance, controls inputs, monitors outputs, and handles business decisions. Incident and change responsibilities are shared and documented.

Under A.10.3, the organization evaluates whether the service’s data handling, change practices, documentation, availability, and support align with its responsible-use approach. It establishes appropriate requirements and monitors them.

If the organization then offers the classifier to corporate customers, A.10.4 makes customer needs part of design and operation. It supplies relevant limitations, integration instructions, reporting routes, and change information.

A golden regression set and a zero-retention term might be good controls. They are examples, not mandatory wording of A.10.3.

Correcting common numbering errors

• A.10.1 is the objective row, not “responsibilities of suppliers.”
• A.10.2 is allocating responsibilities.
• A.10.3 is suppliers.
• A.10.4 is customers.

A guide that calls A.10.2 “third-party AI system risk management” and A.10.3 “customer responsibilities and communication” changes the official control titles and misses the allocation structure.

Exam approach

For a third-party scenario, ask:

1. Have responsibilities been allocated across parties?
2. Does supplier use align with the organization’s responsible-AI approach?
3. Are customer expectations and needs considered?
4. Are relevant external services controlled under Clause 8.1?
5. Is the allocation reflected in risk, impact, documentation, and communication?