Data Subject Rights in Practice
Access, export, and erasure as features that ship — not promises in a policy.
Most privacy policies describe data subject rights as something you exercise by emailing an address and waiting. That is where a great deal of EdTech quietly falls down: the rights exist on paper, but honouring them means an engineer running ad-hoc database queries, which is slow, error-prone, and itself a privacy risk. Our position is that a right you cannot exercise through the product is not really a right the product respects. So access, export, and erasure are built in.
Information requests and access (GDPR Article 15)
A data subject is entitled to know what is held about them and to receive a copy. In Lesson Commons this is a single operation that assembles a complete export of an individual student’s data: their profile, the groups they belong to, their full attempt history and scores, and the relevant audit records of their own activity. It runs as a defined use case in the application, not as a manual query, which means every request returns the same complete, consistent result.
Two design decisions matter here:
- Two doors, one mechanism. The same export can be initiated by a teacher on a student’s behalf or, where enabled, by the student self-service. Different people, identical underlying operation — so a self-service request is never a thinner or different answer than an administrator-run one.
- We export the person’s data, not the system’s secrets. The export deliberately excludes the password hash and the pseudonymised IP hash. Neither is meaningful personal information to hand back — a password hash is a security credential, and an IP hash is a one-way value that identifies nothing on its own — and exporting them would weaken security while adding no transparency. Article 15 is about giving people their information, not dumping internal storage.
Deletion requests and the right to erasure
Erasure is where “privacy-first” claims are actually tested, because deletion in a relational system is rarely one row. A student belongs to groups, has an attempt history, has audit entries. Deleting carelessly either leaves orphaned fragments behind (the data you swore you removed) or breaks referential integrity elsewhere.
We handle this with dedicated deletion use cases at three levels, each performing a safe, auditable cascade rather than an uncontrolled wipe:
- Delete a student — removes the individual and their associated records.
- Delete a group — removes a class and cascades to its members’ data.
- Delete a teacher’s data — removes an account and the data under it.
Because activity records reference a student by internal identifier and the name lives only on the roster (see What We Collect), erasure is a contained operation with a known blast radius, not a search-and-destroy across the whole database. The cascade is designed once and exercised the same way every time, which is what makes a deletion request something we can honour reliably rather than heroically.
Archiving versus deleting: two different outcomes
“Getting rid of” a class can mean two genuinely different things, and conflating them is how data quietly leaks out the back of a system. So we separate them explicitly.
- Archiving is for a class that has simply finished — the term ended, the group is done. The group and its students move to an inactive state: logins stop, the class drops out of active views, but the academic record is deliberately kept, because a teacher may legitimately need last term’s scores. Archived classes appear in a read-only “Archived Groups” view, summarised at the group level; the individual student records behind that view are retained intact — they are simply no longer live or editable. Archiving is one-way: there is no quiet re-activation, which keeps the audit trail honest.
- Deleting is removal. A class that never accumulated any student work can be hard-deleted outright. A class that does hold student attempt data cannot be silently hard-deleted — the system requires you to archive it instead, so that real academic records are never destroyed by an offhand click. Genuine erasure of that data is handled through the deletion paths above, as a deliberate act with a recorded reason.
The point of the split is that the easy, everyday action (clearing finished classes off your screen) is non-destructive by default. Destroying data is always the explicit, harder-to-do path. Most accidental data loss in software comes from the reverse arrangement.
Holding periods and automatic expiry
Erasure on request is necessary but not sufficient. The strongest retention guarantee is the data that expires without anyone asking. As described in the activity-data note, the most sensitive signal we hold — the pseudonymised IP hash — is purged automatically after 90 days, independent of any request. Beyond that, different data has a different lifetime:
- Security data — 90 days. Pseudonymised IP hashes are deleted on a fixed schedule, whether or not anyone is looking.
- Archived class records — bounded retention (planned). When a class is archived rather than deleted, its academic records are kept so a teacher can refer back to them. The intended end state is that after a defined window (roughly one academic year) the individual records are aggregated into anonymous group summaries and then removed. During the current beta those records are retained in full — this scheduled conversion is part of the retention automation still being finalised, and when built it will honour the legal-hold window below before removing anything.
- Closed accounts — 30-day export grace, then deletion. Our Terms of Service commit to this in writing: after an account is terminated you can export your materials for 30 days, after which the data is permanently deleted.
- Law-violation terminations — one-year legal-hold. The one exception, again stated in the Terms: if an account is terminated for a violation of applicable law, the data is retained for one year so that a competent authority can request it, and is then permanently deleted. This is a narrow, named exception — not a general “we keep everything” clause — and it exists because a blanket right to erasure that overrode a lawful preservation request would itself be a problem.
The principle holds throughout: security data expires on a clock, educational data expires with the relationship or shortly after, the rare legal-hold case is explicit and time-bounded, and nothing is kept “just in case” forever. The retention commitments above are written into our Terms of Service; the automated jobs that enforce the longer windows down to the day are being finalised for our full release, with the shorter security purge already running.
Objection, and not relying on un-refusable consent
We process student activity under legitimate interest rather than consent, which carries a corresponding right to object. Because the school is the data controller, objections and unusual requests are routed through the school, which knows the pupil and their circumstances, with Lesson Commons providing the technical means to act. We think this is the honest arrangement: the party with the relationship and the legal responsibility makes the call, and the processor gives them real tools — export and deletion that actually work — to carry it out.
Why build all this for a beta?
Retrofitting data subject rights onto a system that wasn’t designed for them is painful and usually incomplete — you discover the copies of personal data you forgot about precisely when someone asks you to delete them. Building export and erasure early forces the schema to stay honest: every place a student’s data can live has to be reachable by the export and removable by the deletion. The rights are a feature for users and a discipline for us.
This note is adapted from Lesson Commons’ internal architecture decision records. It describes design intent and current implementation; it is not legal advice, and exact behaviour evolves as the platform develops. Schools remain responsible for their own data-protection obligations as controllers.
This document was written with the assistance of Claude (Anthropic). The author defined the purpose, audience, and main ideas, directed the editorial approach, and edited the final text.