Control · C-005 · Third Party & Supply Chain

Third-party model and vendor due diligence

Before an AI supplier, model or dataset is adopted, it is assessed against AI-specific criteria to a depth set by how material the use is, with evidence for the answers.

Control type: Directive
Family: 06 Third Party & Supply Chain
Risks addressed: 15
Audience: Heads-of · Practitioner
Frameworks: Article 28 · Chapter V · Annex A.10 · GOVERN 6
Responsible AI domain: 06 Third Party & Supply Chain
Lifecycle stage: 1 Ideate & screen
2 Assess & tier
5 Approve
Reviewed: 2026-11-11

What it does

It finds out what the organisation is taking on before it is committed. The assessment covers what a standard software review omits: how the model was trained and on what data, how it was tested and for whom, how it changes, what the supplier does with customer data, where processing takes place, who else is in the chain, and what has gone wrong before. Third-party risk or procurement runs it; the business owner of the system is accountable for the decision. It operates before contract and is refreshed on renewal or material change.

How to implement it

Tier suppliers by the materiality of the use, and set the depth of assessment for each tier.
Use AI-specific questions on training data, evaluation, change control, data use and incident history.
Ask for evidence: test results, model documentation, certifications, sub-processor lists.
Confirm processing locations and transfer mechanisms.
Involve risk, security, data protection and legal, each for their part.
Record the residual risks and who accepted them.

Evidence it operates

Design: a due diligence standard with tiers and an AI question set. Operation: completed assessments dated before contract; supplier evidence on file; examples of a supplier rejected or conditions imposed; refreshed assessments at renewal.

Where it fits

At selection, before contract. It is the primary control for inadequate AI vendor due diligence, third-party model and dataset provenance, sub-outsourcing visibility gap, missing provider documentation and cross-border AI data transfer risk. Its findings are secured through AI contract terms. The AI vendor due diligence questionnaire gives a starting question set.

Limits

It relies on what the supplier chooses to disclose, and large providers answer with standard documents. It describes the supplier on the day of assessment. A small customer has little power to obtain more.

Risks this mitigates

Primary mappings

Cross-border AI data transfer risk Medium: Establishes where a supplier processes and stores data before contracting. Personal data processed by an AI system, often through a cloud or model provider, is sent outside the UK without a valid transfer mechanism.
Inadequate AI vendor due diligence High: Carries out the AI-specific assessment of the supplier. An AI supplier is taken on without due diligence proportionate to how material its system is, or with a generic assessment that never asks the questions specific to AI.
Loss of control of advanced AI Medium: Selects providers with credible safety evaluation and commitments. A highly capable AI system pursues objectives or acquires capabilities beyond the oversight of its developer or deployer, and cannot readily be corrected or stopped.
Missing provider documentation Medium: Makes adequate documentation a condition of selecting the provider. A provider does not supply the information a deployer or downstream builder needs to assess, integrate and oversee its model.
Sub-outsourcing visibility gap Medium: Identifies the supplier's own AI suppliers before contracting. An AI supplier relies on its own suppliers for models, hosting, data or labelling, and the organisation has no visibility of that chain and no contractual hold over it.
Third-party model and dataset provenance Medium: Examines the origin, training and testing of an external model or dataset before use. A model, dataset or component is adopted from an external source with no verified account of where it came from, how it was made, what rights attach to it or how it has changed.

Supporting mappings

Copyright infringement in training data High: Establishes how a provider's model was trained. A model is trained or fine-tuned on protected works without a licence or an applicable exception, by the organisation or by a provider whose model it uses.
Dangerous capability uplift Medium: Considers the provider's own safety evaluation when selecting a model. A deployed model gives meaningful help towards chemical, biological, radiological or nuclear weapons, serious cyber attack or other mass-harm activity.
Environmental footprint of AI Medium: Obtains providers' environmental data. The energy, water and hardware that training and running AI require conflict with the organisation's environmental commitments, or go unmeasured and undisclosed.
LLM application supply chain vulnerabilities High: Assesses the supplier behind each component. Vulnerable, tampered or mislicensed components, including base models, adapters, datasets, libraries and hosting platforms, enter an AI application through its supply chain.
Malicious model artefacts and unsafe loading High: Assesses the source before its artefacts are trusted. A model file or dependency obtained from a public source executes code or carries hidden behaviour when loaded.
Training data bias and discriminatory outcomes High: Asks suppliers how their training data was assembled and tested. Bias in the data a model learns from, whether from history, sampling or labelling, is reproduced or amplified in its outputs and in the decisions that rely on them.
Training data transparency gap Medium: Obtains the equivalent information from providers. The organisation cannot say what data a model was trained on, to the level regulators, customers or rights holders require.
Unallocated liability for AI harm High: Identifies liability gaps before commitment. Contracts, insurance and internal accountability do not settle who bears the loss when an AI system causes harm.
Vendor reuse of organisation data High: Establishes the provider's default data practices before signing. A provider uses the organisation's prompts, documents or outputs to train or improve its own models, or keeps and reviews them, beyond what the organisation intended.

Framework and clause references

Framework	Clause	Title
Digital Operational Resilience Act (DORA)	Article 28	General principles on ICT third-party risk ICT third-party risk.
EU AI Act	Chapter V	General-purpose AI model obligations
ISO/IEC 42001:2023	Annex A.10	Third-party and customer relationships Supplier relationships.
NIST AI Risk Management Framework (AI RMF 1.0)	GOVERN 6	Third-party and supply chain AI risk Third-party risk.
SS2/21: Outsourcing and Third-Party Risk Management	Chapter 8	Access, audit and information rights Access, audit and information rights.

Related terms

How to cite

Axiom Verity (2026). Third-party model and vendor due diligence. Reference Library, C-005. https://axiom-verity.com/controls/third-party-model-due-diligence. Reviewed 2026-11-11.

Found an error or a better source? Report a correction.