What the governing body should require for third-party and AI supply-chain risk oversight

Authority disclaimer. This page is an executive narrative. It does not establish requirements; the linked corpus governs. It is provided to support understanding, discussion, and decision-making by the governing body and accountable executive leadership (board, ELT, or senior management, as applicable). It creates no obligation, control, or assurance by itself. Its publication approval is an editorial act only and confers no authority over any corpus document. Where it differs from a corpus document, the corpus document prevails.

An organization's critical operations and AI capabilities can carry a dependency on a chain of services other organizations run: a model provider, a platform, a retrieval or orchestration service, and the suppliers behind those suppliers. The AI board oversight guide defines the accountability allocation for the organization's use of AI (its section 2) and the governance red flags relevant to supplier reliance (its section 6); this brief routes to those values. The guide treats responsibility for an AI outcome attributed to the system or the vendor rather than an accountable person as a warning sign that AI oversight may be inadequate. A supplier can operate a control on the organization's behalf; it cannot hold the organization's accountability for it.

The governing body does not run supplier assessments and does not sign contracts. Its oversight is of the programme: whether a defined lifecycle governs every supplier relationship, whether AI suppliers receive the additional scrutiny the corpus defines for them, whether the organization can see past its direct suppliers to the dependencies beneath them, and whether all of that is visible in evidence rather than described in assurances. This brief points to where the corpus establishes each of those. The framing of the governing body's role as programme-level oversight is synthesized across the sources named below; see the limitations.

• A single standard governs third-party and supply-chain risk end to end. The third-party and supply chain risk standard requires due diligence where its criticality model makes it mandatory, at the point, to the depth, and across the domains that model defines (its sections 3 and 4.1). The tiers, domains, and depths live in the standard; this brief does not restate them.
• Supplier governance is a lifecycle, not an onboarding event. The supplier and cloud governance framework defines the supplier lifecycle, the required governance activity at each stage, and the evidence for that activity (its supplier lifecycle section). The evidence class paired with each stage is evidence that the stage operated.
• AI suppliers carry additional, defined obligations. The third-party AI due diligence procedure requires its pre-engagement assessment at the point and depth it defines (its section 5) and requires the AI-specific contract provisions it lists (its section 6); the procedure owns the applicable notification windows, deletion timelines, and retention floors, and this brief routes to them. The supplier and cloud governance framework states that AI suppliers require specific assessment and lists what that assessment covers, at the normative strength the framework defines (its AI supplier requirements section). The umbrella standard states its own AI service-provider contract requirements, which overlap with but do not coincide with the procedure's (its section 5.1), and the supplier security and privacy assurance standard requires minimum security and privacy clauses for suppliers in its scope (its section 6).
• Foundation models have their own seven-step lifecycle procedure. The foundation model lifecycle procedure owns the ordered members and their contents, including those labelled Pre-engagement evaluation (Step 2) and Contractual integration (Step 3); use it for their required outputs and provider-arrangement rules.
• Evidence has a defined quality order. The supplier security and privacy assurance standard defines the order of assurance evidence and the acceptance rule for each evidence tier (its section 5); this brief routes to both.
• Monitoring continues past onboarding. An unscheduled supplier review has a dependency on the event set the supplier ongoing monitoring procedure defines, irrespective of the scheduled cycle (its trigger-based reviews section). For AI suppliers, an out-of-cycle reassessment has a dependency on the condition set the AI due diligence procedure defines (its section 7.4).
• Oversight extends past the first tier. The fourth-party and nth-party risk procedure defines sub-tier visibility expectations, and the applicable expectation has a dependency on the supplier-criticality model the procedure defines (its visibility tiers section); an escalation has a dependency on the conditions the procedure defines (its step 4). The concentration risk register tracks where critical dependencies converge across the dimensions it defines, and maintaining the register is a contribution to producing the supplier-risk report, at the cadence and to the audience its operating expectations set. The register and the umbrella standard define separate reporting artefacts (the register's operating expectations; the standard's section 10); this brief routes to their cadence and audience values. Portfolio-level concentration visibility has a dependency on the role assignment the umbrella standard defines (its section 6.2).
• Software composition is inventoried within a defined scope. The SBOM register defines its software scope and its tier-based handling of SBOM gaps, and contractual remediation has a dependency on the gap-handling rule the register defines (its operating expectations). The software composition analysis standard defines the supply-chain and AI-specific analysis requirements (its sections 4.5 and 4.7).
• AI supplier dependency sits inside AI governance, not outside it. The AI governance and risk framework carries supplier governance as one of its control domains (its control domains section). The framework carries external model or supplier dependency among the criteria its risk classification weighs (its risk classification criteria); the framework defines their coverage and normative strength.
• The governing body asks questions and receives reports. Per the AI board oversight guide, structured interrogation is a contribution to governing-body oversight (its section 5); the guide defines red flags relevant to inadequate AI oversight (its section 6); and the guide states that the governing body itself defines what it receives and how often, with the view it should expect described in its section 7.

