Control A.10.3 – Suppliers
In today's article by Kimova AI, we examine Annex A Control A.10.3 – Suppliers, the control that extends your AI governance to everyone who contributes to your AI systems without working for you.
Very few organizations build AI entirely in-house. Datasets, pre-trained models, cloud infrastructure and tooling all arrive from outside — and each one carries its supplier's risk into your environment. In an interconnected AI landscape, your risk posture is only as strong as your weakest supplier.
Objective of Control A.10.3
The control requires organizations to identify, assess and monitor suppliers that deliver AI-relevant components, ensuring they align with the organization's security, ethical and compliance standards.
Crucially, it applies for the duration of the relationship — not just at onboarding.
Which suppliers are in scope
- data suppliers and aggregators — training, validation and enrichment datasets
- model providers — pre-trained, foundation and fine-tuned models
- cloud and infrastructure providers — compute, storage and hosting
- AI tooling vendors — MLOps, labelling, monitoring and evaluation platforms
- external developers and consultants building or maintaining AI components
What auditors look for
From an ISMS auditor's perspective, conformity rests on demonstrable process:
- risk assessments performed before onboarding, and repeated on a defined cycle
- AI-specific contractual terms and SLAs — not generic IT clauses retrofitted to AI
- ongoing monitoring and audits proportionate to the supplier's criticality
- incident reporting obligations, with agreed timelines and escalation routes
- exit and continuity provisions for when a model or dataset is withdrawn
Generic vendor questionnaires are the most common weak point. A supplier assessment that never asks about training data provenance, model updates or bias testing is not an AI supplier assessment.
Real-world pitfalls
- biased or poorly documented training data inherited from a dataset vendor
- silent model updates that change behaviour in production without notice
- vulnerabilities in AI tooling that sit outside the usual patching process
- unclear data-use rights, where a supplier's terms conflict with your own commitments
- concentration risk — several critical AI functions resting on a single provider
Best practices
- classify AI suppliers by criticality and assess them proportionately
- require notification of material model or dataset changes as a contractual term
- test what you can: sample the data, evaluate the model, verify the claims
- keep supplier records inside your AIMS so they are audit-ready rather than reconstructed
- review the supplier register whenever the AI system changes, not only annually
Conclusion
Annex A Control A.10.3 recognises that AI risk arrives through the supply chain as readily as it emerges internally. Structured identification, assessment and monitoring of suppliers is what allows an organization to stand behind an AI system it did not build end to end.
At Kimova AI, we treat supplier governance as inseparable from AI assurance — you cannot certify what you cannot see.
In the next article by Kimova.AI, we'll explore Annex A.10.4 – Customers, covering how organizations inform customers about AI use and define responsibilities for AI-driven outputs.