Vendor offboarding is the set of steps a TPRM program runs when a vendor relationship ends: revoking every form of access the vendor held, confirming your data has been returned or destroyed, and closing out the contractual obligations that governed the relationship. It sounds like administrative cleanup. In practice it is a control point - every access path and every copy of your data that offboarding fails to close stays live indefinitely, under a vendor that no longer has a contract, an SLA, or a reason to protect it.
The reason offboarding is chronically under-governed is structural, not a lack of diligence. Onboarding has a natural trigger - a new relationship needs approval before it starts, so someone owns making it happen. Renewal has a calendar date. Offboarding has neither: a contract lapsing, a vendor being replaced, or a project quietly winding down does not automatically generate a ticket. Unless a program builds an explicit trigger for it, offboarding simply does not happen, and the vendor keeps whatever access and data it had on the day everyone stopped paying attention.
The two things offboarding has to accomplish
Strip away the paperwork and offboarding reduces to two obligations, and a program needs to close both - closing one while leaving the other open is a common way this stage half-fails.
- Access revocation. Every credential, connection, and physical access path the vendor was granted gets disabled, not just the ones someone remembers.
- Data return or destruction. Your data - and any copies the vendor's own subprocessors made - is returned to you or verifiably destroyed, with evidence you can point to later.
Access revocation: the checklist that matters
Access sprawls further than the original contract usually implies, and the accounts that get missed are rarely the ones a human logs into.
- SSO and identity provider access. The obvious one, and usually the first thing revoked - but only covers access that actually ran through SSO.
- VPN and network access. Any standing network path granted for integration or support work, including access that predates a later SSO rollout and was never migrated.
- API keys and service accounts. These outlive human accounts by default, because deactivating a person's SSO login does nothing to a machine credential issued separately for an integration.
- Shared or break-glass credentials. Any credential handed over for emergency or initial-setup access and never rotated afterward.
- Physical access. Badges, site access, and hardware issued for on-site work.
- Downstream and subprocessor access. Confirm the vendor's own subprocessors - the fourth parties in the relationship - lose access too; a primary vendor can be fully offboarded while a subcontractor it engaged still holds a live connection.
Data return or destruction: what "confirmed" actually requires
A vendor's email saying "we've deleted your data" is not evidence; it is a claim. Confirming destruction means asking for something you can point to later - to an auditor, a regulator, or your own security team - and getting it before the relationship formally closes, not after.
NIST SP 800-88 Revision 1, the federal standard for media sanitization, defines three levels with different guarantees: clear (logical techniques applied through standard read/write commands, recoverable with specialized tools), purge (physical or logical techniques that render data infeasible to recover even in a lab), and destroy (physical destruction of the media). What a vendor actually did to "delete" your data determines whether a former subcontractor, a decommissioned backup, or a recovered disk could still expose it - and a contract that only says "delete data" without specifying a sanitization standard leaves that entirely up to the vendor's discretion.
The practical requirement is a certificate of destruction or an equivalent attestation naming the method used, the data covered, and the date - specified as a contractual deliverable at offboarding, not requested informally afterward. For a return path instead of destruction, the same discipline applies: agree on format and transfer method in advance, and confirm the vendor's copies (including backups) are destroyed once the return is verified, so the data does not exist in two places indefinitely.
What regulators and standard contracts expect
This is not just good hygiene - specific frameworks require it in writing before a relationship starts, which is the only point at which you have real leverage to negotiate it.
- GDPR Article 28(3)(g). A data processing agreement under GDPR must obligate the processor, at the end of the provision of services, to delete or return all personal data at the controller's choice, and to delete existing copies unless EU or member-state law requires the data to be retained.
- HIPAA business associate agreements. A BAA must require the business associate to return or destroy protected health information when the contract ends, per HHS guidance on business associates; where return or destruction is infeasible, the BAA must extend the same protections to whatever data remains and limit further use.
- DORA exit strategies. DORA requires financial entities to maintain documented exit strategies for ICT third-party arrangements supporting critical or important functions, covering transition to an alternative provider and the orderly return or destruction of data - decided and contracted before the relationship starts, not improvised when it ends.
The common thread: every one of these frameworks expects the return-or-destroy obligation to be a contract term negotiated at signing. None of them can be satisfied by asking nicely once a vendor relationship is already over and your leverage is gone.
Where offboarding fails in practice
- No trigger event. Nothing on a calendar forces offboarding to start, so it depends entirely on someone remembering a contract ended.
- Orphaned service accounts. API keys and integration credentials are provisioned separately from human SSO access and routinely survive a "completed" offboarding that only touched user logins.
- Accepting an unverified deletion claim. An email confirmation is not evidence; without a specified sanitization method and a certificate naming it, there is nothing to show an auditor.
- Ignoring the subprocessor chain. Data returned or destroyed by the primary vendor can still exist in a subcontractor's backups or a downstream processor's systems the contract never named.
- Negotiating return-or-destroy terms after the fact. Once a relationship is ending, the vendor has no incentive to agree to a stricter standard than the original contract specified - this has to be written in at onboarding.
Making offboarding a workflow, not a memory test
The structural fix is to stop treating offboarding as something a person has to remember and instead tie it to an event: a contract end date, a vendor replacement, or a tier downgrade to zero. Platforms that track the full vendor lifecycle - Rescana among them - can flag offboarding automatically when a contract lapses or a vendor is marked inactive, so revocation and destruction verification become a tracked task with an owner rather than something that only happens if someone happens to notice.
Frequently asked questions
What is vendor offboarding in third-party risk management?
Vendor offboarding is the end-of-relationship stage of the TPRM lifecycle: revoking every form of access a vendor held - SSO, VPN, API keys, service accounts, and physical badges - and confirming that your data has been returned to you or destroyed, with evidence you can point to later. It is the stage most programs govern worst, because unlike onboarding or renewal, nothing forces it to happen on a schedule; it only runs if a contract end or vendor replacement explicitly triggers it.
What should a vendor offboarding checklist include?
A complete vendor offboarding checklist covers two categories. For access, revoke SSO and identity-provider access, VPN and network connections, API keys and service accounts (which outlive human logins by default), shared or break-glass credentials, physical badges, and any access held by the vendor's own subprocessors. For data, confirm return or destruction using a specified sanitization standard such as NIST SP 800-88, request a certificate of destruction naming the method and date, and verify backup and subprocessor copies are also destroyed rather than assuming the primary vendor's deletion covers them.
Does GDPR require a vendor to delete your data after the contract ends?
Yes. GDPR Article 28(3)(g) requires that a data processing agreement obligate the processor, at the end of the provision of services, to delete or return all personal data at the controller's choice, and to delete existing copies unless EU or member-state law requires the data to be retained. This has to be written into the processing agreement before the relationship starts - GDPR does not give the controller a way to compel this after the fact if it was never contracted.
How do you verify a vendor actually destroyed your data after offboarding?
Verification requires more than a claim in an email. Ask the vendor to specify the sanitization method used - NIST SP 800-88 defines clear, purge, and destroy as distinct levels with different recovery guarantees - and to provide a certificate of destruction naming the method, the data covered, and the date. This should be a contractual deliverable agreed at onboarding, not a request made informally after the relationship has already ended, since a vendor with no remaining contract has little incentive to go beyond what it originally agreed to.