AI Incident Response Runbooks Are Now A Practical Requirement For UK Businesses

Tools & Technical Tutorials

24 August 2026 | By Ashley Marshall

Most AI risk plans still describe what should not happen. The useful question is what your team will do in the first 30 minutes when it does.

Why the first 30 minutes now matter

The first mistake many businesses make with AI incident response is treating it as a branding exercise for the existing cyber incident plan. That sounds efficient, but it misses the operational difference. A conventional cyber plan usually starts with compromised accounts, malware, data exfiltration or service disruption. An AI incident can start with a customer-support assistant following a malicious instruction hidden in a web page, a coding agent modifying the wrong repository, a workflow agent sending data to the wrong system, or a retrieval assistant exposing a document it was never meant to retrieve.

The NCSC's August 2026 guidance on agentic AI is clear that organisations should think about how autonomous systems behave when they do not function as expected, then deploy them with safeguards, sandboxing, observability and active oversight. It also says all deployments should have operational monitoring and response procedures, which is the point many pilots still skip. If an AI agent can take action, access tools or influence customer-facing work, the incident plan has to describe what gets stopped, who has authority to stop it, what evidence is preserved and which systems are checked next.

What this means in practice is simple: the runbook should begin with a 30-minute containment checklist. Disable the agent or route it to read-only mode. Revoke or narrow tool tokens. Preserve prompts, tool calls, retrieved sources, model responses, logs and human approvals. Check for abnormal API usage, unexpected data transfers and unusual login patterns. Name the decision owner who can choose between temporary shutdown, degraded service and monitored continuation. That owner cannot be a generic inbox. It needs to be a role with real authority.

The counterargument is that this sounds too heavy for an internal assistant. It is not. A light runbook can be one page for a low-risk summarisation tool. The point is proportionality, not paperwork. The higher the autonomy, data sensitivity and customer impact, the more detailed the runbook needs to be.

Use UK guidance as the structure, not as decoration

The strongest starting point is to map your runbook to the language regulators and security bodies already use. The UK government's AI Cyber Security Code of Practice says AI systems should be designed to withstand adversarial attacks, unexpected inputs and system failure. It also says developers should create an audit trail covering the operation and lifecycle management of models, datasets and prompts, and that system operators should log system and user actions to support compliance, incident investigations and remediation. Those are not abstract principles. They translate directly into runbook sections.

A useful AI incident runbook should therefore include five evidence lines: what model or service was used, what prompt or instruction was active, what data sources were available, what tools or permissions were enabled, and what outputs or actions occurred. Without those details, the post-incident review becomes guesswork. You may know something went wrong, but not whether the root cause was a bad instruction, poisoned retrieval content, a weak permission boundary, a model change, a missing approval gate or ordinary user error.

The ICO's May 2026 advice on AI-powered cyber threats reinforces the same operational message. It tells organisations to monitor for unusual login patterns, unexpected data transfers and abnormal API usage, and to maintain and regularly test an incident response plan with clear staff roles and reporting contacts. For any system touching personal data, the runbook also needs a data protection lane: identify whether personal data was exposed, whether the incident is likely to create risk for people, who assesses UK GDPR notification duties, and what evidence supports that decision.

This is where many businesses overcomplicate the work. They try to create an AI governance document, a cyber policy and a data protection policy as separate artefacts. A better runbook joins them at the point of action. When the alert fires, the team should not have to search three policy folders before deciding whether to contain, investigate or notify.

Build scenarios around AI failure modes

A generic severity matrix will not cover AI incidents properly unless the scenarios reflect how AI systems fail. The ICO lists indirect prompt injection, data poisoning, AI-enhanced phishing, deepfake social engineering, automated vulnerability scanning, AI-powered malware and credential attacks as practical threat categories. The NCSC adds a sharper point for agentic AI: an agent may interpret goals literally or unexpectedly, and prompting alone is not enough. Runbooks should turn those risks into rehearsable scenarios.

For a retrieval assistant, one scenario should cover sensitive source leakage. The trigger could be a user receiving an answer based on a confidential HR, finance or legal document. The runbook then asks: was the document incorrectly indexed, was access control ignored, did the prompt encourage over-disclosure, or did the user have legitimate access but the answer combined information in a risky way? The containment action might be disabling the affected index, narrowing retrieval scope, rotating document embeddings, preserving the conversation trace and testing whether other users can reproduce the exposure.

For an agent connected to tools, the scenario should cover unintended action. That might mean creating tickets, sending emails, changing records, writing code or calling APIs outside the intended task. The runbook needs a tool-by-tool rollback map. Which actions are reversible? Which require supplier support? Which create customer notification duties? Which logs are authoritative when the AI application, SaaS platform and identity provider disagree?

For staff-facing AI, add a social engineering scenario. Deepfake voice or AI-generated messages can persuade employees to reset credentials, approve payments or grant system access. The response is not only technical. It includes finance, HR, legal, comms and the line manager of the affected team. The runbook should define the human verification route before the incident, because during a convincing impersonation incident people will hesitate.

What this means in practice is that every deployed AI workflow should have at least three named incident scenarios attached to it. They do not need to be dramatic. They need to be specific enough that someone can rehearse them.

Make observability useful to humans

AI observability is often sold as dashboards, but incident response needs a narrower question: can a human reconstruct what happened quickly enough to contain it? The NCSC recommends logging, auditing and monitoring agentic AI activity as part of security operations, making AI activity easy to attribute, and maintaining the ability to pull the plug. That requires more than a transcript viewer. It requires correlated evidence across identity, application, model, retrieval, tool execution and network activity.

