Really deleting cloud data: how do you know for sure?

16 May 2026 · 8 min read · DeSnipperaar

The delete button in the cloud feels final. File gone from the interface, recycle bin emptied, done. But behind that single action lie different systems that each move at their own pace in actually deleting data. Replication between data centres, daily backups, logging systems, monitoring snapshots: all copies that do not automatically come along with the delete. For responsible organisations this is an important theme in retention policy and when phasing out a cloud provider.

Three layers at which a ‘delete’ operates

Layer 1: The application

What you see as a user. A document disappears from Drive, a record is ‘archived’ in a CRM, a mailbox is emptied. At this layer it is almost always the case that the data is only hidden; in the underlying database the record still exists, often with a ‘deleted’ flag.

Layer 2: The database

Records with a deleted flag are periodically really removed, sometimes after 30 days, sometimes after 90, sometimes only during a manual cleanup. Databases often use ‘soft delete’ to allow recovery from errors and to keep audit logs intact.

Layer 3: The physical storage

This is where truly unreadable destruction lies. On SSDs in a data centre the physical storage is only overwritten when new data takes its place; until that moment the old data lies in cells which the provider no longer considers occupied but which are physically still readable. How the distinction between wiping and destroying applies here, you can read in that article; for cloud there is also a fourth layer: replication.

What replication does

Cloud providers automatically replicate data across multiple data centres for reliability. That means: a delete must propagate across all replicas. AWS, GCP and Azure document that this happens within seconds to minutes for live data. But:

Backups have their own retention and often fall outside the delete chain.
Snapshots made for operational reasons are retained according to a separate cycle.
Logs and monitoring often contain data fragments in URL paths, payloads or error traces.
Cache layers can hold copies briefly, sometimes at CDN edge points.

Cryptographic erasure: an elegant shortcut

The modern approach in enterprise cloud is called cryptographic erasure. Data is stored encrypted; on deletion the key is destroyed instead of the data itself. Without the key the encrypted data is effectively random, which NIST 800-88 accepts as a form of Purge.

Advantage: the delete is instantaneous regardless of how many replicas exist, because the key is a single object. Disadvantage: you trust the provider to truly destroy the key and not retain a copy in a key management archive. For most customers and use cases that trust relationship is acceptable; for heavily regulated sectors it is reason to demand additional safeguards. Read more about the NIST and DIN standards.

What retention policy must record

Which data belongs to which retention period. See the GDPR retention cheat sheet for the statutory periods.
How long backups exist and what that means for ‘right to be forgotten’ requests.
What ends up in logs and audit trails and how long those are retained.
How your provider handles deletes: synchronous delete across all data centres, or asynchronous? Do you get evidence of that?
Cryptographic erasure options per service.

What your provider should deliver

A data deletion attestation on request, with date and scope.
NIST 800-88-compliant process for the physical layer (drive replacement, secure-erase).
Documentation of the backup cycle and how deletes propagate through it.
An SLA on delete time, not just on replication.
Standard contractual clauses under GDPR for cross-border cloud.

A delete button is an instruction, not destruction. Ask your provider explicitly for evidence that the instruction is also carried out at the physical level.

When cloud is not enough

For some data categories cloud destruction is not enough. Patient records, professional-secret domains or state secrets must reside on media whose physical destruction you can prove. Cryptographic erasure is then insufficient; you want to see the drive itself shredded. For on-premises hardware at end of life that is the standard route; read about how a hard drive is shredded.

Practical step-by-step plan for a phase-out

Inventory which data is in the cloud and which retention periods apply to it.
Determine whether cryptographic erasure suffices for your classification, or whether physical destruction is needed.
Request a data deletion attestation from your provider with date and scope.
For data outside the cloud (export files, own backups on USB or HDD): destroy physically.
Keep the attestation and certificate in your record of processing activities.

The cloud is watertight, but your on-premise backup USB is not.

We destroy your physical copies on site: USB sticks, HDDs, old backup tapes. With a certificate that aligns with your cloud attestation.