A company buys an AI service to summarize customer complaints. The supplier runs the model, chooses its upstream providers, and releases updates. The company decides what customer data to send, how employees use the results, and whether a summary is accurate enough to act on. A vendor review needs to cover both sides of that arrangement.

ISO/IEC 42001:2023 gives organizations a management-system approach to these decisions. It connects AI risk assessment, responsibility, supplier controls, impact assessment, monitoring, and documented review. In practice, the hard part is determining what evidence applies to the system your organization actually uses—not merely collecting supplier policies.

The practical question: What does the supplier control, what can your organization verify, and what evidence supports the decision to use the AI?

Does ISO/IEC 42001 cover third-party AI?

Yes. Clause 8.1 calls for control over externally provided processes, products, and services relevant to an organization’s AI management system (AIMS). Annex A.10 addresses responsibility allocation, suppliers, and customer relationships. Clause 6.1.3 connects the selection of controls to AI risk treatment and the Statement of Applicability (ISO/IEC, 2023).

The standard applies to organizations that develop, provide, or use AI. A company using an external model still manages its own business purpose, deployment, people, data, oversight, and decisions. How much supplier evidence it needs depends on the role of the service and the risks it creates.

Which ISO/IEC 42001 requirements matter for suppliers?

Supplier oversight fits into several connected parts of the AIMS:

• Clause 6.1.3 — AI risk treatment: decide how to address risks, select relevant controls, compare those choices with Annex A, and document them in the Statement of Applicability. Management approval covers the treatment plan and remaining risk.
• Clauses 6.1.4 and 8.4 — AI impact assessment: examine the effects an AI system may have on individuals, groups, and organizations; revisit the assessment at planned intervals or when significant changes are proposed.
• Clause 8.1 — Operational planning and control: operate the chosen controls, manage changes, and address external processes and services relevant to the AIMS.
• Clauses 8.2 and 8.3 — Risk assessment and treatment: reassess risks when needed, act on new findings, and check whether risk treatments are effective.
• Clause 9.1 — Monitoring and evaluation: define what the organization needs to measure and how it will assess results.
• Annex A.10 — Third-party and customer relationships: allocate responsibilities (A.10.2), manage supplier use (A.10.3), and consider customer needs (A.10.4).

Do all suppliers need ISO/IEC 42001 certification? No. The standard does not make supplier certification a universal purchasing condition. Nor does it require an organization to select every Annex A control. Control choices must follow the risk-treatment process, with the reasons for inclusion or exclusion recorded in the Statement of Applicability. Annex B provides implementation guidance to support those choices (ISO/IEC, 2023).

A supplier’s certificate may be useful. Read its scope: it speaks to the certified management system, not automatically to every product, model version, or customer deployment.

Who is responsible when an AI service has several suppliers?

One business application can depend on a software provider, a foundation-model provider, cloud infrastructure, external data, and connected tools. Your contract may name only the application provider. That makes it important to understand which parties operate the components that matter to your business.

For each consequential AI use, document four distinct responsibilities:

1. Business accountability: who owns the outcome, affected customers, escalation, and corrective action?
2. Technical control: who can alter the model, application, data, permissions, or connected tools?
3. Evidence access: who holds testing records, incident information, version histories, and operating logs?
4. Decision authority: who may approve the use, impose conditions, pause it, or choose a replacement?

Also record the intended use, affected users, data categories, current service or model version where known, important upstream dependencies, monitoring route, and fallback. A supplier name alone is not a useful AI system inventory.

What does peer-reviewed research tell us about AI suppliers?

Responsibilities can become fragmented. In interviews with 27 AI engineers, Widder and Nafus (2023) found that practitioners frequently regarded potential AI harms as someone else’s responsibility across modular development arrangements. The study describes how work and accountability are organized; it does not establish how frequently a particular supplier-control failure occurs (Widder & Nafus, 2023).

Dependencies extend beyond software components. An integrative review of 67 sources by Attard-Frost and Widder (2025) examined AI value chains, including the people, infrastructure, information, resources, and organizational relationships involved. For a buyer, this supports looking beyond the company printed on the invoice when a dependency affects system behavior or accountability (Attard-Frost & Widder, 2025).

