A good deletion answer states when deletion starts, what is covered (production, replicas, backups, logs, analytics), how it is done, and what proof the customer gets. In the cloud you rarely wipe a disk yourself, so describe logical deletion plus key retirement if you use per-tenant keys, and say how long backups take to age out.
What the question is probing
Contracts often say "return or delete customer data on termination." A reviewer wants to know that this is a process, not a promise. The risky answer is "we delete it", with no scope, no timeline and no evidence.
The five parts of a complete answer
- Trigger. Contract end, written request, or account closure.
- Window. How long you hold data after termination for export, then how long deletion takes.
- Scope. Primary database, read replicas, object storage, search indexes, caches, analytics stores, logs, support tools, and subprocessors.
- Method. Logical deletion, overwrite, or cryptographic erase.
- Proof. A written confirmation, with date and scope.
Backups deserve their own sentence. Most teams cannot edit a backup, so the honest statement is that data in backups is overwritten when those backups expire, and gives the retention period. State the period you really use.
Method and standards
NIST SP 800-88 covers media sanitization. It defines the goal as making access to target data on media infeasible for a given level of effort, and Revision 2, published in September 2025, supersedes Revision 1. Its keywords include secure erase and cryptographic erase. If you rely on a cloud provider's storage, your provider handles the physical media, and your answer should say that and describe what you control.
For multi-tenant systems, the OWASP Multi-Tenant Security Cheat Sheet notes that tenant specific encryption keys should be retired as part of offboarding, following the documented retention policy. If you use per-tenant keys, deleting the key can render that tenant's stored data unreadable. Only claim this if your design really encrypts each tenant's data under its own key.
Answer pattern
"On termination, customers have 30 days to export data. We then delete production data within a further 30 days and confirm in writing. Backups are overwritten as they expire, within 35 days. We also remove the customer from our subprocessors where they hold data." Replace every number with your real one, and only say what your system does.
Evidence to keep
- The written deletion procedure.
- A ticket or log entry for a past deletion.
- The backup retention setting.
- A template confirmation letter.
Pitfalls
- Forgetting analytics exports and support attachments.
- Promising immediate deletion while backups persist.
- Saying "secure wipe" for cloud storage you do not control.
- Not testing the process, so the first real request exposes gaps.
Quick check
Can we promise instant deletion?
Rarely. Backups and replicas take time to age out. Give honest windows for each store.
Is deleting a tenant key the same as deleting data?
It can make encrypted data unreadable if each tenant has its own key, but only claim it if your design works that way, and say how long keys and backups persist.
Safeguard's compliance and evidence automation can help you keep the procedures and proof together for audits. The free scan covers dependencies, not data stores.
Sources
- NIST, SP 800-88 Rev. 2, Guidelines for Media Sanitization: abstract, September 2025 publication, supersedes Rev. 1. Paraphrased.
- OWASP, Multi-Tenant Security Cheat Sheet: tenant key retirement at offboarding. Paraphrased.
Last reviewed: 19 October 2026.
