AI governance · ISO/IEC 42001 · Third-party risk
Your company can buy an AI system without gaining control of its model, its upstream dependencies, or the evidence needed to assess it. That does not make the governance decision somebody else’s problem.
A customer-service platform may call a commercial foundation model. An internal assistant may combine hosted inference, retrieval, external datasets, and tools. A fraud-detection vendor may change its model while the customer leaves its own software untouched. At every boundary, some technical control and knowledge move to another organization.
ISO 42001 third-party AI governance is concerned with what happens next: who remains responsible, what evidence is available, which conditions the organization can enforce, and whether continued use is justified when important facts are outside its control.
01 / Direct answer
What does ISO/IEC 42001 require for third-party AI?
ISO/IEC 42001 requires organizations to control externally provided processes, products, and services relevant to their AI management system. Its Annex A.10 addresses relationships with suppliers, partners, customers, and other third parties, including allocation of AI lifecycle responsibilities and supplier processes.[1]
This is not a rule that every supplier must hold ISO 42001 certification or deliver full access to proprietary source code. It is a management-system obligation to identify and address risks through controls appropriate to the organization’s role, intended use, and operating context.
Three parts of the standard are particularly relevant:
| Location | What it addresses | Implication for AI users |
|---|---|---|
| Clause 8.1 | Operational control of relevant externally provided processes, products, and services | Govern relevant supplier contributions throughout operation, not only during purchase. |
| Annex A.10.2–A.10.3 | Allocation of responsibilities and supplier processes | Record the division of control and the supplier requirements that matter for responsible AI use. |
| Clause 6.1.3 | Risk treatment, control selection, and the Statement of Applicability | Choose necessary controls, justify applicability decisions, and add controls when Annex A is insufficient. |
The distinction between a management-system requirement and a proposed implementation method matters. The standard sets the governing expectations; the practical workflow later in this article is an InfoSecured.ai interpretation, not a mandatory ISO checklist.
02 / Accountability
The supplier may own the model. You still own the decision to rely on it.
Research on AI development describes how responsibility can become fragmented across the companies and people who supply models, data, software, and infrastructure. Widder and Nafus interviewed 27 AI engineers and found that participants often regarded responsible-AI questions as lying outside their own authority or ability to act. The authors called this dislocated accountability.[4]
A later integrative review by Attard-Frost and Widder examined 67 sources discussing ethical concerns across AI value chains. Its contribution is a reminder that AI is not simply a bilateral relationship between a buyer and one vendor.[5]
For directors, the problem is easier to understand when four questions are kept separate.
Who is accountable for the business use, consequences, response, and affected parties?
Who can change models, permissions, safeguards, data, or service behavior?
Who can produce credible records of performance, testing, change, and incidents?
Who can approve, limit, challenge, suspend, or terminate the use?
These are not necessarily the same party. A supplier may control the model while the customer controls its inputs, authorizations, downstream actions, and business workflow. Neither party’s documentation alone necessarily describes how the assembled application behaves in production.
03 / Dependency mapping
Start with the AI you actually use, not just the vendor you pay
A vendor register usually names the company on the contract. That record can be useful for procurement and payment, but it may not describe the AI system at the point of use.
Consider a company using a SaaS assistant to handle employee questions. The service may include a hosted language model, an embeddings service, a document index, an identity provider, and tools that can read or update enterprise systems. Some of these components may be separately operated and capable of changing without customer approval.
The inventory should identify the business use, internal owner, supplier and product, material model or service dependencies, data boundaries, permissions, and relevant versions or configurations where known. It should also record what is unknown. NIST’s AI RMF treats risks from third-party systems and resources as a management issue rather than only a procurement concern.[2]
The objective is not an impossible inventory of every component worldwide. It is visibility into dependencies capable of materially changing a decision about the organization’s AI use.
04 / Evidence sufficiency
A vendor document is useful only for the claim it can support
Supplier assurance can deteriorate into document collection. A questionnaire is completed, an audit report is filed, a model card is received, and the system becomes “approved.” That process can miss the more important question: What has actually been demonstrated for the way this organization plans to use the AI?
Model cards were proposed as a structured way to describe intended uses, evaluations, performance characteristics, and limitations. They can be valuable. But a model card generated under one test setting does not, by itself, establish how an application works with your data, permissions, users, and decision processes.[6]
Evidence needs scope. Records should be linked to the claim, product or feature, version or deployment state, business use, reviewer, time period, known limitations, and an approval or restriction decision.
| Artifact | What it can support | What it does not prove alone |
|---|---|---|
| Supplier questionnaire | Recorded assertions, disclosed practices, control ownership, and open questions | Independent evidence that controls work in practice |
| Model card / technical note | Intended use, evaluation context, limitations, selected test results | Fitness for your actual workflow or all downstream controls |
| Security assurance report | Specified controls within an examined service, scope, and period | Every AI quality, safety, bias, performance, or use-case claim |
| Customer-side evaluation | Behavior under specified local tasks, datasets, configurations, and conditions | Behavior across untested versions, uses, or future changes |
| Supplier ISO 42001 certificate | Relevant evidence about the supplier’s AIMS within its certification scope | That a particular AI product is fit for your use or legally compliant |
Where evidence is important but inaccessible, the gap should remain visible. A supplier’s refusal to disclose model weights is not necessarily fatal; inability to test a consequential claim or detect material changes may be.
See the separate Vendor AI Risk Evidence guide for how to record claims, evidence provenance, limitations, independent tests, and decision conditions without pretending document volume equals assurance.
05 / Proprietary AI
What if the vendor will not disclose how the model works?
The wrong answer is that every proprietary system is ungovernable. An equally weak answer is that the vendor’s commercial confidentiality justifies accepting its claims without challenge.
NIST’s AI RMF Playbook provides suggested actions for testing, evaluation, validation, and verification of third-party AI systems, including approaches that address transparency needs without requiring proprietary algorithm disclosure.[3] Depending on the application, organizations can examine outputs, test workflows, review access restrictions, inspect logs, obtain assurance reports, evaluate known limitations, and observe operations.
These approaches do not restore every missing fact. The question is whether the resulting evidence and compensating controls are sufficient for the consequence of the use. An internal drafting assistant and an automated system affecting financial or medical decisions do not require identical confidence levels.
Training-data detail is unavailable, but customer-specific evaluations, scoped technical documentation, access controls, change notification, and operating monitoring support a constrained use.
The AI can take consequential actions, but the organization cannot establish permitted behavior, detect changes, test critical boundaries, or suspend use reliably.
Those are illustrative judgments. They are not ISO-defined thresholds. An organization must document its own criteria and any relevant legal or regulatory obligations.
06 / Supplier terms
The contract determines which controls you can realistically enforce
Contract language is frequently negotiated before AI governance teams know which evidence and operational rights they will need. That order can leave the organization unable to exercise the controls it later writes into policy.
The NIST Generative AI Profile recommends supplier-risk assessments, inventorying third-party entities, and contractual provisions that allow organizations to evaluate third-party generative-AI processes and standards. It also addresses monitoring of supplier performance and AI value-chain dependencies.[7]
For material uses, contract review should examine change notification, data processing and retention, access to relevant evidence, incident reporting, audit or assessment rights, subprocessor visibility, remediation, business continuity, and exit or transition support.
Not every contract needs identical clauses. Some suppliers may offer narrow rights. That commercial reality does not disappear through policy wording: it must be considered as an explicit control limitation, addressed through alternatives, or reflected in the approval decision.
Identify the evidence, restrictions, and rights needed to justify the proposed use.
Confirm the supplier’s commitments produce usable records, notification, and escalation capability.
Use the agreement and local controls to reassess, constrain, or exit the dependency.
07 / Continuing assurance
The original approval can become obsolete without any change to your code
Third-party AI is not static. A model provider may update the model, adjust filtering, change a service tier, introduce new tool use, revise data retention, or replace infrastructure. A SaaS provider may alter its prompts or switch upstream models. Even an unchanged customer workflow can behave differently.
ISO/IEC 42001 calls for controlled changes and risk reassessment when significant changes arise. The NIST AI RMF similarly emphasizes ongoing monitoring and decisions about continued deployment and treatment of identified risks.[1][2]
| Material event | Question for the owner | Potential response |
|---|---|---|
| Model/version change | Are earlier evaluations still representative? | Regression test material functions; revalidate approval conditions. |
| New provider or subprocessor | Do data, responsibility, or concentration assumptions still hold? | Review supplier dependencies and contract rights. |
| Added autonomy or tools | Can the system now act beyond its approved boundary? | Recheck permissions, approval gates, and stop mechanisms. |
| Incident or degraded output | Is continued use still justified? | Investigate; restrict or suspend if warranted; update risk treatment. |
One supplier failure can affect several systems
Different AI applications may depend on the same foundation model, cloud provider, or data source. An upstream failure can therefore affect apparently unrelated business processes. For material use, management should know which dependencies are shared, how much disruption is tolerable, and which fallbacks are actually workable. NIST AI 600-1 includes consideration of over-reliance on third-party systems and value-chain risks.[7]
08 / Director and CISO oversight
What should executives ask before relying on third-party AI?
Executives do not need a longer supplier questionnaire. They need a reliable explanation of the business use, material dependencies, control ownership, evidence and uncertainty. These questions are designed for review discussions, not to generate a single compliance score.
| Executive question | Decision-relevant record |
|---|---|
| Where do we rely on third-party AI? | Use-case register with business owner, vendor, and material dependencies. |
| What is the AI allowed to do? | Intended use, permissions, exclusions, consequential actions and approval boundaries. |
| Who controls what? | Allocation of supplier, customer and shared responsibilities. |
| What proves this use is acceptable? | Scoped tests and assurance records linked to the claim, configuration, and time period. |
| What can we not verify? | Material evidence gaps, compensating controls and documented acceptance conditions. |
| What would invalidate approval? | Change/incident triggers, monitoring indicators, named owner and review authority. |
| Can we stop or replace it? | Technical disablement, fallback, exit terms and transition plans. |
These questions also make the role of internal audit clearer. Audit can challenge whether the organization’s chosen controls and evidence actually support its decisions; it should not be expected to certify the safety of a vendor’s model simply because a checklist was completed.
09 / Worked example
When a vendor cannot supply everything management wants to know
Fictional example: A financial institution considers a third-party AI assistant for internal customer-complaint summaries. The supplier provides service documentation and a security assurance report, but will not share all evaluation details or disclose some upstream model arrangements.
The organization should not record only “vendor approved.” A more useful record would distinguish an allowed use from an evidence limitation.
- Proposed scope: draft internal summaries only; no final decisions or direct customer communications.
- Local controls: authorized access, restricted inputs, independent staff verification against source records, and proportionate logging.
- Testing: representative complaint categories, factual error checks, and access-control tests in the intended environment.
- Unresolved: incomplete evidence on some model behaviors and restricted visibility into supplier changes.
- Decision: limit deployment, specify monitoring and change conditions, assign an owner, and preserve the right to suspend use.
This illustration does not establish that the hypothetical system is safe, effective, compliant, or ISO-conformant. It shows how an organization can make the distinction between what it knows, what it cannot verify, and what it has chosen to accept.
The output of vendor due diligence should be a decision that another reviewer can reconstruct—not a completed procurement file.
For a deeper recordkeeping method, see the AI Assurance Evidence Review Kit. For AI-specific workflows involving retrieval, model changes, or tool permissions, see LLM and RAG Risk.
10 / FAQ
ISO 42001 third-party AI: common questions
Does ISO 42001 cover third-party AI?
Yes. Clause 8.1 addresses relevant externally provided processes, products and services; Annex A.10 addresses third-party relationships, responsibility allocation and suppliers. Annex A control decisions follow the organization’s risk-treatment and Statement of Applicability process.
Does ISO/IEC 42001 require every AI vendor to be certified?
No. The standard does not impose a universal requirement for all suppliers to hold ISO/IEC 42001 certification. Any supplier certificate should be interpreted according to its scope and the customer’s intended use.
Can a vendor’s model card substitute for local testing?
Not automatically. Model cards can describe intended uses, evaluation contexts and limitations, but they cannot establish how an untested customer workflow behaves with different data, configurations, permissions, or dependencies.
Can proprietary or black-box AI be governed?
Sometimes. Testing, monitoring, contractual information, third-party assurance and operational restrictions can support a bounded decision without access to model internals. The organization should document unavailable evidence and reject or limit uses where critical claims cannot be supported.
When should a third-party AI assessment be repeated?
At risk-based planned intervals and when material incidents, model changes, new features, provider changes or other events can invalidate the original assessment. No single universal review interval fits all systems.
Does supplier ISO 42001 certification prove that the AI product is safe?
No. Certification can provide evidence about a supplier’s AI management system within its stated scope. It does not independently prove that a specific product is fit for every customer use, free of material risks or compliant with every applicable law.
Executive conclusion
Control the reliance decision, even when you cannot control the model
Organizations can neither demand complete visibility into every AI supplier nor treat commercial opacity as an exemption from governance. The obligation is to understand the use, identify material dependencies, allocate responsibilities, gather appropriate evidence, and make explicit decisions about the uncertainty that remains.
ISO/IEC 42001 provides a management-system structure. Management must decide what evidence is enough—and when continued reliance is no longer justified.
11 / Research and primary sources
Verified references
ISO requirements are interpreted from the 2023 standard. Public links below point to authoritative standard, NIST, and publisher records. The figures, practical questions, and fictional example are InfoSecured.ai original interpretations, not additional standard requirements. NIST AI RMF 1.0 is under revision; check status at the time of future updates.
- ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. Relevant provisions: clauses 6.1.3 and 8.1, Annex A.10 and Annex B.10. Official ISO record.
- National Institute of Standards and Technology (2023). AI Risk Management Framework (AI RMF 1.0). DOI: 10.6028/NIST.AI.100-1.
- NIST. AI RMF Playbook — Manage. Official guidance.
- Widder, D. G., and Nafus, D. (2023). “Dislocated accountabilities in the ‘AI supply chain’: Modularity and developers’ notions of responsibility.” Big Data & Society. DOI: 10.1177/20539517231177620.
- Attard-Frost, B., and Widder, D. G. (2025). “The ethics of AI value chains.” Big Data & Society. DOI: 10.1177/20539517251340603.
- Mitchell, M., et al. (2019). “Model Cards for Model Reporting.” Proceedings of FAT* 2019. DOI: 10.1145/3287560.3287596.
- NIST (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. DOI: 10.6028/NIST.AI.600-1.
Related InfoSecured.ai resources
Continue the vendor AI review
Vendor AI Risk · Vendor AI Risk Evidence · AI Assurance Evidence Review Kit · Evidence Library