What should a small business put in an AI incident response plan?

By Hugh Donatello, LAN Service Group · Reviewed October 20, 2026

Short answer

Add an AI section to your incident response plan, or write a general plan first if you have none. It should list the AI tools in use and their owners, define what counts as an AI incident, name an incident lead and who can switch a tool off, and set seven steps: report, stop or restrict the tool, preserve evidence, assess the harm, notify, fix, and review. It should also list who you may have to tell. CIO Support's free one-page template covers each of these.

Free one-page AI incident response plan template

Editable Word document and PDF, one landscape page. No form or sign-up. Roles and contacts, five AI incident types, seven steps, notification duties and an incident record. General guidance, not legal advice.

Download Word (.docx) Download PDF

What counts as an AI incident

NIST's Generative AI Profile (NIST AI 600-1) uses a broad definition: an event, circumstance or series of events where the development, use or malfunction of an AI system directly or indirectly contributes to harm, such as harm to a person's health, a breach of legal obligations that protect fundamental, labor or intellectual property rights, or harm to property, communities or the environment. For a small business that uses AI tools rather than building them, these five situations are the ones to plan for, whether or not harm has happened yet.

Your plan should name these situations in plain words, so an employee knows a confidential file pasted into a chatbot is something to report, not something to keep quiet about. NIST's AI Risk Management Framework (NIST AI 100-1) covers this in GOVERN 4.3, practices that enable identification of incidents and information sharing, and MANAGE 4.3: incidents and errors are communicated to relevant AI actors, including affected communities, and tracking, response and recovery are followed and documented.

Five AI incidents a small business should plan for, and the first move for each
Incident	What it looks like	First move	Source
Sensitive data put into an AI tool	An employee pastes customer personal data, health records, financial details, credentials or confidential client documents into a tool that is not approved for that data, such as a personal chatbot account.	Record what data went into which tool and account, and when, and screenshot the chat. Do not delete it yet. Stop further use, then check the vendor's retention and deletion options and whether a notification duty applies.	[5] [1]
Wrong or harmful AI output reached someone	An AI-drafted email, quote, summary or chatbot answer that was false or misleading went to a customer or was relied on in a decision. NIST calls confidently stated but false content confabulation.	Correct or withdraw the output, tell the people who received it, and check whether the same tool produced other output that needs review.	[1]
An AI assistant or agent was manipulated or acted on its own	An AI tool with access to email, files or other systems followed hidden instructions in a web page, email or document (indirect prompt injection), or took an action nobody approved.	Disconnect its access: turn off the connector or integration, revoke its tokens or keys, and review what it did while connected.	[4]
AI-enabled impersonation or fraud	A cloned voice, fake video call or AI-written message that appears to come from an executive, vendor or bank asks for a payment, a bank-detail change or credentials.	Do not act on the request. Verify by calling a number you already have, call your bank at once if money moved, and report the fraud to the FBI's IC3.	[6]
An incident or outage at your AI vendor	The vendor reports a breach, a data exposure or a change that breaks how you use the tool, or the tool becomes unavailable.	Follow the vendor's notice, rotate any keys or passwords tied to the tool, decide whether to pause it, and switch the affected work to your manual fallback.	[1]

Incident types and first moves are CIO Support guidance drawn from the sources cited, not a list published by NIST, OWASP or the FBI. An AI incident can also be an ordinary security incident, such as a stolen AI-tool password, so it follows your general plan as well.

Add it to your existing plan, do not start a second one

NIST published SP 800-61 Rev. 3, its incident response guidance, in April 2025. It supersedes Rev. 2 from 2012 and is written as a profile of the NIST Cybersecurity Framework 2.0. In our view, most of a general plan built on it, such as roles, contacts, evidence and notification, applies to AI incidents unchanged. If you do not yet have a general incident response plan, write that first; CIO Support's guide to a small-business incident response plan covers it.

