Vendor offboarding for small teams: the data deletion checklist

Cancelling a SaaS subscription is a two-click operation. Offboarding the vendor — making sure they stop holding your customer list, your documents, your API access, and your billing card — is a different job, and almost nobody does it. The result shows up a year later as a surprise: the "cancelled" tool still appears in your SSO dashboard, its API key still works, and its privacy policy still says it retains customer data. If you passed the cyber insurance application questions about third parties, that ghost vendor is exactly the exposure the underwriter was asking about.

This checklist takes one afternoon per vendor and leaves you with three artifacts: an export, a written deletion confirmation request, and a dated record that the door is closed. Run it before the renewal date — the order matters.

1. Read the exit clause before you send the cancellation email

Every lever you have was agreed at signing, in the contract and the data processing agreement (DPA). Before cancelling, find and note:

• Notice period. 30 days is common. Cancel inside the window and the contract auto-renews — now the offboarding runs against a contract that just extended itself. The renewal prompt (like the one in the SaaS sprawl audit) is the moment to act, not the day after.
• Data return. What format, what fields, how long the vendor keeps the export available after termination. Some platforms let you export yourself; some make you request it. Learn which before your admin access ends.
• Deletion timeline. Most DPAs say primary data is deleted "within 30-90 days of termination" and backups "in the normal course of business" (90-180 days). That's fine — but it means deletion is a date in the future, not a switch. Write the date down.
• The auto-renew trap. Some contracts renew unless cancelled 60+ days out. If you're inside that window, your first task isn't deletion — it's deciding whether one more term is cheaper than fighting the renewal. That's a recorded decision, not an inbox mood.

2. Export what you own, while you still have admin

The day admin access ends, so does your leverage to get data out. Export on your schedule, not the vendor's:

• Primary data — the customers, tickets, documents, or records you'd need if a dispute or an audit shows up in six months.
• User and access list — who had accounts in the tool. This becomes your input for revoking their side door later.
• Configuration and audit logs — if the vendor holds settings or logs that a future postmortem would need, export them now. Logs are almost never included in "your data" exports unless you ask.
• Anything you paid to produce — templates, automations, custom fields. This is the part teams regret losing, because recreating it costs more than the subscription ever did.

Store the export where your backups actually run — an export sitting inside the same vendor's cloud is not a backup, it's a copy with the same failure mode.

3. The untangle list: everything that connects you to them

Vendors don't connect by password alone. Walk this list before you cancel, because half of it breaks silently:

• SSO/SAML app entry. If the tool is in your identity provider, it's a working door until you remove it — cancelled billing does not revoke login. Remove the app after the user list is exported, and note who was assigned.
• API keys and tokens. Every integration script, every webhook, every "connect" you clicked in another tool. These outlive cancellations for years. Treat this as a pass of the secrets rotation checklist: find them, then kill them.
• Inbound webhooks. Other systems may still POST to the vendor's endpoints. A dead webhook is usually a silent failure in a job you forgot you had — the same failure class as the cron job nobody watches.
• DNS records and MX changes. If the vendor ever touched your domain (email routing, verification TXT records), remove those entries deliberately. Left-behind DNS is both a security hole and a future mystery outage.
• The billing card. If the vendor has your card on file, cancel via the billing settings and confirm the subscription shows cancelled in writing (screenshot). "I emailed them" is not a cancellation record.

4. Revoke everything that opens a door

Access offboarding follows the same logic as employee offboarding — same order as a leaver, but the account is the vendor's:

• Disable vendor admin accounts from your side where the integration allows it.
• Rotate any shared credentials the vendor ever saw — SMTP passwords, database users, cloud keys. If a vendor engineer ever connected to your systems, assume that credential is theirs until rotated.
• Remove vendor service accounts from your identity provider, and check for OAuth grants ("sign in with Google") that users granted individually — those don't appear in admin consoles and survive everything else.

5. The deletion request, in writing, with a date

Don't assume cancellation deletes data. Send a short deletion request referencing the contract, and ask for specifics:

• Name the data. "All customer personal data and documents associated with account [id]" beats "our data".
• Include backups. Ask them to confirm the backup deletion timeline from the DPA, in days. If the answer is "90 days", your verification date is 90 days out — put it in the calendar.
• Ask for written confirmation. A named reply, not a help-center article. This email is your evidence artifact for the next insurance renewal and the next vendor review.
• Sub-processors. If your data flowed to the vendor's own vendors, ask how deletion propagates. You don't need to audit their chain — you need the question answered in writing.

6. Verify instead of trusting

Offboarding fails at the verification step because it happens after everyone stopped caring. Three cheap checks:

• Try the old login. SSO app removed + password login rejected = the door is actually closed. Two minutes.
• Confirm billing stopped. Next statement: the charge is gone and nothing auto-converted to a free tier with your card still on file.
• The 30/60-day follow-up. One calendar entry: "vendor X — deletion confirmation received? yes/no." If no, one follow-up email. Vendors answer the second email.

7. The paperwork (ten minutes, saves the next argument)

Keep one record per vendor exit: who approved it, the cancellation date, the export location, the deletion request, and the confirmation (or the follow-up you still owe). This is the same discipline as the incident changelog — the record exists so a future you doesn't re-litigate a decision from memory.

The failure modes this checklist exists for

• The ghost login. The SSO app entry survives the cancellation. Six months later, an audit finds a "tool we don't use" that still authenticates users. Doors get closed by action, not by invoices stopping.
• The living API key. A cron job in another tool still holds the vendor's token. It fails silently when the vendor purges data — and you find out from a broken report, not an alert. Secrets rotation isn't just for leaks.
• The auto-renew you meant to kill. The offboarding intent was real; the notice window wasn't. Renewal prompts are the leverage point — that's where the sprawl audit earns its hour.
• "Deletion" that meant cancellation. No written request, no date, no confirmation. The vendor keeps your data under their retention policy indefinitely, and nobody notices until it's their breach notification in your inbox.

The pattern: an exit is complete when access, data, and billing are all three verifiably closed — not when the subscription stops charging. Vendors you keep get an annual review; vendors you fire get an exit record. The only bad vendor relationship is the one you can't prove is over.

The decision to fire a vendor gets made on the vendor renewal calendar, at T−60 while cancellation is still cheap; this checklist is what runs in the thirty days after that decision.

Need all of it at once? The Ops Mega Bundle collects all five ops kits in one download — $29.