AI Incident Response Plan for Small Businesses (With Template)

Write it as a two-page document that names one incident lead and a deputy, defines what counts as an AI incident, sets three severity levels, and lists the first actions for each: switch the tool or automation off, preserve the evidence, tell the right people within set times, fix the cause, and record what you learned.

Where small firms usually go wrong is assuming their general IT or cyber plan already covers AI. The incidents AI causes are different: client data pasted into a personal chatbot account, an automation emailing the wrong invoice to 40 customers, a chatbot promising a discount you don't offer. Each needs a named person and a known off switch, and many owners only discover where those switches are in the middle of an incident.

Follow me on Instagram@sagnikteaches

What counts as an AI incident in a firm your size

An AI incident is any event where an AI tool, or an automation that uses one, exposes data, harms a customer, costs money or does something nobody approved. The label matters because it is what sets the plan in motion. A clumsy draft that someone catches before it goes out is not an incident; it belongs in your AI error log, where quality problems are tracked over time.

Connect on LinkedInSagnik Bhattacharya

Name these seven types in your plan, because they are the ones small businesses actually run into:

Subscribe on YouTube@codingliquids

Three severity levels, and who hears about each

Severity decides speed. Three levels are enough for a small team; with more, people argue about the level instead of acting.

One rule saves a lot of dithering: if you can't choose between two levels within ten minutes, treat it as the higher one for the first hour. Downgrading later costs nothing. Discovering at hour 60 that it was a Level 3 costs a great deal, because some notification clocks start when you become aware of a problem, not when you finish investigating it.

Four quick cases show how the levels sort real events (all illustrative):

• Not an incident. A bookkeeper's AI-drafted year-end email to a client gives the wrong filing date; the partner spots it before it's sent. Log it in the error log and move on.
• Level 1. An estate agency's automation posts twelve listings to its own website with the asking prices from last month, for about three hours on a Sunday morning, and no enquiries come in during that time. Fixed, logged, and the cause is found on Monday.
• Level 2. The same agency, but two buyers booked viewings quoting the wrong price, or a staff member pasted one tenant's reference letter into a personal chatbot account.
• Level 3. The agency's full applicant spreadsheet, with contact details and salaries, is uploaded to an unapproved AI tool that shares chats by public link, and one link has been posted in a group chat.

The difference between the second and third listing cases is not the fault, which is identical, but whether anyone outside acted on it. That's why the scoping questions in the first hour matter so much.

Roles for a team of five or fifteen

The plan needs names rather than job titles, and every name needs a deputy for holidays. In most small businesses the roles fold into two or three people:

• Incident lead. Runs the response, switches things off and keeps the log. Usually whoever manages your AI tools day to day. They need admin access to every tool on the kill-switch sheet, or the mobile number of whoever has it.
• Owner or director. Decides anything involving money, customer promises, notifications and public statements. Stays out of the technical work.
• Customer contact. Speaks to affected customers. Keep this separate from the incident lead if you can; the person fixing the fault shouldn't also be answering the phone.
• External contacts. IT support, your insurer's claims line, your data-protection adviser or solicitor, and the support route for each AI vendor. Write the numbers into the plan. Searching for an insurer's phone number mid-incident burns the first hour.

If you haven't yet settled who owns AI decisions in general, do that first; AI governance for a small business sets out who decides, approves and checks.

The first hour: contain first, investigate second

The instinct is to work out what happened. Hold off until the damage has stopped growing. In this order:

1. Stop it. Switch the automation off (in Zapier, turn the Zap off; in Make, switch the scenario off). Replace the chatbot with a "please call us" message or remove it from the page. Cut the AI tool's access to your accounts: for a Google account that's Security, then Third-party apps & services, then remove access; for Microsoft 365, your admin or IT support can remove the app's permissions. Revoke any exposed API key in the vendor's developer console and issue a new one. Change the password of a compromised login and sign out its other sessions.
2. Keep the evidence. Before deleting anything, take screenshots, export the chatbot transcript, save the automation's run history and write down times. You'll need all of it for the fix, for customers and possibly for your insurer.
3. Pull public links. If a conversation was shared by link, delete the link. In ChatGPT these sit under Settings, Data controls, Shared links. Deleting a link stops future access but doesn't recall a copy someone already saved, so note who might have seen it.
4. Scope it. Answer four questions in the log: what data or which customers, how many, since when, and is it still happening?
5. Set the level and tell the people that level requires.

Hours 1 to 72: notify, fix and put things right

When personal data is involved

