AI Control Library / CF-10: Recourse & Incident Response
Designation: Core | Control types represented: Operational and Technical
Control requirement
Coordinate AI incident response across suppliers and customers with explicit contacts, evidence exchange, containment duties and restoration conditions. Maintain the organization’s own action capability where provider control or visibility is limited.
Why this matters
A supplier incident can affect multiple components while its investigation remains incomplete. Customer response must assess actual deployment exposure rather than wait passively for a general provider statement.
How the control types work together
Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.
When it applies
Incidents involving model providers, datasets, libraries, tools, hosted infrastructure and other material AI dependencies.
Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.
Ownership
The internal incident authority coordinates supplier relationship and system owners with provider responders.
Implementation guidance
- Map response responsibilities and verified contacts, linking obligations and evidence to material dependencies.
- Assess incoming reports against deployed versions, data and permissions, requesting necessary facts through approved channels.
- Contain at customer-controlled boundaries and coordinate supplier actions, preserving evidence and protecting shared information.
- Verify trusted replacements or recovery and reconcile customer-specific effects before restoring affected use.
How to verify it
Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.
| Test | Expected result |
|---|---|
| Exercise a supplier alert | The team identifies relevant deployments and internal authority. |
| Make provider information incomplete | Customer containment and uncertainty handling still operate. |
| Review restoration | Provider claims and local verification support the actual deployment. |
Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.
Evidence to retain
- Supplier response responsibilities
- Version and exposure assessment
- Protected communications and containment
- Restoration and impact reconciliation
Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.
If the control fails
Escalate unresponsive suppliers or ongoing material exposure to incident and business owners. Restrict, replace or suspend affected dependencies through the approved response.
Example in practice
Hypothetical example: A model repository reports a compromised artifact. The customer checks deployment digests, quarantines affected copies and evaluates a trusted replacement instead of assuming all similarly named models were compromised.
Related controls
- CF03-004: SSRM Implementation & Review
- CF03-014: Model Provenance & Integrity Verification
- CF10-006: AI Incident & Breach Notification
Framework mappings
- CSA AICM
- NIST AI RMF (MANAGE 3.1)
- EU AI Act (Art. 72)
- ISO 42001 (Cl. 10.2)
Review and maintenance
Review at the interval approved by the control owner and after relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.
Back to Recourse & Incident Response
Version 1.0