What "de-identified" student data actually means
You delete a family's account. The platform's policy says the record is now "de-identified." That sounds like the data is gone, or at least anonymous. Often it just means the platform removed the fields that obviously name the student, then kept everything else, indefinitely, as its own asset.
That gap between what "de-identified" sounds like and what it actually does is worth thirty seconds of your attention before you upload anything.
What de-identification actually does
De-identification, in plain terms, is a process where a platform strips out the fields that directly identify someone, typically a name and an email address. The record that remains still travels through the platform's systems. It can still be analyzed, aggregated, or reused, often described in a privacy policy as being kept "for any purpose," because in the platform's view it is no longer personal data at all.
That is a real distinction from deletion, where the record itself is destroyed. De-identification is a relabeling, not a removal.
Why a few remaining fields are enough
Here is a composite example, not a real student: a 17-year-old cellist from a town of eleven thousand people, applying to conservatory programs, with a graduation year on file. Strip her name and email from that record. She is still findable.
A town that small, an instrument that specific, and a graduation year narrow the pool to a handful of people, often to one. Anyone who already knows roughly who she is, a competing consultant, a nosy relative, a data broker cross-referencing a public orchestra roster, can recombine those three ordinary-looking fields and land back on her name. None of the fields is sensitive by itself. Together, they function as a name.
This is the core problem with de-identification as most platforms practice it: removing the obvious identifiers does not remove the ability to identify.
Weak versus strong de-identification
Weak de-identification means dropping the name and email field and calling the rest of the row "de-identified." The record is still one row per student, with town, school, activities, scores, and dates all intact and linkable to each other. A clause like "we may retain and use de-identified information for any purpose" is a pattern you will see attached to this kind of processing; it is composite phrasing here, not a quote from a specific vendor.
Strong de-identification looks different. It means aggregating records so no single student's row survives (a report says "12 students from this region applied to music programs" rather than listing them), suppressing any group small enough to point back to an individual (a cell of one or two gets folded into a broader category or dropped), and never retaining a per-student row that can be re-linked later.
Most platform language does not tell you which of these two it means. That is the actual thing to find out.
What to ask a vendor
Three questions get past the word "de-identified" to what is actually happening:
Which fields are removed, specifically, and which remain? A name-and-email strip is not the same claim as a field-by-field list.
Is the retained data structured as per-student rows, or as aggregates with no individual row surviving? This is the weak-versus-strong question in one line.
Has anyone outside the company assessed the re-identification risk of what remains? A vendor's own internal judgment that data is "safe" is not the same as an outside assessment, and a policy that does not mention one has probably not had one.
The practical takeaway
"De-identified" is a claim about which fields were removed, not a claim that a student can no longer be picked out of the data. A composite of a handful of ordinary fields (town, activity, graduation year) can point back to one person just as reliably as a name does, especially for a student in a small town or a narrow specialty.
Before you accept a platform's use of "de-identified" data as a settled matter, ask what fields remain, whether the data is still per-student or has been genuinely aggregated, and whether anyone outside the company has checked. The checklist walks through exactly these questions. Two related reads: how small-group aggregates can still re-identify a student, and the real difference between deleting and de-identifying and retaining a record a vendor says it has "removed."
Bring this to your next vendor demo: the full checklist.