AI Incident Response Plan 2026: The Clocks Your Security IR Plan Doesn't Start

Why the Existing Plan Doesn't Fire

Security incident response is organised around a compromise: someone got access they should not have had, or something became unavailable, or data moved somewhere it should not be. Every part of the plan — the severity matrix, the forensics, the notification analysis — descends from that premise.

An AI incident usually satisfies none of it. The model was authorised to run, the data was authorised to be there, the pipeline behaved as built. The failure is in the content of an output or the substance of a decision, and no clause in a compromise-shaped plan describes that. The result is predictable: the event gets handled by whichever engineer noticed it, as a bug, on a normal deployment cadence, with no evidence preserved and no legal assessment of whether anything is owed to anyone.

Four Shapes of AI Incident

These have genuinely different response profiles, and a single generic runbook handles none of them well.

Adverse decision at scale

A model scoring or screening system produced systematically wrong or skewed outcomes affecting eligibility, employment, credit, pricing or benefits.

Dominant concern: The remediation problem dominates. Decisions already issued may need to be re-run and reversed, and the affected-population analysis usually determines the regulatory posture more than the technical root cause does.

Harmful or defamatory output

A user-facing system published something false about an identifiable person, offered advice in a regulated domain, or generated content that infringes.

Dominant concern: Speed and reach matter most. Whether the output was displayed to one user or syndicated into indexed pages changes the exposure by orders of magnitude, and takedown of derived copies is its own workstream.

Data exposure through the model

Training data, another tenant's content, or documents outside the asking user's permissions surfaced in a response.

Dominant concern: This one does overlap with your security plan and should be routed there in parallel — it is a genuine unauthorised disclosure and standard breach notification analysis applies.

Agent or tool-use failure

An autonomous workflow took real-world actions: sent messages, modified records, moved money, changed permissions.

Dominant concern: Containment is urgent and the blast radius is often unknown at detection time. Credential scope and an action audit log are the difference between a bounded incident and an open-ended one.

The Clocks That May Already Be Running

No single statute governs AI incidents. Several separate regimes may attach to the same event, each with its own trigger and its own timeline, and they are assessed independently:

EU AI Act post-market obligations. Providers of high-risk systems must monitor in the field, investigate serious incidents, take corrective action and report to the relevant market surveillance authority. The binding constraint in practice is detection and classification capability, not the report form.
State AI discrimination statutes. Colorado's framework and comparable state regimes impose duties around algorithmic discrimination in consequential decisions, including notice to affected individuals and disclosure to the attorney general within defined periods of discovery.
Breach notification law. Only engaged where personal information was actually acquired without authorisation — the third incident shape above. Do not assume it applies to the others, and do not assume it does not apply just because the mechanism was a model.
Sector regulators. Financial services, health, insurance and employment each carry their own supervisory expectations, and several have issued AI-specific guidance that assumes a documented incident process exists.
Contractual notice. Frequently the shortest clock of all. Enterprise agreements routinely require notice of incidents affecting customer data within a stated number of hours, defined more broadly than any statute.

Severity Levels That Map to Action

Borrowing your security severity matrix produces nonsense, because it grades on data volume and system availability. Grade AI incidents on consequence to people and on reversibility instead.

Sev 1 — Consequential and irreversible

An automated decision affected access to employment, credit, housing, healthcare or benefits
Money moved, or an agent took an external action that cannot be silently undone
Harmful content about identifiable people was published beyond your own surface
Response: disable immediately, preserve evidence before any redeploy, counsel engaged within the hour

Sev 2 — Consequential but reversible

Wrong outputs entered a workflow where a human review step exists and can be re-run
Internal decisions affected but not yet communicated to the individuals concerned
Cross-tenant retrieval where logs confirm a bounded and small set of impressions
Response: contain within the day, quantify the affected population, assess notice duties

Sev 3 — Quality defect with exposure potential

Systematic inaccuracy in a low-stakes surface with no decision attached
A pattern that would become Sev 1 if the same model were used in a consequential context
Response: normal engineering cadence, but logged in the incident register so patterns are visible

Always escalate regardless of level

Anything touching a protected characteristic in a decision context
Anything involving minors
Anything a customer or regulator has already asked about
Anything where you cannot reconstruct why the output occurred

The Preservation Problem

Forensics on a compromised host is a mature discipline. Forensics on a model output is not, and most teams discover mid-incident that the record they need was never written. To explain an output later you need all of the following captured at the time it was produced:

