This is the AI incident response playbook your existing incident response plan does not have.

Your current playbook covers ransomware, BEC, and credential theft. It does not tell your on-call DPO how to handle a Tuesday morning Slack message: hey, did we ever get back to that customer about the audit?

That gap matters now.

Under GDPR Article 33, you have 72 hours to notify the supervisory authority after becoming aware of a personal data breach, unless it is unlikely to result in a risk to rights and freedoms. Under GDPR Article 34, you may also need to tell affected people if the breach is likely to result in a high risk. For NIS2 entities, Article 23 adds a different clock: early warning within 24 hours of awareness of a significant incident, then a fuller notification within 72 hours. In healthcare, HIPAA §164.404 sets individual notification duties, and HIPAA §164.410 requires a business associate to notify the covered entity without unreasonable delay and no later than 60 days.

Most incident response plans were built for endpoint and network events where detection is assumed. AI prompt incidents flip that. Detection is the hard part.

Once you know what was pasted, where it went, and whether the provider retained it, response becomes procedural.

The five-section playbook

Use this structure as a drop-in section inside your incident response plan.

| Section | Typical owner | Time budget | Output | |---|---|---:|---| | Triage | Security on-call | 0-4h | Initial incident record, scope hypothesis, owner assigned | | Evidence preservation | IT + Legal | 4-12h | Redacted evidence set, retention snapshot, awareness timestamp | | Classification | DPO + Legal | 12-24h | Breach determination, affected data categories, legal path | | Notification | DPO + Comms | 24-48h prep | Draft regulator and customer notices, approvals | | Remediation | Security + affected team | 48-72h start | Containment, control changes, user follow-up |

Keep the owners named. "Security" is too vague at 2:13 a.m. Put job titles or on-call roles in the actual document.

1. Triage 0-4 hours

Owner: Security on-call.

The first question is not whether the employee broke policy. It is whether sensitive data reached an external model, through which tool, and under what account.

Your triage checklist should answer four points fast:

If you can answer those, you can route the incident. If you cannot, the rest of the process stalls and your legal deadlines keep running anyway.

2. Evidence preservation 4-12 hours

Owner: IT + Legal.

This is where most teams fail. They either collect too little, or they grab raw prompts and create a second exposure. Preserve evidence in redacted form unless Legal specifically directs otherwise.

A practical AI-incident evidence set usually includes the following:

User ID (workspace), prompt timestamp, tool + account tier, redacted prompt content (NEVER raw), affected data subjects, vendor retention policy snapshot at time of incident

And you need the message or ticket that established awareness:

Slack/email thread where 'awareness' was established — this is when the 72-hour clock starts under Article 33

If your team wants a plain-language example of what "preserve evidence" means in this context, use this line in the playbook:

Capture the user account, browser session details, tool name, account tier, exact timestamp, redacted prompt text, and the provider retention setting or public policy visible at the time of the event.

Do not rely on memory. Do not ask the employee to paste the original prompt into a ticket. Do not wait for the vendor to answer before freezing what you already know.

!Prytive dashboard showing the evidence base — redacted prompts with timestamps and tool metadata — that an incident response playbook requires

That is what an operations artifact looks like: timestamps, tool metadata, redacted content, auditability. Your incident process needs that shape of evidence even if your current stack was built for laptops and mailboxes.

3. Classification 12-24 hours

Owner: DPO + Legal.

Now decide what this was.

Not every prompt incident is a reportable breach. Some are policy violations with no disclosure risk because the data never left a controlled tenant or was blocked before transmission. Some are near misses. Some are full breaches.

Classification should document:

Write the conclusion in one sentence. Example: "Employee pasted 43 customer records containing names, emails, and claim numbers into a consumer AI account; provider retention setting unknown at time of submission; likely personal data breach; regulator notice preparation required."

4. Notification 24-48 hours prep

Owner: DPO + Comms.

Prepare notices before you finish debating every edge case. Regulators do not grade on literary style. They care about timeliness, facts, impact, and what you are doing next.

For GDPR Article 33, draft the authority notification with the facts currently known, likely consequences, and measures taken or proposed. If the incident creates a high risk, prepare Article 34 data subject notice in parallel. For NIS2 Article 23, align your early warning and 72-hour reporting path with the relevant CSIRT or competent authority. For HIPAA events, map whether your duty sits under §164.404 or §164.410 and document the handoff.

If you want the detailed notification workflow, use the 72-hour AI incident response playbook as the deeper read.

5. Remediation 48-72 hours start

Owner: Security + affected team.

Start remediation before the paperwork is fully closed.

Typical actions:

Then run the post-incident review. Fix the control gap, not just the employee. If your only corrective action is another policy memo, you have chosen theatre over engineering.

Paste-ready playbook section

Use this text inside your IR plan.

AI Prompt Incident Procedure

  1. Triage — Security on-call — 0-4h

Confirm tool used, account tier, user identity, timestamp, suspected data classes, and awareness time. Open incident record and assign DPO and Legal.

  1. Evidence preservation — IT + Legal — 4-12h

Collect redacted prompt evidence, tool metadata, browser and account details, vendor retention policy snapshot, and the Slack or email thread that established awareness. Store no raw prompt text unless Legal directs.

  1. Classification — DPO + Legal — 12-24h

Determine whether this is a personal data breach, security incident, near miss, or policy violation. Assess GDPR Article 33, Article 34, NIS2 Article 23, and HIPAA §164.404 or §164.410 where relevant.

  1. Notification — DPO + Comms — 24-48h prep

Draft regulator, customer, partner, and internal notices. Prepare submissions based on currently known facts and update as evidence improves.

  1. Remediation — Security + affected team — 48-72h start

Contain the route of exposure, adjust controls, document user and team actions, and launch follow-up review.

Ready to paste into your plan

That is the missing section. Five parts. Named owners. Time budgets. No drama.

Most AI incidents are not hard because the response work is novel. They are hard because teams lack evidence at the browser layer where prompts are actually typed. Use Prytive as the evidence-collection layer your playbook assumes you have.