# AI Incident Response Runbook and Report Templates What to do when an AI system causes harm or fails: a classification matrix, a runbook per incident type, a regulatory notification checklist across jurisdictions, a post-incident report template, and an incident register that also captures near-misses. **Who this is for:** The incident commander and governance owner responsible for AI failures. Source playbook: https://aigovernance.com/playbook/ai-incident-response --- ## AI incident classification matrix _Type and severity to a response path, so triage is fast and consistent._ ### Template | Incident type | Sev-1 | Sev-2 | Sev-3 | |---|---|---|---| | Harmful or discriminatory output reaching people | widespread or serious harm; regulator interest likely | limited reach, contained | caught before release | | Data exposure via an AI system | personal or confidential data disclosed externally | internal over-exposure | near-miss | | Wrong consequential decisions at scale | many people wrongly affected | isolated cases | detected in monitoring, no decisions issued | | Agent took an unauthorized or damaging action | irreversible external impact | reversible, contained | blocked by a gate | | Model unavailable or degraded | critical business function down, no fallback | degraded with fallback | minor | | **Response path** | incident commander + exec + comms + legal; out-of-cycle committee | commander + owner + governance | owner handles; log it | ### Worked example > Triage, 2026-09-04: support-copilot drafted a reply containing another customer's order ID; caught by the pre-send review step. | Triage field | Value | |---|---| | Type | data exposure via an AI system; not released | | Severity | Sev-2 (internal over-exposure, one record, one agent) | | Response path | incident commander (support lead) + system owner + governance notified; no exec or comms needed | ### Acceptance criteria - Every incident type has severity definitions and a response path. - Near-misses map to a severity (usually Sev-3) so they are still logged. - The matrix is on the same page as the runbook, reachable during an incident. --- ## AI incident response runbook _Step-by-step per incident type. The generic phases with AI-specific actions._ ### Template > One section per incident type. Common phases below. **Detect and declare:** how it is reported; who declares; severity assigned from the matrix. **Contain (AI-specific):** disable the feature or model; switch to fallback (rules, cached, manual); revoke the agent's credentials; freeze retraining if data is implicated. **Assess impact:** which decisions, which people, over what window; pull the decision log and action log. **Notify:** internal stakeholders now; run the regulatory notification checklist. **Remediate:** fix root cause; validate the fix; re-test for new failures before restoring. **Restore:** staged return; heightened monitoring for a defined period. **Review:** post-incident report within the SLA; feed lessons into controls and training. ### Worked example **Type: harmful or discriminatory output reaching people.** - Contain: disable the generation path; serve a safe static response; preserve prompts and outputs. - Assess: query outputs in the window against the harmful pattern; quantify how many users saw it. - Notify: Legal assesses discrimination-law and consumer-protection notification; comms prepares holding lines. - Remediate: adjust filters/prompt; add a regression test for the pattern; independent check of adjacent behaviours. - Restore: re-enable for internal traffic first, then a canary, then full, with alerting on the pattern. ### Acceptance criteria - Each incident type has containment steps that do not depend on the failing component. - The runbook says to preserve logs and evidence before remediation. - Restoration is staged and gated on re-testing. --- ## Regulatory notification obligation checklist _Who must be told, by when, in which jurisdictions. Run it during an incident, not after._ ### Template | Obligation | Trigger | Deadline | Who notifies | Applies here? | |---|---|---|---|---| | GDPR personal data breach (supervisory authority) | risk to individuals' rights | 72 hours from awareness | DPO | | | GDPR breach (data subjects) | high risk to individuals | without undue delay | DPO | | | EU AI Act serious incident (high-risk systems) | death, serious harm to health, fundamental rights, property, environment; serious infrastructure disruption | per Article 73 timelines | provider | | | Sector regulator (financial, health) | per sector rules | varies | compliance | | | US state breach laws | personal data of state residents | varies by state | legal | | | Contractual customer notification | per MSA/DPA | often 24-72h | account team + legal | | ### Worked example | Obligation | Applies here (support-copilot Sev-2)? | Action | |---|---|---| | GDPR authority notification | No: one order ID, exposed internally to one agent, no external disclosure, low risk | documented the assessment and reasoning | | GDPR data subject notification | No | same | | EU AI Act serious incident | No: limited-risk system; no serious harm | n/a | | Contractual customer notification | Reviewed the affected customer's DPA: internal-only exposure below the notification threshold | logged; no notice required | ### Acceptance criteria - The checklist covers privacy, AI-specific, sector, state, and contractual obligations. - Every incident records a notification assessment with reasoning, even when the answer is "no". - Deadlines and the responsible notifier are named per obligation. --- ## Post-incident report template _The permanent record. Timeline, root cause, impact, notifications, remediation, prevention._ ### Template > Completed within the SLA. Filed with the system documentation and the incident register. - **Incident ID, date, severity, system/version** - **Timeline** with timestamps: detection, declaration, containment, resolution - **What happened** in plain language - **Impact:** who and how many; decisions or communications affected - **Root cause:** technical and process - **Notifications:** what was assessed, what was sent, to whom, when - **Remediation:** completed fixes - **Prevention:** control, process, or training changes with owners and dates - **Lessons for other systems** - **Reviewer and sign-off** ### Worked example - **INC-2026-041**, 2026-09-04, Sev-2, support-copilot v1.6 - **Timeline:** 14:10 detected (pre-send review) / 14:12 declared / 14:35 feature disabled / 2026-09-06 09:00 fix deployed / 09:09 re-tested clean / 10:00 restored - **What happened:** retrieval query for reply drafting was not scoped to the ticket's customer, so a nearby order from another customer was pulled in. - **Impact:** zero customers (no send); one order ID visible to one agent. - **Root cause:** missing customer-ID filter on the retrieval call; no CI test for retrieval scoping. - **Notifications:** GDPR and contractual assessments done; none required (reasoning on file). - **Remediation:** customer-ID scoping added; safe-field allowlist on retrieved order data. - **Prevention:** retrieval-boundary test added to CI (MLOps, 2026-09-20); prompt-injection scenario added to the red-team library. - **Lessons:** audit every RAG system for retrieval scoping (owner: ML Platform, 2026-10-15). - **Reviewer:** R. Nkemelu, 2026-09-08 ### Acceptance criteria - The timeline has timestamps for detection, containment, and resolution. - Prevention actions have owners and dates and are tracked in the review queue. - Lessons that apply to other systems are called out and assigned. --- ## AI incident register _The log of every incident and near-miss. Near-misses are the cheap lessons._ ### Template | ID | Date | System | Type | Severity | Near-miss? | Status | PIR link | Prevention actions closed? | |---|---|---|---|---|---|---|---|---| | | | | | | Y / N | open / closed | | Y / N | ### Worked example | ID | Date | System | Type | Severity | Near-miss? | Status | PIR | Prevention closed? | |---|---|---|---|---|---|---|---|---| | INC-2026-041 | 2026-09-04 | support-copilot | data exposure | Sev-2 | N (caught pre-send) | closed | link | in progress (1 of 2) | | NM-2026-018 | 2026-08-22 | fraud-scoring | wrong decisions | Sev-3 | Y | closed | link | Y | | INC-2026-039 | 2026-08-11 | resume-screener | discriminatory output risk | Sev-3 | Y | closed | link | Y | ### Acceptance criteria - Every incident and near-miss is logged, not only the ones that caused harm. - Each entry links to its post-incident report and tracks whether prevention actions are closed. - The register is reviewed in the governance committee for patterns. --- ## Governance controls this kit produces evidence for - **IRC-001**: The classification matrix is the AI incident classification standard. - **IRC-002**: The runbook is the AI incident response playbook. - **IRC-003**: The notification checklist is the AI harm notification procedure across jurisdictions. - **IRC-004**: The post-incident report template is the post-incident review record. - **IRC-005**: The incident register is the incident log and tracking system, including near-misses.