AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational
Control requirement
Establish a shared security responsibility model policy requiring explicit agreement on how AI security and related operational duties are divided between providers, customers and other participants. Define minimum ownership, evidence and escalation requirements.
Why this matters
A provider may secure its platform while leaving retrieval permissions, tool access and output decisions to the customer. A general statement that security is shared does not identify who performs a particular safeguard.
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
Hosted models, managed AI applications, external integration partners and internal platform services supporting business AI deployments.
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 security program owner defines the policy with supplier-risk and platform teams; business service owners ensure its application.
Implementation guidance
- Define the categories requiring responsibility allocation, including identities, data, model changes, tools, monitoring, incident handling and recovery.
- Require the model to reflect the actual deployment and service terms rather than a generic cloud diagram.
- Specify that each duty has an accountable party, a performing party, required evidence and a route for unresolved gaps.
- Apply the policy during onboarding and material changes, distinguishing shared performance from retained organizational accountability.
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 |
|---|---|
| Inspect a service’s responsibility model | It covers customer configurations and integrations as well as the provider platform. |
| Review a jointly performed safeguard | Accountability and handoffs are explicit rather than assigned to everyone. |
| Introduce an unresolved ownership gap | The defined escalation route produces a decision before consequential use. |
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
- SSRM policy and scope
- Required responsibility categories
- Onboarding and change gates
- Gap and exception decisions
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 undefined responsibilities to the internal service owner and provider counterpart. Restrict affected use where a necessary safeguard has neither a responsible operator nor adequate evidence.
Example in practice
Hypothetical example: A vendor protects the model endpoint, but the buyer controls which documents its assistant retrieves. The policy requires that retrieval authorization be assigned explicitly instead of being assumed to come with the platform.
Related controls
- CF03-003: SSRM Control Ownership Delineation
- CF03-004: SSRM Implementation & Review
- CF01-005: AI Governance Responsibility Model
Framework mappings
- CSA AICM (STA-02, STA-03)
- 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