Under data-protection law such as the GDPR, a business must report a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to put people's rights and freedoms at risk. Where the risk to individuals is high, you must also tell the people affected without undue delay. If your AI vendor suffered the breach, it has to tell you promptly. Whether your incident meets those tests is a judgement call, so for any Level 3 ring your data-protection adviser or solicitor on day one rather than deciding alone.

Your insurer

Many policies require prompt notice of anything that could lead to a claim, and late notice can give an insurer grounds to refuse. Read your wording now, while nothing is on fire. Whether your business insurance covers AI mistakes depends heavily on that wording.

Affected customers

Customers hit by a wrong answer or a misdirected email need to hear from a person, quickly, with a plain account of what happened and what you're doing about it. What to say, and when to honour a price or promise the AI made, is covered in what to do when AI gets something wrong with a customer.

The fix

Fix the cause, not only the symptom. If a chatbot quoted an old price, correcting that one price leaves the real fault in place: nobody owns the bot's source material. Before switching anything back on, run it on test data with a person watching, and add a check that would have caught this particular failure. For automations that usually means an approval step before anything goes to customers in bulk, plus alerts when a run fails; stopping automations breaking silently shows how to set those alerts up.

Your kill-switch sheet

This is the page people actually open during an incident, so fill it in before you need it. One row per AI tool or automation. The rows below are examples of the level of detail to aim for:

Test every "how to switch it off" entry once, for real, on a quiet afternoon. A common gap is that only the person who built an automation knows where it lives, and they're on holiday the week it misfires. An automation audit finds those orphaned workflows before they find you.

A two-page plan to copy and fill in

Copy this into a document, fill in the brackets and keep a printed copy somewhere other than the systems it protects. Two pages is the target; if yours grows past four, people won't read it under pressure.

AI INCIDENT RESPONSE PLAN
[Business name]   Version [1.0]   Last tested [date]   Next review [date]

1. PURPOSE
This plan says what we do when an AI tool, or an automation that uses one,
exposes data, harms a customer, costs money or acts without approval.

2. PEOPLE
Incident lead:      [name]  [mobile]     Deputy: [name]  [mobile]
Decision-maker:     [owner/director]  [mobile]
Customer contact:   [name]
IT support:         [company]  [number]  [hours]
Insurer claims:     [number]  Policy no. [ ]
Data-protection adviser or solicitor: [name]  [number]
AI vendors:         [vendor]  [support route]   (one line per vendor)

3. WHAT COUNTS AS AN AI INCIDENT
- Personal or confidential data put into an unapproved tool, or exposed
- AI output that reached a customer and was wrong, misleading or offensive
- An automation that sent, changed or deleted things it should not have
- A compromised AI account, a leaked API key, or unexplained usage charges
- An AI tool taking an action nobody approved
- A security incident reported to us by an AI vendor

4. SEVERITY
Level 1  Contained; no customer or personal data affected.
         Log within 1 working day.
Level 2  Customer affected, or small data exposure.
         Lead acts within 1 hour; owner told the same day.
Level 3  Many people's data, money lost, legal or public exposure.
         Owner told immediately, day or night.
If unsure, treat it as the higher level for the first hour.

5. FIRST HOUR
[ ] Stop it: switch off the tool or automation (kill-switch sheet)
[ ] Keep evidence: screenshots, logs, transcripts, times
[ ] Delete public links; revoke keys; change passwords
[ ] Scope: what data, which customers, how many, since when, still happening?
[ ] Set the level and tell the people in section 4
[ ] Open the incident log

6. WITHIN 72 HOURS
[ ] Personal data involved? Adviser consulted on notification (date, time)
[ ] Insurer notified if the policy requires it (date, time)
[ ] Affected customers contacted by a person (who, when)
[ ] Root cause found; fix tested before switching back on
[ ] Decision to switch back on recorded (by whom)

7. AFTERWARDS
[ ] Review meeting within 10 working days
[ ] Risk register, usage policy and training updated
[ ] This plan changed if any part of it failed

INCIDENT LOG (one per incident)
Found (date, time):             Found by:
What happened:
Level:                          Changed to (and why):
Actions (time, who, what):
People and data affected:
Notifications made (who, when):
Root cause:
Fix, and how it was tested:
Changes we are making:
Closed by, date:

Blank, the log looks bureaucratic. Filled in for a small Level 2 case at a florist whose website chatbot made a promise the shop can't keep, it reads more like a short story (illustrative):

