Retention is a security control
Retention defines how long data remains available for an operational, security, recovery, contractual, or historical need. Secure deletion ends access to data at the required assurance level. Both decisions depend on classification, purpose, recovery need, threat, storage technology, and every copy.
Long retention increases breach and misuse impact. Short retention can destroy evidence, recovery data, or required business state.
Copy and key inventory
Map primary records, replicas, caches, search indexes, queues, logs, exports, temporary files, browser storage, support bundles, analytics, snapshots, backups, disaster-recovery copies, and physical media. Record owners, expiry, deletion mechanism, restore behavior, and verification.
For encrypted data, map data keys, wrapped keys, root keys, copies, escrow, and recovery. Cryptographic erase can make ciphertext inaccessible by sanitizing the required keys, but only when the encryption and key inventory are trustworthy and no plaintext or key copy remains.
Deletion and sanitization
Use automatic lifecycle policy where possible. Delete application references and underlying data according to the storage semantics. Propagate tombstones or deletion events to downstream systems. Ensure a restored backup does not silently resurrect expired data without reapplying retention.
For media reuse or disposal, select clear, purge, cryptographic erase, or destruction according to the current NIST guidance and approved organizational standard. Verify the sanitization result and preserve non-sensitive evidence of what was sanitized, by whom, with which method, and when.
Failure and residual risk
Deleting a database row can leave replicas, logs, indexes, free pages, snapshots, and exports. Object-store versioning can retain old objects. A backup retention policy can outlive the primary record. Cryptographic erase fails when keys were copied, data was encrypted under a shared key that other data still needs, or plaintext exists elsewhere. Destruction can harm availability when the owner or dependency inventory is incomplete.
Pomerium boundary
Pomerium can produce access and decision logs. Operators control log export, storage, retention, backup, and deletion outside the service. Application owners control their records and copies. Removing a Pomerium route or user does not delete application data or external evidence systems.
Evaluation checklist
- Does every data class have a purpose, retention period, owner, deletion trigger, and recovery rule?
- Are primary, replica, cache, queue, index, log, export, snapshot, backup, and media copies inventoried?
- Does restore reapply deletions and current retention policy?
- Can cryptographic erase prove that every required key and plaintext copy is gone?
- Is the selected sanitization method suitable for the media and assurance need?
- Can the team verify deletion without retaining the sensitive data as evidence?
