AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational
Control requirement
Document control-level ownership across AI service participants, identifying who implements, configures, monitors and verifies each relevant safeguard, who provides evidence, and who acts when the safeguard fails.
Why this matters
An agreed policy remains incomplete until responsibilities are assigned to actual controls and interfaces. Splitting a safeguard between teams can create a gap precisely where information or authority crosses the boundary.
How the control types work together
Operational controls establish the supplier assessment, ownership, agreement and review processes described here. They work when the assigned parties perform the required activities and use evidence to guide decisions.
When it applies
AI deployments involving multiple teams or suppliers, especially data retrieval, delegated tools, identity integration, logging and incident response.
Tailor review depth to information sensitivity, granted authority and business dependence. Record what the organization can test directly, what relies on provider evidence and how material visibility gaps affect the acceptance decision.
Ownership
The AI service owner coordinates the allocation; provider contacts and internal control owners confirm their assigned duties.
Implementation guidance
- Decompose the service into data flows, identities, integrations and control activities; identify the boundaries at which responsibility changes.
- Assign accountable and performing roles for each activity, including customer configuration, verification, evidence delivery and failure response.
- Record dependencies and handoff conditions; confirm supplier commitments against contracts and available capabilities rather than sales assurances.
- Resolve gaps and conflicting assignments, then obtain confirmation from the involved parties and maintain current contact and escalation routes.
How to verify it
Use representative deployment records and authorized controlled tests. Establish the assessed service, artifact version and acceptance conditions before interpreting results; do not extend evidence beyond the boundary it covers.
| Test | Expected result |
|---|---|
| Trace a tool permission or retrieval control | Implementation, review and failure response have identified owners. |
| Compare assignments with supplier commitments | The provider can deliver the assigned activity and evidence. |
| Follow an incident across a boundary | Each handoff has a receiving role and an actionable next step. |
Record a finding when a required result cannot be demonstrated or actual practice differs materially from the accepted conditions. Assign corrective action and verify the affected boundary before closing the issue.
Evidence to retain
- Control ownership matrix
- Architecture and boundary references
- Supplier and internal confirmations
- Gap-resolution and handoff records
Protect supplier-confidential information, credentials and personal data in these records. Preserve enough version and scope information to establish which service or artifact the evidence supports.
If the control fails
Escalate rejected or ambiguous assignments to the service and supplier relationship owners. Hold the affected integration until coverage or an authorized restriction addresses the gap.
Example in practice
Hypothetical example: A buyer assumes the vendor reviews privileged access, while the vendor assumes the buyer does so in its identity system. Control-level allocation identifies and closes that missing review before onboarding.
Related controls
- CF03-002: Shared Security Responsibility Model (SSRM) Policy
- CF03-004: SSRM Implementation & Review
- CF03-007: AI Supply Chain Contractual Requirements
Framework mappings
- CSA AICM (STA-04, STA-05)
- NIST AI RMF (GOVERN 6.1)
- EU AI Act (Art. 9(1)(b))
- ISO 42001 (Cl. 5.3, A9.1)
Review and maintenance
Review at the interval approved by the control owner and after relevant supplier, component, contract, access or deployment changes. Reassess material incidents and new evidence, updating acceptance conditions and verifying corrective actions where required.
Back to AI Supply Chain & Third-Party Risk
Version 1.0