AI incident response plan for small firms

An AI incident response plan gives a small business a calm, repeatable way to deal with an AI tool or agent that behaves unexpectedly. It tells your team when to stop a workflow, what evidence to preserve, who must be involved and what needs to be true before the system can return to work.

The plan does not need its own control room. It can be a short playbook connected to your existing cyber-security, data protection and business continuity procedures. The important part is that people can use it under pressure, without relying on the person who originally built the workflow.

This guide sets out a practical structure for AI-enabled marketing and business workflows. It is general operational guidance, not legal, data protection or cyber-security advice for a particular incident.

Decide what counts as an AI incident

Not every weak draft is an incident. A reviewer correcting an awkward sentence before publication is normal quality control. An incident begins when behaviour, access or impact moves outside the limits you agreed for the system.

Examples include:

an agent sends, publishes or changes something without the required approval;
confidential or personal information appears in an input, output or log where it should not;
the workflow follows an instruction hidden in an email, webpage or file;
outputs become materially inaccurate, biased or inconsistent with the acceptance test;
the agent tries to use an unapproved tool, account, folder or action;
a supplier, model or integration change causes unexpected behaviour;
repeated failures create a customer, financial, operational or reputational risk;
the system cannot be stopped, traced or restored as the runbook says it can.

Set these boundaries before launch. The UK Government’s AI Risk Management Toolkit recommends incident procedures for AI systems that perform beyond acceptable limits, supported by monitoring and alerts for anomalies.

Your AI agent runbook should describe the normal operating range for one workflow. The incident plan takes over when that range is breached.

Use three response levels

A simple severity model helps staff escalate consistently. Adapt the examples to the job and the potential effect on people.

Level 1: contained quality issue

The problem is confined to a draft or test environment. Nothing has been sent, published or changed outside the controlled workspace, and no restricted data or unauthorised access is involved.

Pause the affected run, record the example, correct the cause and retest before continuing. Repeated Level 1 events may indicate a larger problem and should trigger a review.

Level 2: material operational incident

The workflow has taken or attempted an unapproved action, produced repeated material errors, disrupted an important process or affected internal records. The impact remains limited, but the business owner or technical support needs to investigate.

Stop the workflow, preserve evidence, restrict its access if necessary, switch to the manual fallback and notify the named response contacts.

Level 3: external, security or data incident

The event may affect customers, staff or other people; expose personal or confidential information; create financial loss; involve account compromise; or cause uncontrolled external actions.

Treat this as urgent. Halt the system, involve the people responsible for security and data protection, assess notification duties and use specialist advice where appropriate. Do not wait for a complete technical explanation before containing the risk.

Avoid tying severity only to the sophistication of the failure. A simple automated message sent to the wrong audience may matter more than a complex error that stayed in a test folder.

Write the first 15-minute checklist

Put the immediate actions at the top of the plan. The responder should be able to follow them without searching through technical documentation.

Stop the activity. Pause the schedule, trigger or agent process. If activity may continue through another connection, restrict the service identity, token, network route or integration.
Protect people and live systems. Block further sends, publications, record changes, purchases or other consequential actions. Use the safest reversible control available.
Preserve evidence. Keep relevant prompts, inputs, outputs, tool calls, approvals, timestamps, logs, configuration versions and supplier notices. Do not delete a suspicious run just to tidy the workspace.
Open an incident record. Note who discovered it, when the business became aware, what was observed and which immediate actions were taken.
Name a coordinator. One person keeps the timeline, assigns actions and makes sure the right specialists and decision-makers are involved.
Use the fallback. Move essential work to the documented manual process while the AI workflow remains paused.

The National Cyber Security Centre’s guidance on agentic AI risk says organisations should be able to halt autonomous activity immediately. It also stresses the value of protected logs for real-time oversight and later investigation.

Test the stop control. A button labelled “pause” is not enough if queued jobs, connected agents or external actions continue afterwards.

Give people clear roles

Small teams do not need a large incident committee, but every decision still needs an owner. Assign roles rather than assuming “someone technical” will deal with it.

Reporter: raises the alert and records what they saw without trying to hide or fix the evidence.
Incident coordinator: owns the timeline, actions, status and hand-offs.
Business owner: assesses operational and customer impact and decides whether the workflow remains paused.
Technical owner or supplier contact: isolates the system, protects evidence and investigates configuration, access and integrations.
Data protection or legal contact: advises where personal data, contractual duties, regulated activity or notification requirements may be involved.
Communications owner: coordinates accurate messages to affected people, staff, suppliers or other parties when needed.
Restart approver: signs off the recovery criteria. This should not be the system acting on its own recommendation.

One person may fill several roles in a microbusiness. Write their name, deputy and contact route into the plan. Also record the supplier’s support and security-reporting routes before an incident occurs.

Your AI policy for small businesses should give staff one obvious reporting route. The incident plan explains what happens after they use it.

Keep one useful incident record

The record should separate facts from assumptions. Capture:

incident ID, date, time and current severity;
person who reported it and incident coordinator;
affected workflow, account, supplier and version;
what was expected and what actually happened;
known inputs, outputs, tool calls and external actions;
data, customers, records or systems potentially affected;
containment steps and the exact time each was completed;
preserved evidence and where authorised responders can find it;
decisions, owners, deadlines and communication status;
current hypothesis, clearly labelled as unconfirmed;
recovery tests, restart decision and follow-up actions.

