in one lineCancelling a SaaS contract ends the invoices; the vendor's grants, tokens, and your data on their side all need closing separately.
the numbers
- 48%of breaches involve a third partyVerizon DBIR, 2026
- 700+companies reached through one compromised OAuth integrationFINRA on the Salesloft/Drift breach, 2025
- 53%of breaches took customer personal dataIBM Cost of a Data Breach, 2025
1what it is
Vendor decommissioning is the deliberate closure of everything a SaaS relationship created: the OAuth grants and API tokens the tool held into your environment, the user accounts your people held in theirs, the app-to-app integrations wired up during onboarding, and the company data accumulated on the vendor's side over the life of the contract.
Procurement processes handle the start of a vendor relationship. Almost nothing handles the end. The subscription lapses, the logins stop being used, and every technical artifact of the relationship persists by default.
2why it accumulates
Nobody owns endings. The team that championed the tool has moved on to its replacement; finance sees only that billing stopped; IT was often never told the tool existed. The connections stay because revoking them is a task on nobody's list.
The scale of the leftover layer is documented: Valence Security's SaaS research found that a majority of SaaS-to-SaaS integrations are inactive yet still hold valid OAuth tokens or API keys. Dead vendors with live credentials are the normal state of an environment that has never decommissioned deliberately. The Salesloft/Drift breach of 2025 showed where that leads: attackers abused a vendor integration's OAuth tokens to pivot into customers' Salesforce data across hundreds of companies, and a dormant connection would have offered the same path as an active one.
3what it costs you
Each leftover carries its own exposure. The vendor's standing access into your stack is attack surface that no longer buys you anything: if the vendor is breached tomorrow, you are in the blast radius of a tool you stopped using last year. Your data on the vendor's side keeps its GDPR weight: under Article 28(3)(g), your processing contract must require the vendor to delete or return personal data at the end of the engagement, and exercising that clause is up to you. And the orphaned accounts your team held in the dead tool are credential-stuffing targets carrying your email domain.
The audit cost compounds quietly: every dead vendor still in your OAuth list is a finding you will have to explain in the next questionnaire or review.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedSalesloft / Drift, 2025howA chat tool's key into your CRM is stolen from the vendor.what leavessupport tickets, including passwords pasted into themwho ends up with itan extortion group working through hundreds of companies
- it happenedGitHub OAuth tokens, 2022howIntegration keys to your code host are stolen from the integration vendor.what leavesyour private code and the secrets inside itwho ends up with itattackers looking for the next door
- it happenedSisense, 2024howAn analytics vendor is breached and the keys it holds to your systems are copied.what leavesconnections straight into your datawho ends up with itwhoever holds the vendor's keys
4what works
Dead vendors surface through a cross-reference: the OAuth grant list and the SSO app list on one side, what finance actually pays for on the other. Connected but unpaid usually means retired but never decommissioned. The same pass catches the adjacent signatures, connected apps holding valid tokens with no recent activity, integrations whose creator has left, SSO entries for tools nobody opens, which mark vendors that are functionally dead even where a subscription still quietly renews.
Revocation covers more than the obvious grant. A vendor relationship typically leaves OAuth grants, API keys, webhook endpoints, and sometimes directory service accounts, and each one gets revoked, confirmed, and documented, since the confirmation is what turns cleanup into audit evidence.
The data side runs on GDPR Article 28(3)(g): the processing contract must require the vendor to delete or return personal data at the end of the engagement, and the clause does nothing on its own, because exercising it is the customer's move to make. The working sequence is a formal request for return or deletion under the contract and the Article, followed by written confirmation of deletion. Where the contract turns out to lack the clause, that gap becomes an action item for the next procurement template, so future contracts end better than this one did. Closing the customer's own side mirrors it: team accounts in the dead tool deactivated, with anything retention rules require exported first.
What makes this repeatable rather than archaeological is a decommissioning checklist inside vendor management, applied at every contract end. A tool leaves the estate the way an employee leaves the company: completely, and on a date.
on the record
your turn
what you can do about it
this week
Pick the last vendor you stopped using and check what access and data it still holds.
Revoke keys and integrations, and ask for deletion.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →