Implementation Kit
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.
1. AI incident classification matrix
SpreadsheetType 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.
2. AI incident response runbook
DocumentStep-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.
3. Regulatory notification obligation checklist
SpreadsheetWho 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.
4. Post-incident report template
DocumentThe 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.
5. AI incident register
SpreadsheetThe 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
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The classification matrix is the AI incident classification standard.
The runbook is the AI incident response playbook.
The notification checklist is the AI harm notification procedure across jurisdictions.
The post-incident report template is the post-incident review record.
The incident register is the incident log and tracking system, including near-misses.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →