checklist
AI chatbot post-incident review template for small teams
A practical post-incident review template for a customer-facing AI chatbot, covering impact, evidence, data exposure, customer communication, corrective actions, restart decisions, and follow-up.
Use this template after a customer-facing AI chatbot incident, near miss, unsafe answer, data-boundary failure, outage, or unexplained tool action.
The purpose is to establish what happened, what customers or systems were affected, what evidence supports the current view, what remains unknown, and which controls must change. Complete it after containment, while logs, configuration versions, customer reports, and vendor evidence are still available. Run the AI Tool Risk Checker and attach the result to the review record.
Bottom line
A good post-incident review does not end with “the bot is working again.” It records the affected route and time window, separates facts from assumptions, checks data and tool-action impact, documents communications, assigns corrective actions, and makes a deliberate decision about restart scope and residual risk.
Use the Small Team AI Security Checklist for baseline ownership and incident routing. Pair this template with the AI chatbot outage recovery drill checklist for recovery testing and the AI chatbot incident communication template for message drafting.
When to use this template
| Event | Use this review? | Start with |
|---|---|---|
| Customer received an unsafe or materially wrong answer | Yes | Affected topic, sessions, source, and correction path. |
| Customer or internal data crossed an unapproved boundary | Yes, high priority | Containment, data scope, access, retention, and legal/privacy routing. |
| A connector or tool action was unauthorized, duplicated, or unexplained | Yes, high priority | Downstream state, retries, approvals, and customer impact. |
| Vendor or model outage interrupted customer support | Yes | Detection, fallback, recovery, and service-level impact. |
| A prompt injection or poisoned source changed behavior | Yes | Evidence preservation, source scope, permissions, and affected requests. |
| A test failed in a controlled drill with no customer impact | Use a lightweight version | Record the control gap and retest date. |
| A cosmetic copy change did not change behavior | Usually no | Normal change record unless the notice or fallback became inaccurate. |
Use protected incident storage for real customer records, credentials, tokens, and raw transcripts. This public template should contain only redacted facts, placeholders, and links to approved evidence locations.
Incident summary form
Complete this first. Keep it factual and time-bounded.
| Field | Entry |
|---|---|
| Incident ID | |
| Date and time detected | |
| Date and time contained | |
| Review owner | |
| Affected chatbot route | |
| Model, vendor, and configuration version | |
| Source and connector versions | |
| Incident type | Outage, unsafe answer, data boundary, action, injection, abuse, or other. |
| Customer channels affected | |
| Customer groups affected | |
| Current status | Contained, investigating, recovering, monitoring, or closed. |
| Fallback route | |
| Executive or business owner | |
| Security owner | |
| Privacy or legal owner | |
| Evidence location | |
| Next update time |
Do not use the summary to guess the root cause. Write “unknown” when the evidence is not yet sufficient.
Severity and impact matrix
Choose severity based on the highest credible impact, not only on the number of conversations.
| Finding | Possible impact | Initial severity | Required action |
|---|---|---|---|
| Wrong answer on a low-impact topic | Confusion or rework. | Low or Medium | Correct the source or instruction and sample affected answers. |
| Wrong answer on billing, access, safety, legal, or security topic | Customer harm, dispute, or unsafe decision. | High | Force human review, identify affected sessions, and assess notice. |
| Unapproved customer data in input, retrieval, output, or logs | Privacy, contractual, or security exposure. | High | Stop the route, preserve evidence, and escalate to security/privacy. |
| Unauthorized or duplicate action | Account, order, ticket, billing, or other system change. | High | Disable the action, reconcile state, and assess affected users. |
| Vendor outage with working fallback | Service interruption. | Medium | Keep fallback active, track duration, and verify recovery. |
| Prompt injection or source poisoning changed behavior | Data disclosure, policy bypass, or unsafe action. | High | Quarantine the source or route and preserve representative evidence. |
| Repeated high-severity findings or unknown scope | Potential systemic impact. | Critical | Keep the route paused or human-only until an accountable owner approves the next step. |
Record the reasoning, evidence, and approver for the selected severity. Do not downgrade because the incident was short or because a vendor later reports recovery.
Timeline and evidence log
| Time | Event or observation | Source of evidence | Confidence | Owner |
|---|---|---|---|---|
| Confirmed, likely, or unknown. | ||||
- Record the first signal, first customer report, and first internal escalation.
- Record pause, fallback, configuration, source, connector, and restart times separately.
- Preserve request IDs, timestamps, version identifiers, and relevant status events.
- Keep a copy or protected reference for vendor notices, support responses, and change records.
- Mark facts, assumptions, and open questions explicitly.
- Record who made each high-impact decision and when.
The FTC’s breach-response guidance says to document the investigation, identify the type and scope of information involved, preserve evidence, and avoid destroying material that may be needed for review. Apply the same discipline to chatbot incidents, even when the initial finding is a quality or availability issue rather than a confirmed breach.
Affected users and system scope
| Scope question | Result |
|---|---|
| Which chatbot route, channel, and customer segment were affected? | |
| What was the start and end of the credible impact window? | |
| How many requests were attempted, completed, retried, denied, or unknown? | |
| Which topics, sources, or workflows were involved? | |
| Did the issue affect internal users, customers, or both? | |
| Did the route use a connector or write action? | |
| Which model, prompt, retrieval, policy, or configuration version was active? | |
| Did the issue continue through a fallback or another channel? | |
| What remains outside the confirmed scope? |
- Search by route, channel, time window, request ID, and configuration version.
- Check failed, successful, retried, queued, and dead-letter requests.
- Review customer complaints, corrections, escalations, and support tickets separately from aggregate metrics.
- Identify a sample for manual review without copying raw customer content into this record.
- Record the limits of the search, including unavailable logs or retention gaps.
Data and privacy assessment
Inspect what actually moved through the route. Do not rely only on the intended schema.
| Data location | What to check | Finding |
|---|---|---|
| User input | Prohibited fields, identifiers, credentials, or sensitive topics. | |
| Retrieved context | Source permissions, cross-customer scope, and stale or poisoned content. | |
| Model or vendor request | Data classes, account, region, retention, and support access. | |
| Model output | Sensitive data, cross-user context, unsafe instructions, or misleading claims. | |
| Conversation logs | Access, retention, export, deletion, and redaction. | |
| Analytics and traces | Identifiers, payload fragments, and downstream access. | |
| Temporary files and queues | Copies, retries, dead letters, and deletion status. | |
| Human support tools | Context transferred to staff and least-necessary access. |
- State whether personal, financial, health, account, credential-like, or confidential business data was involved.
- State whether the data was observed in input, retrieval, output, logs, exports, or vendor support systems.
- Record the deletion, retention, access, and notification decision owners.
- Use legal or privacy advice for applicable notification duties; do not infer them from this template.
- Keep raw data and transcripts in approved protected storage, not in the public repository.
Answer and source review
Use a fixed sample so the review can distinguish a single correction from a broader behavior change.
| Sample | Expected behavior | Observed behavior | Source or instruction involved | Decision |
|---|---|---|---|---|
| Approved normal topic | ||||
| Expected no-answer case | ||||
| Sensitive-topic handoff | ||||
| Current policy or pricing | ||||
| Conflicting source | ||||
| Prompt injection attempt | ||||
| Multilingual or accessibility case |
- Compare the affected answer with the approved source and configuration version.
- Test whether a source correction fixes the issue without widening access or changing unrelated topics.
- Check whether a prompt, retrieval, model, safety, or routing change was deployed near the incident.
- Review refusal and human-handoff behavior, not only helpful answers.
- Preserve representative redacted inputs and outputs in protected evidence storage.
If the answer was wrong but no customer was harmed, record it as a near miss rather than deleting it from the incident history. Near misses are useful evidence for future tests and monitoring.
Connector and tool-action review
| Action state | Questions | Result |
|---|---|---|
| Read access | Was the source and permission approved for this route? | |
| Write attempt | Who or what approved the action? | |
| Denied action | Did the denial fail safely and reach a human if needed? | |
| Retry or queue | Could the action have been duplicated after the incident? | |
| Completed action | What record changed and what customer saw it? | |
| Unknown state | Can the team prove whether a side effect occurred? | |
| Correction or reversal | Was the correction authorized and complete? | |
| Old route | Did a retired identity, queue, or webhook continue to create events? |
- Disable the affected action until permissions and side effects are understood.
- Reconcile downstream records, queues, retries, webhooks, and service identities.
- Check idempotency keys and duplicate handling.
- Record every action that was blocked, completed, duplicated, reversed, or unknown.
- Require explicit approval before restoring a high-impact action.
OWASP’s LLM risk materials describe excessive agency as a combination of excessive functionality, permissions, or autonomy. Treat an unexplained tool action as a security and integrity finding, not only as an integration bug.
Customer and stakeholder communication review
| Audience | What they needed to know | Message owner | Sent or updated |
|---|---|---|---|
| Customers | Impact, available help, and next update. | ||
| Support team | Route state, fallback, and approved answer. | ||
| Product and engineering | Scope, containment, fix, and restart gate. | ||
| Security and privacy | Data, access, evidence, and risk decision. | ||
| Vendor or provider | Request for status, logs, fix, and prevention. | ||
| Leadership or approver | Severity, residual risk, and decision needed. |
- State what is confirmed, what is not yet known, and what the team is doing.
- Do not say that no data was affected unless the review supports that statement.
- Give customers a working human or non-AI route.
- Avoid exposing internal implementation details, credentials, or unverified vendor claims.
- Record the message version, approver, audience, and time.
- Plan an update when the scope, fix, or customer action changes.
The FTC advises businesses to communicate with affected audiences using clear information about what happened, what was done, and what people can do next, while avoiding misleading statements or details that create further risk.
Root cause and contributing factors
Do not stop at the first visible failure. Separate the direct trigger from the conditions that allowed it to affect customers.
| Question | Finding |
|---|---|
| What was the direct trigger? | |
| Which control should have prevented or detected it? | |
| Was the control missing, misconfigured, bypassed, or not monitored? | |
| Did a vendor, model, source, connector, prompt, or policy change contribute? | |
| Did staffing, ownership, training, or support capacity contribute? | |
| Did retention, logging, or access gaps delay the response? | |
| Why did the issue reach a customer or downstream system? | |
| What evidence would disprove the current hypothesis? |
Use a causal chain such as trigger, enabling condition, missed signal, customer impact, and recovery gap. Avoid assigning blame to a model when the operational control around it is the part that failed.
Corrective action plan
| Action | Type | Severity | Owner | Due date | Verification |
|---|---|---|---|---|---|
| Containment, fix, monitoring, process, or training. | |||||
- Fix the affected route, source, prompt, permission, connector, or vendor configuration.
- Add a regression test for the incident and a nearby failure mode.
- Add an alert or manual review for the signal that was missed.
- Update the pause, fallback, communication, or recovery plan.
- Review access, retention, and data minimization controls.
- Schedule a retest with a named owner and evidence requirement.
Each action needs a verification method. “Monitor more closely” is not a complete action until the team names the signal, owner, threshold, review time, and response.
Restart and residual risk decision
| Gate | Pass condition | Result |
|---|---|---|
| Containment | The affected route, source, or action is controlled. | |
| Scope | The credible impact window and affected users are understood. | |
| Data review | Data path, access, retention, and deletion decisions are recorded. | |
| Action review | External side effects are reconciled or the action remains disabled. | |
| Fix verification | The corrective change passes fixed and adversarial tests. | |
| Customer route | Notice, support, and fallback wording match the actual state. | |
| Monitoring | Owners, thresholds, and escalation paths are active. | |
| Approval | A named owner accepts the residual risk and restart scope. |
| Decision | Use when |
|---|---|
| Keep paused | Scope, evidence, customer impact, or action state remains unknown. |
| Human-only | The bot cannot safely handle the affected topic or route. |
| Limited restart | The fix is verified for a narrow topic, channel, or read-only scope. |
| Full restart | All material gates pass and residual risk is explicitly accepted. |
| Retire or replace | The system repeatedly exceeds risk tolerance or cannot be made reconstructable. |
Do not restart because the vendor reports that service is healthy. Restart only after the local route, data, actions, customers, and controls are verified.
Post-incident review record
| Field | Entry |
|---|---|
| Final incident classification | |
| Confirmed impact | |
| Unconfirmed or unknown impact | |
| Customer communication decision | |
| Privacy, legal, or contractual review | |
| Root cause summary | |
| Corrective action summary | |
| Restart or retirement decision | |
| Residual risk owner | |
| Evidence retained | |
| Evidence deleted and date | |
| Lessons shared with team | |
| Next review date |
Keep this record with the timeline, approved configuration versions, test results, vendor correspondence, and action verification. Keep raw customer data in the protected system defined by the incident process.
Seven-day and 30-day follow-up
| Follow-up window | Review |
|---|---|
| Within 24 hours | Confirm containment, customer support, evidence preservation, and critical actions. |
| Within 7 days | Re-run fixed tests, inspect trends, verify corrective actions, and review the fallback load. |
| Within 30 days | Review monitoring effectiveness, access and retention controls, vendor changes, training, and residual risk. |
- Re-test the original failure and one adjacent failure mode.
- Check whether customer complaints or corrections continued after the fix.
- Review model, vendor, prompt, source, connector, and policy changes since the incident.
- Close an action only when the verification evidence is stored and reviewable.
- Update the incident or recovery plan when the operating assumptions changed.
Metrics to track
Track a small repeatable set across incidents and near misses.
- Time from first signal to pause and to safe fallback.
- Number of affected requests, users, topics, channels, and downstream systems.
- Number of data-boundary observations, unknown records, or retention gaps.
- Number of unauthorized, duplicate, delayed, or unexplained tool actions.
- Time to identify root cause and deploy a verified fix.
- Fixed test pass rate before restart and at seven-day review.
- Time to first internal update and customer update when required.
- Number of corrective actions overdue or reopened.
- Number of incidents or near misses by failure class.
Evidence checked
- NIST AI RMF Core includes outcomes for post-deployment monitoring, incident response, recovery, change management, communication, and safe deactivation.
- NIST AI RMF Manage Playbook recommends documenting incident and error response, maintaining reported-error records, tracking system changes, and verifying contingency processes.
- NIST AI RMF Playbook provides voluntary, adaptable actions and documentation practices for managing AI risk.
- FTC Data Breach Response: A Guide for Business covers securing operations, preserving evidence, determining scope, documenting the investigation, and communicating with affected audiences.
- FTC Cybersecurity for Small Business covers incident response, recovery, business continuity, backups, vendor controls, and need-to-know access.
- CISA and UK NCSC Guidelines for Secure AI System Development emphasizes ownership of security outcomes and secure-by-design practices across development, deployment, and operation.
- OWASP Top 10 for LLM Applications provides current risk categories for prompt injection, sensitive information disclosure, supply chain, excessive agency, misinformation, and unbounded consumption.
FAQ
Is a post-incident review only for data breaches?
No. Use it for unsafe answers, service outages, prompt injection, source poisoning, unexplained tool actions, material near misses, and data-boundary failures. The depth should follow customer impact and residual risk.
Should the review name the model as the root cause?
Only when evidence supports that conclusion. Review the surrounding prompt, source, routing, permissions, monitoring, fallback, staffing, and vendor controls. A model output is often the visible symptom of a wider system condition.
What evidence should a small team keep?
Keep timestamps, request identifiers, configuration and source versions, protected samples, action and queue state, vendor responses, decisions, messages, and corrective-action verification. Avoid retaining more customer data than the incident process requires.
When should customers be notified?
Use the applicable legal, contractual, privacy, and customer-impact process. This template does not decide notification duties. A review should record the decision owner, supporting facts, message, audience, and next update.
Can we close the incident when the chatbot is back online?
No. Close it only when impact and unknowns are reviewed, customer communication is handled, corrective actions have owners and due dates, restart scope is approved, and verification evidence is stored.
How do we review a near miss without overloading the team?
Use the summary, severity matrix, timeline, affected scope, action plan, and restart decision. Record the missing control and one regression test. Escalate to the full template when data, customers, high-impact actions, or repeated failures are involved.