Vendor decommissioning

what 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.

why 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.

what 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 your move to make, not theirs. 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 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.