A useful deletion confirmation says what was deleted, from which systems, by what method, on what date, who did it, and what remains in backups until it ages out. It should also cover sub-processors. A one line email saying "your data has been deleted" is weak evidence.
Why ask for it
When you leave a vendor, you remain accountable for the data you gave it. If a regulator, customer or auditor later asks what happened to that data, a dated, specific confirmation is your answer. The GDPR requires a processor contract to provide for deletion or return of personal data at the end of services, and deletion of existing copies unless law requires storage. A confirmation is how you check that term was met. This is general information, not legal advice.
Fields to ask for
| Field | What good looks like |
|---|---|
| Scope | Account, workspace or tenant named exactly, with the data classes covered |
| Systems | Primary database, object storage, search indexes, caches, analytics |
| Method | Logical delete, overwrite or cryptographic erase, described plainly |
| Date and time | When deletion ran, and when it finished |
| Performed by | A named role or team, not just "the system" |
| Backups | Which backups hold copies, and the date the last one expires |
| Sub-processors | Whether each one deleted its copy, and when |
| Exceptions | Anything kept under a legal duty, and for how long |
| Verification | How the vendor checked, such as a query returning no records |
Method matters
NIST's media sanitization guidance defines sanitization as rendering access to target data on the media infeasible for a given level of effort. The current version, SP 800-88 Rev. 2, was finalised in September 2025 and supersedes Rev. 1, which has been withdrawn. It lists cryptographic erase among its sanitization methods. In cloud services you cannot see the disks, so the realistic question is not "did you shred the drive" but "can anyone still reach our data, and how do you know". Cryptographic erase, where the keys that decrypt your data are destroyed, is one answer. See crypto-shredding: when deleting the key deletes the data.
The backup gap
Deletion from live systems rarely removes data from backups at once. That is normal, as long as it is stated. Ask:
- How long do backups live?
- Is deleted tenant data restorable during that time?
- If a backup is restored, is the deletion replayed?
A vendor that can answer these has thought about it.
Request it in the contract
Put the field list into the agreement as an exit deliverable, with a deadline such as a number of days after the export window closes. Ask that the signer be someone able to speak to the facts, such as a security or privacy lead.
For the wider exit sequence, see what happens when you cancel a security platform.
How Safeguard fits
If you keep scanning on infrastructure you host, deletion is something you can perform and verify yourself. Safeguard supports SaaS, private VPC, on-prem and air-gapped deployments. The free scan is a way to look at outputs before committing.
Quick check
Does a certificate prove deletion?
It is a statement, not proof. It is still valuable, since it makes the vendor commit to specifics you can hold them to and show to auditors.
Do I need one for a free trial?
If you shared real repositories or user data, yes, ask for confirmation, even a short one. If you used only public code, it matters less.
Sources
- NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization
- NIST SP 800-88 Rev. 1 (withdrawn, superseded by Rev. 2)
- GDPR Article 28, processor
Last reviewed: 19 October 2026.
