AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Governance and Operational
Control requirement
Define the external and organization-selected compliance requirements that AI providers must meet for a particular service and use, including required evidence, customer dependencies, subcontractor coverage and response to nonconformance.
Why this matters
A broad demand to comply with all laws does not tell a provider what the buyer needs to verify. Requirements should identify the actual service, roles and obligations without transferring duties the customer cannot delegate.
How the control types work together
Governance controls establish applicable binding external rules and requirements. Operational controls translate those requirements into supplier selection, agreements, evidence and continued-use decisions.
When it applies
AI supplier selection, onboarding and ongoing assurance where external obligations, contractual commitments or adopted standards affect provider eligibility.
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
Legal and compliance validate applicable external duties; supplier-risk and service owners establish provider conditions and evidence requirements.
Implementation guidance
- Identify required provider capabilities and obligations using the actual deployment roles, locations, data and customer commitments.
- Specify acceptable evidence, scope, frequency and notification conditions, including material subprocessors where relevant.
- State the customer’s retained responsibilities and review provider claims against service-specific conditions rather than badges or generic statements.
- Communicate nonconformance, remediation and continued-use conditions through the procurement and supplier assurance processes.
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 |
|---|---|
| Review an eligibility requirement | Its scope, rationale and evidence expectations are explicit. |
| Compare a provider claim with the specific service | The evidence addresses the required roles and deployment conditions. |
| Inspect a subcontractor or provider change | The requirement and evidence coverage are reassessed. |
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
- Provider requirement specification
- Reviewed applicability and role analysis
- Evidence and eligibility criteria
- Nonconformance and approval 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 unmet mandatory provider conditions to legal, procurement and the business owner. Hold affected onboarding or processing until an appropriate compliant arrangement is established.
Example in practice
Hypothetical example: A buyer requires a provider to support specified incident information and retention conditions. The supplier must demonstrate those service capabilities, while the buyer retains responsibility for its own notifications and internal decision process.
Related controls
- CF03-007: AI Supply Chain Contractual Requirements
- CF03-009: AI Supply Chain Compliance Assessment
- CF01-006: AI Regulatory & Standards Mapping
Framework mappings
- CSA AICM (STA-13)
- NIST AI RMF (GOVERN 6.1)
- EU AI Act (Art. 28(4))
- ISO 42001 (Cl. 8.3, A9.2)
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