What an AI incident response plan needs to cover
An AI incident response plan tells your team what to do when an AI tool gives a customer wrong information, exposes data, takes an action it should not, or quietly gets worse. For a small business it needs five parts: every AI touchpoint with its off switch and human fallback, severity levels for AI failures, named roles, first-hour steps, and a review afterward.
If you already have a cybersecurity incident plan, this template adds the AI layer. It assumes AI touches your customers, directly or not, through a website chatbot, an AI receptionist, AI-drafted client emails, or review replies.
What counts as an AI incident
NIST's Generative AI Profile (AI 600-1, July 2024) (opens in a new tab) quotes a working definition: an event where the development, use, or malfunction of an AI system directly or indirectly contributes to harm, such as injury to people, breaches of legal obligations that protect rights, or harm to property. For a small service business, that usually means:
- Wrong information acted on. A chatbot states a refund policy you never offered, or a receptionist books the wrong service.
- Data exposure. Client details pasted into an unapproved tool, or a call transcript sent to the wrong person.
- Manipulated input that triggers an action. Hidden instructions in an email or document make an automated workflow send, change, or delete something.
- Silent degradation. Answers get worse after a vendor or content change, with no error message.
- Harmful output published under your name. A review reply that discloses a customer's details, or an offensive message.
Record near misses too: AI 600-1 suggests tracking "reported errors, near-misses, and negative impacts" (MG-4.3-002), and a caught near miss shows where the next incident may start.
Why a standard incident plan misses AI failures
NIST's incident response guidance, SP 800-61 Rev. 3 (April 2025) (opens in a new tab), says detailed procedures change too often for one static document, so the AI specifics are left to you. Three gaps recur:
- Detection. AI failures often look like plausible output, not errors, so no alert fires when a chatbot invents a policy. The first report often comes from a customer or an employee.
- Containment. Some AI tools have no off switch the person on duty can reach, and some take the whole chat widget or phone line down too.
- Evidence. The prompt, the tool's instructions, the content it retrieved, and the model version may not be kept by default.
AI 600-1 suggests deactivation criteria, escalation when they are met, and a communication plan (MG-2.4-001 to MG-2.4-004), and notes that fallback "may include manual processing" (GV-6.2-006), which for most small businesses means a person.
The template covers all three: detection and off switches in Part 1, the reporting route in Part 3, and evidence in Part 4.
The AI incident response plan template
Every example row is hypothetical; replace it with your own tools, people, and vendors.
Part 1: AI touchpoints, off switches, and fallbacks
Two tables keep it readable on a phone; use one row per touchpoint in each.
| AI touchpoint | What it can do without a person | How you would notice a failure | Off switch, and who can use it |
|---|---|---|---|
| Website chatbot | Answers questions, collects contact details | Weekly transcript sample; customers quoting the bot | Disable the widget in the site admin; owner or office manager |
| AI receptionist | Answers calls, books appointments, sends summaries | Daily read of call summaries; callers reporting a wrong booking | Forward the line to voicemail or a cell phone; owner |
| AI-drafted client email | Drafts only; a person reviews and sends | Reviewer catches it before sending; a client questions a figure | Stop using the drafting template; staff write by hand |
| Review reply assistant | Drafts replies; the owner posts | Owner reads every draft; a customer objects to a reply | Remove its access to the review account |
| AI touchpoint | Human fallback | Vendor contact | What is logged, and for how long |
|---|---|---|---|
| Website chatbot | Contact form and phone number in its place | Vendor support portal (login in the password manager) | Transcripts in the vendor dashboard; check retention |
| AI receptionist | Owner's cell, then voicemail with a same-day callback | Vendor phone and ticket queue | Recordings and transcripts; confirm retention |
| AI-drafted client email | Staff write replies directly | Internal tool owner | Sent mail keeps the final text; drafts may be lost |
| Review reply assistant | Owner writes replies | Vendor support email | Posted replies are public; drafts in the tool |
Fill in the detection column honestly: the tool owner's regular read of outputs finds what nobody reports. A tool with no off switch someone on duty can use quickly is a finding to record now, not during an incident.
Part 2: Severity levels for AI failures
| Level | What it looks like | Hypothetical example | Response |
|---|---|---|---|
| Severe | Harm to a person, sensitive personal data exposed, an automated action that moved money or deleted records, or a pattern across many customers | The AI receptionist reads one client's appointment details to a different caller | Switch off now, preserve evidence, and call counsel before any customer message |
| Serious | Customers got wrong information they may act on, or quality dropped across many interactions | The chatbot tells visitors a discount applies to every service | Switch off or restrict the same day, correct affected customers, open a vendor ticket |
| Minor | One poor output reached someone, with no lasting harm | A review reply posted in the wrong tone, then edited | Fix it, record it, and raise it at the weekly review |
| Near miss | Wrong output that review caught before it went out | A draft email with the wrong invoice amount, stopped in review | Record it and look for a pattern |
Set the level by consequence, not embarrassment. If the scope is unknown, start one level higher and come down once the facts are in.
Part 3: Roles and the reporting route
- Incident lead. Sets the severity and runs the first hour. Often the owner.
- Tool owner. Knows the configuration and can use the off switch; one per touchpoint.
- Communications. Drafts customer messages; nothing goes out without the incident lead's approval.
- Vendor liaison. Opens the ticket, requests logs, and asks what changed on the vendor's side.
- Counsel and insurer. Names and phone numbers, written down in advance.
- Reporting route. One place, such as the incident lead's phone or a shared channel, where staff report suspected AI problems and forward customer complaints about the chatbot or phone assistant. If you have an AI acceptable use policy, its mistake-reporting rule should name the same person and channel.
One person can hold several roles, but every role needs a named backup.
Part 4: First-hour steps
Triage. The incident lead confirms what was reported through the Part 3 route and sets the severity from Part 2.
Contain. Use the off switch or restrict the tool to a safe mode, and route the channel to the human fallback. Delete nothing.
Preserve. Capture the prompts, outputs, system instructions or configuration, model name and version if the tool shows them, retrieved documents, timestamps, and screenshots. Export the vendor's logs before any retention window closes. SP 800-61 Rev. 3 recommends recording investigation actions and preserving the integrity of incident records and data (RS.AN-06 and RS.AN-07).
Scope. Work out how many interactions, which customers, since when, and what data. Search the transcripts for the same pattern.
Escalate to the vendor. Open a ticket with the evidence and ask whether the model, configuration, or service changed. If it looks like a deliberate attack rather than a malfunction, also bring in whoever handles your IT security. AI 600-1 suggests vendor contracts cover serious-incident notification and incident response service levels (GV-6.2-007); check yours in advance with the incident-notification row of the AI vendor evaluation checklist.
Decide on notification. If personal data may be involved, talk to counsel before messaging customers. Once the facts are confirmed, correct what affected customers were told.
Log decisions. Write down each decision, when, and by whom; the after-action review depends on it.
Part 5: Review and return to service
After containment, hold a short after-action review: what failed, how it was detected, how long containment took, whether the off switch and fallback worked, and what evidence was missing. AI 600-1 suggests after-action assessments of this kind (MG-4.3-001).
Switch the tool back on only after the fix passes the case that failed and the tool owner signs off, then update the touchpoint table and your AI risk register.
A hypothetical scenario: the chatbot that invented a refund policy
The scenario does not describe a real business.
A twelve-person home services company runs a website chatbot that answers from its FAQ page. On a Saturday, the office manager notices two contact-form messages mentioning a "30-day, no-questions refund" the company never offered.
- Severity. Serious: customers may act on the claim; no personal data is exposed.
- First hour. She disables the chat widget, leaving the contact form and phone number in place, then screenshots both messages, exports a week of transcripts, saves the bot's settings, and texts the owner, who becomes incident lead.
- Scope. A transcript search finds the claim in a handful of conversations, all since Wednesday, when an FAQ rewrite removed the warranty section.
- Vendor. The vendor reports no model change, which points to the content.
- Customers. The owner decides whether to honor or correct what each affected visitor was told, and contacts each one.
- Review. Refund and warranty questions now hand off to a person, and any FAQ edit triggers a ten-question retest before the bot goes back on.
The cause was an ordinary content edit, not an attack. The plan worked because the off switch, the evidence, and the decision-maker were known before Saturday.
Breach notification and other legal questions
This section is informational, not legal advice. Notification duties depend on what data was involved, whose it was, where those people live, your industry, and your contracts. As of October 2026, the FTC's Data Breach Response guide for business (August 2023) (opens in a new tab) states that all states, the District of Columbia, Puerto Rico, and the Virgin Islands have laws requiring notification of security breaches involving personal information, and tells businesses to talk to legal counsel. AI 600-1 likewise suggests reviewing incident plans for third-party AI tools against breach reporting, data protection, and privacy laws (GV-6.2-003), and client contracts may add their own notice clocks. Check your obligations before each new touchpoint launches.
Rehearse the plan before you rely on it
A plan nobody has rehearsed is a guess. Run a tabletop: walk the people named in Part 3 through the scenario above, or your own, with a clock running. Who notices? Who uses the off switch? Does the fallback work, and does the evidence exist? AI 600-1 suggests rehearsing incident plans for third-party AI tools regularly (GV-6.2-003).
How to red-team an AI system covers this exercise in its disaster-recovery walkthrough, and the shadow AI post covers touchpoints nobody approved, which belong on your list too.
Cleland & Co. publishes its failure planning method as the AI Contingency Framework: named failure conditions, rehearsal, and sustainment after launch. The advisory and fractional engagements apply it, and anyone can use it as a checklist for their own plan.
