checklist

AI chatbot vendor exit checklist for small teams

A practical vendor exit checklist for customer-facing AI chatbots, covering contract and data review, deletion requests, connector shutdown, credentials, subprocessors, backups, fallback operations, customer communication, and final verification.

Published: Aug 13, 2026 Last reviewed: Aug 13, 2026 Audience: Founders, support leads, product owners, security owners, privacy owners, procurement owners, and admins leaving an AI chatbot vendor Risk: High Evidence: NIST AI RMF Core and Playbook, FTC small-business cybersecurity guidance, FTC AI privacy and confidentiality guidance, CISA secure AI system development guidance, OWASP Top 10 for LLM Applications, and Cybergiz chatbot operations templates

Use this checklist when a small team is ending, replacing, or materially reducing its use of a customer-facing AI chatbot vendor.

An AI vendor exit is complete only when the team understands what the vendor stored, connected, copied, or could still access; disables active paths; preserves required evidence; provides a working fallback; and verifies that old traffic and actions have stopped. Before approving the exit, run the AI Tool Risk Checker and attach the result to the exit record.

Bottom line

Start with a data and access map, not the cancellation button. Identify conversations, summaries, uploads, indexes, connectors, OAuth grants, service accounts, webhooks, support access, subprocessors, backups, and open customer requests. Then set the exit date, preserve holds, submit documented deletion or export requests, revoke access, move customers to a controlled fallback, and run post-exit verification.

Use the Small Team AI Security Checklist for baseline ownership, access review, and incident routing. If the decision is whether the chatbot capability should exist at all, use the AI chatbot retirement decision checklist first. This page focuses on the vendor relationship and technical exit.

When to use this checklist

Situation	Use this checklist?	First question
Replacing one chatbot vendor with another	Yes	What data, access, and customer routes must move or stop?
Ending a chatbot subscription	Yes	What remains in the vendor account after cancellation?
Reducing from customer-facing to internal-only use	Yes	Are public routes, connectors, and customer data separated?
Vendor changes retention, subprocessors, or support access	Yes	Does the change exceed the team’s risk tolerance?
A vendor outage requires an emergency switch	Yes	Can the fallback operate without creating a new data leak?
Removing a low-risk public FAQ widget	Usually	Are there still analytics, scripts, source indexes, or vendor copies?
Changing only wording or a prompt	Usually no	Use the chatbot change approval workflow instead.

Do not treat a paid plan cancellation, disabled widget, or deleted workspace as proof that data and access are gone.

Exit trigger matrix

Trigger	Severity	Default response	Owner to involve
Vendor cannot explain retention or deletion behavior	High	Pause new customer data and escalate before exit approval.	Privacy, security, vendor owner.
Connector or OAuth scope is broader than required	High	Revoke or restrict access immediately; preserve evidence.	Engineering, security, system owner.
Vendor support or subprocessor access is unknown	High	Request access details and apply a temporary data boundary.	Vendor, privacy, security.
Customer data is in an export, index, transcript, or ticket copy	High	Map every copy and apply deletion, export, or legal-hold rules.	Privacy, support, legal when needed.
Tool actions or webhooks can still write downstream systems	High	Disable actions, queues, retries, and service identities before exit.	Engineering, product, security.
Contract or renewal date is near	Medium	Start the exit packet early enough to complete verification.	Procurement, finance, vendor owner.
Replacement route is not ready	Medium	Keep a narrow safe scope or use human-only fallback.	Support, product, customer success.
Vendor risk exceeds the team’s tolerance	High	Use the retirement decision process and document the rationale.	Business owner, security, privacy.

The trigger starts a review. It does not authorize deleting records or breaking a customer workflow without an owner and replacement route.

Exit decision table

