What do teams get wrong about deleting data versus erasing data?

Why teams conflate deletion with erasure

Deletion is often treated as a user-interface action, while erasure is a data-handling outcome. That distinction matters because a record removed from an application can still exist in backups, snapshots, logs, replication sets, storage slack, or cached copies. The practical mistake is assuming the front-end control tells you what happened at the storage layer.

For security and governance, the key question is whether the data is merely hidden from normal access paths or actually rendered unrecoverable. That is why retention, disposal, and media re-use decisions need a clear method definition rather than a generic “delete” label. On shared systems, identity and access controls around API keys, service accounts, and other machine credentials can determine who can still reach residual copies after an application-level delete.

What “erasure” means in practice

Erasure is about making the data unrecoverable by ordinary and, where required, advanced recovery methods. That can mean cryptographic erasure, secure wipe, overwriting under a validated media sanitization process, or destruction of the storage medium when the risk profile justifies it. The right method depends on the medium, the sensitivity of the data, and whether the organisation must satisfy regulatory retention or destruction requirements.

The operational trap is that a method can be technically “deleted” but still fail an erasure objective. For example, removing a database row does not necessarily remove page remnants, transaction history, replicas, object versioning, or retained backups. Erasure therefore has to be designed as a lifecycle control, not treated as an application feature. For teams handling high-value credentials or secrets, the same lifecycle discipline that governs secret rotation and overprivilege also applies to how stored data is retired and made unrecoverable.

Where teams usually go wrong, and what to verify

Teams most often fail in three places: they delete the visible record but not the residual copies; they assume a storage vendor’s default retention equals erasure; or they lack evidence that the chosen method actually met the intended destruction standard. In practice, “delete” is often a workflow state, while “erase” is a control outcome that has to be evidenced.

What to verify is the full data path: primary storage, replicas, backups, logs, search indexes, object versions, export files, and downstream systems that ingest the data. If any of those locations retain recoverable content, the job is not complete. Where the concern is media retirement or sanitization, teams should align the removal method to the data class and the reuse plan, then keep proof of completion. Standards and control catalogues such as NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-57 Key Management support that evidence-first approach when cryptographic deletion or controlled destruction is part of the design.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.DS — Data Security	Deletion versus erasure is a data protection and destruction issue.
Recommendation — Classify data disposal methods and ensure residual copies are removed or rendered unrecoverable.
CIS Controls v8	8 — Audit Log Management	Logs and retained records often preserve deleted data remnants.
	3 — Data Protection	Erasure requires protecting data through its full lifecycle and sanitizing media before reuse.
Recommendation — Limit sensitive data in logs and verify retention settings do not preserve recoverable content. Apply media sanitization and disposal procedures that match the data classification and reuse plan.
NIST SP 800-63	AAL — Authenticator Assurance Levels	Identity controls matter when residual data remains accessible through retained access paths.
Recommendation — Use stronger authenticators and access controls where deleted content may still be reachable.

Practitioner Guidance

What to prioritise: Decide whether the business need is removal from a user-facing system or true irrecoverability. Those are different controls, different evidence sets, and different approval thresholds.

What to verify: Validate the exact storage and retention layers that can still expose residual data, especially backups, replicas, archives, and export paths. If the data can still be restored by an administrator or an attacker with access to retained media, it is not erased in the security sense.

Decision rule: If the data class is sensitive, regulated, or being retired for reuse of the underlying media, treat “delete” as insufficient unless the organisation can demonstrate a sanitization method that matches the risk and compliance requirement.

Practitioner takeaway: The right question is not “was it deleted?”, but “can it still be recovered, and from where?” If the answer is yes, the control objective has not been achieved.

#1 Authority in NHI Education, Research and Advisory, empowering organizations to tackle the critical risks posed by Non-Human Identities (NHIs), including AI Agents.