Create an AI Incident Response Plan for a Small Business

An AI incident response plan gives a small business a calm, repeatable way to stop harm, establish what happened, decide who needs to act and restore normal work. The plan does not need enterprise software or a large committee. It needs clear triggers, named decision-makers, an evidence record and a short response sequence that people can follow under pressure.

This guide turns that idea into a practical six-stage playbook. It covers mistaken outputs, unintended data exposure, biased or unsafe decisions, broken automations, unauthorised AI use and supplier failures. It complements your wider small-business AI controls; it is not a substitute for legal, cyber-security, privacy or sector-specific advice.

What counts as an AI incident?

An AI incident is an event in which an AI-enabled task, tool or supplier causes harm, creates a credible risk of harm, or behaves outside the limits your business approved. The trigger is not simply “the output was imperfect”. It is that the failure may affect a person, a business decision, confidential information, a customer promise, a regulated process or the reliability of an operational system.

Examples include a customer email sent with invented facts, confidential material pasted into an unapproved tool, a support bot giving unsafe instructions, an automated workflow repeatedly rejecting valid requests, an AI-generated price applied without approval, or a supplier outage that leaves staff unable to complete a critical task. A near miss can also be worth recording when the same conditions could cause material harm next time.

Start by agreeing three useful severity levels:

• Level 1 — contained error: limited impact, no sensitive data involved and a straightforward correction is available. Record the event, fix it and check for repetition.
• Level 2 — material incident: customers, important decisions, confidential data, money or a public claim may be affected. Pause the workflow, appoint an incident lead and complete a documented assessment.
• Level 3 — urgent incident: there is credible risk to people, significant data exposure, fraud, unlawful discrimination, serious financial loss or a critical service. Contain immediately and bring in the appropriate technical, legal, privacy, insurance or sector specialist.

Tailor those descriptions to your business before an incident occurs. A low-value drafting error for one team could be a serious failure in healthcare, finance, employment, safety or legal work.

Build the plan around six response stages

The sequence is simple: detect, contain, preserve, assess, recover and learn. The stages can overlap. New evidence may move the incident up or down a level, and recovery should wait until the team has enough confidence that the cause is controlled.

1. Detect and declare the incident

Give staff an obvious way to raise a concern. That may be a dedicated email address, service desk form or named contact. The first report should capture what was observed, when it was noticed, which AI tool or workflow was involved and whether the output reached anyone outside the business.

The person receiving the report should assign an incident reference, make an initial severity call and name an incident lead. Do not require the reporter to prove the root cause before the response begins. Early reports will often be incomplete.

2. Contain without destroying evidence

Containment reduces the chance of further harm. It may mean pausing an automation, removing a public page, disabling an integration, reverting to a manual process, withdrawing a faulty recommendation or temporarily restricting access to an AI workspace.

Choose the smallest action that safely controls the risk. Turning off an entire service can create a second problem, while leaving a harmful workflow running can multiply the impact. Your plan should say who can pause a workflow and who can authorise a wider shutdown.

3. Preserve the record

Keep the information needed to reconstruct the event: prompts, outputs, source material, model or product name, version where available, timestamps, account and workspace details, workflow rules, approval records, affected files and relevant supplier messages. Record what is known, what is uncertain and who took each action.

Do not copy sensitive data into another AI tool simply to summarise the incident. Store evidence in an approved location with suitable access controls and retention rules. Your existing business data classification should guide what can be collected, where it can be stored and who can see it.

4. Assess impact and escalation

Work through four questions:

1. Who or what may be affected: customers, staff, suppliers, decisions, money, content, data or service availability?
2. What type of failure occurred: confidentiality, accuracy, bias, safety, access, availability, misuse or a supplier dependency?
3. How far did it travel: draft only, internal use, one recipient, a customer group, a public channel or another automated system?
4. What obligations might apply: customer commitments, contracts, insurance conditions, privacy reporting, employment duties or sector rules?

