AI incident response plan: a template for small teams
Four AI incidents account for nearly everything that goes wrong at small companies. A one-page plan that names them beats a twenty-page policy nobody opens.
An AI incident response plan is a page that answers one question: when something goes wrong with a tool nobody formally approved, who does what in the first hour. Small teams skip this because incident response sounds like something with a security operations centre attached. It is not. Four things go wrong, they go wrong repeatedly, and the entire useful plan fits on one side of paper.
Below is that page, written out. Adapt the names, keep the structure.
The four incidents
Not a risk register. These are the ones that actually occur at companies of five to fifty people:
Confidential data was pasted into a tool.
A contract, a customer list, a patient record, source code. Usually by someone competent and busy who did not think of it as a transfer.
A wrong AI answer reached a customer.
A drafted email quoted a policy that does not exist, a chatbot promised a refund, a generated document contained an invented figure.
An agent took a destructive action.
Deleted files, sent a batch of emails, pushed a change, spent money. Anything with write access qualifies.
A vendor had a breach or shut down.
Your data was in a tool that got compromised, or the tool disappeared with your data in it.
If your plan covers those four, it covers the field. Everything else is a variation. One variation common enough to plan for separately: if someone deepfakes your business with cloned audio or video of an executive, the first-hour actions differ enough from the four above that it deserves its own line in the plan.
The first hour, per incident
Speed matters in the first hour and precision does not. Write these as actions, not principles.
Incident | First action | Second action |
|---|---|---|
Data pasted into a tool | Note exactly what was pasted, where, and when. Do not delete the chat yet, it is your evidence | Check the vendor's retention and training settings, then request deletion in writing |
Wrong answer sent | Correct it with the recipient directly, in plain words, same day | Find every other place the same wrong statement went out |
Agent did something destructive | Revoke the agent's credentials before anything else | Restore from backup, then read the logs to find what triggered it |
Vendor breach or shutdown | Rotate every credential that tool held | List what data was in it and who needs telling |
The order in row three is the one people get wrong. The instinct is to investigate first. Revoke first: an agent that misbehaved once is still running, and understanding why can wait ten minutes.
Who decides
Name one person, by name, not by role. Two rules attached to them:
They can stop any AI tool being used, immediately, without asking anyone.
They decide whether an incident needs to be reported externally, and they get that decision reviewed by someone qualified when personal data is involved.
A plan with a committee in it is a plan that activates on Monday. Deputise a second person for holidays and stop there.
What you need before an incident, not during
Three artefacts, and none of them takes a day to produce.
A list of tools in use. Not the approved list, the real one. Ask the team, without blame, what they actually use. The gap between those two lists is shadow AI, and during an incident it is the difference between knowing where your data went and guessing. Ask once a quarter, keep it in a spreadsheet, and do not make disclosure feel like a confession.
A record of what was sent where. Not surveillance. Just enough of an audit trail of AI use that you can answer "which customer records could have been in that tool" without a week of interviews. For most teams that means logging which systems are connected to which tools, not logging every prompt.
A written rule people have read. One page covering what may never be pasted into a general AI tool, and which tools are approved for customer data. That is the job of an AI usage policy, and a policy nobody read is worse than none, because it creates the appearance of control.
The reporting question
This is where small teams freeze. The honest guidance: if personal data about identifiable people went into a tool that should not have had it, that is potentially a notifiable data breach in most jurisdictions with a privacy regime, and the clocks are short. In the EU the GDPR requirement is notification to the supervisory authority within 72 hours of becoming aware, per Article 33, with narrow exceptions.
You do not need to decide that alone, and you should not. What the plan needs is a trigger: personal data involved means legal advice today, not next week. Getting told it was not notifiable costs an hour. Missing a deadline costs considerably more.
Test the AI incident response plan before you need it
Spend twenty minutes on a tabletop. Read out one scenario, have the named person walk through what they would do, and write down every question nobody could answer. Those gaps are the plan's real content.
A good scenario to start with, because it is the most likely: someone pastes a customer contract into a general chatbot to summarise it, and mentions it in passing a week later. Who do they tell, what do you do about the copy that already exists on a vendor's servers, and does anyone need to be notified? If your team can answer that comfortably, the plan works.
None of this makes AI safe to use carelessly. It makes the aftermath survivable, which is the achievable goal, and it belongs alongside the broader picture of AI risks rather than instead of it. The alternative is what most teams have now: a plan that gets invented at speed, by whoever noticed, on the worst afternoon of their quarter.
FAQ
Do we need a formal incident response plan for AI?
You need one page naming four scenarios, one decision maker and the first action for each. Formality is not the point, speed is. Anything longer will not be opened during an incident.
Is data pasted into a chatbot a reportable breach?
It can be, when it includes personal data about identifiable people and the tool was not authorised to hold it. The determination depends on your jurisdiction and the data, so the plan should trigger legal advice rather than try to answer it.
What is the first thing to do when an AI agent deletes something?
Revoke its access before investigating. The agent is still running and still holds the permissions that let it act. Diagnosis can wait ten minutes, further damage cannot.
How do we find out which AI tools staff actually use?
Ask directly and make it blameless, once a quarter. Auditing tools will find installed software and miss anything used in a browser, which is most of it.
How often should we rehearse this?
Twice a year, twenty minutes, one scenario read aloud. The value is finding the questions nobody can answer, not the rehearsal itself.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
