Gains:
- Ability to classify AI-specific incident types and design a response cycle
- Ability to define roles, authorities and legal reporting obligations before the event
- Ability to establish permanent improvement with business continuity and blame-free postmortem
No matter how well you defend it, one day something will go wrong: a key will leak, an injection will work, a provider will crash, or an output will harm a customer. What makes a mature institution mature is not the absence of events, but being prepared and fast when an event occurs. In this unit, we will learn an AI-specific incident response plan, roles, steps and business continuity.
Why Is Incident Response Different in AI?
In a classic security incident, "shut down the system, isolate" is often sufficient. There are additional dimensions to AI events: the event may not be in a code but in the behavior of the model (e.g. systematic incorrect/biased output); the proof is in the prompt/response logs; and "undo" is sometimes not possible because the erroneous output has already become a decision. Therefore, the AI incident plan should cover both classical security and model behavior.
Attention: At the time of the incident, a plan is not written, it is implemented. Who will call whom, who has the authority to "stop the system" and how communication will be done must be decided before the event.
AI Event Types
- Data leak: PII or confidential data leaked out (via prompt, log, or output).
- Security breach: Leaked key, successful injection, unauthorized access.
- Harmful/biased output: The model systematically produced an incorrect, discriminatory or dangerous response.
- Service outage: Provider crashed or hit speed-limit; The system cannot respond.
- Abuse: The system was used for a harmful purpose for which it was not designed.
Step by Step: Incident Response Cycle
- Detection. A monitoring alarm, user complaint, or audit finding reveals the incident.
- Sort and prioritize. Give levels based on impact and spread (e.g. P1 critical – P3 low).
- Contain. Stop the spread: revoke the key, turn off the feature, pull the system to read-only.
- Eradicate & recover. Fix root cause, return to safe state.
- Report it. Inform legal/contractual notification obligations (such as KVKK 72 hours) and those affected in a timely manner.
- Post-event examination (postmortem). Without placing blame, document the root cause and permanent fix.
Roles and Responsibilities
It should be clear who does what in an incident: incident commander (sole person making the decision), technical response (stopping/repairing the system), communications (customer/management/regulator), legal/compliance (obligation to report). In small teams, one person can take on several roles, but the roles must be written.
Four Copiable Templates
Event classification prompt:
Classify the following event: {{ event_description }}Identify:- Type: data leak / security breach / malicious output / outage / abuse- Impact: how many people/records, what data class, money/compliance consequences?- Propagation: stopped or ongoing?- Priority: P1 / P2 / P3 + justification- First control step: what should be done immediately?
First response (containment) checklist:
In the first 30 minutes when the incident is confirmed:- [ ] Disable the affected feature/tool or set it to read-only- [ ] Cancel suspicious keys/sessions- [ ] Preserve evidence (freeze relevant logs, record trace_id)- [ ] Notify incident commander and required roles- [ ] Deploy a temporary safe mode / backup flow
Notification draft prompt:
Write a draft internal notification for the following incident: {{ incident_summary }}Must include: what happened (in non-technical language), when it was noticed, what data/who was affected, what has been done so far, next steps, from whom additional information can be obtained. Do not include speculation or accusations.
Postmortem skeleton:
Post-event review (no blame):- Timeline: detection -> control -> recovery (minutely)- Root cause: technique + process size- What went well / what went badly- Permanent fixes (who, when)- Monitoring/control to catch this event sooner than later
Weak Prompt / Strong Prompt
poor approach
Strong approach
Impromptu at the event without a plan
Pre-written plan, roles and authorities
First say "who is guilty"
First containment, then postmortem without blame
Delay/skip notification
Notification within the legal period (e.g. 72 hours)
Waiting for the same event to happen again
Extracting permanent control from postmortem
Three Mini Cases
Case 1 — Caught within the 72 hour rule. An employee at one company noticed that 1,200 customer records were left exposed in a log due to misconfiguration. Thanks to the written plan, the incident commander was clear; The team closed the access in 40 minutes, and the law made the KVKK notification within 72 hours. Timely reporting significantly reduced criminal risk and reputational damage.
Case 2 — Read-only safe mode handled the outage. The main model provider went out for 3 hours. The firm's business continuity plan included switching to a backup provider and "safe mode" (critical functions only). Although users lost full functionality, the system survived; critical operations did not stop.
Case 3 — Postmortem prevented recurrence. A successful indirect injection leaked another user's data to an assistant. Non-blaming postmortem showed that the root cause was lack of <data> isolation. Added permanent fix (isolation + output scan + a regression test); The same class of attack was not successful again.
Tip: Conduct the postmortem without blame. The aim is not to find people, but to strengthen the system in a way that will not allow the same incident again. A culture of blame causes people to hide things, and this is the most dangerous.
Common mistakes
- Not preparing a written plan and role distribution before the event.
- Getting into an argument/blame before taking control.
- Missing legal notification obligations (KVKK/GDPR deadlines).
- Resetting the system without preserving evidence (logs).
- Not considering a backup provider/safe mode for business continuity.
- Not doing a postmortem and leaving room for the same event to be repeated.
In summary
- Maturity is not the absence of events; It means being prepared and fast when it happens.
- AI events can be in model behavior rather than code; the proof is in the prompt/response logs and reversal is not always possible.
- Response cycle: detect, classify, contain, recover, report, postmortem.
- Roles and authorities (incident commander, technical, communications, legal) should be in writing before the event.
- Backup provider/safe mode for business continuity; Blame-free postmortem and permanent correction are essential for the aftermath of the event.
Application task
Write a draft incident response plan for your own AI system: list the three most likely incident types, identify an initial 30-minute containment checklist and roles for each. Then do a tabletop exercise: Play out the “key leaked” scenario step by step and point out and correct any missing/ambiguous points in your plan.
checklist
- [ ] There is a written incident response plan and role distribution.
- [ ] It is clear who has the authority to "stop the system".
- [ ] The first 30 minutes containment checklist is ready.
- [ ] Legal notification periods and responsible person are defined.
- [ ] Backup provider/safe mode planned for business continuity.
- [ ] Blame-free postmortem and permanent correction are performed for each incident.