Designing for GDPR From Day One
What “privacy-first” means when you actually build to it — and why so few vendors write it down.
May 20, 2026 — By Brent Miller
There is a recurring conversation in education circles about why student records are protected so much more weakly than medical records — why FERPA, the main US law, says so much about who can release a record and so little about consent, retention, secondary use, or what a student can actually do when their data is mishandled. It is a fair question, and it points at a real gap. But there is a quieter gap next to it that almost nobody addresses: there is very little written guidance for the vendors who genuinely want to do the right thing. Plenty of law tells you what not to do. Very little tells you how to build well.
When I designed Lesson Commons, I started from the GDPR rather than from FERPA — not because most of our users are in the EU, but because the GDPR is the strictest mainstream framework available. Build to it, and FERPA and COPPA largely fall inside the lines. Build to the loosest applicable law and patch upward, and you end up treating privacy as a liability to be managed instead of a property to be designed in. Here is what that choice actually produced, concretely.
1. The cheapest data to protect is the data you never collect
Data minimisation is the default, not the exception. We don’t collect geolocation, device fingerprints, or advertising identifiers. We don’t store raw IP addresses. We turned down keystroke analytics and webcam proctoring — both easy to build, both surveillance. Data you don’t hold cannot be breached, subpoenaed, or mishandled. The clearest statement of a privacy philosophy is the list of easy features you declined.
2. Don’t collect a child’s identity in order to teach them
The most consequential decision in the whole product is how a student logs in. Most platforms open with a registration form: name, email, password, verify email. For minors that form is a compliance problem — collecting a child’s email generally triggers parental-consent obligations under COPPA and heightened duties under the GDPR and national rules. So we removed it. A student signs in with two codes — the teacher’s code and their own auto-generated access code — under a short display name the teacher assigned beforehand. No email, no password, no account creation. Because we never ask for the email, we never have to justify holding it. The friction we removed for teachers and the consent burden we removed for parents are the same decision seen from two sides.
3. When you do need a signal, pseudonymise it and put it on a timer
Detecting account sharing needs some sense of where a session came from. Rather than store IP addresses, we store a salted, one-way hash — enough to tell that ten sessions came from the same place, never enough to recover the place. The salt is per-school, so nothing correlates across customers, and the hash is deleted automatically after 90 days by a job that runs every night whether or not anyone is watching. An automatic clock is the only retention limit that actually holds over years.
4. The school is the controller; we are the processor
In GDPR terms the school decides why and how student data is processed; we act on its instruction. That isn’t a label, it’s a boundary: we don’t repurpose student data for our own analytics, don’t sell or share it, and don’t train anything on it. Teachers accept a plain-language data processing agreement, and the platform ships separate privacy policies for teachers and for students rather than one document that serves neither.
5. Data subject rights are features, not promises
This is where a lot of EdTech quietly fails: the rights exist on paper, but honouring one means an engineer running ad-hoc queries. We built them in. There is a single operation that exports an individual student’s data — profile, group memberships, attempt history, relevant audit records — and it deliberately excludes the password hash and the IP hash, because handing back a security credential isn’t transparency. Erasure runs through dedicated deletion paths at the student, group, and teacher level, each a safe, auditable cascade rather than an uncontrolled wipe. Building these early keeps the schema honest: every place a student’s data can live has to be reachable by the export and removable by the deletion.
Why write any of this down?
Because “trust us” is not an answer when a teacher hands you a classroom of minors’ data, and because the vendors who want to do this well have almost no map to follow. So we are publishing ours. The full design notes — the principles, exactly what we collect and refuse to, and how access, export, and erasure work — live in our documentation, adapted from the internal architecture decision records we actually build from.
If you build EdTech and you’re trying to get this right, I’d genuinely like to compare notes. And if you think we’ve got something wrong, I’d like to hear that even more.
Lesson Commons is an educational software platform for teachers and trainers. The Editor, Learn platform, and LC-JSON open format are in active development. Follow updates at lessoncommons.com/news.
This article 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.