AI Incident Response Plan (2026): Templates, Timelines & GDPR/EU AI Act Reporting

Written and reviewed by Irfan Ullah, Founder of TrusteraAI and creator of the TrusteraAI AI Risk Assessment Framework™. Last updated: August 2026 · Regulatory review: August 2026.

Sources & Methodology: Regulatory requirements are based on the applicable EU legal text and official EU guidance (EUR-Lex, EDPB). Framework references are mapped to NIST and ISO publications. Statistics are attributed to their original publishers, linked below.

An AI incident doesn’t wait for you to have a plan. A prompt injection leaks customer data, a model hallucinates a refund policy that costs real money, or an automated decision quietly discriminates against a protected group. Traditional incident response procedures weren’t built for these failure modes — and in many cases, no attacker is involved at all.

Quick Answer: An AI incident response plan is a structured set of procedures for detecting, containing, and recovering from incidents involving AI systems — including both attacks against AI (prompt injection, data poisoning) and harmful behavior produced by AI working as designed but incorrectly (hallucination, biased automated decisions) — with defined severity tiers, regulatory notification timelines, and evidence preservation requirements.

Gartner’s survey of 302 cybersecurity leaders found that 69% of organizations suspect or have direct evidence of employees using unsanctioned generative AI tools, and 32% reported an attack on AI applications leveraging prompts. Separately, IBM’s 2025 Cost of a Data Breach Report found that breaches involving a high level of shadow AI cost organizations $670,000 more on average than standard breaches ($4.63M vs. $3.96M), and that shadow AI was a factor in 20% of breaches studied. These are two distinct findings from two distinct studies — together, they illustrate why AI-specific incident visibility and response controls deserve explicit treatment, separate from a general security program.

---

🎯 Start Here

• Need the plan template now? Download the AI Incident Response Plan Template or use the Incident Record Template below
• Mid-incident right now? Jump to First 15 Minutes or the Regulatory Decision Tree
• Building a program from scratch? Jump to the 5-Phase Response Lifecycle

---

What Is an AI Incident?

TrusteraAI operational definition: an AI incident is any event where an AI system causes, or is reasonably suspected to have caused, harm, data exposure, a regulatory violation, or a significant deviation from its intended behavior — whether or not an attacker was involved. There isn’t a single universal legal definition of “AI incident” that maps cleanly across GDPR, the EU AI Act, NIST, and ISO — this is TrusteraAI’s operational framing for response planning.

This is broader than a security incident. AI incidents fall into three overlapping buckets:

• Security incidents: prompt injection, data exfiltration, model theft, credential compromise
• AI safety/reliability incidents: hallucination, unsafe output, model drift, unintended autonomous action
• AI governance/compliance incidents: discriminatory automated decisions, unauthorized data processing, prohibited use cases, regulatory noncompliance

A model that hallucinates false medical guidance, an agent that autonomously issues unauthorized refunds, or a hiring tool that produces systematically biased shortlists are all AI incidents — none of them require an attacker.

AI Incident vs. Security Incident vs. Data Breach vs. Serious AI Incident

These terms get conflated, and the conflation matters — not every AI incident triggers regulatory reporting.

Event	AI Incident?	Security Incident?	GDPR Breach?	EU AI Act Serious Incident?
Hallucinated product description	Yes	Not necessarily	Not necessarily	Not necessarily
Prompt injection exposing PII	Yes	Yes	Potentially	Potentially, depending on system and impact
Biased hiring output	Yes	Not necessarily	Not automatically	Potentially, if the facts meet Article 3(49), including the relevant fundamental-rights criterion
API credential theft via AI system	Yes	Yes	Potentially	Not automatically
High-risk AI system causing serious harm	Yes	Not necessarily	Not necessarily	Potentially, once Article 73 applies to that system (see below)

The lesson: an AI incident is not automatically a reportable event. Each of the four questions in this table needs its own assessment — see the Regulatory Decision Tree below.

The TrusteraAI AI Incident Taxonomy