Documentation helps, but its scope matters. Mitchell and colleagues proposed model cards to communicate model performance, intended uses, and limitations. Gebru and colleagues proposed datasheets for datasets to improve documentation of dataset origins and characteristics. Both approaches can help the buyer ask more precise questions about its own data and workflow (Mitchell et al., 2019; Gebru et al., 2021).

Audit conclusions depend on access. Casper and colleagues (2024) explain why black-box testing alone can leave important questions unanswered about model development and deployment. Raji and colleagues (2020) describe a lifecycle audit approach in which evidence is gathered and reviewed throughout development and operation. Together, these papers support asking what was examined, what information was available, and which decisions the work can support (Casper et al., 2024; Raji et al., 2020).

How should a team assess supplier AI evidence?

Begin with the business use and the supplier’s specific claim. For example: “The assistant produces accurate complaint summaries for our customer-service workflow.” A useful review asks which version was tested, on what data, how performance was measured, and whether the test resembles the actual work.

Different documents answer different questions. A supplier questionnaire records assertions; a model card describes intended use and evaluation context; a security assurance report covers controls in its stated scope and period; test records show observed behavior under particular conditions. None should be treated as interchangeable.

When reviewing a report or certificate, check the system and period covered, the independence and methods of the review, exclusions, outstanding findings, and whether customer-specific configurations were assessed. Retain the report’s scope alongside your approval record.

Can a proprietary model still be evaluated?

Often, yes. Customer-run tests can examine outputs, workflow controls, reliability, access restrictions, logging, and performance on representative tasks. Contracts and change records can provide additional visibility. Where model weights, training data, or internal evaluations are inaccessible, reviewers should explain the resulting limits to their findings.

Those limits matter more for high-consequence applications. A benchmark result from the supplier may be enough to start an evaluation, but it may not answer whether a credit, healthcare, or customer-service workflow remains reliable under the organization’s actual conditions. Casper and colleagues’ analysis of audit access is particularly relevant here (Casper et al., 2024).

CEDAR: Connect the claim, evidence, and decision

InfoSecured.ai uses CEDAR — Claim, Evidence, Dependency, Assurance, Reliance — to keep supplier reviews centered on what the organization needs to decide. Its five questions can fit into an existing vendor-risk record rather than creating another approval process.

1. Claim — What exactly is being asserted? Identify the supplier statement and the version, users, and business purpose to which it relates.
2. Evidence — What supports it? Link the claim to tests, reports, documentation, or operating records; note what each covers.
3. Dependency — What does it depend on? Identify upstream providers, datasets, shared controls, earlier evaluations, and assumptions that could affect the result.
4. Assurance — What was checked? Record the scope, methods, access, findings, and gaps in the review.
5. Reliance — What decision can follow? Explain the approval, restrictions, owner, remaining questions, and conditions for another review.

Consider the complaint-summary assistant. A supplier’s model card supports a claim about the model under the conditions described in that document. The organization tests a sample of real-world complaint categories using appropriately protected records, checks whether important facts are omitted, and requires a human reviewer before summaries influence customer responses. It approves internal drafting while retaining limits on final decisions. The CEDAR record links that limited approval to the actual evidence and the supplier changes that would require another review.

Which supplier contract terms help governance work?

Contract review should follow the risks of the intended use. Depending on the service, procurement, legal, security, and governance teams may need to address:

• Changes: notice of material model, provider, feature, data-processing, or safeguard changes.
• Evaluation: access to relevant documentation, assessment summaries, and customer testing where practical.
• Data: permitted use, retention, secondary training, subprocessors, access, and deletion.
• Incidents: clear notification channels, evidence sharing, investigation support, and escalation responsibilities.
• Exit: continuity arrangements, data return, transition support, and safe termination of the service.

A good contract gives teams information and options when something changes. It should connect to actual monitoring and response processes rather than sit separately in the procurement file. The NIST AI RMF and Generative AI Profile provide useful risk-management considerations for external AI services (NIST, 2023; NIST, 2024).

When should third-party AI be reassessed?

Review the AI at planned, risk-based intervals and when a change may affect the earlier decision. A new model version, an upstream provider change, altered data use, new capabilities, an incident, or poorer performance can all justify a fresh look. Clause 8.2 addresses AI risk reassessment when significant changes are proposed or occur; Clause 8.4 addresses impact assessment when significant changes are proposed (ISO/IEC, 2023).

