CF10-001: AI Incident Management Policy & Procedures

AI Control Library / CF-10: Recourse & Incident Response

Designation: Core | Control types represented: Operational

Control requirement

Establish AI incident management policy and procedures covering detection, assessment, containment, recovery, communication and learning. Include harmful or unauthorized outcomes that may occur without a conventional cybersecurity breach.

Why this matters

An AI failure can harm people through incorrect decisions or excessive authority even when no attacker enters the system. Incident policy must recognize those events and assign a workable response.

How the control types work together

Operational controls establish the assigned responsibilities, review processes and response decisions described here. Their effectiveness depends on performing the work and using evidence to guide action, rather than approving a document alone.

When it applies

AI applications, models, agents and supporting suppliers across consequential development, pilots and operation.

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 management owner coordinates security, business, domain, privacy and legal responsibilities.

Implementation guidance

  1. Define AI incident and near-miss scope, including security, reliability, fairness, privacy and loss of effective control.
  2. Assign classification, command authority, evidence handling, escalation and recovery duties with coverage and deputies.
  3. Integrate AI response with established business and security processes, including affected-person support and supplier coordination.
  4. Exercise the procedures and review them after material changes or lessons showing unclear ownership.

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
Present a harmful non-security outcome The policy assigns assessment and response rather than excluding it as merely model quality.
Exercise an urgent control failure Authorized containment and decision routes are available.
Trace a closed incident Recovery and learning records support the disposition.

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

  • Incident policy and scope
  • Roles and escalation
  • Response and recovery procedures
  • Exercise and review 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

Escalate unowned harmful events to the accountable business and response authorities. Contain ongoing exposure while the appropriate response function is established.

Example in practice

Hypothetical example: A model wrongly restricts access to a service. The organization activates incident handling for the affected decisions even though security finds no evidence of account compromise.

Related controls

Framework mappings

  • CSA AICM (SEF-01)
  • 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

Scroll to Top