checklist
AI chatbot outage recovery drill checklist for small teams
A practical recovery exercise for a customer-facing AI chatbot, covering pause, fallback, data boundaries, connector shutdown, customer notice, restore, verification, and lessons learned.
Use this checklist to run a controlled recovery drill for a customer-facing AI chatbot before an outage or unsafe behavior becomes a customer incident.
The exercise should test more than whether the vendor is reachable. It should prove that the team can pause the affected route, move customers to a safe fallback, stop or reconcile tool actions, protect transcripts and customer data, communicate what is known, restore the approved scope, and record evidence. Run the AI Tool Risk Checker before the drill and attach the result to the exercise record.
Bottom line
Small teams should be able to answer four questions during a chatbot disruption: who can pause it, what customers see next, what happens to in-flight data and actions, and what evidence is required before restart. Treat an AI chatbot recovery drill as an operational test of the complete route, not just a model uptime test.
Use the Small Team AI Security Checklist for baseline ownership and incident routing. Pair this page with the AI chatbot pause and fallback plan template for the standing fallback plan and the AI chatbot post-cutover review checklist for the first-week review after a change.
When to use this checklist
| Situation | Run a recovery drill? | Minimum scope |
|---|---|---|
| New customer-facing chatbot is about to launch | Yes | Pause, human fallback, data boundary, and restore gate. |
| Vendor, model, orchestration layer, or connector changed | Yes | Re-test every changed boundary and any customer-impacting action. |
| The chatbot is read-only and has a documented fallback | Yes | Test vendor outage, bad answer, and customer notice. |
| The chatbot can change accounts, orders, tickets, or billing | Yes, high priority | Include action denial, duplicate prevention, reconciliation, and approval evidence. |
| A real outage or unsafe answer already occurred | Yes, after containment | Use protected incident evidence and do not rehearse with live customer data. |
| Only a cosmetic copy change was made | Usually no | Use normal change review unless routing or behavior changed. |
Run the drill in a controlled window. Use synthetic records, test accounts, redacted transcripts, and clearly marked exercise messages. Never paste production credentials, access tokens, or unredacted customer records into the drill notes.
Recovery drill scope matrix
| Scenario | Inject | Expected control | Stop the drill when |
|---|---|---|---|
| Vendor outage | The model or provider returns errors or times out. | Pause the route and show the approved fallback. | Requests continue without a known status or owner. |
| Unsafe answer | The bot gives an incorrect answer on a sensitive topic. | Remove or limit the affected topic and route to a human. | The team cannot identify impacted sessions or the correction owner. |
| Data boundary failure | A test prompt includes a prohibited data field. | Reject, redact, or route the request without retaining the field unnecessarily. | The field reaches an unapproved model, connector, log, or export. |
| Tool action problem | An action is denied, duplicated, delayed, or applied to the wrong test record. | Block further actions and reconcile state. | The team cannot prove whether a side effect occurred. |
| Source or prompt poisoning | A test source or instruction attempts to change policy. | Quarantine the source and preserve the evidence. | The route continues to trust the changed source. |
| Abuse spike | Oversized, automated, or manipulative traffic increases load. | Rate-limit, narrow scope, or move to a human route. | The team cannot protect availability or observe the load. |
Choose at least one scenario from service availability, safety or quality, data protection, and tool action integrity. A quiet vendor outage drill is not enough to prove safe recovery from a bad answer or unauthorized action.
Drill intake form
Copy this into the exercise record.
| Field | Entry |
|---|---|
| Exercise date and window | |
| Exercise owner | |
| Customer-facing route | |
| Systems and vendors in scope | |
| Scenario selected | |
| Synthetic accounts and data set | |
| Pause authority | |
| Fallback owner | |
| Security and privacy owner | |
| Customer communications owner | |
| Connector and action owner | |
| Recovery target | |
| Rollback or restart approver | |
| Evidence location | |
| Exercise success criteria |
If pause authority, fallback ownership, or restart approval is unclear, resolve that gap before introducing the failure scenario.
Recovery objectives table
Set the objectives before the exercise starts. Do not change the target after seeing the result.
| Objective | Target | Observed | Pass condition |
|---|---|---|---|
| Detect the failure | An owner sees or receives the signal within the agreed window. | ||
| Pause new chatbot traffic | New requests stop or are clearly routed to the fallback. | ||
| Confirm in-flight state | The team can identify pending, failed, retried, and completed requests. | ||
| Protect customer data | Exercise data remains within approved systems and retention rules. | ||
| Stop tool actions | High-impact actions require an explicit approval or are disabled. | ||
| Notify internal owners | Support, product, engineering, security, and privacy receive the agreed update. | ||
| Show the fallback | Customers get a usable human or non-AI route with accurate wording. | ||
| Restore limited service | Restart begins at the approved scope, not the largest scope. | ||
| Verify recovery | Fixed tests, logs, actions, and customer routes pass before expansion. | ||
| Record lessons learned | Findings have an owner, severity, and retest date. |
Use separate objectives for recovery time, data recovery, customer wait time, and action reconciliation. A fast restart is not a pass if the team cannot explain what happened to customer data or side effects.
First 15 minutes runbook
Follow this order during the exercise and record the time for each action.
- Announce the exercise and mark all messages and records as test data.
- Confirm the scenario, affected route, and exercise owner.
- Capture the first error, unsafe answer, data-boundary finding, or action event without adding secrets to the record.
- Pause new AI traffic or narrow it to the approved safe scope.
- Disable high-impact tools and connectors when their state is uncertain.
- Preserve request IDs, timestamps, configuration version, source version, and vendor status without storing sensitive payloads unnecessarily.
- Check whether requests are queued, retried, duplicated, or still visible to customers.
- Activate the approved human or non-AI fallback.
- Send the internal status update to named owners.
- Decide whether customer notice is needed for the scenario and message impact.
- Record the first containment decision and its approver.
Do not troubleshoot by repeatedly sending real customer content to a failing or unsafe route. Use synthetic probes and protected evidence instead.
Pause and fallback controls
| Control | Expected behavior | Evidence to capture |
|---|---|---|
| Route pause | New requests are blocked, diverted, or limited as documented. | Timestamp, owner, route state, and test result. |
| Human handoff | A customer can reach a person without a loop. | Test request, queue owner, and response target. |
| Sensitive topic routing | Privacy, security, billing, access, legal, health, and safety topics avoid unsafe automation. | Test cases and routing result. |
| Customer wording | Notice and fallback language match the actual state. | Approved message version and display location. |
| Connector shutdown | Unknown or high-impact actions are disabled before recovery work. | Permission state and action test. |
| Support visibility | Support can see the route state and tell customers what to expect. | Screenshot or protected run record. |
| Manual alternative | The team can complete the critical customer task without the bot. | Successful test transaction or workflow result. |
- Confirm that the fallback does not expose internal error details, vendor credentials, or private implementation notes.
- Confirm that support can distinguish an exercise from a real customer incident.
- Test a request that should be refused and a request that should reach a human.
- Confirm that the fallback owner has enough context to help without receiving unnecessary sensitive data.
Data and transcript handling
Review the data path before restore, not only after an incident is declared.
| Review item | Question | Result |
|---|---|---|
| Input payload | Did the exercise send only approved synthetic or redacted fields? | |
| Model and vendor | Which system received the request and under what configuration? | |
| Retrieval context | Did the route read only approved sources and access scopes? | |
| Logs and traces | What identifiers were retained, and for how long? | |
| Exports and tickets | Did any transcript or error payload leave the approved boundary? | |
| Support view | Did human operators see only the context they needed? | |
| Deletion | Can exercise records and temporary files be removed on schedule? | |
| Customer request path | Could a deletion, export, correction, or opt-out request still be handled? |
- Record the data classes in scope and the approved retention period.
- Check temporary files, queues, dead-letter messages, and vendor support exports.
- Verify that redaction and deletion work on the fallback and restored routes.
- Escalate any unapproved data observation as a control finding even if the drill used synthetic data.
The FTC’s small-business guidance recommends incident response, disaster recovery, business continuity, backups, and explicit vendor controls. Use the drill to verify the parts that affect the chatbot route rather than treating a vendor status page as the recovery plan.
Connector and action reconciliation
If the chatbot can read or change an external system, recovery is incomplete until the team can reconcile the action state.
| Action state | Required question | Safe response |
|---|---|---|
| Not attempted | Did the pause prevent the call? | Keep blocked and record the denial. |
| Accepted but not completed | Did the provider queue or retry it? | Hold, inspect, and require approval before replay. |
| Completed once | What record changed and who approved it? | Verify the expected state and preserve evidence. |
| Completed more than once | What duplicate side effect occurred? | Stop retries, reconcile the record, and escalate impact. |
| Unknown | Can the team prove whether a side effect occurred? | Keep the action disabled until state is known. |
| Reversed or corrected | Was the correction authorized and safe? | Confirm the final state and customer communication. |
- Disable actions whose permission or state cannot be explained.
- Check idempotency keys, queue state, retries, webhooks, and service identities.
- Review one safe denial and one approved test action.
- Confirm that a restored route cannot replay stale requests without a new approval.
OWASP identifies excessive agency as a risk when an AI system has excessive functionality, permissions, or autonomy. Keep recovery actions narrow, approval-based, and reversible wherever possible.
Customer and team communication
| Audience | Message purpose | Owner | Send when |
|---|---|---|---|
| Support team | Explain the route state, fallback, and approved wording. | ||
| Product and engineering | Explain the technical boundary and next decision. | ||
| Security and privacy | Explain data, access, and incident implications. | ||
| Vendor or provider | Request status, evidence, and recovery actions. | ||
| Affected customers | Explain impact, available help, and next update. | ||
| Leadership or approver | Request pause, scope, or restart decision. |
- Use a plain statement of what is known, unknown, and being done.
- Do not claim that no data was affected until the review supports that statement.
- Give customers a working route to a person or a non-AI alternative.
- Keep internal technical details and credentials out of customer messages.
- Record the message version, approver, audience, and time.
Restore and verification gates
Restore the smallest approved scope first. Require a recorded result at every gate.
| Gate | Pass condition | Decision owner |
|---|---|---|
| Cause or boundary understood | The team can state the scenario, affected component, and current uncertainty. | |
| Pause remains effective | The unsafe or unavailable path cannot receive new unapproved traffic. | |
| Data state reviewed | Logs, queues, transcripts, and temporary files are within the approved boundary. | |
| Action state reconciled | All external side effects are known, blocked, corrected, or escalated. | |
| Fixed test set passes | Normal, refusal, sensitive-topic, handoff, and abuse probes pass. | |
| Fallback is ready | Customers have a working route and support has the current wording. | |
| Monitoring is active | Owners can see errors, latency, customer impact, and vendor events. | |
| Restart approved | A named owner accepts the residual risk and approved scope. |
- Restart read-only or low-impact routes before write actions.
- Keep affected topics, connectors, and channels limited until the evidence supports expansion.
- Run the same fixed tests after each material configuration change.
- Schedule a post-recovery review and a retest of every open finding.
Decision rules
| Finding | Decision |
|---|---|
| Provider unavailable but fallback works and no action state is uncertain | Keep the route paused and use the fallback until service is verified. |
| Unsafe answer affects a sensitive topic | Keep that topic in human-only mode and correct the source, prompt, or policy before retest. |
| Unapproved data reaches a model, connector, log, or export | Pause the route and escalate to security/privacy for impact review. |
| Tool action is duplicated or not reconstructable | Disable the action, reconcile downstream state, and do not restore it on schedule alone. |
| Monitoring or alert ownership is missing | Keep limited or paused until an owner and threshold exist. |
| Fixed tests pass but customer fallback is overloaded | Reduce automation or traffic until the support capacity is ready. |
| Evidence is incomplete but no failure is observed | Keep limited and close the evidence gap before expansion. |
| All gates pass and residual risk is accepted | Restore the smallest approved scope and move to post-recovery monitoring. |
Do not turn a green vendor status page or a successful health check into a restart approval. Recovery is a risk decision supported by evidence.
Recovery drill record
| Field | Entry |
|---|---|
| Scenario and exercise window | |
| Systems and versions | |
| Initial signal | |
| Pause time and approver | |
| Fallback time and owner | |
| Data review result | |
| Connector and action result | |
| Customer impact result | |
| Fixed test result | |
| Open findings | |
| Restore decision and approver | |
| Residual risk accepted | |
| Next review date |
Store the record with the approved runbook, test cases, configuration version, and protected evidence. Do not commit customer exports, API keys, tokens, or private transcripts to the public repository.
Next drill action tracker
| Finding or improvement | Severity | Owner | Due date | Retest evidence |
|---|---|---|---|---|
- Assign an owner to every failed objective.
- Separate a control fix from a content correction and a staffing issue.
- Set a retest date before closing the exercise.
- Update the standing pause, fallback, or incident plan when the drill exposes a gap.
Final recovery checklist
- The scenario and success criteria were agreed before the exercise.
- The team paused the affected route without using production secrets.
- A human or non-AI fallback served a representative customer request.
- Sensitive topics and refusal behavior were tested.
- Data, logs, queues, temporary files, and vendor access were reviewed.
- Connectors, actions, retries, webhooks, and service identities were reconciled.
- Customer and internal messages used approved wording and owners.
- The fixed test set passed after containment and before restart.
- Monitoring thresholds and owner assignments were active.
- Restart scope and residual risk were approved and recorded.
- Findings have owners, due dates, and retest evidence.
Metrics to track
Track a small set of repeatable measures across drills and real incidents.
- Time to detect and time to pause the affected route.
- Percentage of test requests that reached the approved fallback.
- Time to establish whether queued or retried actions had side effects.
- Number of unapproved data observations or boundary failures.
- Number of duplicate, unauthorized, or unexplained tool actions.
- Time to deliver the first internal status update and customer notice when needed.
- Fixed test pass rate before and after restore.
- Number of findings reopened after retest.
- Fallback wait time and support capacity during the exercise.
Evidence checked
- NIST AI RMF Core describes contingency processes for high-risk third-party AI failures and post-deployment monitoring that includes incident response, recovery, appeal, override, decommissioning, and change management.
- NIST AI RMF Playbook provides suggested actions for risk response and recovery; it is voluntary and should be adapted to the team’s context.
- NIST guidance on monitoring deployed AI systems explains why variable and unforeseen behavior makes post-deployment monitoring important.
- CISA and UK NCSC Guidelines for Secure AI System Development emphasizes secure-by-design ownership across development, deployment, and operation.
- FTC Cybersecurity for Small Business covers incident response, disaster recovery, business continuity, backups, vendor controls, and need-to-know access.
- OWASP LLM06:2025 Excessive Agency explains how excessive functionality, permissions, or autonomy can affect confidentiality, integrity, and availability.
FAQ
Is a vendor outage test enough?
No. It tests availability, but not unsafe answers, data boundaries, customer handoff, connector state, duplicate actions, abuse traffic, or restart approval. Use at least one scenario from each material risk area.
Should we run the drill with production conversations?
No. Use synthetic accounts and redacted test cases. Production evidence may be preserved through the protected incident process when required, but it should not be copied into a public article, repository, or casual chat.
When should the chatbot be restored?
Restore only after the affected boundary is understood, the fallback is usable, data and action state are reconciled, fixed tests pass, monitoring is active, and a named owner accepts the residual risk. Restore the smallest approved scope first.
What if the team cannot tell whether a tool action happened?
Keep the action disabled, preserve the request and system evidence, inspect the downstream record, and escalate the uncertainty. Unknown side effects are not a successful recovery condition.
How often should a small team run this drill?
Run it before launch, after material vendor, model, connector, prompt, or workflow changes, and on a recurring cadence appropriate to customer impact. Re-run it after a real incident or when a prior exercise leaves an unresolved high-severity finding.
Does passing the drill prove the chatbot is safe?
No. It shows that the selected recovery controls worked under the tested conditions. Keep monitoring, review new changes, and update the scenario set as the system, vendors, sources, customers, and actions change.