At minimum, the runbook should say where to find the AI conversation record, system prompt version, model version, retrieval sources, tool-call log, API usage, user identity, approval history and downstream system changes. If the agent can interact with Salesforce, Microsoft 365, Google Workspace, GitHub, Xero, Slack, a CRM or an internal database, the runbook should link each system to its relevant audit log and retention window. It should also state who has access to those logs at 2am, because an elegant monitoring architecture is useless if only one engineer can open it.

The government's Cyber Security Breaches Survey 2025/2026 shows why this matters. Just over four in ten UK businesses reported a cyber breach or attack in the previous 12 months, with medium and large businesses at 65% and 69% respectively. Yet only around a third of businesses had written guidance on who to notify after an incident, and only 30% used user monitoring as a cyber hygiene control. AI systems increase the need for monitoring while many organisations still lack the basic operational muscle.

A practical runbook should therefore include alert thresholds that non-specialists understand. Examples include an unusual spike in model spend, a high number of failed tool calls, retrieval from restricted folders, repeated policy refusals, outbound traffic to a new domain, or an agent continuing after a stop condition. The aim is not perfect detection. It is enough signal to let people intervene before a small failure becomes a customer, compliance or availability problem.

Decide escalation before the incident

Escalation is where AI incident response often becomes politically awkward. Is a hallucinated answer a content issue, a product issue, a security incident or a data protection incident? Is an AI agent sending the wrong email a service error, a breach, a conduct issue or a supplier problem? If the runbook does not define escalation paths in advance, the first hour becomes a meeting about ownership instead of containment.

The runbook should separate severity from embarrassment. A public mistake may look serious but have little legal or operational impact. A quiet internal retrieval leak may look small but involve special category data, commercial confidentiality or regulated decisions. Severity should be based on data sensitivity, system criticality, external exposure, reversibility, customer impact, regulatory duties and whether the behaviour is still ongoing. That lets the team respond proportionately without either over-reporting every odd answer or under-reacting to a real breach.

For UK businesses, the data protection route needs special clarity. If personal data is involved, the runbook should name the person or team who decides whether the incident is notifiable to the ICO and whether affected people must be told. It should also capture the evidence needed for that decision: categories of data, number of people affected, likely harm, containment steps, time discovered, time contained and whether the data was encrypted, pseudonymised or otherwise protected. The ICO's advice to maintain offline copies of critical documentation is worth following here. If the AI incident also affects identity, email or document systems, the response documents may be hard to reach.

One common misconception is that supplier-hosted AI makes this the vendor's problem. It does not. The supplier may operate the model or platform, but the customer still owns many of the business decisions: what data was connected, what permissions were granted, what customers were affected and what workarounds are acceptable. The runbook should include vendor support routes and contractual evidence requirements, but it should not wait for the vendor to decide your risk tolerance.

Rehearse recovery, not just containment

The final section of the runbook should describe how the business returns to service. This is usually more important than the dramatic shutdown moment. Recovery for an AI workflow means deciding whether the model, prompt, retrieval index, tool permissions, approval gates, vendor version or user training needs to change before the system is restored. If you simply turn the assistant back on after a concerning incident, you have learned almost nothing.

Good recovery starts with a written decision record. What happened? What was the most likely root cause? Which controls worked? Which failed? What evidence is missing? What changed before restart? Who approved the restart? For agentic systems, recovery should also include a replay test using the incident prompt, retrieved content or tool sequence where legally and ethically appropriate. The aim is to prove that the same path is blocked, not just to reassure everyone that the team has had a conversation.

The NCSC's Five Eyes statement in June 2026 told leaders to test response plans, train and prepare teams, assume breaches will occur, and focus on fast containment and recovery. That is the right frame for AI. The strongest organisations will not be the ones that pretend their assistants and agents never fail. They will be the ones that can pause them quickly, explain what happened, fix the control, and restart with evidence.

A small business does not need a security operations centre to begin. It needs a simple table for each AI workflow: owner, data touched, tools connected, stop action, log location, supplier contact, data protection contact, customer comms owner and restart criteria. For higher-risk systems, expand that into exercises, alerting, test packs and board reporting. The goal is not to slow adoption. It is to make adoption survivable when real systems, real customers and real data are involved.

Frequently Asked Questions

Do small businesses really need an AI incident response runbook?

Yes, if AI tools touch business data, customer communication or connected systems. A small-business version can be one or two pages covering the owner, stop action, logs, supplier contact, data protection contact and restart criteria.

How is an AI incident different from a normal cyber incident?

AI incidents can involve prompt injection, unintended agent actions, data leakage through retrieval, model behaviour changes or tool misuse without a traditional malware or account compromise event. The evidence and containment steps are therefore different.

What should be captured during an AI incident?

Capture the prompt, model and system prompt versions, retrieved sources, user identity, tool calls, approval records, API usage, downstream system changes and any personal data involved. Preserve this before changing configuration.

Who should own the runbook?

Ownership should sit with the business owner of the AI workflow, supported by security, IT, legal and data protection. The person with authority to pause the workflow must be named clearly.

Does a vendor-hosted AI platform remove our responsibility?

No. The vendor may operate the platform, but your organisation still controls the data connected, permissions granted, customer impact, internal escalation and decisions about shutdown or restart.

How often should AI incident response be tested?

Test high-risk AI workflows before launch and after major changes to model, prompt, retrieval, tool access or vendor configuration. Lower-risk workflows should still be rehearsed periodically as part of wider cyber exercises.

What is the most important control for agentic AI incidents?

The most important control is a reliable stop mechanism backed by logging. If you cannot pause the agent and reconstruct what it did, you cannot contain or explain the incident properly.

When does an AI incident become a data protection issue?

It becomes a data protection issue when personal data is exposed, altered, lost, accessed without authorisation or otherwise processed in a way that creates risk to people. The runbook should route that assessment to the right data protection owner immediately.