Does deleting an account actually delete student data?
Not always. Many policies promise to "delete or de-identify" on request, and the "or" is the whole question: delete destroys the record; de-identify strips the name and keeps everything else. Which one happens to a given record is often not stated, so ask before you assure a family the data is gone.
A family asks a platform to delete their student's account. The button says "delete." Somewhere in the policy, a different word does the actual work: "de-identify." Those are not the same promise, and a consultant reading the policy on a family's behalf needs to know which one is being made.
That gap is worth thirty seconds of attention before you tell a family their data is gone.
The pattern
Here is a pattern you will see across privacy policies, composite phrasing rather than a quote from any one vendor: "when you delete your account, we will delete or de-identify your personal information." Read that sentence again. The word "or" is not a small connector. It is the entire question this explainer is about.
"Delete" means the record is destroyed. "De-identify" means the name and other obvious identifiers are stripped out, and the rest of the record, the school, the scores, the activities, the dates, is kept. A policy that promises one "or" the other has not told you which one happens to any given record, and it may not be the platform's choice to make clear, since backend systems can differ by data type.
The two promises, side by side
| "Delete" | "De-identify and retain" | |
|---|---|---|
| The record itself | Destroyed | Kept, minus name and email |
| Scores, school, activities, dates | Gone | Retained, often indefinitely |
| Usable by the platform afterward | No | Yes, commonly "for any purpose" |
| Re-identification risk in small groups | None | Real, see the small-group problem |
| What to ask the vendor | Confirm backups expire too | Which fields are removed, and is retention optional |
Why retention exists at all
There are ordinary, defensible reasons a platform keeps data after a deletion request, and it is fair to name them before drawing the distinction that matters. Backups need time to cycle out, sometimes called a backup-retention window, meaning the period before an old backup copy is overwritten by a newer one. Legal holds can require a company to preserve records tied to a pending dispute or investigation rather than delete them on schedule. Fraud prevention can require keeping some data to recognize a bad actor who is trying to sign up again under a different name.
None of these reasons implies bad intent. They are the kind of thing any operator of a system with real users has to plan for.
The distinction that matters is not whether retention happens. It is how long it lasts and what it becomes.
A bounded backup-retention window, say a fixed number of weeks until old backups roll off, is a different promise than indefinite de-identified retention kept for product use, model training, or analytics with no stated end date. The first is operational housekeeping with a known expiration. The second is a permanent asset built from a record a family believed they had deleted.
What survives is only as anonymous as the process is strong
A record that is "de-identified" rather than deleted is not automatically anonymous. What survives deletion is only as anonymous as the de-identification behind it is strong, and what "de-identified" actually means is its own question worth reading in full, since a name-and-email strip on an otherwise intact row is a much weaker promise than aggregation that removes any single student's row entirely.
What to ask
Four questions turn "delete or de-identify" from a shrug into an answer.
After a deletion request, what specifically remains, and for how long? Ask for the fields, not a summary description.
Do backups age out on a stated schedule? If the answer is vague, that is itself an answer: a schedule that cannot be stated is not a schedule.
Does deletion extend to subprocessors, meaning the other companies the platform shares data with to run parts of its service? A deletion promise that stops at the platform's own database is narrower than one that reaches every copy sitting elsewhere.
If data is retained as de-identified rather than deleted, is that retention bounded or indefinite, and for what stated purpose?
The practical takeaway
"Delete" and "de-identify and retain" describe two different fates for a student's record, and a policy that offers them joined by "or" has not committed to either one for any specific piece of data. Backups, legal holds, and fraud prevention are legitimate, time-limited reasons for a platform to keep something after a deletion request. Indefinite retention of de-identified data for product use is a separate practice with a separate justification, and it deserves a separate question.
Before you tell a family their student's data is gone, ask what remains after a deletion request, whether backups age out on a stated schedule, and whether deletion reaches the subprocessors that touched the data along the way. The checklist walks through these questions in order, alongside what "de-identified" actually means for the records that remain and how a company's bankruptcy or acquisition can override a deletion promise entirely.
Before the next vendor demo, print the nine-question checklist: the checklist.