The AI section adds what a general plan usually lacks: the list of AI tools in use and who owns each, the AI incident types above, the authority and the technical steps to switch a tool off, and the AI-specific evidence to keep, such as prompts, outputs and an agent's action history. NIST's Generative AI Profile suggests related steps for third-party AI tools: define who owns incident response, rehearse the plan at a regular cadence, improve it from retrospective learning, and review it against breach-reporting, data-protection and privacy laws.

Keep the AI section to one page that points back to the main plan for everything the two share; a short page is more likely to be used during an incident.

Roles: who does what

In a company of ten or twenty people one person often holds two of these roles. That is fine as long as each role has a named person and a backup, and the plan says who can make the call to switch a tool off. NIST's AI RMF lists as an outcome that responsibilities to supersede, disengage or deactivate an AI system that is not performing as intended are assigned and understood.

Incident lead: runs the response, keeps the log and makes sure each step happens. Often the operations lead or office manager.
Decision-maker: usually the owner or CEO. Approves switching off a tool the business depends on, spending on outside help, and any message to customers or regulators.
AI tool owner: the person who approved or administers each AI tool. Knows its settings, its admin console and the vendor contact.
IT support, in-house or your managed IT provider: revokes access and keys, preserves logs and checks whether the incident spread to other systems.
Outside contacts, listed in advance: legal counsel, your cyber insurer or broker, your bank, and the support or security contact at each AI vendor.

The seven steps

These steps draw on outcomes in NIST's AI RMF and Generative AI Profile: disengaging a system, responding and recovering, communicating incidents, and after-action review. NIST does not set a sequence; the steps and their order are CIO Support's.

Report it. Anyone who sees an AI incident reports it to the incident lead at once, by a route that works even if email is down. Make reporting blame-free; the paste into a chatbot you hear about in ten minutes is far easier to handle than the one you find in three months.
Stop or restrict the tool. Stop using the tool for the affected task, turn off or suspend the integration or connector, or revoke its access. Disable rather than uninstall or delete, so its logs are more likely to survive. NIST's Generative AI Profile notes that a fallback may include doing the work manually, so decide the fallback for each important tool in advance.
Preserve evidence. Before anything is deleted, save the prompts, outputs, chat history, file names, timestamps, admin and audit logs, and the agent's action history if it has one. Screenshots are better than nothing. Only then ask the vendor to delete data, on counsel's advice if personal data is involved.
Assess the harm. Work out what data was involved and whose it was, how many people or customers are affected, whether wrong output reached anyone, and whether an agent changed or sent anything. Write down what you do not know yet.
Notify. The decision-maker, with counsel where personal data is involved, decides who must be told: affected customers, the vendor, your insurer, your bank, and any regulator or individual a law or contract requires you to notify. Use the clocks you listed in the plan.
Fix and recover. Correct or withdraw bad output, change the tool's settings or permissions, restore normal work, and update your approved-tool list and acceptable-use policy if the incident showed a gap.
Review and improve. Within two weeks, hold a short after-action review: what happened, what worked, what did not, and what changes. NIST's Generative AI Profile suggests after-action reviews to check the response was followed and effective, then updating the plan.

Notification: decide the rules before you need them

Notification is often where a small business gets stuck, so the plan should list the duties that may apply before an incident happens. All 50 states, the District of Columbia, Guam, Puerto Rico and the Virgin Islands have laws requiring businesses to notify people of security breaches involving personally identifiable information. Whether a particular AI incident counts as a breach under one of those laws depends on whether the data is personal information as that law defines it, often a name combined with a Social Security, driver's license or account number; whether pasting it was an unauthorized acquisition; and exemptions such as encryption. That is a question for counsel, not for the plan.

Sector rules add their own clocks. Under the HIPAA Breach Notification Rule, a covered entity must notify affected individuals without unreasonable delay and in no case later than 60 calendar days after discovering a breach of unsecured protected health information. A business associate, such as a billing or IT service, has a different duty: under 45 CFR 164.410 it must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery, and its business associate agreement may set a shorter deadline. NIST's Generative AI Profile names HIPAA breach reporting as an example of reporting AI incidents in line with legal requirements. Contracts with customers, your cyber insurance policy and any government contract may set shorter deadlines of their own, so write each one into the plan with who owns it.