INCIDENT LOG  #2026-04
Found (date, time):   Sat 12 Sep, 16:40     Found by: shop assistant
What happened:        Website chatbot told customers that same-day
                      Sunday delivery is free. We don't deliver on Sundays.
Level:                2                     Changed to (and why): -
Actions:              16:45 lead paused the bot, contact form shown instead
                      17:10 exported the last 3 days of transcripts
                      17:30 found 3 customers given the promise
People and data affected: 3 customers; no personal data exposed
Notifications made:   owner 17:35; all 3 customers phoned by 19:00;
                      owner chose to honour the 3 deliveries
Root cause:           last December's holiday delivery offer was still
                      on the FAQ page, which the bot reads as its source
Fix, and how tested:  offer removed; 20 delivery questions put to the bot
                      on Mon 14 Sep before it was switched back on
Changes we are making: FAQ page now has a named owner; every seasonal
                      offer carries an end date on the page itself
Closed by, date:      owner, Tue 15 Sep

Two lines in it do most of the work. "Root cause" points at the source material rather than the bot, which is where the fix belonged. And "Changes we are making" names something that stops the next seasonal offer causing the same trouble in a year's time.

Worked example: a cleaning company's invoice mix-up

This is an illustration, not a real client. Say an 18-person commercial cleaning company runs a Make scenario every Friday: it reads completed jobs from a spreadsheet, has an AI model write a two-line summary of the work, builds each invoice and emails it to the customer. Someone inserts a column in the spreadsheet, and the scenario starts pairing each customer's email address with the next row's invoice.

• 08:10 A customer rings: they've received another client's invoice, showing that client's name, address and amount.
• 08:20 The incident lead switches the scenario off. The run history shows 61 invoices went out and which address each went to. Level 2 for now.
• 08:45 Scoping shows 43 of the 61 went to the wrong customer. Most are businesses, but nine are sole traders whose invoices show home addresses. The lead raises it to Level 3 and calls the owner.
• 10:00 The owner rings the firm's data-protection adviser. They agree what to record and a timetable for deciding on notification well inside the 72-hour window.
• 11:00 to 15:00 The customer contact emails each wrong recipient asking them to delete the invoice and confirm they have, then phones the 43 affected customers with a plain explanation. Correct invoices go out by hand.
• Day 2 Root cause: the scenario matched on column position, not column name. The fix matches on customer ID, adds a filter that halts any invoice whose customer name doesn't match the recipient record, and makes a person approve the Friday batch for the next four weeks.
• Day 8 Review meeting. The plan held up, but the kill-switch sheet hadn't said where the run history lives. That line is now added.

The email to the wrong recipients is where wording matters most, because it's the one asking a favour of people who didn't cause the problem. A first draft in that sort of hurry tends to read: "Please disregard the previous communication, which was sent in error due to a technical issue. We apologise for any inconvenience." It doesn't say what to do, and "technical issue" sounds like an excuse. A better version:

Subject: Please delete the invoice we sent you this morning

This morning we emailed you an invoice that belongs to another of our
customers. That was our mistake, caused by a fault in our invoicing
system, which we've now switched off.

Please delete that email and its attachment, and reply to this
message to confirm you have. Your own correct invoice will follow
separately today.

I'm sorry for the trouble. If you have any questions, call me
directly on [mobile].
[Name], [role]

Rough cost: about 14 staff hours over three days, plus the adviser's time. Without a plan, the realistic alternative is the same scenario running again the following Friday because nobody was sure what had caused it.

Test it with a 30-minute tabletop drill

A tabletop drill is just a conversation. You read out a scenario, and the people named in the plan say what they would do, step by step, using only the plan. Nothing is switched off for real. Run one when the plan is new, then every six months, and whenever you add an AI tool that touches customers or personal data. Three scenarios that exercise different parts of the plan:

1. "A new starter tells you they pasted last month's payroll spreadsheet into a personal chatbot account to tidy it up." Tests data exposure, whether anyone knows how to delete the chat and check the account's training setting, and whether this is Level 2 or 3.
2. "A customer forwards a chatbot transcript in which your bot promised free weekend call-outs." Tests customer handling, who decides whether to honour it, and whether anyone knows where the bot gets its information.
3. "This morning's usage dashboard shows $900 of API charges overnight. A normal month is about $40." Tests key revocation, who can log in to the developer console, and how to reach the vendor.