Quick Answer: For practical response planning, TrusteraAI groups AI incidents into eight operational categories — this is our analytical framework for assigning containment actions quickly, not a universally standardized taxonomy.

Category	What It Looks Like	Primary Containment Action
Prompt injection	Malicious input overrides system instructions or extracts hidden prompts	Update guardrail rules; block the attack pattern
Data leakage	Model exposes PII, credentials, or proprietary data in outputs	Revoke exposed credentials; activate kill switch if active exfiltration
Model manipulation	Data poisoning, model extraction, or adversarial inputs corrupt behavior	Quarantine affected data/model; roll back to last known-good version
Hallucination-driven harm	False AI-generated output causes financial, medical, or legal harm	Escalate to human review; issue correction to affected users
Automated decision harm	Biased or discriminatory automated decisions affecting people	Suspend automated decisioning; switch to human-in-the-loop
Vendor / supply chain compromise	Compromised third-party model, library, or API introduces risk	Isolate the affected integration; activate vendor’s incident process
Resource abuse	Attacker drains API budget or compute via automated queries	Rate-limit or block the source; review billing anomalies
Model/system performance degradation	Model drift, unexpected accuracy collapse, guardrail bypass without a successful exploit	Roll back to known-good version; investigate retrieval/data pipeline

This structure is deliberately compatible with the domains in our Enterprise AI Security Checklist, which covers the preventive controls that reduce the likelihood of these incidents in the first place.

Severity Tiers: Internal Targets, Not Regulatory Deadlines

Tier	Internal Response Target	Example
P1 — Critical	Contain within 15 minutes	Active data exfiltration; automated system taking harmful real-world action
P2 — High	Contain within 1 hour	Confirmed prompt injection with limited data exposure
P3 — Medium	Contain within 4 hours	Isolated hallucination causing customer-facing but non-critical harm
P4 — Low	Contain within 24 hours	Minor output quality issue with no data or safety impact

Important: these severity-tier response targets are internal operational objectives. They do not replace or modify statutory reporting deadlines. A P1 incident contained in 15 minutes may still carry a 72-hour GDPR notification obligation, or — once applicable — an EU AI Act reporting deadline. The two clocks run independently.

Set these targets before an incident occurs — a severity classification made in the moment, under pressure, with no pre-agreed threshold, is where response plans break down in practice.

The 5-Phase AI Incident Response Lifecycle

This guide uses a five-phase operational lifecycle: Detect → Contain → Eradicate → Recover → Review. This is TrusteraAI’s operational simplification — NIST, ISO/IEC 27035-1, and ISO/IEC 27035-3 use somewhat different phase names and structures. Preparation is the program layer that exists continuously before these five phases begin — severity thresholds, RACI, evidence storage, notification templates, and tabletop exercises are all preparation work, established ahead of any incident.

• Detect: Triage within 5 minutes of alert — assign incident category, severity tier, and affected systems. Preserve evidence before any other action where doing so doesn’t delay emergency containment.
• Contain: Execute the containment action for the relevant category (see taxonomy above). For P1/P2 incidents involving active harm, kill switch activation may be warranted.
• Eradicate: Conduct root cause analysis (a simple “Five Whys” approach works for most AI incidents). Address the systemic failure, not just the immediate symptom.
• Recover: Test the fix in staging, deploy via gradual rollout, and monitor closely for 24 hours before declaring the incident closed.
• Review: Document lessons learned within one week. Update the runbook and feed findings back into your risk register — see From Inventory to Controls for how this connects to your broader governance chain.

First 15 Minutes: What to Do Immediately

Minutes	Actions
0–2	Acknowledge the alert; assign an incident ID; preserve volatile evidence before it’s overwritten
2–5	Classify the incident category and severity tier; identify affected AI systems
5–10	Stop active harmful behavior; revoke exposed credentials; suspend autonomous actions if an agent is involved
10–15	Engage security, legal, and privacy; establish an incident commander; begin the regulatory assessment

