AI Incident Response Plan

How to use this document

• What it is for. This is a base procedure to detect, classify, contain, investigate, communicate and close incidents involving an AI system: model failures, bias, harmful content, AI-specific attacks, data leaks through AI tools, vendor incidents and incidents in self-hosted models. Its incident record (Section 10) is the organization's single AI incident record: other documents send their incidents here.
• Who should own it. Usually the head of information security or AI operations, working with privacy, legal and the AI committee. Enter the function in [RESPONSIBLE FUNCTION] and the person who leads the response in [OWNER].
• Decisions to take first. Decide whether this plan stands alone or works as an annex to a general incident response plan (clause 1.3), which activation and escalation times to use (Section 5), who may switch off an AI system without prior approval (Section 7.4) and how long to keep logs and evidence (Section 10).
• Fields to complete. Replace the bracketed fields, complete the notification table in Section 8.1 and the response team directory (aid F). Keep [OPTIONAL] clauses only if they apply.
• Country variants. This document has no country variants. Notification deadlines, authorities and content differ by jurisdiction and industry: complete table 8.1 using the laws listed in "Related regulatory references" that apply to your organization and, if you report personal data breaches in several countries, the "Data Breach Notification Procedure by Country."
• Review. Have counsel validate the notification table and the messages to affected people, and have security and technical teams validate containment and rollback for each critical system.
• Approval and publication. Have it approved by management or the appropriate committee, record the approval in "Version history," distribute it to the response team, support and AI system owners, and test it with a tabletop exercise within three months.

AI Incident Response Plan

Field	Value
Organization	[LEGAL ENTITY NAME]
Owning function	[RESPONSIBLE FUNCTION]
AI incident response lead	[OWNER]
Approved by	[APPROVED BY]
Effective date	[DATE]
Review frequency	[REVIEW FREQUENCY]
Incident reporting channel	[AI GOVERNANCE EMAIL] and [COMPLETE] (phone or on-call channel)

1. Purpose and relationship to other plans

1.1 This plan sets out how [ORGANIZATION NAME] detects, classifies, contains, investigates, communicates and learns from incidents involving an AI system, in order to limit harm to people and to the organization, meet applicable notification obligations and prevent incidents from recurring.

1.2 AI incidents need specific handling because they can originate in the model, the data, the way outputs are used or a vendor, and because their impact can be ethical, legal or reputational as well as technical.

1.3 [OPTIONAL] This plan supplements the general incident response plan of [ORGANIZATION NAME], version [COMPLETE]. The roles, channels and tools of the general plan apply to everything this plan does not specifically address.

1.4 This plan applies together with the "Responsible AI Use Policy (Including Generative AI)," the "Data Breach Notification Procedure by Country" and the business continuity plan. Technical containment is carried out with the "AI Rollback and Safe-State Protocol" and service continuity with the "AI Failure Contingency Runbook"; this plan does not repeat their steps.

2. Scope

2.1 This plan applies to any incident that meets at least one of these criteria:

a) the root cause is a failure, unexpected behavior or vulnerability of an AI model or system;
b) an AI system exposes, alters or mishandles personal data or confidential information;
c) the behavior of an AI system causes or may cause a significant impact, whether operational, ethical, financial, reputational, legal or on people's health and safety, on the organization, its customers, its staff or third parties;
d) an attack targets AI components, for example through data poisoning, adversarial inputs, prompt injection, model theft or agent abuse;
e) staff use AI in breach of the responsible AI use policy with a significant impact, for example by entering confidential information into an unapproved tool;
f) a vendor reports an incident in an AI system the organization uses;
g) a general incident has AI-specific implications that require expert knowledge to manage;
h) in a self-hosted model, the hash of the weights in production does not match the approved one, a tampered chat template or hidden behavior is found, or the developer of the upstream model or of the inference server publishes a security advisory that affects it.

2.2 It applies to AI systems developed in-house, acquired from third parties or integrated as a service, and to all staff and vendors involved in operating them.