What should an AI incident plan look like for a small business?

4 October 2026

What counts as an AI incident?

An AI incident is any event in which an AI tool, its data, its connection to another system or the way a person uses it creates material risk. Do not limit the definition to hacking. A member of staff pasting a client contract into an unapproved chatbot can be an incident. So can an assistant sending an invented refund promise to a customer, an agent deleting records, a supplier exposing conversation history, or a model change causing a reliable workflow to produce unsafe answers.

Use five practical trigger categories: confidentiality, integrity, availability, safety and compliance. Confidentiality covers data disclosed to the wrong person or supplier. Integrity covers false, altered or fabricated output entering a business record. Availability covers an AI service or integration failing when the business depends on it. Safety covers output that could harm a person, customer or employee. Compliance covers uses that breach your policy, a contract, professional rules or data protection law.

Give staff examples that match their work. A marketing draft with an awkward sentence is usually a quality issue, not an incident. A fabricated product claim published to customers is an incident. A chatbot suggesting a reply that a person catches is a near miss worth logging. The same reply sent automatically to 2,000 customers is a serious incident. Your plan should make that distinction clear so staff report real risks without treating every imperfect sentence as an emergency.

Who should take charge, and what should they decide?

Name one incident lead and one deputy. In a small business, the lead may be the owner, operations director or data protection contact. The technical investigation can be handled by an IT provider, but the business still needs one person who owns decisions, keeps the timeline and prevents conflicting instructions. List mobile numbers and an alternative communication channel in case email or Microsoft 365 is affected.

Assign five responsibilities even if one person holds several of them: incident command, technical containment, data protection assessment, customer and staff communication, and business recovery. Record who can suspend an AI automation, revoke a supplier token, disconnect an integration, approve a customer message and authorise a return to service. Also write down the point at which a decision must move to a director. The National Cyber Security Centre guidance for small businesses specifically recommends assigned roles, shared responsibility, current contact details and documented trigger points for senior involvement.

Do not make the AI vendor your incident lead. Its support team may know its platform, but it cannot judge your customer harm, contractual duties or acceptable downtime. Keep your account identifier, support route, contract, data processing terms and emergency contact beside the plan. If a consultant manages the system, state what they must do, how quickly they must respond and who in your business can instruct them.

What should happen in the first hour?

The first objective is not to prove exactly what happened. It is to stop further harm while preserving evidence. The person discovering the problem should note the time, affected tool, account, customer or workflow, then alert the incident lead through the agreed route. The lead should assign a severity level and open a single incident log. Screenshots, prompts, outputs, user IDs, audit logs and supplier notifications should be preserved before anyone clears histories or rebuilds the workflow.

Containment should be specific to the risk. Pause the automation or scheduled job. Remove the tool's access to the CRM, mailbox or shared drive. Revoke exposed API keys and active sessions. Switch customer interactions to human review. Block a compromised account. Preserve the original output and configuration. Do not delete evidence, publicly blame an employee, or make confident claims about the cause before the facts are known.

Use three severity levels. Level 1 is a contained near miss or low impact error with no sensitive data or external harm. Level 2 affects customers, important records or business operations but is limited and controllable. Level 3 involves sensitive personal data, widespread harmful output, fraud, safety risk, major outage or loss of control over a connected system. Level 3 should trigger immediate director involvement and specialist advice. Set a 15 minute target for acknowledging reports and a one hour target for an initial containment decision. These are internal operating targets, not legal deadlines, but they stop a small warning sitting unread all morning.

When do the ICO, customers or other organisations need to know?

If personal data may have been lost, disclosed, altered, made unavailable or accessed without authority, start a data breach assessment immediately. The Information Commissioner's Office guidance says a reportable personal data breach must be notified without undue delay and within 72 hours of becoming aware of it. The clock starts when you discover the breach, not when it originally occurred. You can report early and provide more information later. Not every AI mistake is reportable, but every suspected personal data breach should be assessed and recorded.

Your log should state what happened, the systems and data involved, how many people may be affected, likely consequences, containment actions and the reason for reporting or not reporting. Where there is a high risk to individuals, they may also need to be told without undue delay in clear language, with practical steps they can take. Obtain professional advice if the risk is unclear. Other reporting routes may include Action Fraud, the NCSC, your insurer, a sector regulator, a contractual client contact or the police, depending on the event.

Communicate facts, not speculation. Tell customers what happened, what information or service is affected, what you have done and what they should do. Give a named contact and a time for the next update. Do not hide the use of AI if it is material to the incident. Equally, do not label an ordinary supplier outage as a data breach without evidence. Accuracy and useful action matter more than a polished apology.

How detailed should the plan be, and what will it cost?

For most businesses with fewer than 50 staff, the usable plan is two to four pages plus a contact list and incident log template. It should contain scope, trigger examples, severity levels, named roles, immediate actions, notification routes, recovery checks and a review date. Keep a protected digital copy and an offline copy. If the only copy is in the system that fails, it is not an incident plan.