Preserve volatile evidence as quickly as practical — but do not delay emergency containment when continued operation creates immediate or escalating harm. If an autonomous agent is actively exfiltrating data, shut it down; don’t wait to capture every log first.

GDPR Breach Notification: The 72-Hour Clock

Quick Answer: Under GDPR Article 33, controllers must notify their supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach — unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Article 34 requires notifying affected individuals without undue delay where the breach is likely to result in high risk.

This applies to personal data breaches specifically, not to every AI incident — an AI incident with no personal data involved doesn’t trigger the GDPR Article 33 notification obligation (see the comparison table above; other obligations may still apply separately).

The 72-hour period runs from when the controller becomes aware that a breach has occurred, not from when the internal investigation is fully completed. Awareness does not necessarily mean the first unexplained alert — the EDPB describes awareness in terms of a reasonable degree of certainty that a security incident has occurred and has compromised personal data. Once that degree of certainty is reached, the notification assessment should proceed without waiting for the investigation to conclude.

If your organization is a processor, not a controller: the Article 33 notification duty to the supervisory authority sits with the controller. As a processor, your obligation under Article 33(2) is to notify the controller without undue delay after becoming aware of a personal data breach — the controller then makes the regulatory notification decision.

A defensible notification workflow:

1. DPO receives incident details from the response lead within 1 hour of containment
2. Legal drafts the notification covering the nature of the breach, affected data subjects, likely consequences, and measures taken
3. DPO submits to the supervisory authority within the 72-hour window
4. If high risk to individuals exists, affected data subjects are notified without undue delay

Beyond statutory deadlines: customer contracts, DPAs, cyber insurance policies, vendor agreements, and sector-specific rules may impose notification deadlines shorter than GDPR’s 72 hours. Don’t assume the statutory deadline is your only deadline — check contractual commitments as part of the regulatory assessment.

For Spain-specific regulatory context, see our AEPD Inspection Guide and Spain GDPR Checklist for SaaS.

What Applies in 2026? A Regulatory Snapshot

Regime	Trigger	2026 Status
GDPR Article 33	Personal data breach meeting risk threshold	Applicable now
GDPR Article 34	High risk to individuals	Applicable now
EU AI Act Article 73 (Annex III systems)	Serious incident, stand-alone high-risk system	Deferred to December 2, 2027
EU AI Act Article 73 (Annex I systems)	Serious incident, embedded high-risk system	Deferred to August 2, 2028
EU AI Act Article 4 (AI literacy)	Staff AI literacy	Applicable since Feb 2, 2025 — unaffected
Contractual / vendor notification	Contract-specific incident clauses	Depends on contract — verify independently
Sector-specific rules	Healthcare, financial services, critical infrastructure, etc.	Depends on sector and system

Important: the EU AI Act’s Digital Omnibus (entered into force July 27, 2026) deferred the application of Chapter III’s high-risk obligations — the regime that includes Article 73 — from the original August 2, 2026 date. Don’t assume every high-risk system is already subject to Article 73 reporting today; confirm the applicable date for your specific system’s Annex classification before treating this obligation as current.

EU AI Act Article 73: Who Must Report, When — and Does It Apply Yet?

Quick Answer: Article 73 of the EU AI Act (Regulation (EU) 2024/1689) establishes a tiered serious-incident reporting framework for providers of high-risk AI systems — and, where applicable, deployers. As of August 2026, following the Digital Omnibus, this obligation applies on a delayed timeline (see the snapshot above), not immediately for most systems. Build your response process now — the reporting clock isn’t running yet for most high-risk systems.

Don’t use a flat “15-day” or “2-week” rule — this is the single most common error in AI incident response content. Once applicable, the deadlines are tiered:

Incident Severity	Reporting Deadline
Other serious incidents	Immediately after a causal link (or reasonable likelihood of one) is established, and no later than 15 days after becoming aware
Death may have been caused	10 days from becoming aware
Widespread infringement or serious, irreversible disruption to critical infrastructure	2 days from becoming aware

