GDPR and children (GDPR-K): what European rules mean for school edtech

Scope note: plain-language guidance, not legal advice — and GDPR is the one regime where "consult your DPO" is not a formality: schools in scope have data-protection officers precisely for these calls. Non-EU readers should still care: GDPR set the global vocabulary, and its children's provisions shaped the UK Children's Code and Australia's incoming code.

The GDPR (2016, applying from 2018) contains no single "children's chapter" — instead, children's protections thread through the whole regulation, with Recital 38's plain statement of principle: children "merit specific protection" because they may be less aware of risks and rights. "GDPR-K" is shorthand for that thread. Here's what it means operationally for schools and the vendors they choose.

The pieces that matter for schools

Lawful basis — the part everyone gets wrong. Every processing of personal data needs one of six lawful bases (Art. 6). The famous children's provision — Art. 8's parental-consent requirement for under-16s (member states may lower to 13; the result is a European patchwork) — applies only when the basis is consent for "information society services offered directly to a child." Here's the practical twist: for school-directed edtech, consent is usually the wrong basis anyway — regulators have repeatedly noted consent is problematic where power imbalances exist (can a family really refuse the school's chosen platform?). Schools typically process under public task or legitimate interests, with the vendor as processor under an Art. 28 contract. Why teachers should care about this legal plumbing: it determines whose rules bind the vendor — a processor may act only on the school's documented instructions, which makes the contract, not the privacy policy, the operative document. Ask for the DPA (data processing agreement), not just the policy.

Data minimisation and purpose limitation (Art. 5) — collect only what's necessary, use it only for the stated purpose. The same principle as COPPA §312.7 and APP 3, here with the EU's enforcement weight behind it. The recurring edtech violation: "improve our services" as a purpose elastic enough to cover model training and product analytics (question 10).

Data protection by design and by default (Art. 25) — the architecture mandate: privacy-protective settings must be the default, and minimisation must be built in, not bolted on. This is the article that zero-PII architecture satisfies by construction, and the one most retrofitted products satisfy by paperwork.

DPIAs (Art. 35) — systematic processing of children's data at scale is squarely in required-impact-assessment territory. A vendor unable to share a DPIA (or its summary) for a children's product hasn't done the homework the regulation assumes.

Rights with school-specific texture: access (a parent asking "what does the platform hold on my child?" — the school must be able to answer, which means the school must know), erasure (Recital 65 gives deletion particular force for data collected in childhood), and portability. Note pseudonymised data (hashed identifiers included) remains personal data under Recital 26 — GDPR is the regime that settled that argument.

Breach notification (Arts. 33–34) — 72 hours to the authority; the calculus that makes empty inventories attractive is partly this clock.

The age-of-consent patchwork

Where consent is the basis (consumer apps, home use), Art. 8's age varies by country — 13 in some member states, 16 in others, with every value between represented. Practical takeaways: a vendor claiming simple pan-European compliance via one age gate is describing the problem away, and schools relying on the school-authority bases sidestep the patchwork for classroom use — one more reason the school-directed model, done properly, is cleaner than the bring-your-own-app model.

What GDPR-K doesn't do

It doesn't ban processing children's data — it prices and constrains it.
It doesn't make consent forms the answer — for schools, consent is usually the wrong tool entirely; contracts and lawful-basis discipline are.
It doesn't self-enforce — but its vocabulary (controller/processor, DPIA, minimisation) has become the international language of procurement, which is why this page matters outside Europe.

In practice

Ask for the DPA and the subprocessor list, not the privacy policy — for school use, they're the binding documents.
Locate the lawful basis for each tool in writing; "we have consent" from a vendor about school-directed use is a yellow flag showing the analysis hasn't been done.
Use Art. 25 language in evaluation: "what's the most protective default?" and "what exists only because a function needs it?" are questions vendors of well-built products enjoy answering.
Run the eleven questions — they were built to operationalize exactly these articles.

How Wiz Kids relates

Our answer is the same one COPPA and the APPs get, because it's architectural: no personal data from students or teachers means most GDPR machinery has nothing to attach to — no consent patchwork to navigate (nothing rests on consent), minimisation and Art. 25 satisfied by construction rather than configuration, erasure genuinely complete, and the breach clock guarding pseudonyms and star counts. For EU deployments, formal controller/processor documentation would still be prepared per school — the paperwork is lighter when the inventory is empty, but it is never zero, and we'd rather say that than pretend.

References

Regulation (EU) 2016/679 (GDPR) — esp. Arts. 5, 6, 8, 25, 28, 33–35; Recitals 26, 38, 65.
Article 29 Working Party / EDPB — guidance on consent (power imbalance), on Art. 25, and Opinion 05/2014 on anonymisation.
UK ICO — children's data guidance and the Age Appropriate Design Code (the GDPR-K thread made into design standards).

© 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.