A competent owner or operations manager can prepare the first version in half a day using free NCSC and ICO guidance. A facilitated workshop with your IT provider, data protection adviser and process owners may take two to four hours. External review for a straightforward small business commonly costs hundreds rather than thousands of pounds, although regulated operations, complex integrations or extensive personal data may justify deeper legal and security work. The bigger cost is usually staff time spent identifying tools, permissions, suppliers and critical workflows.

The need is not theoretical. The UK government's Cyber Security Breaches Survey 2025/2026 found that 43% of businesses had identified a cyber breach or attack in the previous 12 months, yet only 25% had a formal incident response plan. Among businesses using, adopting or considering AI, just 24% had cyber security practices or processes to manage AI risk. Those figures cover cyber risk more broadly, but they show why a short working plan is more valuable than assuming the supplier will handle everything.

How should you test, recover and learn from the plan?

Test the plan twice a year and whenever a high impact AI workflow is introduced. A useful tabletop exercise takes 60 to 90 minutes. Give the team a plausible scenario, such as a sales assistant exposing customer notes through an incorrect sharing setting, then ask what they would do at five minutes, one hour, four hours and the next day. The NCSC's free Exercise in a Box can help organisations practise cyber response without needing an internal security specialist.

Recovery is more than switching the automation back on. Confirm that credentials have been replaced, permissions are least privilege, affected records are corrected, human review is operating and monitoring can detect a repeat. Test the workflow with safe sample data. A manager should approve the return to service and record why it is safe. For a model output failure, test known difficult cases rather than only the example that triggered the incident. For a supplier failure, check whether its status update, root cause and corrective actions answer your questions.

Within five working days, hold a blameless review. Identify the technical cause, process weakness and management decision that allowed the event to progress. Decide which control, training, permission or approval step will change, give it an owner and set a deadline. Update the AI register and risk assessment. Track near misses as well as serious events because repeated small errors often reveal a weak workflow before customers are harmed. The purpose is not to produce paperwork. It is to make the next incident less likely, easier to spot and faster to contain.

When this does not need to become a separate project

Do not buy an expensive AI governance platform simply to create an incident plan for a five person business using one approved chatbot with no system integrations. Add a clear AI section to your existing data breach and cyber response documents, maintain an AI tool register, and rehearse one realistic scenario. A spreadsheet log and a protected contact sheet can be sufficient when ownership is clear and the process is tested.

A separate, more detailed plan becomes sensible when AI can act without approval, access several business systems, influence regulated advice, process special category data, communicate directly with customers at scale or affect safety. It is also justified when several suppliers share responsibility and nobody has mapped the boundaries. Complexity should follow risk, not fashion.

Do not delay all AI use until every possible scenario has a scripted answer. The NCSC advises planning for the most likely incidents rather than attempting detailed instructions for every event. Start with data exposure, harmful output, unauthorised access, supplier outage and uncontrolled automated action. Name the people, rehearse the choices, then improve the plan using what the exercise reveals.

Is This Right For You?

This plan is right for you if staff use ChatGPT, Copilot, Gemini or another AI service for real work, if an automation can update business systems, or if an AI tool can see customer, employee or commercially sensitive information. It is also appropriate if you rely on a managed provider. Outsourcing the technology does not outsource your responsibility to customers or staff.

You do not need a separate 40 page AI manual if your existing cyber incident and data breach plans are current and tested. Add AI specific triggers, supplier contacts and containment steps to those documents. If nobody can find or use the existing plan, however, treat that as no plan at all.

This does not replace legal, data protection or cyber security advice for a live serious incident. If you want to test whether your plan works, run a 60 minute tabletop exercise with the people named in it. If you would value an independent review, book a conversation with Precise Impact AI. No pitch, no pressure, just a practical look at the gaps.

Frequently Asked Questions

Does every AI error count as an incident?

No. A harmless draft error caught during normal review is a quality issue. Treat it as an incident when it creates material risk to data, customers, decisions, compliance, safety or operations. Log repeated near misses because they can reveal a failing control.

Who should own an AI incident in a small business?

A named senior person in the business should own the incident, with a deputy. An IT provider or AI consultant can investigate and contain the technical problem, but the business owner must control customer, legal, operational and recovery decisions.

Do we have to report an AI incident to the ICO?

Only if it involves a personal data breach that meets the reporting threshold. Assess every suspected breach and document the decision. Where reporting is required, notify the ICO without undue delay and within 72 hours of becoming aware of it.

Should we turn off every AI tool during an incident?

Usually not. Isolate the affected account, workflow, integration or data source first. A wider shutdown may be justified if you cannot identify the boundary, credentials are compromised or the tool can continue causing serious harm.

How often should we test the plan?

Test it at least twice a year, after a serious incident and before launching a high impact AI workflow. A 60 to 90 minute tabletop exercise is enough to expose missing contacts, unclear authority and weak containment steps.

What evidence should we preserve?

Keep prompts, outputs, timestamps, screenshots, audit logs, account IDs, permissions, model and workflow versions, supplier messages and every containment decision. Preserve originals before changing settings or deleting conversation history.

Can our existing cyber incident plan cover AI?

Yes, and that is often the best approach. Add AI specific triggers, connected system details, supplier contacts, evidence sources and containment steps. Make sure the plan covers harmful output and unauthorised automated actions, not only cyber attacks.