For AI-enabled fraud, the FBI asks victims of financial fraud schemes to file a report with its Internet Crime Complaint Center at ic3.gov, including, if possible, identifying information about the people involved and the transaction details. Our advice: call your bank's fraud line first if money has moved.

What the free one-page template contains

The template fits on one landscape page you can print or keep as a shared document. The top block lists the roles above with a name, a backup and a phone number that works if email is down, and the outside contacts: counsel, insurer, bank and each AI vendor.

The incident-types block lists the five AI incident types with their first move, and the steps block lists the seven steps as a checklist with a box to tick and a time to record. A notification block lists the duties to check, from customer contracts and insurance to state breach laws and HIPAA, with a blank for each deadline that applies to you. The bottom block is an incident record: date found, tool, what happened, data involved, who was told and when, and the follow-up actions.

Each block is labelled with the NIST AI RMF outcomes it supports, so the page also shows a customer, insurer or partner how you handle AI incidents. It is general guidance, not legal advice, and it is not published or endorsed by NIST. It pairs with CIO Support's one-page NIST AI RMF worksheet, which keeps the register of AI tools this plan refers to.

Practice it once a year

A plan nobody has rehearsed tends to fail the first time it is used. CISA's Tabletop Exercise Packages are customizable and include template objectives, scenarios and discussion questions, with cybersecurity scenarios such as phishing and insider threats. The scenarios listed on CISA's page are not AI-specific, but the cybersecurity packages can be adapted to scenarios like an employee who pasted a customer list into a personal chatbot account, or a cloned voice of the owner asking the bookkeeper to wire money.

We suggest one tabletop a year with the decision-maker, the incident lead and your IT provider, plus a quick run-through whenever you connect an AI tool to email, files or payment systems. Update the plan with what each exercise shows.

Common follow-up questions

Do we need a separate AI incident response plan?

Usually not. Most small businesses are better served by an AI section added to their general incident response plan, which already covers roles, contacts, evidence and notification. The AI section adds the AI incident types, who owns each AI tool, how to switch a tool off, and the AI evidence to keep.

Is it an incident if an employee pastes confidential data into ChatGPT?

Treat it as one if the data was not approved for that tool: record what went in, which account was used and when, screenshot the chat before anything is deleted, stop further use, and check the vendor's retention and deletion settings. Whether it is a reportable breach depends on the data, the applicable law and your contracts, so involve counsel when personal data is involved.

Who should be allowed to switch off an AI tool?

Anyone should be able to stop using a tool for a task when it misbehaves and report it. Switching off a tool the business depends on, or revoking its access for everyone, should be the decision-maker's call, carried out by the tool's owner or IT support. NIST's AI RMF lists as an outcome that these responsibilities are assigned and understood.

What evidence should we keep after an AI incident?

The prompts and outputs involved, chat history, file names, timestamps, the tool's admin and audit logs, and the action history of any AI agent, plus screenshots if logs are not available. Save them before deleting anything or asking the vendor to delete data.

Is the AI incident response template free?

Yes. Download the one-page template in Word or PDF on this page, with no form, email or sign-up. It is general guidance, not legal advice, and it is not published or endorsed by NIST.

How often should we test the plan?

NIST does not set a frequency; its Generative AI Profile says to rehearse incident response plans for third-party AI at a regular cadence. We suggest one tabletop exercise a year, plus a quick run-through whenever you connect an AI tool to email, files or payment systems, and an update after every real incident.

Need help with this?

LAN Service Group helps small and mid-size businesses add AI to their incident response plans, from the AI tool register and switch-off procedures to tabletop exercises with leadership, and supports response as their managed IT provider, fully outsourced or co-managed alongside in-house IT staff.

Talk to LAN Service Group LAN Service Group AI services → (888) 281-7243