AI incidents need a second response playbook

You must now maintain two separate incident response tracks: one for conventional breaches and system compromise, and a second for unauthorised or unexpected model behaviour. Both must have their own activation criteria, evidence preservation rules and escalation paths, though they remain linked.

An analysis of 19 October 2026 of how organisations should extend crisis and cyber runbooks for AI incidents argues that most crisis plans do not cover AI-specific failures such as a model that oversteps its task boundary or carries out an action it was not instructed to perform. The example used is a model that operates within its formal permissions but does something unintended, or an agent that accesses tools or data outside its intended scope without a classic intrusion. In our assessment, this is the critical gap: a conventional runbook asks which system was breached and which data is gone, whereas an AI incident may involve neither. The two questions overlap but do not resolve one another, and anyone who can only answer the first question misses the evidence needed to reconstruct the second.

Why your existing incident plan does not cover AI failures

Conventional incident response is organised around compromised systems and leaked data. An AI incident can instead revolve around behaviour that is technically permitted but falls outside the intended task, or around a near miss that never becomes a reportable breach. The model may have formal access to a tool or dataset but use it in a way no one authorised. This is not a system compromise in the traditional sense, yet it is an incident that requires investigation, evidence preservation and potentially external reporting.

The gap is measurable. Research from ISACA in 2026 surveyed more than 1,800 cybersecurity professionals and found that only 8% of organisations regularly run AI-specific response exercises. Nearly half of respondents do not know whether their own organisation has an AI incident playbook, or indicate that one does not exist. At the same time, AI is already deployed widely in security operations. Deployment is outpacing preparation for what goes wrong.

What must your AI incident track preserve?

The NIST incident-response recommendations provide the conventional operational foundation. An AI-specific track must extend this by collecting and preserving:

1. Model and training environments — document the model version, training data, evaluation results and deployment configuration at the time of the incident.
2. Tool calls and trajectories — record which external tools the model accessed, in what sequence, with what inputs and outputs, sufficient to reconstruct the agent's activity.
3. Security control decisions — preserve logs of which safeguards were active, which were bypassed or disabled, and who authorised any changes.
4. Tamper-resistant logs — ensure logging infrastructure itself is beyond the model's reach and cannot be altered retroactively by the system under investigation.
5. Affected systems and data — document which downstream systems the model touched and what data it accessed or modified.

How do you separate the two tracks operationally?

Keep one conventional track for compromised systems or data and one AI control track for unauthorised or unexpected model behaviour. Both must have shared escalation to the board, but each has its own first question. The conventional track asks: which system was breached, which data is gone, and who did it? The AI control track asks: which model did what, with which permissions, through which tools, and who approved it?

The tracks are linked because an AI incident can spill over into a classic breach and vice versa. A model that accesses a database it should not have touched may trigger both tracks. But they each have their own criteria for activation, their own evidence rules and their own reporting obligations. A single runbook leaves directors without the foothold to decide whether something is reportable. Separating them gives you the clarity to answer the right question first.

What must the board do now?

For the next risk review, assign owners for both tracks. Plan a tabletop exercise with an AI scenario — not a cyber scenario — and test whether your logging can reconstruct an agent's trajectory at all. Many organisations will discover that they cannot. The lawyer must now have the internal AI incident criteria tested against applicable external reporting criteria, with legal advice where regulation such as the EU AI Act may be relevant.

Incident triage and the reporting duty must not run together; doing so makes both weaker. The board must establish which two tracks exist, who activates which track, and what evidence each track must preserve before an incident occurs. A CISO who discovers too late that evidence was not preserved has already lost the investigation.

Tooling can help you log and monitor, but the decision of what constitutes an AI incident, and whether it is reportable, remains yours. Automated detection of model drift or unexpected tool use can flag candidates for investigation, but the human judgment of whether the behaviour was authorised, whether it caused harm, and whether it triggers a reporting obligation cannot be delegated to the system itself.