Under Article 3(49), a “serious incident” is an incident or malfunction that directly or indirectly leads to: (a) death of a person, or serious harm to a person’s health; (b) serious and irreversible disruption of the management or operation of critical infrastructure; (c) infringement of obligations under Union law intended to protect fundamental rights; or (d) serious harm to property or the environment. Article 73(5) allows submitting an initial, incomplete report with supplemental information to follow — the obligation is to report promptly, not to arrive with a fully resolved investigation.

Provider vs. deployer — don’t treat them as identical: Article 73 establishes the reporting regime primarily for providers of covered high-risk systems. A deployer that becomes aware of a serious incident has a corresponding duty to notify the provider — and, in circumstances specified by the Act, relevant authorities directly if the provider cannot be reached.

Applicability check — before assuming Article 73 applies (or doesn’t):

• What role does your organization hold — provider, deployer, or both?
• Is the specific AI system classified as high-risk, and under which Annex (I or III)?
• Has the relevant provision become applicable to your system yet, given the 2027/2028 deferral?
• Which market surveillance authority is competent for this incident?
• Does the incident fall within Article 73’s scope, or is it a lower-severity event better handled through internal review?

Confirm your role and the system’s classification using the fields in your AI Inventory before treating this obligation as currently applicable. For the official regulation text, see EUR-Lex, Regulation (EU) 2024/1689.

Regulatory Decision Tree

Use this sequence for any confirmed AI incident:

1. Does the incident involve a personal data breach? → No: skip to step 3. → Yes: continue.
2. Is it unlikely to result in a risk to individuals’ rights and freedoms? → Yes: document; no Article 33 notification required. → No: notify the supervisory authority within 72 hours where feasible. If high risk to individuals exists, also notify affected individuals under Article 34.
3. Is the AI system within EU AI Act Article 73 scope, and has the applicable date passed for its Annex classification? → No: Article 73 not currently triggered. → Yes: continue.
4. Does it meet the Article 3(49) definition of a “serious incident”? → No: document and handle through internal review. → Yes: continue.
5. Determine severity and the applicable deadline: default 15 days; 10 days if death may have occurred; 2 days if widespread or critical-infrastructure disruption.
6. Check contractual and sector-specific deadlines separately — these may be shorter than the statutory ones above.

Evidence Preservation Checklist

Evidence destroyed during containment can’t be recovered — and can create legal exposure of its own if it looks like spoliation. Before taking containment action (where doing so doesn’t delay emergency containment of active harm), preserve:

• AI system logs — prompts, responses, guardrail decisions, token usage
• Application and authentication logs
• Network and API traffic logs, including provider/API request IDs
• Model artifacts — version, configuration, system prompt, relevant model parameters
• Deployment/environment identifier and guardrail/policy version at time of incident
• User/session context involved in the incident
• Timestamps synchronized to a known time source
• Chain-of-custody documentation — who accessed evidence, when, and why

For AI agents, preserve the full action chain — not just the final output. Capture the model invocation, retrieved context, tool/function calls, authorization decisions, external side effects, human approvals, and final state. An agent incident cannot be reconstructed from the final model output alone; also capture vector database queries and any downstream actions the agent already executed before containment.

Common mistake to avoid: restarting an affected system to “clean up” before evidence is captured, or applying a fix that overwrites the logs needed to understand what happened.

Kill Switch: A Pre-Authorized Emergency Control

A kill switch is a pre-authorized emergency control that disables an AI system or its autonomous capabilities when continued operation creates unacceptable risk — it is not simply a strong containment action. Define, before any incident:

• Who can activate it, and whether single-person emergency authority is permitted for active-harm scenarios, versus when secondary approval or post-action review is required
• What gets disabled and what remains operational
• Rollback procedure and how evidence is preserved during activation
• Safe restoration process, including staged rollout and monitoring before full traffic resumes

There’s no universal rule requiring two-person authorization — for an actively exfiltrating autonomous agent, requiring a second approver before acting could itself be dangerous. Decide deliberately whether your organization needs single-person emergency authority with post-action review, or a stricter pre-approval requirement, based on your risk tolerance and system criticality.