Decision	Use when	Minimum condition
Exit now	Active access, action, data, or vendor risk is unacceptable.	Containment owner, fallback route, evidence preservation, and shutdown sequence are ready.
Exit on a scheduled date	The service is stable and the team needs a controlled transition.	Contract date, migration plan, customer notice, and verification owner are recorded.
Reduce scope first	Risk is isolated to a connector, topic, channel, or action.	Blocked scope is tested and the reduced route has separate controls.
Keep temporarily	Exit would create greater immediate customer or safety risk.	Expiry date, compensating controls, owner, and exit work items are explicit.
Retire the capability	The use case has low value or cannot be operated within tolerance.	Customer impact, data cleanup, access removal, and final verification are complete.

If the team cannot state what remains connected after the exit, the decision is not ready to close.

Exit intake form

Copy this into the vendor or chatbot operations record.

Field	Entry
Review date
Request owner
Vendor and product
Workspace, tenant, or account
Current chatbot capability
Exit type	Replace, cancel, reduce scope, emergency switch, or retire.
Effective date and timezone
Customer groups and channels affected
Data classes involved	Public, internal, customer, account, billing, regulated, or credential-like.
Connectors and actions
Subprocessors or support access
Replacement route
Data deletion/export owner
Credential and access owner
Customer communication owner
Evidence location

Unknown data classes, connectors, or subprocessors are open findings. Do not mark the exit low risk because the inventory is incomplete.

Contract and data review

Read the current contract, order form, data-processing terms, privacy notice, retention documentation, and support-access terms. Record the version and review date.

Question	Evidence to capture
What data may the vendor collect, store, infer, index, or use for support?	Contract or current vendor documentation.
Which data is deleted automatically and which requires a request?	Retention schedule and deletion procedure.
What happens to backups, disaster-recovery copies, and cached indexes?	Vendor answer, contractual term, or documented limitation.
Can the vendor or subprocessor access content for support or abuse review?	Support-access policy, role, and approval path.
What data can be exported and in what format?	Export scope, fields, timestamps, and integrity check.
What happens after cancellation or account closure?	Account-closure and retention terms.
Are legal holds, complaints, or incident investigations open?	Hold record and owner.
What notice is required for customers or employees?	Approved notice and publishing owner.

The FTC’s small-business guidance recommends specifying how vendors handle data, including use, sharing, retention, and deletion. Record unanswered questions as residual risk instead of converting them into assumptions.

Data map and deletion request

Make a copy inventory before asking the vendor to delete anything.

Data location	Typical contents	Action	Verification
Chat history	Prompts, responses, attachments, feedback, metadata.	Export, delete, or retain under an approved hold.	Vendor result and sample lookup.
Summaries and labels	CRM notes, ticket summaries, tags, classifications.	Trace downstream copies and correct or delete as required.	Downstream owner confirmation.
Knowledge index	Source chunks, embeddings, cached documents.	Remove source and derived index where applicable.	Search test shows the source is unavailable.
Upload storage	Documents, images, transcripts, or recordings.	Export, delete, or place on hold.	Object count or deletion record.
Analytics	Events, user IDs, referrers, session data.	Apply the approved retention rule.	Event and dashboard review.
Support records	Vendor tickets, attachments, screen captures.	Request deletion or preserve an incident record.	Vendor case response.
Backups	Historical copies and disaster-recovery data.	Follow vendor deletion and retention terms.	Written limitation or completion evidence.

Deletion requests should identify the account, data categories, date range, relevant identifiers, and any records that must be preserved. Do not send a customer export or secret-bearing diagnostic bundle to a vendor unless it is approved and necessary.

Export and migration checks

If another system replaces the vendor, separate data that must move from data that should be deleted.

Define the minimum fields needed for the replacement workflow.
Exclude secrets, unnecessary transcripts, raw credentials, and unrelated customer records.
Validate export completeness, timestamps, encoding, attachments, and ownership.
Redact or tokenize sensitive fields before transfer where possible.
Confirm the new system’s access, retention, connector, and deletion controls.
Test a small sample before importing the full export.
Record who approved the migration and who can access the exported file.
Set an expiry or deletion date for temporary migration files.

Do not copy a vendor’s entire historical dataset into a replacement just because an export is available. Minimize the data set to the documented use case.

