Definition: An AI incident response playbook is a written plan, agreed in advance, for security incidents and faults in AI systems. For each type of incident, it sets out who does what and in which order. It names the technical levers you can pull to contain the damage. It also lists the reporting duties you must check. The playbook adds AI-specific cases to your general incident response plan.
Why AI needs its own playbook
Classic emergency plans deal with hacked accounts, malware or failed servers. AI incidents often look different. The system runs fine from a technical view, but it gives harmful, wrong or confidential output. Some examples:
- A chatbot reveals internal price lists after someone feeds it a crafted input.
- An AI agent sends emails that nobody asked for.
- A vendor updates its model, and a classifier quietly starts to behave differently.
Without set procedures, the team loses precious time arguing whether this even counts as a security incident.
Typical incident categories
| Scenario | First steps |
|---|---|
| Prompt injection leading to data leakage | Cut off the affected feature or data source, secure the logs, find out which data leaked |
| Agent performs unwanted actions (excessive agency) | Revoke tool rights, stop pending actions, undo the effects |
| Tampered knowledge base (RAG) or data poisoning | Move suspicious documents to quarantine, roll back to the last checked index |
| Compromised API keys for AI services | Revoke the keys, check usage and costs, document the misuse |
| Harmful or discriminatory output | Limit the feature, add human review, find the root cause |
| Deepfake fraud attempt against the company | Stop payments, call back on a known channel, secure the evidence |
Structuring the playbook around incident phases
1. Preparation
- Keep the AI inventory close at hand, with system owners, vendor contacts and dependencies.
- Set up technical kill switches: feature flags to turn off single functions, a way to revoke API keys, and a fallback to manual work.
- Set up prompt, response and tool logs so they are detailed enough for analysis and kept long enough.
- Keep versioned copies of models, system prompts and vector indexes so you can roll back.
2. Detection and assessment
Define what sets off the playbook. This can be user reports, monitoring alerts, odd costs or notices from the vendor. Set criteria for how severe an incident is. Look at the data involved, the effect outside the company, the number of people affected and whether the system can take actions.
3. Containment
The goal is to stop the damage without destroying evidence. Often it is enough to turn off single tools or data sources. You rarely need to shut down the whole system. Secure the current state before every change.
4. Eradication and recovery
Fix the root cause. For example, tighten input filters and rights, remove tampered documents or restore a checked model. Before you go live again, test against the original attack patterns. Then turn functions back on step by step.
5. Post-incident review
Write down the lessons learned. Update the risk assessment and the playbook. Adjust training where needed.
Checking reporting obligations
- GDPR: For a personal data breach, tell the supervisory authority within 72 hours (Art. 33). Where required, also tell the people affected (Art. 34).
- NIS2/BSIG: For organisations in scope, significant incidents need an early warning within 24 hours. A notice follows within 72 hours, and a final report after one month.
- EU AI Act: Providers of high-risk AI systems must report serious incidents to the market surveillance authority (Art. 73). Deployers tell the provider in such cases. These duties apply once the high-risk rules take effect. After the Digital Omnibus, that is from 2 December 2027 (Annex III) or 2 August 2028 (Annex I).
- Contracts and insurance: Keep in mind your duties to inform customers and cyber insurers.
Practical tips
- Keep the playbook short: one page per scenario with a checklist and contacts.
- Name a deputy for every role, so holidays or illness do not hold up the response.
- Run a tabletop exercise with a realistic AI scenario at least once a year.
- Bring in the AI vendor. Agree in the contract how fast they will help you during an incident and which logs they can provide.
Conclusion
With an AI incident response playbook, your team does not have to make things up when an AI incident hits. It has clear scenarios, kill switches ready to go and checked reporting paths. SecTepe helps you create and practise such playbooks. We also provide incident response when it counts.
Frequently asked questions
Do we need a separate document or an addition to our existing plan?
An addition is usually enough. Your current incident response process stays the framework. The AI playbook adds steps for each scenario and the technical levers.
Who should be on the AI incident team?
Besides IT security, you need at least:
- the business owner of the system
- data protection
- communications, if there is an effect outside the company
- legal, where needed
- the AI vendor
More terms in “AI & Machine Learning”
- Adversarial Machine Learning
- AI Backup and Model Recovery
- AI Certification
- AI Data Protection Impact Assessment (AI DPIA)
- AI Forensics
- AI Governance for Managing Directors
- AI Governance Framework
- AI Monitoring and Anomaly Detection
- AI Penetration Testing
- AI Phishing Detection
- AI Poisoning
- AI Red Teaming