Example AI Incident Response RACI

Example only — adapt accountability to your organizational structure.

Activity	Response Lead	Security	Legal / Privacy / DPO	Engineering	Executive
Triage & severity classification	A	R	C	C	—
Containment	A	R	C	R	C
Evidence preservation	R	A	C	R	—
GDPR notification (if applicable)	C	C	A	—	C
EU AI Act reporting (if applicable)	C	C	A	C	C
Root cause analysis	A	R	C	R	—
Post-incident review	A	C	C	C	C

(R = Responsible, A = Accountable, C = Consulted. Accountability for regulatory notification varies by organization; in some, the DPO advises rather than personally owns the final decision. Larger teams may also involve Communications/PR, Vendor Management, and Business Continuity roles not shown here. Small teams can combine roles but should not eliminate responsibilities.)

The AI Incident Response Plan

An incident record documents what happened during one event. An incident response plan is your organization’s standing procedure — the document that exists before any incident occurs. We’ve built a complete, ready-to-use version of this plan as a downloadable Word template covering all 20 sections below — download the AI Incident Response Plan Template.

Your plan should define:

• Purpose and scope — which AI systems and teams this plan covers
• Incident definition and taxonomy — using the categories above
• Severity matrix — the P1–P4 tiers and their internal targets
• Roles and escalation paths — your RACI, plus who has kill switch authority
• First 15-minute procedure — formalized for your organization
• Evidence preservation procedure — including AI-agent-specific evidence
• Containment procedures — per incident category, plus kill switch governance
• Regulatory assessment procedure — the decision tree above, formalized
• GDPR and EU AI Act assessment — including your organization’s role (controller/processor, provider/deployer) and current applicability
• Vendor/third-party notification procedure — for incidents involving a compromised AI vendor
• Communication rules — internal escalation and, separately, external/regulatory communication
• Recovery requirements — staged rollout, monitoring period, sign-off before closure
• Record retention — how long incident records and evidence are kept
• Testing schedule — tabletop exercise cadence and scenario rotation

The AI Incident Record Template

This is the form completed during a specific incident — distinct from the plan above.

Incident ID:
Date/Time Detected:
Detected By:
Incident Category: [Prompt Injection / Data Leakage / Model Manipulation /
                     Hallucination Harm / Automated Decision Harm /
                     Vendor Compromise / Resource Abuse / Performance Degradation]
Severity Tier: [P1 / P2 / P3 / P4]
Affected System(s):
Personal Data Involved (Y/N):
GDPR Role: [Controller / Processor / Joint Controller]
GDPR Notification Required (Y/N):
EU AI Act Serious Incident (Y/N):
EU AI Act Role: [Provider / Deployer / Both / Not Applicable]

Containment Actions Taken:
Evidence Preserved:
Root Cause:
Remediation Actions:
Recovery Date:
Post-Incident Review Date:
Lessons Learned:

This record’s fields feed directly into your AI Risk Assessment and AI Inventory — an incident closes the loop back into both.

Worked Example: AI Support Assistant Data Leakage (Fictional Scenario)

The scenario below is illustrative and does not describe a documented TrusteraAI customer incident. Actual notification decisions depend on the specific facts, controller/processor roles, and a documented risk assessment.

Scenario: A SaaS company’s AI-powered support assistant, serving customers across the US, Spain, and the broader EU, begins including other customers’ account details in its responses due to a prompt-handling bug.

Time	Decision Point / Action
T+0	Customer report received; evidence preserved; triaged as P1 (active data leakage)
T+12 min	Assistant taken offline; affected session logs preserved before any change
T+30 min	Privacy/legal assessment initiated to determine controller status and scope
T+4 hours	Preliminary breach assessment completed; root cause traced to a context-window bug
T+18 hours	Fix patched and validated in staging
T+24 hours	Notification decision made: GDPR Article 33 applies; drafting begins
T+42 hours	Gradual rollout complete; full traffic restored after clean monitoring period
T+48 hours	Supervisory authority notified — within the 72-hour window
T+1 week	Post-incident review complete; findings fed back into the AI Inventory entry for this system

