How to read an edtech privacy policy: a teacher's checklist

Every classroom tool arrives with a privacy policy, and nearly every one of them is written to be skimmed, trusted, and closed. You don't need legal training to read one well — you need to know which eleven questions the document must answer, and which soothing phrases are doing tricks. This page is the checklist we'd want every school to run on every vendor, including us. (Run it on us: wiz.kids/privacy.)

First, the two rules of reading

Rule 1: What's collected matters more than what's promised. Every downstream promise — security, sharing, retention — protects only what exists. Data never collected cannot be breached, subpoenaed, sold in a bankruptcy, or "shared with trusted partners." When a policy leads with promises instead of inventory, start at the inventory.

Rule 2: Read for what's absent. Privacy policies are written by people who know exactly what they're not saying. No retention period stated means "indefinitely." No deletion mechanism described means "email us and hope." Silence is an answer.

The eleven questions

1. Exactly what personal data is collected from or about a child? Look for a complete enumeration — names, emails, birthdates, photos, free-text fields (a child's free text is personal data the moment they type their address into it), voice, behavioral logs. Red flag: "information you provide to us" with no list.

2. Is any of it collected from the child directly, and is any of it optional? COPPA (US) conditions much of its machinery on collection from under-13s (COPPA for schools); the UK Children's Code expects default-off for anything non-essential.

3. What identifiers does an account require? "We need an email to create an account" is a design choice, not a law of nature — class-code-plus-pseudonym architectures exist (zero-PII architecture). Every required identifier should have to justify itself.

4. Is data "shared with third parties," and who are they, by name? "Trusted partners," "service providers," and "affiliates" are categories, not answers. Analytics SDKs and ad-tech embedded in the product ARE third-party sharing, whether or not the policy frames them as such. Ask for the subprocessor list.

5. Is there advertising, and is any of it behavioral? Any behavioral advertising in a child-directed service is a walk-away in most jurisdictions and all good judgment.

6. What happens to data if the company is sold or shuts down? The honest clause says data transfers with the business — meaning your pupils' data has whatever future the company does. Weigh accordingly; prefer vendors holding little enough for the question not to matter.

7. How long is data retained, in numbers? A real answer has units ("deleted N days after account closure"). "As long as necessary to provide the service" is not a number.

8. Can a school delete a child's data — themselves, immediately, verifiably? The gold standard is a delete button a teacher can press. A support-ticket process is silver. Nothing described is the actual answer.

9. Was any of it hashed and called anonymous? A special trap: "we only store hashed emails" sounds like non-collection. A deterministic hash of an identifier is a pseudonym, not anonymity — it can be matched by anyone who can hash a guessed email (the hashed-emails myth). Treat hashed identifiers as identifiers.

10. Is student data used to train AI models, or "improve our services"? "Improve our services" is where model-training lives when a policy doesn't want to say model-training. Post-2023, a child-data policy without an explicit answer on AI training is incomplete.

11. What does a breach cost your pupils? The synthesis question. List the data (Q1), assume the worst day, write down what's exposed. For most edtech: names + emails + birthdates + behavioral records of identifiable children. That paragraph is the vendor's real privacy posture — and the case for data minimization is that the best possible answer is "pseudonyms and star counts."

Phrases that sound protective but aren't

In practice

1. Run the checklist on your current stack, worst tool first — usually the free one nobody procured formally.
2. Make Q1 and Q11 the procurement summary for any new tool: a one-line data inventory and a one-line breach cost. Leadership decisions get instantly easier.
3. Keep evidence: save a PDF of the policy version you approved (see Q-phrase 6). Ofsted/DPO conversations go better with receipts.
4. Send vendors the unanswered questions. The answer's speed and specificity is itself diagnostic — good actors have these answers pre-written.

How Wiz Kids answers its own checklist

Inventory: no names, no emails, no birthdates — not from students or teachers, not even hashed; a student is a class code, a generated animal name and a picture-secret; progress data is pseudonymous skill records. Third parties: none — no analytics, no trackers, no external requests at runtime. Retention: teacher-initiated deletion is immediate and self-service. Breach cost (Q11): pseudonyms and star counts. This isn't virtue — it's architecture: we made the checklist easy to pass by making the data not exist.

Reference

• US Federal Trade Commission — Children's Online Privacy Protection Rule (16 CFR Part 312) and the FTC's COPPA FAQs for schools and ed tech.
• UK Information Commissioner's Office (2020). Age Appropriate Design Code (the Children's Code) — esp. standards on data minimisation and default settings.
• Future of Privacy Forum / Student Privacy Pledge — useful as a vendor-commitment baseline (and for noticing who hasn't signed).

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