# [Organization name]: AI incident checklist

> For reference purposes only. Not legal advice. Draft for review by a qualified professional.

**How to use this template.** Keep this checklist with your AI incident response plan and use it when something goes wrong with an AI system. AI incidents are often behavioral: the infrastructure works normally while the system produces harmful, false or biased results, so standard IT incident steps are not enough. Template version 1.0, last reviewed 2026-10-02. Certainty: simplified. Notification duties differ by region and always need confirming with counsel.

| Field | Entry |
|---|---|
| Incident ID | [ID] |
| System | [Name, from the AI register] |
| Reported by / date found | [Name, date] |
| Incident lead | [Name and role] |

## 1. Detect and record

- [ ] Describe what happened, in plain words.
- [ ] Record when it started, how it was found and who reported it.
- [ ] Record which system, version and environment.
- [ ] Preserve logs and examples. Do not delete anything.

## 2. Contain

- [ ] Decide whether to pause, restrict or switch off the system.
- [ ] Switch to a manual or fallback process if people depend on it.
- [ ] Tell the system owner and the AI governance lead.

## 3. Assess severity

- [ ] S1: serious harm to people or rights, or a likely legal notification.
- [ ] S2: significant harm or many people affected.
- [ ] S3: limited harm, contained.
- [ ] S4: near miss.
- [ ] Record the number and groups of people affected and the regions.

## 4. Who to notify

*Tick only after confirming with counsel. This list is a prompt, not a statement of what is legally required.*

- [ ] Internal: [executive sponsor, legal, privacy, security].
- [ ] The AI provider or vendor (check your contract for notice terms).
- [ ] Possible regulator or authority notifications by region: [region, authority, deadline, source]. A personal data breach may carry short deadlines.
- [ ] Affected people, if appropriate.

## 5. Investigate cause

- [ ] Find the cause: data change, model change, misuse, attack, process failure or other.
- [ ] Check whether the same issue affects other systems.

## 6. Fix

- [ ] Agree the fix with owners and dates.
- [ ] Re-test before restoring service.

## 7. Document

- [ ] Complete the incident log: description, severity, people affected, actions and notifications made.
- [ ] Record decisions and who made them.

## 8. Review after

- [ ] Hold a blameless post-incident review within [number] days.
- [ ] Record lessons learned and update policies, tests and monitoring.
- [ ] Add actions to the roadmap with owners and due dates.

---

For reference purposes only. This site offers general guidance for learning and planning; it is not legal advice and creates no lawyer-client relationship. Rules change often, so check the primary sources and qualified counsel before you act.