Outcome: Because evidence was preserved before containment and the GDPR clock was tracked from the point at which the company became aware of the personal data breach — not from the completion of the internal investigation — the company met its notification deadline with time to spare and had a defensible record for the supervisory authority.

Tabletop Exercises

A plan that’s never been rehearsed fails in exactly the ways a fire drill would predict. Run tabletop exercises at least twice a year, rotating through different scenarios — prompt injection leading to data exfiltration, hallucination causing financial harm, an AI agent taking an unauthorized action, a vendor compromise, and a bias/discrimination complaint each surface different gaps.

For each exercise, measure: time to detect, time to classify, time to contain, time to involve legal, time to preserve evidence, time to reach a regulatory determination, and any points of unclear ownership. Update the plan and the template based on what the exercise reveals.

Framework Mapping: NIST, ISO 27035, ISO 42001, EU AI Act & GDPR

Framework	What This Plan Supports
ISO/IEC 27035 (Information security incident management)	The primary incident-management foundation this plan extends with AI-specific categories and evidence
NIST Cybersecurity Framework (Detect/Respond/Recover functions)	The 5-phase lifecycle above aligns with these functions for AI-specific incidents
NIST AI Risk Management Framework (Govern, Map, Measure, Manage)	Incident response sits primarily within Manage; findings feed back into Map and Measure for the affected system
ISO/IEC 42001	Supports operational controls within an AI management system and can be integrated with existing incident-management processes
EU AI Act Article 73	Serious incident reporting timelines for high-risk system providers and applicable deployers, once the relevant obligations apply
GDPR Articles 33 & 34	Breach notification to authorities and affected individuals

For the broader risk and inventory context this plan connects to, see our AI Risk Assessment Checklist, AI Inventory Template, and AI Governance Checklist for SaaS Founders.

Common Mistakes to Avoid

• Treating AI incident response as a subset of general IT incident response without AI-specific categories or containment actions
• Assuming every AI incident is automatically a reportable event under GDPR or the EU AI Act
• Starting the GDPR 72-hour clock from formal confirmation instead of initial awareness
• Using a flat “2-week” or “15-day” rule for EU AI Act reporting, or assuming Article 73 is already fully applicable in 2026
• Destroying logs or restarting systems before evidence is preserved
• Not preserving model, prompt, and tool-call state — reconstructing an agent incident from the final output alone is often impossible
• No pre-agreed severity thresholds, leading to inconsistent classification under pressure
• Treating vendor AI as outside your incident response scope
• Failing to update the AI inventory and risk register after an incident
• Never rehearsing the plan before a real incident

Best Practices

• Define severity tiers and response-time targets before you need them, and keep them clearly separate from regulatory deadlines
• Preserve evidence before taking any containment action, without delaying emergency containment of active harm
• Track the GDPR notification clock from awareness, not confirmation
• Confirm your organization’s role and system classification — and current applicability date — before assuming EU AI Act Article 73 applies
• Check contractual and vendor notification deadlines separately from statutory ones
• Run tabletop exercises at least twice a year against varied, realistic AI-specific scenarios
• Feed every incident’s findings back into your risk register and inventory, closing the governance loop

Key Takeaways

✅ AI incidents include both attacks against AI systems and harmful behavior from AI systems working as designed — and not every AI incident is automatically reportable.

✅ When Article 73 applies, serious-incident reporting is tiered — 15 days by default, 10 for death, 2 for widespread or critical infrastructure incidents. But following the 2026 Digital Omnibus, the underlying high-risk obligations are deferred to December 2027 (Annex III) and August 2028 (Annex I) — confirm your applicability date before assuming the clock is running.

✅ The GDPR 72-hour clock starts at awareness, not formal confirmation.

✅ An incident response plan (the standing procedure) and an incident record (the per-incident form) are different documents — most competing resources only offer the second.

✅ This plan connects directly to your AI Risk Assessment Checklist and AI Inventory Template.

Frequently Asked Questions