If personal data may be involved, assess the risk to people promptly and obtain qualified advice when needed. UK organisations should consult the Information Commissioner’s Office guidance on personal data breaches. The well-known 72-hour period is not permission to wait: where notification is required, the rule is to act without undue delay and, where feasible, within that period.

5. Correct, validate and recover

Recovery is more than switching the workflow back on. Correct affected records or content, contact people who need accurate information, remove unsafe access, test the changed process and confirm that the failure does not recur under the same conditions.

Use a person with enough subject knowledge and authority to approve restoration. This is where existing human approval checkpoints become valuable: the reviewer should see the source, the AI output, the identified failure, the correction and the evidence that the revised workflow stays within its approved boundary.

Keep a manual fallback for important work. If the supplier itself caused the failure or cannot provide adequate evidence, use the contingency and export steps in your AI vendor exit plan.

6. Close, learn and update controls

Close the incident only when the owner confirms containment, required communications, corrections, recovery testing and follow-up actions. Then hold a short review focused on the system, not blame.

Ask what allowed the failure, which signal first revealed it, what evidence was missing, whether roles were clear and which control would most reduce a repeat. Update the relevant policy, prompt, workflow, approval threshold, supplier requirement or training. Give each improvement an owner and due date.

The NIST Generative AI Profile specifically recommends defined incident responsibilities, documented third-party AI incidents, rehearsed response plans and after-action reviews. The UK National Cyber Security Centre’s incident-management guidance reinforces the value of escalation criteria, response records, containment, recovery and post-incident learning.

Assign a small response team before you need it

A small business may give several roles to the same person, but the responsibilities should still be explicit:

• Incident lead: owns the timeline, severity, actions and closure decision.
• Workflow owner: understands the task, data flow, integrations and intended operating limits.
• Impact reviewer: checks effects on customers, staff, decisions, content and money.
• Technical or supplier contact: preserves logs, changes access and obtains vendor evidence.
• Communications owner: coordinates accurate internal, customer or public messages.
• Specialist adviser: provides privacy, legal, cyber-security, insurance or sector advice when the trigger requires it.

Name a deputy for every critical role. Store contact details somewhere that remains available if your normal email, identity provider or AI supplier is unavailable.

Worked example: an AI summary sends the wrong commitment

Imagine a small consultancy uses AI to turn meeting notes into client follow-up emails. An account manager notices that one sent message promises a delivery date and a service that were not agreed.

The team declares a Level 2 incident because a customer-facing commitment may affect money and trust. The incident lead pauses the email automation but leaves the underlying CRM available. The workflow owner preserves the meeting notes, generated draft, prompt template, approval history and send log. A quick check finds three other messages created by the same template; two are accurate and one contains a softer but still unsupported commitment.

The account manager contacts the affected clients with a clear correction, while the workflow owner changes the template so proposed commitments are labelled and cannot be sent without explicit approval. A reviewer tests several representative meetings before the automation returns. The team records the cause: the prompt asked for “clear next steps” but did not distinguish agreed commitments from suggestions, and the approval screen hid the source notes.

The lasting fixes are not “tell staff to be more careful”. They are a source-visible approval screen, a specific rule for commitments, a test case for unsupported dates and a weekly sample review for the next month.

Use one copyable incident record

Keep the record factual and update it as evidence changes:

Incident reference:
Date and time detected:
Reporter and incident lead:
AI tool, model or workflow:
Approved purpose:
Observed event:
Initial severity and reason:
People, data, decisions or services potentially affected:
Containment action and time:
Evidence preserved and storage location:
Known facts:
Uncertainties:
Supplier, specialist or regulator contacts:
Corrections and communications:
Recovery tests and approver:
Root or contributing causes:
Follow-up actions, owners and due dates:
Closure decision and date:

The record should show how decisions were made, not merely the final outcome. If facts change, add an update rather than silently rewriting the timeline.

A bounded prompt for organising known facts

AI can help structure an incident record only after you remove or mask information the tool is not approved to receive. It should not decide severity, legal obligations or whether people must be notified.

