AI Incident Response Plan Generator

The first hour

1. 1Stop, and rotate anything exposed

   • Whoever noticed stops immediately. Do not send the next message, continue the conversation, or quietly fix the output and carry on.
   • If a password, API key, or access token was exposed, rotate it now — before anything else on this list. An exposed key is actively exploitable in a way a leaked draft is not.
   • Do not delete the conversation yet if you still need to read what was in it.

2. 2Establish exactly what was involved

   • Which tool, which account, and which tier (a company account and a personal one have different terms).
   • What exactly went in — how many records, whose, containing which fields. “Some customer data” is not something you can act on.
   • What came out, where it went, and who has seen it.
   • When it happened, and whether the history still exists.
   • Deleting the conversation is not containment. Vendor retention terms usually mean a server-side copy persists regardless of what your interface shows — delete it to limit who can see it, but record what was exposed rather than treating deletion as resolution.

3. 3Write it down before the details fade

   • Record the log fields below the same day. Specifics degrade fast — a log written a week later is a guess.
   • Record who was involved as a fact, not a fault. The wording matters: this log gets re-read later by people who were not there.

4. 4Escalate outward, if the band says so

   • Tell the owner or a founder, at the speed the severity band requires. One named person owns the incident until it is closed.

5. 5Do not open with blame

   • Resist establishing fault in the first hour. Contain first.
   • Someone who expects consequences for reporting will report the next one later, or route around the process entirely — and the incident you hear about in ten minutes is far cheaper than the one found in a quarterly review.
   • If there is a genuine pattern of ignoring clear rules, that is a separate conversation, held later, as a performance matter.

Who gets told (3)

• First, always: the owner or a founder. Every incident, including Low ones, at Low's slower pace.
• Whoever else uses the same tool and account — if a setting caused this, they are exposed to it too until it is changed.
• The vendor — if the exposure is on their side, or you need to know their retention terms to establish what still exists.

What gets logged (6)

• 1Date and time (of the incident, and of when it was noticed — they are rarely the same)
• 2Who was involved, recorded as a fact and not a fault
• 3Which tool and which account
• 4What data or output was involved, specifically
• 5What was done in response, in order
• 6Whether anyone outside the business was affected

What counts as an incident (4)

• Sensitive data was entered into an AI tool. Someone pasted more into ChatGPT than they should have — a customer record, a contract, a spreadsheet extract.
• Wrong output was acted on. AI-generated text with an invented figure, date, or citation was sent to a customer, published, or used in a decision.
• An unapproved tool was used for work. Business information went into a tool nobody reviewed, so its retention and training terms are unknown.
• An account or setting was misconfigured. A personal account used for work, history visible to the wrong people in a shared workspace, or training-on-your-data left enabled.

The review, within a week (5)

• Was there a rule covering this? If not, that is the finding — write one. If there was, the next question matters more.
• Why did the rule not prevent it? Usually one of three: nobody knew it existed, it was ambiguous in this case, or following it would have blocked real work with no approved alternative. The third is the most common and the most fixable — people route around rules that leave them no way to do their job.
• Was the tool the problem, or the use? A tool with acceptable terms used for the wrong data is a use problem. A tool with unknown terms is an approval problem.
• What one change makes recurrence less likely? One. A review producing twelve action items produces zero completed action items.
• Has this happened before? Three incidents of the same type is not three accidents, it is a process gap. Read the log periodically, not just after each incident.