ISO 42001 Holds You Accountable for AI You Cannot See or Contract With

The Invisible Tier in Your AI Supply Chain

When a CISO or Third-Party Risk Management lead maps their organization's AI exposure, they typically inventory the AI systems the enterprise has directly procured or built. That inventory misses a structural category: the foundation models that SaaS vendors have embedded inside their platforms, often without prominent disclosure. These are fourth-party AI supply chain risks — AI components introduced by your vendor's vendors, operating underneath products your organization has contractually approved but whose underlying model lineage you have almost certainly not reviewed.

The practical consequence is a gap that runs from the procurement desk to the audit room. Your vendor agreement may include a data processing addendum. It almost certainly does not name the foundation model provider, specify the model version in production, describe the training data provenance, or assign accountability for model-level control failures. Industry analysis published by KPMG in its 2023 global survey on AI governance found that 92 percent of organizations had no policies governing third-party AI use at all. If that figure holds directionally — and the structural incentives suggest it does — contractual coverage for fourth-party foundation-model risk is not a gap in most enterprises. It is an absence.

Why ISO 42001 Closes the Delegation Loophole

ISO 42001:2023, the international standard for AI management systems, addresses this directly and without ambiguity. The standard requires that organizations establish, implement, and maintain AI governance obligations across the supply chain — not just for the AI systems they operate directly. Critically, it does not treat a vendor contract, a shared-responsibility model, or a supplier attestation as a substitute for organizational control. Where a third-party AI component is embedded in a product the enterprise has deployed, the enterprise retains accountability for ensuring that the relevant AI governance requirements are met. The words 'our vendor is responsible' do not constitute a control under ISO 42001 clause structure.

This creates a specific and uncomfortable obligation for regulated enterprises. The SaaS platforms used in loan origination, claims processing, patient scheduling, or fraud scoring increasingly run on foundation models from a small number of providers. The enterprise deploying the SaaS product has an ISO 42001 obligation to understand what that model is, how it is governed, and what evidence demonstrates that governance — even if no contract currently requires the SaaS vendor to disclose any of that information.

What Fourth-Party Exposure Actually Looks Like

Understanding the exposure requires being concrete about the architecture. A regulated bank deploys a customer communication SaaS tool. That tool uses a large language model from a third-party foundation model provider to generate response suggestions. The bank's procurement team approved the SaaS vendor after a standard security review. The bank's legal team signed a data processing agreement that governs how the SaaS vendor handles customer data. Neither document addresses the foundation model. The model provider — the fourth party — has no direct contractual relationship with the bank. No model card has been reviewed. No usage policy has been assessed for regulatory alignment. No change notification mechanism exists for model version updates.

That architecture is not unusual. It describes a large proportion of the enterprise SaaS stack today. Every node in that stack where a foundation model is embedded and undisclosed represents a live fourth-party AI supply chain risk that sits outside the enterprise's current governance perimeter.

Supply Chain Governance Evidence Checklist

An ISO 42001 audit will not accept a policy statement as evidence of fourth-party control. Auditors expect artifacts — documented, repeatable, demonstrably operational. The following six-point checklist maps the minimum evidence a regulated enterprise must be able to produce when foundation-model exposure is present in its supply chain.

1. Fourth-Party AI Component Registry. Maintain a structured inventory that maps each SaaS product in scope to the foundation model or AI component embedded within it, including provider name, model version where obtainable, and the business process the product supports. This registry is the prerequisite for every other control — without it, you cannot demonstrate scope awareness to an auditor.

2. Vendor Disclosure and Contractual Update Obligations. Ensure that vendor agreements for AI-enabled SaaS products include explicit disclosure requirements: the vendor must name the AI components in use, notify the enterprise of material model changes, and provide updated model cards or equivalent documentation on request. If existing contracts lack these clauses, log the gap and the remediation timeline as a formal risk treatment action in your ISO 42001 management system.

3. Foundation Model Risk Assessment Records. For each identified foundation model in the registry, document a risk assessment that addresses: intended use alignment with the enterprise's regulatory context, training data provenance to the extent disclosed, known model limitations and failure modes, and any usage policy restrictions that could conflict with enterprise obligations. These assessments do not need to be exhaustive, but they must exist and be dated.

4. Control Mapping to Applicable Regulatory Requirements. Map each fourth-party AI component to the specific regulatory obligations it touches — model risk management requirements, consumer protection rules, sector-specific AI guidance. The output is a control matrix that demonstrates the enterprise has asked the question: 'does this embedded model expose us to a regulatory gap?' Where gaps exist, the risk treatment must be documented.

5. Ongoing Monitoring and Change Detection Mechanism. Establish a repeatable process for detecting material changes to fourth-party AI components — model version updates, changes to the provider's usage policies, disclosed safety incidents, or changes in the foundation model provider's own governance posture. This does not require direct access to the model provider. It requires a defined cadence for querying the SaaS vendor and a documented response protocol when changes are detected. The evidence an auditor needs is a record of that cadence being executed, not just a policy saying it will be.

6. Escalation and Incident Response Integration. Integrate fourth-party AI components into the enterprise's existing AI incident response and escalation procedures. If a foundation model embedded in a SaaS platform causes a material output failure — a biased credit decision, a hallucinated clinical response, a fraudulent transaction not flagged — the enterprise must be able to demonstrate that its incident response process covers that scenario. This means the fourth-party registry is referenced in the incident response runbook, and at least one tabletop or simulation exercise has tested it. The audit artifact is the exercise record, not the policy document.

Why This Cannot Wait for the Contract Cycle

The instinct in most enterprises is to address third-party and fourth-party risk through the procurement cycle — update the standard contract template, add AI-specific schedules at renewal, and let the existing vendor base age out of the gap. That approach is structurally incompatible with ISO 42001's obligation to maintain an operational AI management system now. An audit does not accept 'we are addressing this at the next renewal.' It asks for the current evidence of governance in operation.

The practical starting point is not a contract renegotiation. It is an inventory exercise — mapping which SaaS platforms in scope are likely to embed generative AI or other foundation models, and ranking them by regulatory sensitivity of the business process they support. That inventory exercise is the first artifact in the checklist above. From it, every subsequent control follows.

Fourth-party AI supply chain risk is the structural gap that most supply chain governance programs were not designed for. ISO 42001 does not redesign that for you — it simply declines to accept that the gap is someone else's problem. The evidence that closes the gap has to be yours.