9.3 A.10 Third-Party and Customer Relationships
Key Takeaways
- Annex A.10 (three controls, typically A.10.2–A.10.4) covers allocation of AI responsibilities across suppliers and customers, supplier relationships for AI, and responsibilities of customers—accountability for the AIMS is not outsourced.
- Suppliers include AI system providers, development tools, data providers, annotation services, fine-tuning platforms, and LLM/API vendors—not only traditional IT outsourcing.
- Contractual controls should address data use (including training on prompts), change notification, evaluation rights, security/privacy, incident notice, audit/assurance, and role allocation (who does impact assessment, monitoring, user disclosure).
- Lead auditors sample vendor due diligence files, contracts, ongoing monitoring, and critical AI dependencies; a common major NC is no effective AIMS control over critical AI vendors.
- Customer relationships matter when the organization is a provider: customers need clarity on their duties (configuration, human oversight, prohibited uses) so risk is not merely shifted by silence.
9.3 A.10 Third-Party and Customer Relationships
Auditor focus: A.10 asks whether the organization manages AI risk that originates outside its employees and internal code—vendors, APIs, foundation models, data suppliers, and customer configurations—while still owning AIMS accountability. "The vendor is certified" is a starting claim, not the end of sampling.
Annex A.10 Third-party and customer relationships includes three controls (commonly A.10.2–A.10.4). Themes include allocating responsibilities across the AI value chain, managing AI-related suppliers, and addressing customers when the organization provides AI systems or AI-enabled services. With Clause 8.1, A.10 is the Annex A home for AI supply-chain governance.
Principle: Transfer of activity ≠ transfer of accountability. The certified organization retains responsibility for AIMS conformity for AI systems within its scope, including third-party components.
AI vendor risk beyond generic procurement
| AI-specific risk | Example | Control implication |
|---|---|---|
| Model behavior change | Vendor swaps underlying model | Notice + client re-evaluation |
| Training on client data | Vendor trains on prompts / fine-tunes | Contractual ban or ZDR; verify settings |
| Opaque lineage | Unknown training data / licenses | Diligence; documented risk acceptance |
| Evaluation gap | No client test harness | Acceptance testing before production |
| Multi-party cascade | Fine-tune + base model + vector DB | Multi-party RACI |
| Customer misconfiguration | Customer disables oversight | Documented customer duties |
Allocation of AI responsibilities
Ambiguity is a finding when high-risk outcomes have no owner.
| Area | Provider-leaning | Deployer / customer-leaning | Shared |
|---|---|---|---|
| Foundation training / base safety | Often provider | — | Assurance reports |
| Integration, prompts, RAG data | — | Deployer | Data quality rules |
| Impact assessment for specific use | Provider inputs | Primary for use context | Joint for embedded products |
| User-facing disclosure | Provider templates | Deployer localization | Contract annex |
| Production monitoring | Platform metrics | Use-case metrics & overrides | Alert routing |
| Incident notification | Vendor → client | Client → users/regulators | Severity matrix |
Evidence: RACI in contracts or AI supplier standards; architecture with party boundaries; SoA that does not mark client-side duties "N/A – vendor."
Supplier categories to sample
Build the list from the AI inventory and data lineage, not only strategic IT vendors.
| Supplier type | Examples | Diligence focus |
|---|---|---|
| AI system / model providers | SaaS decisioning, vision APIs, LLM platforms | Evals, safety, change control, subprocessors |
| Development tools | MLOps, labeling UIs, feature stores | Pipeline integrity, access, audit logs |
| Data suppliers | Datasets, synthetic data, market feeds | Provenance, rights, quality, bias |
| Annotation / RLHF | Outsourced labelers | Quality sampling, confidentiality, workforce practices |
| Fine-tuning / hosting | Managed fine-tune, training cloud | Retention, isolation, IP |
| Embedded AI | CRM with AI scoring | Same if in AIMS scope |
Shadow AI: Departmental SaaS AI never entered vendor risk → A.10 + inventory/scope + A.9 when material.
Contractual controls
| Clause theme | Why it matters |
|---|---|
| Role allocation | Who is provider/deployer for which duties |
| Data use & training | Whether client data trains vendor models |
| Security & confidentiality | Prompts, embeddings, fine-tune sets |
| Change / deprecation notice | Time to re-test before behavior changes |
| Incident notice | AI failure modes, not only breaches |
| Assurance / audit rights | SOC, questionnaires, assessment rights |
| Subprocessors | Downstream hosts and processors |
| Exit / portability | Enables risk treatment by switching |
| Customer duties (if you are provider) | Required configs, prohibited uses, oversight |
Weak: Marketing-only MSA; security schedule with no AI; unlimited unilateral model change with no client evaluation window for high-risk uses.
Auditor sampling: diligence, LLMs, APIs, fine-tuning
Pre-use pack (critical vendor): inventory link; security/privacy plus AI questions (evals, bias process, training-on-customer-data); vendor model/system docs; legal/IP/data rights; risk acceptance; production approval gate.
Ongoing LLM/API checks:
| Check | Pass | Fail |
|---|---|---|
| Allow-listed endpoints / versions | Managed config | Any personal API key |
| Client evaluation | Golden set before major version | "Looks good in chat" |
| Monitoring | Quality, abuse, safety filters | Invoice-only monitoring |
| Change detection | Owner reacts to notices | Nobody reads changelog |
| Data path | Contract and console settings verified | Retention unknown |
Fine-tuning: storage of fine-tune data; export of weights; vendor reuse; post-tune evaluation; rollback; link to A.7 and A.6.
When auditee is provider: sample customer onboarding for customer responsibilities, prohibited use, required oversight, and handling of customer misuse. "Customer owns everything" without clear allocation fails A.10 when the provider markets a managed AI outcome.
Common NC: no AIMS controls over critical AI vendors
Pattern: Highest-impact system is a third-party LLM or scoring API. Many A.6 development controls are N/A (sometimes justified), but A.10 is N/A or "covered by procurement." Procurement is generic insurance/DPA with no AI criteria, no re-evaluation on model change, no client monitoring, no AI vendor-risk owner.
| Severity driver | Why serious |
|---|---|
| High impact on people / regulated decisions | Residual risk unmanaged |
| Single critical dependency | Concentration risk |
| Customer data in prompts/fine-tunes | Confidentiality + training risk |
| No exit plan | Cannot switch as treatment |
| Marketing relies on vendor behavior | A.8 accuracy also fails |
Finding direction: Major NC against A.10 (often 8.1). Remediation: AI supplier standard; criticality tiering; mandatory AI diligence; contract playbook; evaluation harness; change-triggered re-assessment; SoA that shows real A.10 implementation.
Integration and Stage 2 trail
| Interface | Relationship |
|---|---|
| 8.1 | Operational control of external processes/products/services |
| A.5 / 6.1.4 | Use-context impacts still assessed |
| A.6 / A.7 | Client deployment, monitoring, third-party data |
| A.8 / A.9 | Disclosure split; use of supplied tools |
| ISMS | Security supplier controls are complementary, not sufficient |
Trap: Vendor ISO/IEC 42001 certificate ≠ client AIMS conformity. The certificate covers the vendor's scope; the client still controls integration, use, data, monitoring, and outcomes in its scope.
Trail: From inventory pick top externally dependent systems → diligence + contract + last review → "What happens when the vendor changes the model?" → one vendor-related change/incident → SoA vs reality → if provider, one customer agreement for duty allocation.
A.10 is effective when every critical AI dependency has an owner, diligence, contract, monitoring, and clear split of duties—and "the vendor handles AI" never excuses an empty control set.
Which statement best reflects Annex A.10 accountability for a certified organization that relies on a third-party LLM API for a high-impact process?
An auditor finds that the organization’s most critical scoring engine is a third-party API, procurement used only a generic security questionnaire from 2019, and no AI-specific diligence, change notification, or client evaluation exists. What is the most accurate characterization?
When the audited organization is an AI system provider, why do customer responsibilities matter under A.10?
Which contractual package best supports A.10 for a fine-tuning service handling sensitive client data?