Identity and connector shutdown

Disable access before closing the account. Include direct and indirect paths.

Access path	Shutdown action	Verification
Human admin accounts	Remove roles, SSO assignments, API access, and temporary users.	Access review and failed-login or denied-access test.
OAuth grants	Revoke grants and remove unused scopes.	Provider grant list no longer shows the vendor.
API keys and service accounts	Rotate or revoke credentials; remove them from jobs and secrets stores.	Old credential fails and no job depends on it.
Webhooks	Disable inbound and outbound endpoints, retries, and signing configuration.	Test event produces no downstream action.
CRM/helpdesk connector	Remove permissions and reconcile queued writes.	No new record or update is created by the old route.
Billing or account actions	Disable action policies and queues first.	Safe denial test and pending-action review.
Browser or embedded scripts	Remove snippets, extensions, and feature flags.	Page source and browser network check are clean.

Never paste live keys into an exit record. Record only the system, owner, revocation time, and verification result.

Subprocessor and support-access review

Third-party dependencies can remain after the primary workspace is closed. Use the vendor’s current subprocessor and support documentation, but do not assume a list answers every data-location question.

List subprocessors involved in hosting, analytics, support, model serving, storage, and communications.
Identify which subprocessors may process customer content or metadata.
Request the retention and deletion behavior that applies to each relevant category.
Review support-access roles, approval, logging, and expected removal after exit.
Record contract notice, audit, incident, and deletion obligations where relevant.
Escalate an unanswered high-impact question to the vendor owner and privacy/security owner.
Preserve the vendor response with the exit evidence, without storing private credentials.

NIST AI RMF Manage guidance treats third-party AI resources as a risk area that needs documented controls, monitoring, contingency processes, and decommissioning when risk exceeds tolerance.

Fallback and customer continuity

The exit is not operationally complete if customers lose a safe route for account, billing, privacy, security, or other sensitive questions.

Customer route	Replacement	Owner	Test result
Public FAQ	Maintained static help content or human support.
Account-specific support	Authenticated support queue.
Billing and refunds	Controlled billing or finance workflow.
Privacy requests	Privacy request intake and verification.
Security reports	Security contact and incident route.
Existing open conversations	Named owner and response deadline.

Test the fallback from every affected channel. A help-center link that no one owns is not a fallback.

Customer communication plan

Short notice template

Starting on [date], we are changing this support route. The AI assistant will [be unavailable / cover fewer topics / route requests to our support team]. For account, billing, privacy, security, or other sensitive questions, contact [human route]. Existing requests will be handled by [owner or process].

Communication checklist

Confirm the effective date and timezone.
Name the replacement route and expected response time.
Explain what happens to open conversations and pending actions.
Provide a human route for sensitive or disputed requests.
Update the widget, help center, onboarding, email, and internal scripts.
Give support and customer success teams approved answers.
Record the approver and published locations.

Do not claim that every vendor copy was deleted unless the team has verification. Use precise wording for known completion, pending requests, and contractual limitations.

Exit sequence

Freeze scope changes and name the exit owner.
Capture the current configuration, data map, connectors, actions, queues, and vendor terms.
Put legal, security, privacy, and incident holds on the record where needed.
Prepare and test the customer and internal fallback route.
Export only the approved minimum data set, if migration requires it.
Disable tool actions, webhooks, queues, retries, and scheduled jobs.
Revoke OAuth grants, API credentials, service identities, and human access.
Remove front-end routes, scripts, feature flags, and source references.
Submit deletion, retention, and account-closure requests to the vendor.
Publish approved customer communication and update support instructions.
Verify no new traffic, data, or action attempts occur.
Close the exit record only after owners sign off on residual risk.

Sequence matters: disabling the visible interface before actions and credentials can leave old clients or queues active.

Final verification checklist

Run safe negative tests after shutdown. Confirm that an old route is denied without sending real customer data or triggering a real write action.

Vendor exit record