Do not store passwords, secret keys or copied personal information in the incident log. Link to protected evidence instead and limit access to the people handling the event.

If personal data may be involved, start the data-breach assessment promptly. The Information Commissioner’s Office small-organisation breach guide advises starting a log, establishing what happened, containing the breach and assessing risk to people. Where a breach meets the reporting threshold, the deadline is within 72 hours of awareness, even if every fact is not yet known. Use current ICO guidance or appropriate advice for the actual case.

Investigate the whole workflow, not just the final answer

An AI incident may come from several layers. Work through them methodically:

Trigger: Was the workflow started by the expected event, user or schedule?
Input: Was the source complete, current and trusted? Could it contain a hidden or malicious instruction?
Instructions: Did the approved prompt, policy or workflow configuration change?
Model or supplier: Was there a model, feature, safety-setting, availability or terms change?
Tools and permissions: Which accounts, folders, APIs and actions were available? Were they broader than the job required?
Human control: Did the approval gate run, and did the reviewer receive the evidence needed to decide?
Output and action: What was generated, changed, sent or published, and can it be corrected or reversed?
Monitoring: Which signal detected the incident? If a person spotted it first, what alert or acceptance check was missing?

Compare the incident with a known-good run and the version recorded in your AI tool register. Do not assume the model alone caused the problem. An expired data export, changed permission, broken template or unclear approval step can create the same visible symptom.

The UK Government’s AI Cyber Security Code of Practice recommends creating, maintaining and testing an AI-specific incident management plan and recovery plan. Use that principle proportionately, even when the system is assembled from third-party services rather than developed in-house.

Set a recovery gate before restart

“The output looks normal again” is not a safe restart test. Define the recovery evidence in advance.

Before restoring live activity, confirm that:

the affected workflow, connections and queued actions are under control;
the likely cause is understood well enough to prevent the same immediate failure;
configuration, instructions, data and permissions match an approved version;
affected outputs, records and external actions have been identified and addressed;
required internal, customer, supplier or regulatory decisions are recorded;
representative normal, edge and failure cases pass in a controlled environment;
the stop control, approval gate and manual fallback work;
monitoring is active with a named person watching the initial live runs;
the business owner and restart approver have signed off.

Use a staged return where possible. Start with a test workspace or read-only mode, then a small supervised batch, then normal volume. Keep higher-impact actions behind human approval until the team has evidence that the control is working.

If the incident exposed a design problem rather than a one-off fault, the right answer may be to narrow the job, remove a connection or retire the workflow. Recovery does not have to mean returning to the previous level of autonomy.

Run a 30-minute tabletop exercise

A plan is useful only if the people named in it can use it. Test one realistic scenario every few months and after major changes.

For example:

A marketing agent reads a supplier email containing a hidden instruction, then attempts to upload a customer export to an unapproved service. The connection blocks the upload, but the alert arrives outside normal working hours.

Ask the team to work through these questions:

Who receives the alert and how quickly?
How do they stop every related process?
Which credentials or connections must be restricted?
Where are the logs, versions and approval records?
Who assesses possible personal-data and customer impact?
What business work moves to the manual fallback?
Who can authorise communications and restart?
Which missing information or access slowed the response?

Record the gaps and assign a date and owner for each fix. A short exercise that reveals an outdated phone number, inaccessible log or ineffective pause control has already improved the plan.

AI incident response plan template

Keep the working document short and link to detail in the runbook, tool register and existing response policies.

Purpose and workflows covered
Incident examples and three severity levels
First 15-minute stop, contain and preserve checklist
Response roles, deputies and contact routes
Supplier, security, data protection and specialist contacts
Incident record fields and protected evidence location
Investigation checklist for triggers, data, instructions, tools and approvals
Customer, staff, supplier and regulatory decision routes
Manual fallback and business continuity steps
Recovery tests, staged restart and approval gate
Post-incident review, owners and deadlines
Exercise schedule and last-tested date

Connect the template to the real system. An AI agent system build should leave your team able to find the controls, operate the fallback and make the restart decision in its own accounts.

Frequently asked questions

Does every AI error need the incident plan?

No. A low-quality draft caught by the normal review process is usually a quality issue. Use the incident plan when behaviour, access or impact moves outside agreed limits, such as an unauthorised action, data exposure, repeated material failure or inability to stop and trace the workflow. Define the boundary for each use case in advance.

Should an AI incident plan replace our cyber incident plan?

Usually not. Add AI-specific triggers, evidence, stop controls, suppliers and recovery tests to the response processes you already use. An event involving account compromise or personal data should follow the relevant security and data-protection procedures as well as the AI workflow plan.

Who should be allowed to restart an AI agent?

A named human owner should approve restart using documented recovery evidence. For higher-impact workflows, separate the person who implements the fix from the person who accepts the business risk. The system should not approve its own return to live operation.

How often should we test the plan?

Test it before a consequential workflow goes live, after material changes and on a regular schedule suited to the risk. A quarterly tabletop exercise is a practical starting point for many small teams. Also test after a real incident or near miss, because those events reveal the most useful gaps.

Need an AI workflow your team can monitor, stop and recover? Talk to us about ongoing AI marketing support for practical operating controls, review and improvement.

Sources checked on 4 October 2026: UK Government AI Risk Management Toolkit, NCSC guidance on managing agentic AI risk, UK Government AI Cyber Security Code of Practice and ICO guidance for small organisations responding to personal data breaches. This is practical business guidance, not legal, data protection or cyber-security advice.