The review record can remain short: what changed; which earlier evidence still applies; what needs testing; who made the decision; and whether to continue, limit, pause, or end the use. Record the next review trigger and the responsible owner.

Watch for concentration risk as well. Two AI products may use the same model provider or cloud platform. An outage or weakness at that shared layer can affect multiple business services. Maintain practical fallbacks for the most consequential uses.

What should boards and risk committees ask for?

A useful executive review should show decisions and unresolved exposures, not only the number of supplier questionnaires completed. Leadership can ask:

1. Which third-party AI systems affect important business or customer outcomes?
2. Who owns each system and its approval decision?
3. Which supplier and upstream dependencies are material?
4. What testing and assurance evidence supports the intended use?
5. Where does the evidence stop, and what safeguards address the gaps?
6. What changes would trigger reassessment, and can the organization restrict or exit the service?

For each material use, keep one readable decision record linking the system inventory, risk assessment, impact assessment where applicable, supplier evidence, testing, decision owner, conditions, and review triggers. That record is useful for management, procurement, model governance, and internal audit.

Frequently asked questions

Is ISO/IEC 42001 certification required for every AI supplier?

No. Organizations select and document relevant controls according to their risks and obligations. A supplier certificate may be informative, but its scope should be checked against the service and deployment being reviewed.

Can ISO/IEC 42001 apply when a company only uses AI and develops no models?

Yes. The standard covers organizations that use AI as well as those that develop or provide AI. The AIMS scope and controls should reflect the organization’s actual role.

Is a model card enough to approve a third-party AI system?

Usually not on its own. Model cards describe an evaluation context. Reviewers still need to consider the organization’s data, users, workflow, configuration, and the consequences of an incorrect result.

Can third-party AI be reviewed without access to source code or model weights?

Yes, through appropriately scoped system testing and operational evidence. The depth of the conclusion depends on the methods and access available. More consequential uses may call for stronger evidence or narrower approval.

What should happen when a supplier changes the model?

Assess whether the change affects prior assumptions or tests. Refresh material evidence, recheck relevant controls, and record a decision to continue, limit, pause, or replace the service.

How does CEDAR relate to ISO/IEC 42001?

CEDAR is an InfoSecured.ai review method that helps connect supplier claims with evidence and decisions. It can support risk assessment, risk treatment, monitoring, and documented oversight within an AIMS.

Make the decision reviewable

Third-party AI governance starts with understanding what the organization uses and what its suppliers control. ISO/IEC 42001 provides the management-system structure. The evidence comes from the specific model, business workflow, tests, contracts, and operating history.

When teams can explain the claim, trace its dependencies, examine the supporting evidence, and name the person who approved reliance on it, supplier oversight becomes more useful across security, governance, procurement, and internal audit.

Continue with Vendor AI Risk Evidence, the AI Assurance Evidence Review Kit, and the Evidence Library.

References

View all 10 research and standards sources

Attard-Frost, B., & Widder, D. G. (2025). The ethics of AI value chains. Big Data & Society, 12(2). https://doi.org/10.1177/20539517251340603

Casper, S., et al. (2024). Black-box access is insufficient for rigorous AI audits. In Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency (pp. 2254–2272). https://doi.org/10.1145/3630106.3659037

Gebru, T., et al. (2021). Datasheets for datasets. Communications of the ACM, 64(12), 86–92. https://doi.org/10.1145/3458723

International Organization for Standardization & International Electrotechnical Commission. (2023). Information technology — Artificial intelligence — Management system (ISO/IEC 42001:2023). Official standard record.

Mitchell, M., et al. (2019). Model cards for model reporting. In Proceedings of the Conference on Fairness, Accountability, and Transparency (pp. 220–229). https://doi.org/10.1145/3287560.3287596

National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1

National Institute of Standards and Technology. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). https://doi.org/10.6028/NIST.AI.600-1

National Institute of Standards and Technology. (n.d.). AI RMF Playbook: Manage. NIST AI Resource Center.

Raji, I. D., et al. (2020). Closing the AI accountability gap: Defining an end-to-end framework for internal algorithmic auditing. In Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency (pp. 33–44). https://doi.org/10.1145/3351095.3372873

Widder, D. G., & Nafus, D. (2023). Dislocated accountabilities in the “AI supply chain”: Modularity and developers’ notions of responsibility. Big Data & Society, 10(1). https://doi.org/10.1177/20539517231177620