A 15-step vendor offboarding checklist across commercial close-out, data return, access, deletion and the record, with four steps that are easy to overlook and a worked example of a weak vendor response.
Most organizations can describe their vendor onboarding process in detail. A request, a risk tier, a security questionnaire, a contract review, a signed DPA, a record in the vendor system. Ask the same people to describe vendor offboarding and the answer is usually shorter. Someone cancels the contract. IT turns off the logins. Somebody emails the vendor about the data.
That asymmetry is the reason this checklist exists. Vendor offboarding is the controlled end of a vendor relationship, and it has four workstreams: the commercial close-out, access revocation, data offboarding, and the record. The first two usually get done, because finance and IT already have tooling and habits for them. The third and fourth are where the gaps tend to be, and they are the ones an auditor or a regulator is most likely to ask about.
The fifteen steps below cover all four workstreams. They are numbered for scanning, not for sequence. In practice the workstreams overlap: planning starts before the termination date, and data return, access removal and deletion have to be coordinated to the agreed end date so that nothing is deleted before it has been recovered and nothing stays accessible after it should be gone. The four steps marked ◆ are the ones that are easiest to overlook, and a worked example at the end shows why they matter.
1. Confirm the end date and the notice terms. Find the actual termination or non-renewal date in the contract, not the date someone remembers. Note any notice period, any auto-renewal clause, and the date on which the data obligations start running. If that date lives only in an inbox, treat that as a finding in itself.
2. Settle the money and the property. Final invoices, disputed charges, unused credits, prepaid licences, and any hardware or materials the vendor holds. Get the final statement in writing.
3. Update the vendor register. Mark the vendor as terminated, with the date, in the single system that lists every third party holding your data. If no such system exists, start one. Step 15 depends on it.
4. Export the data you need to keep, and check it. Before access is removed or deletion begins, identify what data the vendor holds that you are required or expected to retain, export it in a usable format, and verify that the export is complete and readable. A deletion confirmation is of little comfort if the only copy of a record you needed went with it.
5. Confirm the replacement is working. If a successor service is taking over, test it against the exported data and the live process before the old vendor's access ends. The cutover date should be set by that test passing, not by the contract date alone.
6. Revoke every account and credential. User accounts, service accounts, SSO entitlements, API keys, VPN access, shared mailboxes and shared drives, including accounts the vendor created for itself inside your tenant. Time this to the agreed end date and to step 5, not to the day someone gets round to it.
7. Remove integrations. Webhooks, scheduled feeds, SFTP drops, OAuth grants, and any connector that pushes data to the vendor without a human involved. These keep running after the logins are gone.
8. Recover or wipe devices and badges. Laptops, tokens, physical access cards, and anything with your data cached on it.
9. Pull the return-or-destroy clause and read it. Most contracts contain one. Fewer specify a method, a deadline, an evidence requirement, or whether the obligation reaches the vendor's subprocessors. Know what you can actually require before you ask for it. If the clause is weak, you are negotiating rather than enforcing, and it helps to know that going in.
10. Send a written directive, not a question. ◆ The request to the vendor should cite the clause, state the date by which written confirmation is due, and describe what evidence will satisfy the obligation. "Please confirm our data has been deleted" tends to produce a one-line reply. A directive produces a record of what was asked, which is the first half of being able to assess what comes back.
11. Ask the vendor to address backups, non-production environments and subprocessors. ◆ Production data is the easy part. Ask the vendor to state in writing how backup and disaster recovery copies are handled and over what window, whether development, staging, analytics or support environments held the data, and which downstream parties did. Each should come back either as a confirmation or as an explicit statement that it did not hold the data.
12. Assess what comes back against a standard. ◆ A vendor's response is a claim, not a result. Review it for six things: scope, subprocessors, method, timing, attestation by someone authorized to bind the vendor, and exceptions. Record each as present or absent, then assess the gaps by their significance rather than by count. A missing scope statement or an unresolved exception may matter more than several smaller omissions. Resolve material omissions before approving closure. A signed letter on its own records the vendor's claim; it does not independently establish that deletion occurred, and a certificate of deletion is rarely sufficient by itself. For this step followed end to end on one termination, see how to confirm a vendor actually deleted your data.
13. Record exceptions with a basis, an owner and a review date. Anything the vendor retains, whether a backup aging out, a legal hold, or a regulatory retention requirement, goes in the record with the reason, any restrictions on use, a named owner, and either an expiry date or, where none can be set, a next review date and the condition for release. An exception that is documented this way can be explained. One that is not documented cannot.
14. Log every action as it happens. The directive, each reminder, each escalation, the vendor's submission, the assessment, and the closure decision, each with a timestamp and a name. Reconstructing this later from inboxes is the thing you are trying to avoid.
15. Close on a named approval, and file one retrievable record per vendor. ◆ Offboarding ends when a named person confirms the evidence was assessed against the standard, material gaps were resolved or formally accepted, and the record is complete. If the evidence did not meet the standard, the item stays open with an owner, and non-response is itself documented. The record itself, holding the obligation, the directive, the submission, the assessment, the exceptions and the closure, should sit in one controlled location. The test is simple: could you produce it for a vendor terminated last year, within a day, without asking the person who ran it?
Here is a composite of the kind of reply that arrives when step 10 is skipped. The vendor is a mid-sized SaaS provider; the contract ended six weeks ago.
Hi, confirming that all of your data has been deleted from our systems per our agreement. Let us know if you need anything else.
Account manager
Run it against the six elements from step 12.
Five of six are absent and the sixth is weak, but the count is not the point. The two gaps that matter most are scope and exceptions, because they decide whether the data is actually gone. A reviewer's next request should say so: confirm the systems and datasets covered, state how backup and disaster recovery copies are handled and when they age out, list any subprocessors that held the data and their confirmations, name the method and the date, and have the confirmation signed by someone with authority to make it on the vendor's behalf. That request is step 10, sent late. Sending it first is cheaper.
Notice what the improved response still is: a documented assurance. The directive sets the standard for the claim, the attestation records the claim, and the assessment records how you judged it. That is a program that can assess and document how deletion was handled, which is what an auditor is in a position to test. Independent proof, where it is available at all, comes from artifacts such as deletion logs or third-party verification, and auditors assessing vendor data handling tend to ask for what you can show rather than what the policy says.
Give it an owner. One function, named in policy, is accountable for confirming how former vendors handled your data. Privacy, third-party risk, procurement or security can all do the job. What matters is that it is written down and that terminations reach that function without relying on the business owner to remember.
Trigger it from the system, not the person. Contract end dates should live somewhere that can notify someone. Abrupt terminations, replacements, migrations, divestitures and tools that quietly fell out of use all count, not only orderly expirations.
Plan for the contract's timeline, not a generic one. The window for the vendor to confirm destruction is whatever the contract says, and contracts vary widely. Backup retention windows can extend it further. Read step 9 before setting expectations, and record the agreed dates in the log.
Measure more than completion. A count of closed records is easy to improve by closing records. Track it alongside overdue actions, unresolved exceptions, and the quality of the evidence received, so that closing early is visible rather than rewarded.
If you want to know how many of these steps your organization performs consistently, rather than occasionally, the Vendor Data Offboarding Readiness Checklist scores thirty capabilities across six domains in about six minutes, with no email required. The Readiness Framework behind it sets out what each capability looks like when it is working, and the evidence a vendor has to produce for it to count.
A low score is the normal starting point. The value of the checklist is knowing which of the fifteen steps you are actually doing before someone else asks.
The framework and checklist behind every article: six domains, one score, and a view of where your offboarding evidence would hold up.
See how Fimi Data turns vendor data deletion obligations into defensible evidence.
