ISACA CDPSE Training Course

Deletion is the stage most often claimed and least often verified. An organization that cannot demonstrate destruction cannot demonstrate storage limitation, cannot honor an erasure request, and holds data whose breach exposure it has not accounted for. This lesson covers what deletion means at each layer, from a row in a database to a decommissioned drive in a data center you have never visited.

Logical deletion is not destruction

Start with the layers, because a claim of deletion is meaningless without stating which one it refers to.

• Soft delete — a flag marking a record as deleted while the data remains. Useful operationally, not deletion in any privacy sense. If your erasure process ends here, you have not erased anything.
• Logical delete — the row is removed from the table, but the bytes usually persist until overwritten, and may be recoverable from transaction logs, undo segments, replicas, and snapshots for a considerable period.
• Overwrite — the storage locations are rewritten, which works on media where you control physical placement and is unreliable on media that relocates writes.
• Cryptographic erasure — the data was encrypted and the key is destroyed, rendering the ciphertext unrecoverable.
• Physical destruction — the media is destroyed so no data can be recovered from it.

Modern storage complicates overwriting. Solid-state drives use wear leveling and over-provisioning, so a logical overwrite may write to different physical cells and leave the originals intact until garbage collection. Copy-on-write file systems, log-structured storage, deduplicating arrays, and snapshotting all preserve prior versions by design. On virtualized and cloud storage you do not control physical placement at all. The consequence is that overwriting a file is not a reliable sanitization method on most contemporary storage, which is why the other approaches matter.

The NIST SP 800-88 model

NIST Special Publication 800-88 provides the standard vocabulary for media sanitization, with three levels chosen by the confidentiality of the data and whether the media will leave your control:

• Clear — apply logical techniques through the standard read and write interfaces to protect against simple non-invasive recovery. Appropriate for media being reused within the organization.
• Purge — apply physical or logical techniques that make recovery infeasible even with laboratory techniques. This includes device-level sanitize commands implemented in firmware, block erase, and cryptographic erase where the device performs it. Appropriate for media leaving your control but being reused.
• Destroy — render the media unusable and recovery infeasible: shredding, disintegration, incineration, or melting. Appropriate for the most sensitive data or where verification of a lesser method is not possible.

The publication's central discipline is verification and documentation. Sanitization should be verified, either on the full device or by representative sampling, and recorded — media identifier, method, tool and version, operator, date, and verification outcome — with a certificate of destruction where a third party performed it. Categorization drives the decision: assess the confidentiality of the data on the media, then select the level that reduces the risk of recovery to an acceptable point given where the media is going.

Cryptographic erasure

Where you do not control the physical media — a multi-tenant cloud, a managed database, a vendor's SaaS platform — you cannot shred a drive. Cryptographic erasure is the technique that fills the gap: encrypt data at rest, then destroy the key so the ciphertext cannot be decrypted by anyone including you.

Its effectiveness depends entirely on conditions that must hold:

• Everything was encrypted before it was written, with no plaintext copies elsewhere — including in caches, indexes, logs, and earlier backups taken before encryption was enabled.
• The key is genuinely destroyed in every location, including key backups, escrow copies, and any HSM replicas. A key you cannot enumerate is a key you cannot destroy.
• The key granularity matches the deletion granularity. This is the constraint that determines design. One key for an entire database lets you erase the database, not one subject. Per-subject or per-tenant keys let you erase a subject or a tenant, at the cost of managing many keys.
• The algorithm remains sound for the lifetime of the ciphertext, since the ciphertext may persist indefinitely.

Per-subject key design — sometimes called crypto-shredding — is a genuinely useful pattern for erasure in systems where physical deletion is impractical, and it is worth knowing as a design option. It moves the deletion problem into key management, which is a solvable problem with existing tooling, but it does add real operational complexity around key rotation, backup, and performance.

Deleting across the estate

A deletion request or a retention expiry must reach every copy: primary store, replicas, caches, search indexes, message queues and event streams, analytics warehouses, feature stores, exports, application and access logs, archives, backups, and every vendor that received the data. The prerequisites are the inventory and the flow map, which is why those lessons come first.

For each destination, decide the mechanism and the expected latency, then measure it. Deletion that is asynchronous is fine; deletion whose completion nobody verifies is not. Where a system cannot delete — an append-only ledger, an immutable log, a vendor without the capability — record it as an exception with a compensating control and a plan, rather than allowing the overall claim of deletion to quietly become false.

Backups and restoration

Backups generally cannot be selectively edited, and forcing the issue would compromise their integrity as recovery artifacts. The accepted approach is a documented suppression process: record the deletion in a suppression list, and on any restore, re-apply the deletions before the restored data becomes available for use. Combine this with short backup retention so the window in which the data exists is bounded, and disclose the approach in your response to the individual rather than claiming an immediate complete erasure you did not perform.

Evidence

Design deletion to produce records: what was deleted, from which systems, when, by what trigger, what failed, and what was suppressed rather than removed. Retain those records for the period you might be asked about them — noting that the record should identify what was deleted without itself reproducing the personal data, since a deletion log full of the data you deleted is a defect of its own. Then test end to end periodically: create a test subject, propagate it through the estate, delete it, and search every registered store for the identifier. The systems it turns up in are your real deletion gaps.