Skip to content
AI Compliance Tool
Check my AI risk
PlatformSolutionsPricingRegulationsFree toolsGuides Partners Sign in

Creating an AI Incident Response Plan

How a small business builds an AI incident response plan: incident types, severity levels, a six-stage workflow, privacy-breach touchpoints, a tabletop exercise and a record template.

By AI Compliance Tool editorial team · Published 2026-10-14 · Reviewed 2026-10-14 · Reviewer: Pending independent review · 10 min read

Key takeaways

  • An AI incident is any event where an AI system produces harmful, wrong or unauthorized output or action, exposes data, or behaves outside its approved scope. Most are not security breaches, but some become privacy breaches.
  • Use one workflow for every incident: Reported, Triaged, Investigating, Contained, Resolved, Reviewed. Each stage has an owner, a timebox and a record.
  • Build privacy-breach assessment into triage. PIPEDA s. 10.1 and Alberta PIPA s. 34.1 turn on a real risk of significant harm; Quebec has confidentiality-incident reporting; BC PIPA has no statutory notification duty; GDPR has its own notification articles.
  • From 2 December 2027, EU deployers of Annex III high-risk systems must report serious incidents, suspend use where the system may present a risk and keep logs for at least six months (Art. 26(5)-(6)). Texas and Colorado offer 60-day cure periods that reward a ready playbook.

Most small businesses have some kind of IT incident process. Few have one for AI, and the gap shows the first time a chatbot quotes a price that does not exist, an agent emails the wrong client, or a screening tool is accused of bias. This guide gives you a plan you can adopt in an afternoon: incident types, a severity scale, a six-stage workflow, the points where privacy law enters, a tabletop exercise and a record template.

What counts as an AI incident

An AI incident is any event where an AI system you build or use produces harmful, incorrect or unauthorized output or action, exposes data, or operates outside its approved scope. Common types:

TypeExample
Harmful or wrong output reaching a personSupport bot gives incorrect refund terms; summarizer misstates a contract clause sent to a client
Privacy exposureA user’s prompt contains another customer’s data; transcripts shared with a vendor beyond the agreed purpose
Discrimination or fairness complaintCandidate alleges a screening tool rejected them on a protected ground
Unauthorized agent actionAn agent with calendar and email access sends or deletes something it should not
SecurityPrompt injection extracts system instructions or data; API key leaked in a log
Vendor or model changeVendor silently updates a model and output quality drops; outage mid-process
Misleading AI claims or regulatory contactA complaint or regulator inquiry about accuracy or disclosure
Scope violationStaff use an unapproved tool with confidential data

Record all of them, including near-misses. The NIST AI RMF places incident response inside its Manage function, and Canada’s Voluntary Code of Conduct on advanced generative AI commits signatories to post-release monitoring with incident reporting. Both are voluntary, but they describe what a reasonable program looks like.

Severity levels

Keep it to four levels and define them by impact, not by how embarrassing the event is.

LevelDefinitionResponse target
S1 CriticalPersonal data of multiple people exposed; a consequential decision (hiring, credit, health, housing) affected; financial loss or legal exposure likely; regulator or media involvement plausibleContain within hours; executive and privacy contact informed same day
S2 HighSingle-person data exposure; wrong output acted on by a customer or employee; agent took an unauthorized but reversible actionContain within one business day
S3 MediumWrong output caught before action; degraded quality; policy violation with no data exposureFix within a week
S4 LowNear-miss or cosmetic issueLog and batch into the next review

The workflow

Use the same six stages for every incident. Each stage has an owner, a timebox and a line in the incident record.

1. Reported. Anyone can report. Give staff a single channel (a form, an email alias or a chat command) and tell them that reporting is expected, not punished. Capture who, when, which system and what happened. Timebox: immediate.

2. Triaged. The governance owner assigns a provisional severity, names an investigator and runs the privacy-breach screen (below). If personal information may be involved, the privacy contact joins now, not later. Timebox: within one business day of the report, or same day for suspected S1.

3. Investigating. The system owner reconstructs what happened from logs, prompts, outputs and user reports; identifies the cause (prompt, model, data, integration, human use, vendor change); and lists who was affected. Preserve logs and screenshots before anything is changed. Timebox: proportional to severity, typically one to five business days.

4. Contained. Stop the harm from continuing. Options, in rough order of disruption: correct the specific output and contact affected people; restrict the feature; revoke the agent’s credentials or disable the tool; suspend the system entirely. From 2 December 2027, EU deployers of Annex III high-risk systems must suspend use where the system may present a risk and inform the provider and market-surveillance authority (Art. 26(5)); build that decision into this stage now.

5. Resolved. Root cause addressed, affected people informed where required, vendor engaged if the cause was theirs, and the system returned to service with a documented change. Resolution is signed by the system owner and governance owner.

6. Reviewed. Within two weeks, a short post-incident review: what happened, why, what changed, what evidence was retained, whether the inventory and risk assessment need updating. Trend incidents quarterly.

Privacy-breach touchpoints

