Learn how to verify vendor data deletion: request evidence, assess six elements, resolve retained-data exceptions, and document the closure decision.
To verify vendor data deletion, check the vendor’s response against six elements: data scope, subprocessors, deletion method, completion dates, authorized attestation, and retained-data exceptions. Resolve material gaps and record who approved closure. This provides documented assurance; it does not independently prove that every copy was deleted.
You usually cannot inspect all of another company’s systems yourself. The practical task is to establish what the vendor was required to do, request evidence, assess its response, and document the decision. For higher-risk relationships, additional technical evidence or independent verification may be appropriate.
This hypothetical worked example follows an invented vendor termination from start to close. A marketing team has used a mid-sized SaaS tool for four years. It holds customer contact records and campaign data, with two subprocessors of its own. Required data exports have been checked and the migration completed before termination. The day numbers illustrate the sequence; they are not recommended deadlines.
Our Readiness Framework uses six elements to assess a deletion response. This is an assessment framework, not a guarantee that deletion occurred. Evaluate omissions by their significance to the data and the relationship, rather than counting them.
| Element | What to request | What needs follow-up |
|---|---|---|
| Scope | Data categories, systems, storage and environments covered | Broad wording such as “our platform,” with no defined scope |
| Subprocessors | Relevant downstream parties and their deletion status | Missing parties or unsupported exclusions |
| Method | How data was deleted or rendered inaccessible | Unexplained terms such as “secure deletion” |
| Timing | Completion dates and remaining retention windows | No completion date or an undefined backup window |
| Attestation | Confirmation from a representative with appropriate authority | Authority that has not been established |
| Exceptions | Retained data, basis, restrictions, owner, and expiry or review conditions | Unexplained retention or no plan for follow-up |
Before anything goes to the vendor, pull the contract and read the return-or-destroy clause as it was actually signed, not as the template reads. In this case it says:
In this example, the clause sets a 60-day return-or-destruction deadline and requires written confirmation. Check whether the agreement separately specifies when that confirmation is due. Silence about backups and subprocessors does not establish that they are excluded: review the complete agreement, data processing agreement and applicable requirements before deciding what you can enforce. Distinguish established obligations from additional evidence you are asking the vendor to provide.
Note the date obligations start running, name the person on your side who owns the close, and open the record. Everything from here goes in it.
A precise written request gives the vendor a defined scope and gives your team a basis for assessing the response. It does not guarantee a complete answer.
The directive sent on day one does five things:
The scope and evidence items are the six elements of the evidence standard: scope, subprocessors, method, timing, attestation and exceptions. Putting them in the request means the vendor is answering a defined question rather than guessing what you want.
The vendor offboarding checklist places this request within the wider termination process, including commercial close-out, access revocation and recordkeeping.
The account manager replies:
Confirming that your data has been deleted from our platform. Backups are retained for 30 days per our standard policy and will age out automatically. Let me know if you need anything further.
Run it against the six elements, and assess the gaps by what they mean rather than by counting them.
Two gaps decide whether this can close: subprocessors and attestation. Without the first you do not know whether the data is still held by a third party you have never contacted. Without the second you have not established that the sender has authority to make the required representation. The others matter but could be resolved with a short clarification.
Log the response, the assessment and the next request. The record now shows what was asked, what came back, and exactly where it fell short.
The follow-up is specific. It thanks the vendor, acknowledges the backup disclosure, and asks for four things by a stated date:
It also asks when the backup window starts and ends, what restrictions apply while backups remain, and how completion will be confirmed.
The vendor’s security lead provides a signed statement with their authority to make the representation established. It confirms production deletion on day 18, describes the deletion process for the primary database and object storage, and lists both subprocessors with their confirmation dates attached. It also states that development, staging, analytics and support environments retain no customer data.
One exception remains: isolated disaster recovery backups. The vendor explains that production deletion started a 30-day backup retention window, ending on day 48. Those copies cannot be selectively deleted under its backup design. They are restricted from routine use, and any recovery before expiry must reapply the deletion before the restored service is used.
Assessed again:
The privacy and security reviewers check the backup explanation against the agreement and applicable requirements. In this hypothetical example, they establish that the limited retention is permitted subject to the stated restrictions. They record the basis, the affected copies, the vendor’s controls, a named internal owner and a review on day 49. The owner must obtain confirmation that the backup window completed and address any missed deadline.
Documenting an exception does not make it acceptable. The decision depends on the obligation, the reason for retention, the controls and the risk. If those do not support acceptance, escalate the issue and keep it unresolved.
The record remains open pending backup completion. On day 49, the vendor confirms that the affected backup copies expired on day 48. The owner records and assesses that confirmation.
The owner reviews the file: the obligation, the directive, both responses, both assessments, the exception and its basis, and signs off. The record is complete and sits in one place. If an auditor asks about this vendor in eighteen months, it can be produced in minutes by someone who was not involved.
Notice what you have at the end. You have not seen the deletion happen. What you have is a documented assurance: a precise request, a signed statement from someone with authority covering every element you asked for, an assessment of it against a standard, and a documented resolution of the temporary backup exception. A reviewer can examine that process and its supporting evidence. Vendor-generated deletion logs can corroborate a statement, but they are not inherently independent or comprehensive. Independent verification requires attention to who performed it, what systems and copies it covered, and its limitations. For higher-risk vendors, establish appropriate evidence and verification rights in the contract before termination.
Three things made the initial one-line reply usable as the start of an assessment rather than the end of the process.
The directive carried the standard. Every element the vendor eventually provided was named in the first request. The second response was better than the first because the follow-up pointed at specific gaps, not because the vendor changed its mind about cooperating.
Gaps were weighed, not counted. The first response was missing or weak on five of six elements, but only two of those decided whether it could close. Resolving those two first kept the exchange short.
The exception had a follow-up decision. The team checked whether temporary backup retention was permitted, recorded its restrictions and owner, and obtained completion confirmation before closing. A review date created an action, not permission to retain data indefinitely.
This hypothetical process closed on day 50, within the example’s 60-day contractual deadline. The timing illustrates this agreement and scenario; your deadlines and escalation points should follow your own obligations and risk assessment.
If you want to know how your program would have handled this vendor, the Readiness Checklist scores the capabilities involved, from whether anyone would have sent the directive to whether the record would exist afterwards. Why certificates of deletion are not enough covers the first response above in more depth, and the vendor offboarding page sets this workstream in the context of the other four.
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.
