AI Control Library / CF-10: Recourse & Incident Response
Designation: Core | Control types represented: Operational and Technical
Control requirement
Maintain actionable AI incident response plans with triggers, roles, evidence, containment, recovery and communication for relevant failure scenarios. Verify that responders can use the actual system controls.
Why this matters
A generic instruction to disable AI may leave delegated tasks, tool credentials and queued actions active. Plans need deployment-specific intervention and recovery boundaries.
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
AI deployments with material incident exposure, including hosted services and persistent or delegated agent activity.
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 incident response owner coordinates service, platform, data and business owners with supplier contacts.
Implementation guidance
- Develop scenarios from threats, impact assessments and known failures, identifying the required response objective.
- Define concrete containment and evidence steps for models, data, identities, tools, queues and suppliers.
- Specify safe recovery, outstanding-action reconciliation and communication, with explicit restoration authority.
- Keep procedures accessible and exercise representative paths, updating them after changes and failed assumptions.
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 |
|---|---|
| Activate a representative plan | Responders can locate and perform assigned actions. |
| Include delegated or queued work | Containment covers continuing activity within the defined boundary. |
| Restore service in an exercise | Trust and operating checks precede consequential resumption. |
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
- Response plans and dependency map
- Access and containment procedures
- Exercise results
- Restoration and update records
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
Use alternate containment and notify the incident authority if the normal action fails. Keep affected functions restricted until verified recovery is authorized.
Example in practice
Hypothetical example: A plan for an unsafe messaging agent revokes sending authority, pauses workers and reconciles already submitted messages before the service is restarted.
Related controls
- CF07-006: AI System Kill Switch & Emergency Stop
- CF10-004: AI Incident Response Testing & Exercises
- CF01-S12: AI Disaster Response Plan
Framework mappings
- CSA AICM (SEF-03)
- 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