AI incidents involving personal information can trigger breach obligations that have their own tests and timelines. Build the questions into triage:

  • Was personal information lost, or accessed or disclosed without authorization? If no, it is an AI incident only. If yes or unsure, continue.
  • PIPEDA (federal and most provinces). Section 10.1 sets out breach-of-security-safeguards reporting; the test is whether the breach creates a real risk of significant harm to an individual. Our dataset confirmed s. 10.1 from the statute’s table of contents, so read the current section text before relying on this summary.
  • Alberta PIPA s. 34.1. Notify the Commissioner without unreasonable delay of a loss or unauthorized access or disclosure where a real risk of significant harm exists.
  • Quebec P-39.1. Law 25 added confidentiality-incident reporting obligations to the Commission d’accès à l’information. Quebec also requires a privacy impact assessment (s. 3.3) for information-system projects, which should already describe the AI system’s data flows and make the incident assessment faster.
  • BC PIPA. There is no statutory breach-notification duty, but OIPC BC guidance addresses AI reliance and reasonable security arrangements still apply (s. 34).
  • GDPR (EU personal data). The GDPR contains breach notification duties to supervisory authorities and affected individuals (Arts. 33-34). Those articles were not line-verified in our dataset; confirm thresholds and deadlines with EU counsel.
  • Vendors. PIPEDA’s accountability principle makes you responsible for information transferred to a processor. Your AI vendor contracts should require prompt incident notification to you; check the clause during triage.

Document the assessment even when you conclude no notification is required. The reasoning is the evidence.

Regulatory inquiries and cure periods

Two US laws reward preparation. Texas TRAIGA (effective 1 January 2026) gives the Attorney General exclusive enforcement with written notice and a 60-day cure period. Colorado SB 26-189 (obligations from 1 January 2027) provides a 60-day notice-and-cure before Attorney General actions filed before 1 January 2030. A “cure playbook” is simply this incident process pointed at a regulator’s letter: triage within a day, investigate, fix, document, respond inside the window.

Tabletop exercise

Run this with four people in 60 minutes: the governance owner, a system owner, the privacy contact and someone from the front line.

  1. Scenario (5 min). Read it aloud. Example: “Bluewater Dental Group’s website chatbot, built on a vendor platform, has been answering ‘what time is my appointment’ by returning other patients’ names and times. A patient posted a screenshot online 40 minutes ago.”
  2. Report and triage (10 min). Who hears about it first? How does it reach the governance owner? What severity? Does the privacy screen trigger? (Yes: health-related personal information disclosed to third parties.)
  3. Investigate (15 min). What logs exist? Who at the vendor do you call? How do you find out how many patients were affected and over what period?
  4. Contain (10 min). Do you disable the chatbot entirely or only the appointment lookup? Who has the credentials to do it? What do you tell the patient who posted?
  5. Resolve and notify (10 min). Which breach tests apply (Bluewater is in Alberta: PIPA s. 34.1)? Who drafts the notification? What does the vendor fix?
  6. Review (10 min). What would have made this faster? Typical findings: nobody knew who could disable the bot; no log retention; the vendor contract had no incident clause.

Write up the findings as actions with owners and dates. That write-up is itself evidence that the plan is maintained.

Incident record template

Keep one record per incident with these fields:

  • Incident ID, date and time reported, reporter
  • AI system (inventory ID), vendor, owner
  • Description of what happened and how it was detected
  • Provisional and final severity
  • Privacy screen: personal information involved (yes/no/unsure); jurisdictions; test applied; decision and reasoning; notifications made and dates
  • Investigation summary and root cause
  • Containment actions, by whom, when
  • Affected people and communications
  • Resolution and system changes
  • Review date, lessons, follow-up actions with owners
  • Evidence retained: log extracts, screenshots, correspondence, with file hashes
  • Status: Reported / Triaged / Investigating / Contained / Resolved / Reviewed

Store records in a place the whole response team can reach and keep them for at least as long as your longest applicable retention duty. Colorado will require three years of compliance records from 2027; EU high-risk deployers must retain logs for at least six months. For other cases, set a defensible period with counsel and apply it consistently.

Sources

Frequently asked

Is a hallucination an incident?
It is if it reached a customer, employee or decision and could cause harm, cost or a complaint. A wrong answer caught in testing is a finding, not an incident. Your severity scale should make that distinction.
Who should own AI incidents in a company with no compliance team?
The AI governance owner (often the operations lead) coordinates, the system owner investigates, and the privacy contact decides breach questions. Name all three in the plan and give them backups.
When does an AI incident become a reportable privacy breach?
When personal information was lost, accessed or disclosed without authorization and the applicable test is met: a real risk of significant harm under PIPEDA s. 10.1 and Alberta PIPA s. 34.1, Quebec's confidentiality-incident rules, or GDPR's notification provisions for EU data. Confirm the current statutory text and timelines with counsel; thresholds and deadlines differ.
How often should we run a tabletop exercise?
At least once a year, and after any material change such as deploying an agent with write access or adding a new jurisdiction. A 60-minute session with four people is enough.

This guide is general information, not legal advice. Laws and dates are drawn from our verified regulatory dataset and link to official sources; check them for changes after the review date.