AI Incident Response Plan Generator

AI Incident Response Plan — Fictional Cedar Studio

A one-page procedure for the first hour after an AI mistake. Keep it somewhere findable without logging into anything.

Scope

• Team size: 2–10 people
• Incident owner: Duty lead — the owner or a founder
• Approved tools: ChatGPT
• Information in scope: Customer personal information (names, emails, accounts)
• Professional advice available: We could find someone, but nobody is lined up
• Customer notification preference: Take advice first, then notify promptly

What counts as an incident

1. 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.

2. 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.

3. An unapproved tool was used for work. Business information went into a tool nobody reviewed, so its retention and training terms are unknown.

4. 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.

Severity

• Low. Internal, non-sensitive information. Nothing left the business and no decision was made on bad output.

- Response: Log it and correct the habit. No escalation — a plan that escalates everything gets ignored within a month.

• Medium. A bad output was caught before it reached anyone outside, or an unapproved tool was used for real work.

- Response: Tell Duty lead — the owner or a founder the same day. Log it, and fix the cause rather than the instance.

• High. Any incident involving customer personal information (names, emails, accounts) — or wrong output that reached a customer.

- Response: Tell Duty lead — the owner or a founder immediately, not at the end of the day. Establish exactly what was involved before deciding anything, then take advice on whether anyone outside must be told.

• Critical. Passwords, API keys, or access tokens were exposed, or a significant volume of personal records was. This is a security incident that happens to involve AI.

- Response: Rotate the exposed credentials first — before logging, before telling anyone. Then tell Duty lead — the owner or a founder and work through the rest of this plan.

The first hour

1. Stop, 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. Establish 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.
• Whether customer personal information (names, emails, accounts) was involved — this is the fact that decides whether the next step is internal or external.
• 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. Write 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. Escalate outward, if the band says so

• Tell Duty lead — the owner or a founder, at the speed the severity band requires. One named person owns the incident until it is closed.
• For High or Critical, find a qualified professional today. Whether notification is required is not a determination to reason through internally — and the time spent finding someone counts against the timeline.

5. Do 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

• First, always: Duty lead — 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.
• A qualified professional — for any High or Critical incident. Nobody is lined up, so identify one now: mid-incident is the worst possible time to be choosing an advisor.
• Affected customers — timing and wording on advice, per the preference recorded below. Do not send anything before the facts from step 2 are settled.
• 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

1. Date and time (of the incident, and of when it was noticed — they are rarely the same)

2. Who was involved, recorded as a fact and not a fault

3. Which tool and which account

4. What data or output was involved, specifically

5. What was done in response, in order

6. Whether anyone outside the business was affected

7. Which categories of personal or regulated information were involved, and roughly how many records

8. Who was consulted about notification, when, and what they advised — including a decision not to notify, which needs a recorded reason more than a decision to notify does

The review, within a week

• 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.

Gaps to close before you need this

• No advisor identified, with customer personal information (names, emails, accounts) in scope. Whether an incident must be reported, and how quickly, is not a determination to make internally. Find someone now and put their details in this plan — the search itself consumes time you will not have.

Plan details

• Owner of this plan: Duty lead
• Advisor to call (name, number): ______________
• Where the incident log lives: ______________
• Last reviewed: ______________
• Next review due: ______________ (annually, or after any High or Critical incident)

This plan provides practical operational guidance for responding to AI incidents. It is not legal advice and does not guarantee regulatory compliance. Breach notification requirements vary by jurisdiction, industry, and what was exposed — have a qualified professional confirm what applies to your business, ideally before you need it.