Deletion in practice: what "we deleted it" actually means

Evidence grade: technical fact plus regulatory guidance. How deletion actually works in production systems is engineering reality, not controversy; the guidance layer (OAIC on APP 11 destruction, ICO on erasure) confirms the asterisks this page names. The point is not cynicism — real deletion exists — but that the phrase needs unpacking before it can be trusted.

"We delete student data when the school leaves." Every vendor says it; contracts require it; rights demand it. But deletion in a real system is not one act — it's a set of acts across copies the phrase quietly aggregates, and the gap between the sentence and the set is where student data actually lives on. Knowing the anatomy turns "we delete it" from a reassurance into a checklist.

The anatomy: where copies live

The live database — what naive deletion deletes. Necessary, nowhere near sufficient.
Backups — every responsible system keeps them, which means every responsible system cannot delete instantly from all copies: deleted records persist in backups until those age out. Honest vendors say so and name the window ("removed from live systems immediately; backups expire within N days"); the absence of a backup asterisk in a deletion promise is a warning sign, not a comfort — it usually means the person writing the promise didn't ask engineering.
Logs — access and application logs capture identifiers and behavior as a side effect; log retention is deletion's forgotten corner.
Derived data — analytics aggregates, profiles, model features, and (the new asterisk) anything trained into an AI model, which cannot be un-trained by deleting the source row. The vendor questions ask about training for exactly this reason.
Third parties — every SDK data flow created copies outside the vendor's ability to delete at all; deletion promises silently scope to data the promiser still controls.
The anonymisation dodge — "we don't delete, we anonymise" is legitimate only if the anonymisation is real, and the re-identification literature says it usually isn't: stripping names from rich behavioral records produces pseudonymous data wearing an anonymous label. "Anonymised" retained data deserves the same scrutiny as retained data, because that's what it is.

The questions that expose the real policy

"Deleted from live systems in what timeframe — and from backups in what timeframe?" Two numbers or it's not a policy.
"What survives deletion — logs, aggregates, derived data — and for how long?"
"Has any of it been used to train models, and what happens to that?"
"Can you confirm completion in writing, per deletion?" — the confirmation habit turns promises into records.

Making deletion routine (schools)

Deletion managed as an event (a family demands it; a vendor exit turns forensic) is expensive and rare; deletion managed as a calendar is cheap and reliable: leavers' data offboarded each year-end alongside reports, retired tools purged at the annual register review, retention schedules with actual dates (APP 11 requires destruction or de-identification when data's purpose lapses, as does Victoria's IPP 4.2 for government schools — duties with no event trigger, only a calendar one). The minimisation corollary applies with special force: everything never collected is deletion pre-completed.

What this doesn't say

It doesn't condemn backup windows — they protect students' data too (against loss and ransomware); the sin is hiding them, not having them.
It doesn't make deletion impossible — bounded windows, scoped logs, no third-party flows and no model training make "deleted means deleted, within N days, everywhere" an achievable, checkable sentence. (Ours: teacher-initiated deletion is immediate in live systems, with short, stated backup expiry — and nothing personal in the records to begin with, which shrinks what deletion even has to mean.)
It doesn't put the audit on families — rights-holders ask the four questions; schools hold the contracts that make answers mandatory.

References

OAIC — APP 11 guidance on destruction and de-identification of personal information no longer needed.
UK ICO — right-to-erasure guidance, including backup-system treatment ("beyond use" standards).
Article 29 Working Party (2014). Opinion 05/2014 on Anonymisation Techniques — why "anonymised" retention usually isn't.

© Glu IO Pty. Ltd. — Wiz Kids (wiz.kids). Link freely; republication requires permission — see terms. Found an error in our reading of the research? We correct fast: tell any teacher piloting Wiz Kids.