The corpus position, read together, sets the governing body's third-party and AI supply-chain oversight as a small number of standing expectations. This reading is composite.

• Require one programme, with AI inside it. The corpus treats AI suppliers as a distinct class within the supplier programme, not a parallel track; the umbrella and AI-specific sources define how the supplier programme applies to AI suppliers, and this brief routes to their respective coverage. Oversight that asks about the supplier programme and the AI supplier extensions together is asking the question the corpus is built to answer.
• Expect evidence, not assurances. Every lifecycle stage in the supplier framework has the evidence class the framework defines, and the assurance standard defines the evidence order. A supplier relationship the organization cannot evidence at each stage is a relationship the corpus controls are not demonstrably operating on. Certification is evidence that a supplier's control environment was assessed; it is not, by itself, evidence that the organization's own lifecycle controls operate.
• Treat visibility past the first tier as part of the ask. The corpus states sub-tier visibility and concentration tracking as programme expectations with defined escalation. Against those programme expectations, an answer of "we have no visibility into our suppliers' own dependencies" requires examination rather than acceptance. Under the procedure's visibility model the applicable expectation has a dependency on supplier criticality; the governing body checks that the applicable expectation, not an unstated absolute, was applied.
• Onboarding-only assurance is a weak answer. An unscheduled reassessment has a dependency on the condition sets the monitoring and AI due diligence procedures define, and scheduled reassessment runs on the cadences those procedures set. An oversight answer that ends at "they passed due diligence" stops where the corpus keeps going.
• Accountability is not outsourced with the service. The oversight guide treats responsibility for an AI outcome attributed to the system or the vendor rather than an accountable person as a warning sign that AI oversight may be inadequate (its section 6). Accountability remains with the organization in the presence of supply-chain dependency.

Each item below is an evidence class the governing body can call for from management, and each is evidence for a named control or outcome.

• The supplier risk classification and due diligence record for a sample spanning the standard's mandatory scope, as evidence that the due diligence control in the third-party and supply chain risk standard operated at the point the standard defines (its sections 3 and 4.1).
• The completed questionnaire package the template defines for the AI supplier categories in its scope, as evidence of AI-specific supplier assessment at the submission point the AI vendor security questionnaire template specifies (its operating expectations).
• The contract control schedule for a sample of suppliers within each source's scope, as evidence that the minimum clauses in the supplier security and privacy assurance standard (its section 6) and the AI provisions in the third-party AI due diligence procedure (its section 6) are present.
• The pre-engagement evaluation record and its recommendation, in the outcome set the procedure defines for any foundation model in use, as evidence that the gate in the foundation model lifecycle procedure operated across the required outputs the procedure lists (its step 2).
• Monitoring records showing an unscheduled review that actually ran, as evidence for the unscheduled-review control in the supplier ongoing monitoring procedure (its trigger-based reviews section) and the reassessment conditions in the third-party AI due diligence procedure (its section 7.4).
• The concentration risk register and its associated report, as evidence for the register-level reporting control, at the cadence and for the audience the concentration risk register defines (its operating expectations).
• The separate concentration report the umbrella standard defines, as evidence for the standard-level reporting control, at the cadence and for the audience the third-party and supply chain risk standard defines (its section 10).
• Sub-tier disclosure records for the supplier scope the procedure prioritizes, as evidence for the visibility expectations in the fourth-party and nth-party risk procedure and any escalation the procedure defines (its visibility tiers section and step 4).
• An extract of the SBOM register and its gap escalations, as evidence for software supply-chain transparency per the SBOM register, together with the AI dependency scan results the software composition analysis standard requires (its section 4.7).
• The exit and deletion evidence for a recently ended supplier relationship, as evidence that the exit stage of the supplier and cloud governance framework operates, including the AI-specific exit expectations in the third-party AI due diligence procedure (its section 8).

• This page creates no compliance and imposes no requirement. The linked corpus documents govern; where this page differs from a corpus document, the corpus document prevails.
• This page carries composite claims. The reading of the governing body's role as programme-level oversight, the grouping of the corpus's supplier, AI, and software supply-chain documents into one oversight picture, and the reading that accountability for AI use remains with the organization and is not delegated with the service, are synthesized across the sources listed above, and the adopting organization validates those readings against its own governance model and committee structure.
• The corpus documents this page points to carry the source-owned values: the tiers, thresholds, notification windows, retention periods, evidence orders, cadences, and named roles and approval bodies. This page routes to those values and does not reproduce them. That routing is a contribution to the corpus's status as the single source for them.
• Corpus statements described on this page carry the normative strength their source defines. This page does not restate or upgrade that strength, and the corpus wording governs.
• This page makes no claim about how likely any supplier or supply-chain failure is, and none of its statements should be read as a probability or a frequency.