Free template · Word · English and Dutch
AI incident response plan template for data breaches and AI incidents
An AI incident response plan sets out how an organisation recognises, assesses, contains, notifies and evaluates incidents involving personal data, AI systems and network and information systems. It links every reporting duty to the role that carries it: controller under the GDPR, provider or deployer under the EU AI Act, and essential or important entity under NIS2.
- Last checked against the law
- Editor
- Zahed Ashkara, jurist, privacy and AI
- Version and template ID
- 2.0 ·
praxikon:template:ai-incident-response-plan - Legal basis
- Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744; Regulation (EU) 2016/679 (GDPR); Directive (EU) 2022/2555 (NIS2) as implemented in national law
Who is this template for?
- Data protection officer or privacy officerNotifying the supervisory authority and communicating the breach to data subjects (Articles 33 and 34 GDPR)
- Incident coordinator or CISOEarly warning and incident notification for significant incidents (Article 23 NIS2)
- Owner of an AI application at a deployerSuspending use and informing the provider first (Article 26(5) AI Act)
- Provider of a high-risk AI systemReporting serious incidents to the market surveillance authority (Article 73 AI Act)
- Board or managementNotification decision and documentation afterwards (Article 33(5) GDPR)
What is inside
- Route table: which reporting duties apply to your organisation, per role and with the date each applies (chapter 2)
- Roles with deputies and a list of external contacts, from the supervisory authority and CSIRT to the provider of each high-risk system (chapter 3)
- First-hour checklist and four severity levels with triage times (chapter 4)
- Triage table with ten questions: per route what must happen, by whom and within which deadline (chapter 5)
- Timeline with the GDPR, AI Act and NIS2 clocks side by side (chapter 6)
- The plan by phase, with provisions you can adopt as written, including 'provider cannot be reached' (chapter 7)
- Model texts for the provider, data subjects and the board (chapter 8)
- Three fictional exercise cases: a chatbot leak, ransomware and an age effect in recruitment (chapter 9)
- Incident form and one combined incident log that also serves as the breach register (annex A)
How to use the template
- Use the route table in chapter 2 to decide which routes apply and delete what does not, such as the NIS2 route if you are not an essential or important entity.
- Complete chapter 3: incident coordinator, decision-maker, DPO, deputies and the reporting addresses of your AI providers and processors, also outside office hours. Fill in the authorities of your own Member State.
- Make the triage table and the timeline available to the service desk and the security staff on duty.
- Have the plan adopted by the board or management and remove the 'Note for the drafter' boxes.
- Exercise at least once a year with a case from chapter 9 and record every incident in the log in annex A.
Common mistakes
- Reporting serious AI incidents under 'Article 62'. That was the numbering in the Commission proposal; the Regulation covers it in Article 73 (provider) and Article 26(5) (deployer).
- Waiting to notify until the cause is known. The deadlines run from awareness, and an incomplete initial report may be supplemented later (Article 33(4) GDPR, Article 73(5) AI Act).
- Confusing the severity level with the duty to notify. A low-level incident can still be a personal data breach that must be notified to the supervisory authority, where feasible within 72 hours.
- Recording only the breaches you notified. Article 33(5) GDPR requires documentation of every personal data breach, including those you decided not to notify.
- As a deployer of a high-risk system, continuing use when it presents a risk. Article 26(5) requires you to suspend use; suspension is not optional.
When do you need legal advice?
- You are unsure whether to notify, and the clock is running. The risk to data subjects is hard to assess, for example when personal data has ended up with an AI vendor outside the EEA. The controller must take a reasoned decision, where feasible within 72 hours (Article 33 GDPR).
- Your role in the AI value chain is unclear. You have made a substantial modification to a high-risk system or put your own name or trademark on it, or used another AI system for a new purpose that makes it high-risk, or the provider does not respond. As a deployer you may then have to report yourself (Articles 26(5) and 73), or you become the provider (Article 25).
- Several authorities or fundamental rights are involved. The data protection authority, a sector regulator and the CSIRT ask for information at the same time, possibly in more than one Member State, or people may have been discriminated against. Align notifications and messages: each role carries its own duty.
Frequently asked questions
What is the difference between a personal data breach and a serious incident under the AI Act?
A personal data breach is a breach of security affecting personal data (Article 4(12) GDPR). A serious incident is an incident or malfunctioning of an AI system that directly or indirectly leads to death or serious harm to a person's health, a serious and irreversible disruption of critical infrastructure, an infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment (Article 3(49) AI Act). One event can be both.
Does a deployer have to report a serious incident itself?
Where a deployer of a high-risk AI system identifies a serious incident, it immediately informs the provider first, then the importer or distributor and the market surveillance authority (Article 26(5)). If the provider cannot be reached, Article 73 applies to the deployer. This applies to high-risk systems listed in Annex III from 2 December 2027 and to those covered by Annex I from 2 August 2028.
Which reporting deadlines apply?
GDPR (controller): without undue delay and, where feasible, within 72 hours of becoming aware, to the supervisory authority. AI Act (provider of a high-risk system): immediately, and at the latest 15 days after becoming aware; 10 days in case of death; 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. NIS2 (essential or important entity): early warning within 24 hours, incident notification within 72 hours, final report within one month of the incident notification.
Which authority receives a serious incident report under the AI Act?
The market surveillance authority of the Member State where the incident occurred (Article 73(1)). Each Member State designates its own authorities, and not all had done so by 6 October 2026; the Netherlands, for example, had not. The plan therefore leaves this contact for you to fill in per Member State.
Can I use this plan outside the Netherlands?
Yes. The GDPR and the AI Act apply directly in every Member State. NIS2 is a directive, so the CSIRT, the competent authority and the reporting route follow from your national implementing law. Dutch bodies such as the Autoriteit Persoonsgegevens and the Cyberbeveiligingswet appear as marked examples; replace them with your own.
May I adapt the template and share it within my organisation?
Yes. You may use, adapt and share this template freely, including within your organisation, provided the credit 'Source: Praxikon' with the link to this template stays in place.
Use and credit
You may use, adapt and share this template freely, including within your organisation, provided the credit 'Source: Praxikon' with the link to this template stays in place.
How to cite this template: Source: Praxikon, AI incident response plan template for data breaches and AI incidents, version 2.0, as of 6 October 2026, https://www.praxikon.com/en/templates/ai-incident-response-plan
This template is a tool, not legal advice for your situation. It reflects the law as of 6 October 2026. Legislation, guidance and supervisory practice may change after that date. Using this template does not guarantee compliance: applying it in your organisation remains your own responsibility.
Praxikon is a trade name of Embed AI · Chamber of Commerce 90283597