The IAPP argues that organisations should extend their proven crisis and cyber runbooks for AI incidents, such as a model that oversteps its task boundary. Keep two linked tracks: a conventional track for compromised systems or data, and an AI control track for unexpected or unauthorised model behaviour, with their own criteria, monitoring and evidence preservation.
On 19 October 2026 the International Association of Privacy Professionals (IAPP) pointed, in its weekly opinion column, to a concrete gap in preparation: many organisations have tested their crisis and cybersecurity plans, but those plans do not cover AI incidents. In our analysis an AI incident can involve a model that carries out an action it was not instructed to perform, a manipulated monitor, or an agent that oversteps its intended data or tool boundary without a classic intrusion ever taking place.
That preparation is lagging behind is measurable. ISACA's 2026 State of Cybersecurity survey of more than 1,800 cybersecurity professionals shows that only 8% of organisations regularly run AI-specific response exercises, while nearly half of respondents do not know whether their own organisation has an AI incident playbook, or indicate that there is none. At the same time AI is already being deployed widely in security operations. So deployment is outpacing preparation for what goes wrong.
Why is an existing cyber response plan not enough for AI incidents?
Because a conventional plan is typically organised mainly around compromised systems and leaked data, whereas AI incidents can also revolve around behaviour of a model that formally stays within its permissions but does something unintended. An AI incident can revolve around an action that is technically permitted but falls outside the intended task, or around a near miss that never becomes a reportable breach.
The classic runbook asks: which system was breached, which data is gone? An AI control incident asks something else: which model did what, with which permissions, through which tools, and who approved it? In our assessment this is the core point of the IAPP observation: the two questions overlap, but do not resolve one another. Anyone who can only answer the first question misses precisely the evidence needed to reconstruct the second. We described earlier an example of how fine the dividing line is with a model that damaged its own test environment.
What concrete measures does the NIST guidance prescribe for an AI incident?
The NIST incident-response recommendations provide the conventional operational foundation, while the AI-specific practices discussed here call for collecting and preserving model, training, evaluation and deployment environments; preserving configuration, safeguards, tool calls, trajectories and security-control decisions; and using tamper-resistant logs sufficient to reconstruct an agent's activity and affected systems.
Translated into an AI incident track, that means concretely:
- define in advance what an AI incident and a near miss are, so that unexpected model behaviour becomes a trigger rather than an anecdote;
- keep an inventory of models, the harness, tools, credentials and environments an agent can reach;
- monitor model, host, network and the agent's trajectory; on our recommendation, monitoring and logs should stay outside the control of the agent itself;
- preserve tamper-resistant evidence sufficient to reconstruct after the fact what happened;
- revoke credentials and restrict, isolate or terminate the activity in an incident; this is our practical translation of containment into an AI control track;
- rebuild from verified baselines and document the residual risk before the service goes back online.
The NIST recommendations for incident response do not replace your existing practice; in our analysis, they provide the conventional foundation that organisations can extend with AI-specific records and controls. The idea of keeping monitoring and evidence beyond the model's reach aligns with the reasoning for treating advanced AI as an insider with too many permissions.
What does this mean for directors, lawyers and CISOs deciding now?
Our analysis: because an AI incident can be an unauthorised model action without a classic data breach, with a single runbook directors lack the foothold to decide whether something is reportable; therefore the board must now establish which two tracks exist and who activates which track. Because the ISACA research shows that nearly half do not know whether an AI playbook exists, our assessment is that a CISO risks discovering too late that evidence was not preserved by the time an incident is recognised; therefore integrity monitoring of models and the tamper-resistant recording of tool calls and trajectories belongs in the management plan now, separate from the agent. Because for some AI incidents legal or contractual reporting obligations may apply, the lawyer must now have the internal AI incident criteria tested against the applicable external reporting criteria, with legal advice where regulation such as the EU AI Act may be relevant.
For the agenda of the next risk review this means: assign owners for both tracks, plan a tabletop exercise with an AI scenario, and test whether your logging can reconstruct an agent's trajectory at all. Anyone who lets incident triage and the reporting duty run together makes both weaker; we worked out that separation earlier in separating incident triage and the reporting duty for AI incidents.
How do I set up two linked response playbooks?
Keep one conventional track for compromised systems or data and one AI control track for unauthorised or unexpected model behaviour, with shared escalation but their own criteria and evidence rules. The tracks are linked because an AI incident can spill over into a classic breach and vice versa, but they each have their own first question.
- Conventional track: intrusion, malware, data breach; questions: which system, which data, and which applicable reporting duties, including any GDPR obligations where relevant?
- AI control track: unauthorised action, manipulated monitor, boundary overstep by an agent, near miss; which applicable legal or contractual reporting criteria apply, including — where relevant — criteria from the EU AI Act.
- Shared: one escalation line, one shared evidence standard, informed by the NIST recommendations, one coordination of reporting towards data subjects and supervisory authorities.
More background on managing AI risk can be found in our topic hub on AI security and incident management. The core remains sober: the IAPP is not calling for a new apparatus, but for a targeted extension of what you already have.
Sources and references
Sources: The article draws on the IAPP's opinion column, ISACA's State of Cybersecurity research and the incident response recommendations from NIST (SP 800-61 Rev. 3).