ISO 42001 Annex A 10.3 Manage suppliers to support responsible AI use
What it says
The organization shall establish a process to ensure that its usage of services, products or materials provided by suppliers aligns with the organization's approach to the responsible development and use of AI systems.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSet up a process so that the services, products and materials you buy from suppliers support the responsible development and use of your AI (artificial intelligence) systems.
Most organisations don't build their artificial intelligence (AI) systems entirely on their own. You buy things from suppliers: cloud computing, pre-built AI models, training data, software tools, and even people who do the work. This control asks you to put a process in place so that what you buy from those suppliers fits with using AI responsibly. The point is simple. If a supplier provides a dataset that was collected without consent, a model that is biased or poorly documented, or a service with weak security, those problems become your problems the moment you build them into your AI system. Your customers and regulators will hold your organisation accountable, not the supplier. So before and during your relationship with a supplier, you check that their services, products and materials meet your standards for responsible AI. You set clear expectations in writing, ask suppliers to demonstrate how they meet them, and keep an eye on whether they continue to do so over time. This way, responsibility flows all the way through your supply chain rather than stopping at your own front door.
Free. Save your status, tasks and notes.
Why it matters
Without supplier checks, biased data, weak models or insecure services from vendors flow into your AI systems, creating risks your organisation is accountable for.
How to implement
The procurement or vendor manager creates a short set of responsible-AI requirements (such as data sourcing, bias testing, security and documentation) and includes them in every supplier selection checklist before any AI-related service, product or material is purchased.
The AI or technical lead reviews each supplier's AI components (models, datasets, tools) before they are adopted, requesting evidence such as model documentation, data provenance records or test results to confirm they meet your responsible-AI standards.
The legal or contracts owner adds clauses to supplier agreements that require the supplier to meet your AI requirements, notify you of relevant changes, and allow you to review or audit their compliance.
The vendor manager records every AI-relevant supplier in a register that notes what they provide, the risks involved, and the date their responsible-AI status was last checked, so nothing slips through unmonitored.
The risk or compliance owner schedules regular reviews of key AI suppliers (for example annually or at contract renewal) to confirm they still meet your standards and to act on any new risks identified.
Keep it running
Keep the supplier register current and re-check key AI suppliers at contract renewal or when they change a service, product or material you rely on.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the documented process or procedure that governs how suppliers of AI-related services, products or materials are selected and assessed.
Good evidence
a written process that explicitly references responsible AI development and use, not just price and delivery.
- Check 2 of 5What an auditor asks for
Look at
the responsible-AI requirements built into supplier selection checklists or onboarding.
Good evidence
clear criteria covering items such as data sourcing, bias, security, transparency and documentation.
- Check 3 of 5What an auditor asks for
Ask for
to see two or three recent supplier contracts for AI components.
Good evidence
agreements that contain clauses obliging the supplier to meet your AI standards and to allow review or audit of their compliance.
- Check 4 of 5What an auditor asks for
Look at
the supplier register or inventory for AI-related vendors.
Good evidence
a current list showing what each supplier provides, the associated risk, and the date responsible-AI status was last reviewed.
- Check 5 of 5What an auditor asks for
Ask for
evidence that at least one supplier's AI product or dataset was actually assessed before use.
Good evidence
records such as model documentation, data provenance, or test results reviewed and signed off by a named owner.
Mappings
Closest match in ASD Information Security Manual: ISM-1631, Identify suppliers in cyber supply chain, which this control covers in full and more.
ISO/IEC 27001: 6 mappings
This control partially overlaps A.5.10.
Annex A 10.3 requires a supplier-usage process so that external services/products/materials used for AI align with responsible AI practices. Annex A 5.10 relates where supplier-provided AI tools (e.g., SaaS GenAI, model APIs) are treated as organisational assets and their acceptable use and handling rules constrain how personnel can use them responsibly. Annex A 5.10 is primarily about user behaviour and asset handling, whereas Annex A 10.3 is about supplier assurance and governance of third-party AI inputs and services.
This control partially overlaps A.5.19.
Annex A 10.3 requires a supplier management process ensuring external inputs used in AI align with responsible AI development and use. ISO/IEC 27001:2022 Annex A 5.19 overlaps by requiring processes to manage information security risks in supplier relationships, which applies to third-party data, models, platforms and managed services used in AI. Annex A 5.19 is confined to information security risk, whereas Annex A 10.3 extends supplier management to responsible AI outcomes beyond CIA (e.g., safety, transparency and appropriate use).
This control partially overlaps A.5.20.
Annex A 10.3 requires supplier arrangements that ensure third-party inputs used for AI align with responsible AI development and use. ISO/IEC 27001:2022 Annex A 5.20 overlaps by requiring information security requirements to be agreed in supplier contracts, which is a key mechanism to impose AI-related security clauses (e.g., vulnerability disclosure, logging, data handling, access controls). Annex A 5.20 is security-clause focused, while Annex A 10.3 also requires responsible-AI clauses such as transparency, safety testing, human oversight support and acceptable-use restrictions.
This control partially overlaps A.5.21.
Annex A 10.3 requires a supplier process ensuring third-party inputs used for AI align with responsible AI development and use. ISO/IEC 27001:2022 Annex A 5.21 overlaps by requiring processes to manage information security risks in the ICT supply chain, covering many AI dependencies such as cloud infrastructure, MLOps tooling, third-party model components and data pipelines. Annex A 5.21 is information-security scoped, while Annex A 10.3 extends supplier governance to responsible-AI concerns such as transparency, safety and misuse controls.
This control partially overlaps A.5.22.
Annex A 10.3 requires ongoing assurance that supplier-provided AI dependencies continue to align with responsible AI development and use. ISO/IEC 27001:2022 Annex A 5.22 supports this by requiring monitoring, review, evaluation and change management of supplier security practices and service delivery, which helps detect supplier changes that could affect AI integrity or compliance (e.g., model version changes, hosting configuration changes). Annex A 5.22 is centred on supplier information security performance, while Annex A 10.3 requires a broader responsible-AI monitoring lens (e.g., output safety and transparency commitments).
This control partially overlaps A.5.34.
Annex A 10.3 requires the organisation to ensure supplier-provided services/products/materials used for AI align with responsible AI development and use. Annex A 5.34 overlaps because responsible AI supplier usage frequently includes ensuring PII is handled lawfully by AI vendors (e.g., limits on training, retention, secondary use, cross-border transfer), which must be built into supplier selection and oversight. Annex A 5.34 is specifically privacy/PII compliance, whereas Annex A 10.3 covers wider responsible AI alignment beyond privacy, such as safety, robustness, and accountability.
ASD Information Security Manual: 8 mappings
This control is broader than ISM-1631.
Annex A 10.3 requires a supplier management process to ensure supplier services/products/materials used for AI align with responsible AI development and use. ISM-1631 supports this outcome by requiring suppliers in the cyber supply chain to be identified, enabling the organisation to apply AI-specific due diligence and constraints to the right third parties (e.g., model/API providers, data vendors, annotators). ISM-1631 stops at identification, while Annex A 10.3 requires evaluation, acceptance criteria and ongoing assurance against responsible-AI objectives.
This control is broader than ISM-1736.
Annex A 10.3 requires a process to ensure managed services and supplier deliverables used in AI align with responsible AI development and use. ISM-1736 is a prerequisite subset by requiring a maintained and regularly verified managed service register, which identifies where AI-relevant third-party services exist (e.g., hosted AI platforms, external model endpoints, data labelling services) so they can be governed. ISM-1736 is an inventory control and does not require assessment or enforcement of responsible-AI criteria that Annex A 10.3 mandates.
This control partially overlaps ISM-1452.
Annex A 10.3 requires managing suppliers to ensure AI-related services/products/materials align with responsible AI development and use. ISM-1452 overlaps by requiring supply chain risk assessments to determine impact on a system's security risk profile, which applies to third-party AI models, data sources, MLOps tooling and hosting. ISM-1452 is primarily security-risk profiling, while Annex A 10.3 additionally requires assessment against responsible-AI risks (e.g., bias, safety, transparency and misuse potential).
This control partially overlaps ISM-1568.
Annex A 10.3 requires supplier management to ensure AI dependencies are responsibly developed and used. ISM-1568 overlaps by requiring procurement from suppliers committed to product/service security, which is foundational to trustworthy AI operations (protecting model integrity, data confidentiality and availability). ISM-1568 addresses security commitment only, while Annex A 10.3 extends to broader responsible-AI expectations such as transparency, safety validation and appropriate-use safeguards.
This control partially overlaps ISM-1632.
Annex A 10.3 requires ensuring supplier-provided AI dependencies align with responsible AI development and use. ISM-1632 overlaps by requiring procurement from suppliers with a strong security track record, reducing the chance that AI components (e.g., hosted models, MLOps tools, data pipelines) introduce vulnerabilities or enable tampering. ISM-1632 is limited to supplier security posture, while Annex A 10.3 also covers non-security responsible AI expectations such as transparency, bias management and use constraints.
This control partially overlaps ISM-1785.
Annex A 10.3 requires an organisational process to ensure suppliers used for AI align with responsible AI development and use. ISM-1785 overlaps by requiring a supplier relationship management policy, providing the governance framework under which AI supplier due diligence, contracting requirements and ongoing monitoring can be defined. ISM-1785 is policy-level and cyber supply-chain oriented, while Annex A 10.3 demands AI-specific alignment outcomes (e.g., provenance, safety testing, and acceptable-use constraints) rather than policy existence alone.
This control partially overlaps ISM-1786.
Annex A 10.3 requires a process to ensure supplier inputs and services used by AI systems align with responsible AI development and use. ISM-1786 overlaps by requiring an approved supplier list, which is a governance mechanism to enforce supplier selection based on criteria that can include AI safety, transparency, data provenance and misuse controls. ISM-1786 is an artefact/control for supplier approval, whereas Annex A 10.3 additionally requires AI-specific alignment checks across the supplier lifecycle (selection, contracting, monitoring and change).
This control partially overlaps ISM-1882.
Annex A 10.3 requires supplier management so external services/products/materials used in AI support responsible AI development and use. ISM-1882 overlaps by requiring procurement from suppliers committed to transparency, which directly enables responsible AI assurance such as visibility of training data sources, model limitations, evaluation results and update practices. ISM-1882 focuses on transparency as a procurement criterion, while Annex A 10.3 is broader across other responsible AI requirements (e.g., accountability, human oversight, safety and misuse prevention).
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