Field	Entry
Vendor and product
Account or workspace
Exit type and reason
Effective date
Data categories reviewed
Export scope and location
Deletion request and vendor response
Subprocessors reviewed
Access and connector cleanup
Tool action and queue cleanup
Customer fallback
Customer communication
Holds or exceptions
Residual risk
Closure owner
Approvers
Final verification date
Follow-up date

Keep the record with the AI tool inventory, vendor security packet, and any incident evidence. Do not store customer exports, secrets, or private credentials in the public repository.

Metrics to track

Metric	Why it matters
Post-exit traffic	Shows whether old routes still receive users.
Remaining action attempts	Finds stale queues, retries, and hidden integrations.
Access grants removed	Shows connector and identity cleanup.
Data deletion requests completed	Shows closure progress and unresolved copies.
Open customer requests	Shows whether fallback ownership is working.
Fallback response time	Shows customer continuity after the exit.
Vendor questions unanswered	Shows residual third-party risk.
Reopened exit tasks	Finds incomplete shutdown or unclear ownership.

Zero traffic is not enough. Pair usage data with access review, action logs, retention evidence, vendor responses, and a safe negative test.

Evidence checked

This checklist is aligned with:

NIST AI RMF Core, which includes safe decommissioning, third-party risk, clear accountability, and post-deployment risk management outcomes.
NIST AI RMF Manage Playbook, which describes monitoring third-party AI systems, contingency processes, documented controls, and decommissioning third-party systems that exceed risk tolerances.
FTC cybersecurity guidance for small businesses, which recommends specifying vendor data use, sharing, retention, deletion, security requirements, and least-necessary data access in contracts.
FTC guidance on AI privacy and confidentiality commitments, which warns that changes in data use, retention, or confidentiality commitments need clear treatment.
CISA and UK NCSC secure AI system development guidance, which covers secure practices across AI system design, development, deployment, and operation.
OWASP Top 10 for LLM Applications, which covers prompt injection, sensitive information disclosure, insecure plugin design, excessive agency, and overreliance.
Cybergiz templates for chatbot launch, deletion and export, connector approval, incident communication, pause and fallback, retirement decisions, and tool decommissioning.

This page is practical operating guidance, not legal, privacy, compliance, audit, certification, customer-support, incident-response, procurement, or security assurance advice.

FAQ

Is cancelling the chatbot subscription enough?

No. Cancellation may stop billing without revoking connectors, deleting data, closing queues, removing scripts, or addressing backups and support records. Complete the access, data, and verification steps first or document the vendor’s limitations.

Should we export all chatbot history before leaving?

Only export the minimum data needed for a documented migration, customer request, support obligation, or approved evidence hold. Minimize, protect, and set a deletion date for temporary files.

What if the vendor will not confirm backup deletion?

Record the contractual term or limitation, ask the vendor owner and privacy/security owner to assess residual risk, and do not claim complete deletion. Keep only the evidence needed to support that assessment.

Which access should be revoked first?

Disable high-impact tool actions, webhooks, queues, retries, OAuth grants, API credentials, and service identities before removing the visible interface. This reduces the chance that an old client or pending job can still change a downstream system.

Do subprocessors matter for a small team?

Yes, when they process customer content, metadata, support records, analytics, or backups. The team may not need a full legal assessment for every provider, but it does need a clear owner, relevant data path, retention treatment, and escalation route.

Can a replacement vendor receive the old vendor’s full export?

Not by default. Define the minimum fields, remove unrelated and sensitive data, test a small sample, and verify the replacement’s access, retention, deletion, and connector controls before importing.

What should customers be told?

Tell them what route is changing, when it changes, where sensitive questions should go, what happens to open requests, and the expected response time. Avoid unverified claims about data deletion or security incidents.

When is the vendor exit complete?

When the decision and fallback are approved, data and holds are handled, access and actions are disabled, vendor requests are recorded, customer communication is complete where needed, and post-exit tests show that old routes cannot create new access, data, or actions.