Model identity and version. Not the family name but the specific snapshot, because providers rotate and deprecate on their own schedule and a pinned identifier may not be servable in six months.
The full prompt as sent. System instructions, the template version, and every variable substituted into it — not the template alone.
Retrieved context. Which documents were pulled and at what version. Reconstructing this later is impossible once the index has been rebuilt.
Tool calls and their results. For agentic systems this is the audit trail of what was actually done in the world.
Post-processing and the human step. What filters ran, what was modified, and whether a person reviewed and approved.

Retention policy has to survive contact with privacy minimisation. These logs contain personal data by construction, so the defensible answer is a short standard retention window with a documented legal hold mechanism that extends it for a specific incident — not indefinite retention, and not a thirty-day window that quietly destroys the record of an incident discovered on day thirty-one.

Frequently Asked Questions

Why won't our existing security incident response plan cover AI failures?

Security incident plans are built around unauthorised access, availability loss and data exfiltration. An AI incident frequently involves none of those: the system performed exactly as designed, no control was bypassed, and no data left. What went wrong is the content or the decision. Because the entry criteria in a standard plan are written in terms of compromise, the plan simply never triggers — which is why these events tend to be handled ad hoc by whoever noticed, without evidence preservation or a legal assessment.

What counts as an AI incident worth escalating?

The workable test is consequence, not mechanism. Escalate when an output or automated decision affected a person's access to something that matters — employment, credit, housing, healthcare, benefits, pricing — or when it was published in your name and is false about an identifiable person, or when it caused a legal obligation to be breached. A wrong answer in a low-stakes assistant is a quality defect. The same underlying error inside an eligibility workflow is an incident.

Does the EU AI Act require incident reporting?

Yes. Providers of high-risk systems carry post-market monitoring duties and must report serious incidents to the relevant market surveillance authority, with tighter timelines for the most severe categories and an obligation to investigate and take corrective action. The practical consequence for most companies is not the report itself but its precondition: you cannot report inside a short window unless you already detect, log and classify these events, which is an engineering and process problem to solve before an incident, not during one.

What evidence should we preserve when an AI incident occurs?

The inputs, the exact output, and everything needed to explain why that output happened: model and version identifiers, system prompt and configuration, retrieved context, tool calls, any post-processing, and the human review step if one existed. This is harder than it sounds because many stacks log the response but not the retrieval set or the prompt version, and providers deprecate model snapshots on their own schedule. If you cannot reconstruct the decision, you cannot demonstrate corrective action to a regulator or a claimant.

Who needs to be on an AI incident response team?

The security roster is necessary but insufficient. You additionally need whoever owns the model and its evaluation set, the business owner of the affected decision, legal counsel with privacy and employment or lending exposure depending on the domain, and communications. The role most often missing is someone with authority to disable the feature immediately — AI incidents frequently continue producing new harm every minute the system runs, which is different from a breach where the damage has usually already occurred.

Is rolling back the model enough to close an incident?

It stops the bleeding but does not close the matter. Outputs already delivered may have driven decisions that stand — rejections issued, prices charged, content published — and remediating those is a separate workstream from fixing the model. Regulatory duties attach to what happened, not to whether you fixed it quickly. A defensible close requires the rollback, the affected-population analysis, the remediation of decisions already made, and a documented root cause with a control that prevents recurrence.

What if the failure originated with our AI vendor, not our code?

Your obligations to your customers and to regulators do not transfer with the cause. Check what your vendor agreement actually promises about incident notification, because many AI provider terms commit to far less than the enterprise agreements you have signed downstream, and the gap between the two is a risk you are absorbing. Practically, you will often detect a provider-side change before the provider announces it, which is an argument for holding your own evaluation set and running it on a schedule rather than only at integration.

Should the postmortem be privileged?

That is a decision to make with counsel before you need it, not during an incident. Engineering postmortems are valuable precisely because they are candid, and candour written into an unprivileged document becomes discoverable. Many organisations run two artefacts: a privileged legal assessment of exposure and obligations, and a separate technical postmortem focused on the control that failed and the fix. Deciding the structure in advance avoids the worst outcome, which is a single document that is neither fully candid nor protected.

The Cheapest Version of This Plan

You do not need a new document family. Add AI failure modes to the entry criteria of the incident plan you already have, add a severity row that grades on consequence to people rather than data volume, and name the person who can disable a model-backed feature without a deployment.

Then do the one thing that cannot be retrofitted: check today whether you could reconstruct why a specific output happened last Tuesday. If the answer is no, that is the first fix, because every other part of the response depends on it.