During the drill, keep asking three things: who is doing this, where is that written down, and has a deadline passed yet? Every "I'm not sure" becomes a line you add to the plan. When a small print shop ran scenario 3, for instance, the answers exposed three gaps in twenty minutes: nobody knew which email address the developer console login used, the only person with access was the freelancer who built the integration, and nobody had set a spending limit on the account. The plan gained a login entry on the kill-switch sheet, a second admin, and a monthly cap set in the console's billing settings the same afternoon.

The review that stops a repeat

Within ten working days, hold a short review with no blame attached. Work through five questions: what happened, in time order? Why wasn't it caught sooner? What did the plan get right? What was missing or wrong in it? What changes now, whether that's a tool setting, an approval step, training or the plan itself?

Write the answers in the incident log and carry the risk into your risk register so it gets checked again. An incident that closes with a named change, an owner and a date is finished. One that closes with "we'll be more careful" tends to come back.

Questions owners ask about AI incident plans

Do I need a separate AI incident plan if I already have a cyber incident plan?

Not necessarily. You can add an AI section to your existing plan, as long as it covers the AI-specific cases: wrong answers reaching customers, automations misfiring at volume, staff pasting data into unapproved tools, and leaked API keys. Standard cyber plans tend to focus on malware and hacked accounts. Keep one contact list and one severity scale so nobody has to decide which plan applies.

Who should be the incident lead in a five-person business?

Usually the person who set up or manages your AI tools, as long as they have admin access or can reach whoever does. It shouldn't automatically be the owner: the owner makes the decisions about money, customers and notifications, while someone else switches things off and keeps the log. Name a deputy for holidays, even if the deputy is the owner.

Do I have to report every AI mistake to a regulator?

No. Most AI mistakes, such as a wrong draft or a clumsy reply, carry no reporting duty at all. Duties usually arise when personal data is exposed, and even then data-protection law such as the GDPR ties reporting to the risk to the people affected. Record every incident and your reasoning, and ask your data-protection adviser whenever personal data is involved.

Further reads

• Shadow AI: Is Your Team Using AI Without Telling You? — Many data-exposure incidents start with a tool nobody approved.
• A Simple AI Risk Register for Small Businesses (With Template) — Where each incident's lesson should end up.
• Does Cyber Insurance Cover AI Incidents? What Insurers Ask — What insurers ask before they'll cover AI incidents.
• AI Security Risks for Small Businesses and How to Close Them — Close the gaps that cause incidents in the first place.
• How to Add Human Approval Steps to AI Automations — The approval step that stops most bulk-send misfires.
• What Can Go Wrong When AI Agents Take Actions for You? — New incident types once AI tools can take actions.
• Who Should Own AI in a Small Business? Roles and Responsibilities — The four roles AI needs in any small firm, how they're split in a barber shop, an optician and a garden centre, and a responsibilities chart to copy.
• How to Write an AI Usage Policy for Your Small Business — Section-by-section wording, a data traffic-light table, a one-page template and how a tutoring agency's first draft changed after staff read it.
• AI Compliance Checklist for Small Businesses: What Applies to You — Map each AI use to the rules it triggers, work through data-protection and EU AI Act checks, and see a language school's uses mapped end to end.
• How to Run a Pre-Mortem Before You Launch an AI Project — A facilitator script, a 75-minute agenda and AI-specific failure prompts for finding what will sink your AI project before it goes live.
• AI Literacy Requirements: What Your Staff Need to Know — A role-by-role checklist of what staff should know about AI, what Article 4 of the EU AI Act asks since the 2026 changes, and how to record it.
• How to Roll Out an AI Policy So Staff Actually Follow It — The launch plan for an AI policy: one-page rules, an amnesty for hidden tools, paid accounts that beat free ones, and checks that don't feel like spying.
• What Are the Risks of Using AI in My Small Business? — Eight risks of using AI in a small business, a four-factor score for your own exposure, three example risk profiles, and the cheapest control for each risk.
• Is It Safe to Put Customer Data Into ChatGPT? — Which ChatGPT plans can take customer data, which data never goes in, and a two-minute routine for stripping identifiers when you must use a personal plan.
• AI Acceptable Use Policy for a Small Professional Firm — A clause-by-clause checklist and one-page sample policy for accountants, lawyers and consultants who handle confidential client work.
• 7 AI Mistakes That Put an Accounting Firm's Client Trust at Risk — Seven ways AI use damages trust in an accounting practice, each with how it shows up with clients and the control that prevents it.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: GDPR Articles 33 and 34 (personal data breach notification); Zapier pricing and help pages; Google Account Help on third-party connections; OpenAI Help Center on managing shared links.