eduKateSG · Information · The Gold Standard of Education
Delete access by tracing every copy, key and recovery route
Choose the explanation you need, or follow all twelve chapters in order.
Full chapter index · Independent practice · Information subject guide
Pressing delete often removes a name or reference, not every recoverable representation of the data. Blocks can remain on storage media, object versions can persist, replicas and backups can outlive the primary copy, and caches or exports can sit outside the original system. Secure deletion begins with an inventory of those representations and a clear confidentiality objective.
Cryptographic erase makes encrypted data infeasible to recover by sanitising the keys required to decrypt it, under strict conditions. “Crypto-shredding” is a common descriptive phrase, but the evidence must name the actual keys, algorithms, copies and key-management controls. Destroying one wrapper key is not enough if another path still reaches a usable data key.
The teaching examples below are invented. Sanitisation decisions must follow the applicable organisational policy, current standards, legal holds and media-specific guidance. This article explains reasoning, not a universal deletion command.
Continue from The Gold Standard of Information within The Gold Standard of Education: learning that transfers into life and the How X Works learning library.
Full chapter index
See the mechanism · Chapters 1–2
Build the worked model · Chapters 3–5
Test what changes · Chapters 6–8
Check evidence and limits · Chapters 9–10
Practise and continue · Chapters 11–12
CHAPTER 1 OF 12 · See the mechanism
1. Distinguish logical deletion from sanitisation
Logical deletion changes an application state: a record disappears from ordinary use. Sanitisation aims to make access to target data infeasible for a stated level of effort. Physical destruction renders media unusable through an approved process.
These outcomes differ. A database row marked deleted can remain in transaction logs. A cloud object can be hidden by a delete marker while older versions remain. An account closure can leave lawful backups.
Write the target precisely: which data, whose copies, which systems, by what deadline and against which recovery capability.
Evidence check: for Distinguish logical deletion from sanitisation, preserve the observation before the interpretation. Record the exact erasure unit and tolerated failure domain. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Start at creation and follow the data through primary storage, replicas, snapshots, backups, search indexes, analytics extracts, endpoint downloads, message queues and support exports.
For encrypted data, add the dependency chain: ciphertext, data-encryption key, key-encryption key, key versions, recovery escrow, hardware security module backups and cached plaintext. A deletion plan that inventories files but not keys is incomplete.
Assign an owner and retention rule to every route. Unknown copies should be recorded as gaps, not silently treated as absent.
Evidence check: for Build a copy and dependency inventory, preserve the observation before the interpretation. Record k, m, shard order and coding profile. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 3 OF 12 · Build the worked model
3. Understand cryptographic erase from first principles
Suppose data D is encrypted under a strong data key K and only ciphertext remains. If every usable copy of K is sanitised or made inaccessible under the required assurance, recovering D becomes infeasible without breaking the cryptography.
The conclusion depends on prior encryption, algorithm strength, key uniqueness, correct implementation and complete key coverage. Data written before encryption or copied in plaintext does not become sanitised when K disappears.
Cryptographic erase can be fast because it changes a small key dependency rather than overwriting every ciphertext block. Speed does not relax the assurance conditions.
Evidence check: for Understand cryptographic erase from first principles, preserve the observation before the interpretation. Record which position is missing and which values remain valid. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 4 OF 12 · Build the worked model
4. Work through an envelope-encryption example
Imagine 10,000 customer objects, each encrypted with its own data key. Those keys are wrapped by regional key-encryption key R7. Deleting R7 would affect all objects sharing it, not one selected customer.
If the target is one customer, identify and sanitise that customer’s data keys or use a key hierarchy designed for that boundary. If one data key protects mixed-customer data, the architecture cannot selectively erase one customer cryptographically without rewriting the shared data.
Check old wrapped-key versions, backup catalogues and disaster-recovery replicas. A rewrapped data key under R8 remains usable even after R7 is destroyed.
| Asset | Protected by | Copies | Deletion implication |
|---|---|---|---|
| Customer A objects | Data keys A1–A100 | Primary and replica | Sanitise all usable A keys |
| Customer B objects | Data keys B1–B80 | Primary and replica | Must remain usable |
| All wrapped keys | Regional wrapper R7 and rewrap R8 | Two regions | Deleting R7 alone is insufficient |
| Plaintext support export | Support access control | One retained export | Outside cryptographic path |
Evidence check: for Work through an envelope-encryption example, preserve the observation before the interpretation. Record survivor count and independence of repair equations. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Deletion granularity follows key granularity. Per-record keys enable narrow actions but create more key-management state. Per-volume keys simplify management but make selective erase impractical.
Define cryptographic domains before collecting data: tenant, dataset, record, device or retention cohort. Keep domains from crossing legal or operational boundaries that may need independent deletion.
Do not promise selective crypto-shredding where one key protects unrelated retained data. The correct remedy may be migration into better-separated domains.
Map operational boundaries as well as logical ones. A per-tenant key is only independent if its backups, recovery wrapping and access controls remain tenant-specific. If every tenant key can be reconstructed from one unrestricted recovery export, the practical deletion boundary is wider than the application diagram suggests.
Test the architecture before relying on it. Create disposable records, execute a scoped erase and attempt recovery through every supported path. This exposes shared dependencies while the data is harmless and the design can still change.
Evidence check: for Treat scope as a design property, preserve the observation before the interpretation. Record field, matrix, padding and interoperability tests. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 6 OF 12 · Test what changes
6. Account for residual plaintext and derived data
Applications may cache plaintext in memory, temporary files, swap, crash dumps or local exports. Search indexes and machine-learning features may contain derived information even when the original record is gone.
Classify each derivative. Some are reversible copies; some are aggregates; some are independently retained records. The deletion decision depends on sensitivity, purpose and policy, not just byte equality.
Use design controls that minimise plaintext lifetime: bounded caches, encrypted temporary storage, controlled exports and automatic expiry. Prevention is more reliable than discovering unmanaged copies later.
Evidence check: for Account for residual plaintext and derived data, preserve the observation before the interpretation. Record source-block and symbol identifiers. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 7 OF 12 · Test what changes
7. Handle backups, snapshots and object versions honestly
Immutable backups protect recovery and can conflict with immediate physical removal. A defensible design may prevent restoration into production after a deletion request, expire affected backups on schedule and reapply deletion tombstones during recovery.
Record the residual window. “Deleted now” should not mean “absent from the primary interface while restorable for ninety days” unless that limit is clearly stated to the responsible decision-maker.
Snapshots can share storage blocks. Deleting the current logical object may not remove historical references. Confirm behaviour with the storage provider’s documented semantics and a recovery test.
Evidence check: for Handle backups, snapshots and object versions honestly, preserve the observation before the interpretation. Record integrity verification before and after decoding. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
A key-deletion API call needs strong authorisation, separation of duties where appropriate, idempotency and an audit trail. Accidental or malicious key destruction can create irreversible data loss.
Use a state machine such as requested, approved, executed, verified and closed. Bind every step to the exact cryptographic domain and key identifier.
Do not log secret key material. The audit should prove which authorised operation occurred without creating another sensitive copy.
Evidence check: for Protect the erase operation itself, preserve the observation before the interpretation. Record physical placement and correlated failure. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 9 OF 12 · Check evidence and limits
9. Validate rather than trusting a success message
Verification asks whether the target data remains recoverable through any allowed route. Test primary reads, version access, snapshot restoration, backup recovery and alternate-key paths as appropriate.
A failed decryption proves only that one attempted path failed. Confirm that the ciphertext uses the intended key and that no duplicate plaintext or replacement key exists.
Sample-based validation can support large systems, but define the sampling frame, error response and escalation. Preserve evidence for the required retention period.
Verification should be independent enough to challenge the execution record. If the same component reports that it deleted a key and then reports that the key is absent, a configuration fault can satisfy both messages. A separate inventory, recovery service or controlled restore exercise provides stronger evidence.
| Route | Test | Pass condition | Residual risk |
|---|---|---|---|
| Primary object | Read after deletion | Unavailable | Version may remain |
| Object history | Read old version | Unavailable | Provider semantics |
| Snapshot | Restore isolated copy | Target absent or inaccessible | Shared blocks |
| Backup | Approved recovery rehearsal | Deletion reapplied | Retention window |
| Alternate key path | Decrypt with recovery key | Fails as designed | Escrow inventory |
Evidence check: for Validate rather than trusting a success message, preserve the observation before the interpretation. Record scrub interval, repair load and reduced-redundancy time. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Deleting a key is not magic deletion. Weak encryption, reused keys, escrow copies, plaintext derivatives or compromised endpoints can defeat the claim. Rotating a key for future writes does not erase old data.
Overwriting is not universally reliable across modern storage layers because wear levelling, remapping and virtualisation can hide physical locations. Use current media-specific standards and approved tools.
Legal holds, incident investigations and regulated retention can change what may be deleted. Record authority and scope before execution.
Evidence check: for Limits and common misconceptions, preserve the observation before the interpretation. Record metadata version, catalogue and recovery history. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 11 OF 12 · Practise and continue
11. Independent practice and changed-context transfer
Practice case: a tenant’s files use unique data keys, but all keys are backed up and rewrapped under two regional master keys. List the key paths that must be addressed before claiming cryptographic erase.
Changed context: the tenant exported a plaintext archive to a managed support system. Explain why key sanitisation in the primary platform cannot cover that archive and how the inventory should route the action.
Then reverse the problem. Design a key hierarchy for records with seven-year retention cohorts and individual early-deletion requirements. State the trade-off between isolation and operational complexity.
Evidence check: for Independent practice and changed-context transfer, preserve the observation before the interpretation. Record the failure pattern that exceeds the promise. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Is emptying a recycle bin secure deletion?
Usually it is logical deletion from ordinary access. Sanitisation requires evidence about media, copies, recovery routes and the threat model.
Is key rotation the same as cryptographic erase?
No. Rotation can direct future use to a new key while old keys remain available. Erase requires sanitising the relevant key material and alternate access paths.
Can backups remain after deletion?
Policy and law determine the permitted residual window. Operational controls must prevent deleted data from silently returning during restoration.
Continue with envelope encryption and key rewrapping and forward secrecy and compromise windows.
The primary current reference is NIST SP 800-88 Revision 2, Guidelines for Media Sanitization, published in September 2025. Its cryptographic-erase guidance explains the key-sanitisation conditions and program controls; media-specific techniques may require other approved standards. Sources and links were checked on 22 October 2026.
Evidence check: for FAQ, sources and connected reading, preserve the observation before the interpretation. Record a test fixture decoded by the future system. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Contents · Previous chapter · Return to the Information guide