You are organising an incident note, not making legal, privacy or safety decisions.
Use only the facts below. Separate confirmed facts, assumptions, missing evidence and proposed next questions.
Do not infer motives, root cause, liability or notification duties.
Return: timeline; affected people/processes/data; containment already taken; unresolved risks; evidence still needed; decisions requiring an authorised human.

Known facts:
[Insert approved, minimised facts]

A person remains responsible for checking the result against the source record. Do not let an AI-generated summary replace the original evidence.

Rehearse the plan with a short scenario

Run a 30-minute tabletop exercise every six months and after a major workflow or supplier change. Choose one credible scenario, give the team incomplete information in stages and observe how they respond. Useful tests include an inaccurate customer message, unintended sensitive-data sharing, a biased recommendation, a compromised AI account or a supplier outage.

Check whether people can find the plan, pause the workflow, reach the right contacts, preserve evidence and choose a manual fallback. Record the time taken and the points of confusion. The purpose is not to award a score; it is to reveal weak instructions before a real incident.

Track a few operational measures without inventing certainty: time to declare, time to contain, affected items found, corrective actions completed and repeat incidents. The same evidence-first discipline used to measure AI-assisted work without inventing ROI applies here.

Common mistakes to avoid

Treating every weak output as a crisis. A severity model prevents routine corrections from overwhelming the response process.

Waiting for certainty before containing. You can pause a risky workflow while the team continues to investigate.

Deleting the evidence. Removing harmful public content may be necessary, but preserve the source, output, timestamps and actions in an approved location first when it is safe and lawful to do so.

Using the same AI tool to investigate its own failure. The tool may help organise approved facts, but independent evidence and human judgement must drive the assessment.

Reopening without a test. Correcting one output does not prove the workflow is safe. Test the changed control with representative cases and record who approved recovery.

Closing without follow-up owners. A lesson without an owner and due date rarely changes the system.

Reader Q&A

Does every inaccurate AI output count as an incident?

No. Routine errors can follow normal review and correction. Treat the event as an incident when it causes harm, creates a credible risk of harm, crosses an approved boundary or reveals a repeatable control failure.

Who should lead an AI incident in a small business?

Name one incident lead with authority to coordinate containment, evidence, decisions and closure. That person can involve the workflow owner and qualified technical, privacy, legal or sector specialists as the facts require.

Should we report an AI incident to the tool provider?

Report relevant product or security failures through the provider's official channel when doing so will support containment, evidence or remediation. Preserve your own record first and do not send the provider data it is not authorised to receive.

Can AI help investigate an AI incident?

It can organise approved, minimised facts or suggest questions, but it should not replace original evidence, independent checks or authorised human decisions. Never paste sensitive incident material into an unapproved tool.

How often should we test the response plan?

Run a short exercise at least every six months and after a major workflow, supplier, data-use or responsibility change. Test again when a real incident exposes a gap.

When is an AI incident closed?

Close it only after containment, required corrections and communications, recovery testing and follow-up actions are recorded. The incident lead should document the closure decision, remaining risks, owners and due dates.

Make the first hour easier

A useful incident plan reduces improvisation. Put the reporting route, severity triggers, decision authority, contact list, evidence record and manual fallback in one accessible place. Then rehearse a realistic scenario and fix what slows the team down.

After recovery, link the closure and any changed operating conditions to the relevant AI decision-log entry. That preserves why the workflow restarted, changed or remained paused without turning the incident record into a general governance file.

You cannot predict every AI failure. You can make sure the next one meets a team that knows how to contain it, establish the facts, protect affected people and improve the system before work resumes.

Garry Knight

I'm Garry Knight, the person behind Prodify Digital. I write about email list building, email marketing, SEO, AI search and the tools that connect them. My aim is to make online marketing easier to understand, so creators and small business owners can make informed decisions about building an audience and keeping people engaged. Here you'll find straightforward guides and product reviews that explain what something does, where it fits and which limitations matter. The focus is on clear explanations and useful next steps—not hype, shortcuts or promises of easy earnings.

See Full Bio