A delete request returns success in a few milliseconds. What that response confirms is narrow: the namespace will no longer return the object on a read. It says nothing about whether the bytes still sit on disk, whether a replica at another site has caught up, whether last night's backup holds the same content, or whether a cache will serve it for another hour. An auditor asking for proof of erasure is asking a different question from the one the API answered.
Regulation tends to phrase erasure as an outcome. Data must no longer be held, or must be rendered permanently inaccessible, within a defined period. No mechanism is described, which leaves storage teams to decide what counts as done. The gap that opens is between an object being unreferenced, which happens immediately, and an object being unrecoverable, which happens later if at all.
Closing that gap means knowing every place a copy rests, what each place does on a delete, and which of them emit a record. Systems differ in all three, and the differences are invisible from the API.
What a delete marker actually removes
In a versioned bucket, a simple delete does not remove anything. It writes a delete marker that becomes the current version, and the previous versions remain addressable by version identifier to anyone holding the right permission. The key disappears from a default listing, which is what most people check, while the data remains fully readable. Permanent removal requires deleting each version explicitly, or a lifecycle rule that expires noncurrent versions after a defined period.
That period is the one to establish precisely, since it sets the real deletion latency for the whole platform. A noncurrent version expiration of thirty days means an erasure request completed today is not complete for a month, and the capacity those versions occupy is the same capacity examined when tracking where hidden versioning capacity goes. Object Lock complicates matters further: a version under a retention period cannot be deleted before that period ends, by design, and an erasure obligation arriving earlier has no storage-layer answer.
Copies that outlive the namespace entry
Durability schemes exist to make data survive deliberate loss of hardware, which means they also make it survive attempts to remove it. A replicated object exists as whole copies on several nodes, each removed by its own operation. An erasure-coded object exists as fragments spread across nodes and often across sites, and reconstruction needs only a subset of them, so a stale fragment set can stay readable after most fragments are gone. The tradeoffs between the two schemes are covered in erasure coding versus replication, and they apply to deletion as much as to durability.
Space reclamation is usually asynchronous. A delete marks storage reusable and a background process reclaims it on its own schedule, under its own load constraints. Until it runs, the blocks remain on the media. Cross-site replication adds lag, and a delete propagated to a remote site queues like a write. A drive removed from service during that window carries whatever was on it at removal, which is why media disposal procedures belong in the same document as deletion procedures.
Backups, snapshots and derived copies
The copies most likely to be forgotten are the ones made deliberately for protection. A backup taken before the delete request contains the object, and immutable backup storage is specifically designed so that nothing, including an erasure request, can modify it before its retention expires. Snapshots hold point-in-time state by the same logic. Neither responds to a delete issued against production, and the honest answer is usually that the data persists until the retention schedule expires it.
Derived copies are the second category. Content delivery caches hold objects for their configured lifetime. Search and metadata indexes hold object names, sizes and user-defined attributes, which may themselves be the personal data in question. Analytics extracts, logs recording request payloads, and test environments refreshed from production all hold material nobody classifies as storage. Tracing them is the same exercise as mapping where backup copies reside, applied to a deletion obligation rather than a residency one.
| Deletion claim | What the system can evidence | What it cannot evidence |
|---|---|---|
| Object no longer served | Read returns not-found, key absent from listings, timestamped | Whether noncurrent versions or delete markers still hold the content |
| All versions removed | Empty version listing for the key, plus the lifecycle rule that expired them | Whether remote sites have converged on the same state |
| Capacity reclaimed | Reclamation job records and free-space change on the affected pool | Whether specific blocks were overwritten on specific drives |
| Copies expired everywhere | Retention schedules and expiry dates for backups and snapshots | Whether an immutable copy still holds the object until its lock ends |
| Key destroyed | Key manager audit entry for the deletion, and the objects bound to it | Whether a key copy survives in an escrow, backup or exported bundle |
Crypto-shredding and what it changes
Where physical erasure cannot be demonstrated, destroying the key is the usual alternative. Ciphertext without its key is treated as inaccessible, so the obligation is met by removing a small object rather than by chasing a large one across replicas and archives. The approach is only as precise as the key scope, since a key covering an entire bucket cannot be destroyed to erase one tenant's objects. It has to be designed before the data is written, with keys issued per tenant, per dataset or per object.
The evidence question then moves to the key manager, which is better equipped to answer it, since key managers log creation, use and destruction and can enumerate what a key protected. It also moves the risk. Every copy of the key is now a copy of the data, including escrow copies, key manager backups and exported material, so the question of who controls the keys becomes the question of who can undo an erasure.
Where Scality RING fits
RING supports versioning and S3 Object Lock, so the behavior described above applies directly: a delete in a versioned bucket creates a delete marker, noncurrent versions persist until an explicit deletion or a lifecycle expiration removes them, and a version under a retention period is protected until that period elapses. Knowing which buckets have versioning and locking enabled is the first input to any deletion timeline.
Durability is selectable per policy between erasure coding and replication, and multi-site placement is configured by the operator, so the number of copies and their locations are known quantities rather than inferred ones. Self-healing repairs lost or corrupted data as a background task, and the same background model applies to reclaiming space, which means deletion completion is a scheduled outcome rather than an instantaneous one.
Because RING runs on the operator's own hardware in the operator's own facility, media disposal sits under the same control as the delete request. It emits operational metrics and logs that can be retained locally, which makes an evidence trail possible without asking a third party to produce records.
What to write down so deletion can be evidenced
Maintain a deletion map per dataset naming every location a copy reaches: buckets with their versioning and lock settings, replication targets, backup and snapshot schedules with retention periods, caches with their lifetimes, indexes, and analytics or test copies. For each entry, record what a deletion request does there, how long completion takes, and which log or report proves it. Locations with no answer are the finding.
State the platform's deletion latency as a number, derived from the longest retention period in that map rather than from the API response time, and reconcile it against the obligation the organization has accepted contractually or in a privacy notice. A published commitment shorter than the platform's actual latency is a defect in one document or the other.
Test the process on a schedule using a synthetic record placed deliberately in every one of those locations, then deleted through the normal request path. Verify its absence in each location, keep the output, and repeat after any change to replication topology, backup retention or lifecycle configuration.