Vendor onboarding gets a process: intake, tiering, due diligence, approval. Vendor offboarding usually gets a cancelled invoice. The contract lapses, the team moves to a new tool, and the old vendor keeps your data, an API key with write access, and a DNS record pointing at a service you no longer control.
None of that is visible until something goes wrong. A former vendor suffers a breach and your data is in it. An auditor samples terminated vendors and asks for proof of deletion. A forgotten subdomain starts serving someone else's content.
This article sets out a vendor offboarding process in six steps, the evidence each one should leave, and the failures that show up most often. It covers the vendor relationship. For removing departing employees' access, see offboarding that removes access the same day.
When offboarding starts
Offboarding starts before the contract ends, not after. Many of the things you need from the vendor, such as data exports, deletion confirmation and transition help, are easier to get while the vendor is still being paid.
Typical triggers:
A decision not to renew, or to replace the vendor with another
Consolidating overlapping tools
A failed reassessment that cannot be remediated
The vendor being acquired, changing its terms, or ceasing the service
Discovery that a tool is no longer used
Check the contract when the decision is made. Look for the notice period, any auto-renewal date, termination assistance obligations, and the clauses on data return and deletion. Missing a notice window can commit you to another term.
Step 1: inventory what the vendor has
You cannot remove what you have not listed. For the vendor being offboarded, record:
Data. Every category of your data the vendor stores, including copies in logs, backups and exports
Accounts. User accounts for your staff in the vendor's system, and any accounts the vendor's staff hold in yours
Integrations. API keys, OAuth grants, webhooks, service accounts and connectors in both directions
Network and DNS. IP allowlists, VPN or private connectivity, and DNS records pointing at the vendor
Email authorization. SPF includes and DKIM keys that allow the vendor to send mail as your domain
Physical assets. Hardware or media the vendor holds, if any
Your vendor inventory and the original due diligence record are the starting point. The integration list is usually incomplete; check your identity provider and your workspace's connected apps for anything the record missed.
Step 2: get your data out
Export everything you need to keep before you cut access. Confirm the export is complete and readable in the target system. Once deletion begins, a missing table is permanent.
Check your own retention obligations at this point. Some records may need to be kept for legal, contractual or audit reasons, even when the tool that held them is going away. Those records need a new home with the same protections.
Step 3: revoke every path in
Revoke access in both directions, in this order:
Remove the application from SSO and disable any local accounts in the vendor's system that bypass it.
Revoke API keys and OAuth grants issued to the vendor, at the source system that issued them. Deleting the integration in the vendor's interface does not always revoke the token on your side.
Disable vendor staff accounts in your systems, and service accounts created for the vendor.
Rotate shared secrets the vendor knew: passwords, signing keys, webhook secrets, database credentials.
Remove network allowances: IP allowlist entries, firewall rules, VPN profiles and private links.
Clean up DNS and email. Remove CNAME and other records pointing at the vendor, and remove SPF includes and DKIM keys for it.
Step 4: confirm return or deletion
Ask the vendor to delete your data, and to confirm in writing that it has done so. The contract should already require it.
Under GDPR Article 28(3)(g), the processing contract must require the processor to delete or return all personal data at the end of the provision of services, at the controller's choice, unless Union or Member State law requires storage. The HIPAA business associate contract requirements are similar: at termination, the business associate returns or destroys protected health information where feasible, and extends the agreement's protections to any it cannot. If you need to check what your agreement says, our data processing agreement guide lists the required terms. Confirm the interpretation for your contract with counsel.
Three details are worth asking about directly:
Backups. Many vendors cannot delete one customer from a backup set and instead let backups expire on their normal cycle. Ask what that cycle is, and get it in the confirmation.
Sub-processors. Deletion should cover copies held by the vendor's own sub-processors. The fourth-party chain does not end when your contract does.
Format. A short letter or email from an authorized person at the vendor, naming the data, the scope and the date, is the usual evidence. Some vendors provide a certificate of destruction.
If the vendor will not confirm deletion, record that, record what you asked for, and assess the residual risk in your register.
Step 5: update your records
A vendor that has left still appears in documents until someone removes it. Update:
- Not done:
The vendor inventory, with the termination date and status
- Not done:
Your public sub-processor list, if the vendor was one, and any notice your customer contracts require
- Not done:
Your record of processing activities, where the vendor was a recipient of personal data
- Not done:
The system description for your SOC 2 report, if the vendor was a subservice organization
- Not done:
Data flow diagrams and architecture documentation
- Not done:
Business continuity and incident response plans that named the vendor
- Not done:
Risk register entries that referred to the vendor
For GDPR processors, the sub-processor list and the record of processing are the ones customers and regulators read. Keep them accurate.
Step 6: keep the evidence
Auditors sample terminated vendors less often than active ones, but they do sample them, particularly where the vendor held customer data. For each offboarded vendor, keep:
The decision to offboard, with the date and owner
The inventory from step 1
Evidence of access removal: SSO configuration, revoked tokens, closed tickets, DNS changes
The vendor's deletion confirmation, or your record of requesting it
The record updates from step 5
Store these with the vendor's record, so the history of the relationship stays in one place.
What usually goes wrong
Access removed in the interface only. The integration disappears from the vendor's dashboard, but the token still works on your side.
No deletion request. The contract allowed for it. Nobody asked.
Orphaned DNS. The service is cancelled and the record stays.
Shadow copies. Data exported to the vendor's tool from a spreadsheet, a shared drive or an email attachment, outside the main integration, is forgotten in the inventory.
Owner left first. The internal owner of the relationship leaves the company, and nobody else knows what the vendor held. Name an owner for every vendor, and transfer ownership when people move, as part of tiering and intake.
How TrustLynce helps
TrustLynce's third-party risk module keeps each vendor's owner, data access and review history in the inventory, so the offboarding inventory starts from a record rather than from memory. Offboarded vendors keep their history and evidence, ready for an auditor's sample.