Privacy officers in educational settings face a persistent challenge: misconceptions about what protecting children's data truly requires. These myths don't just create confusion, they lead to compliance gaps that supervisory authorities notice.
The following myths frequently appear in school privacy programs. They persist because they seem intuitive or worked in simpler contexts. But when you're managing health screenings, remote learning platforms, and parental access requests, intuition isn't enough.
Myth 1: "FERPA Covers Everything We Need"
Reality: FERPA establishes baseline protections for education records in the U.S., but it doesn't address the full scope of GDPR obligations if you're processing EU residents' data, and it creates dangerous blind spots even domestically.
FERPA focuses on directory information and educational records. It doesn't provide specific guidance on health data collection, biometric attendance systems, or the behavioral analytics embedded in many learning management systems. When you implement a new proctoring tool that captures webcam footage and keystroke patterns, FERPA won't tell you how long to retain that data or whether you need separate parental consent.
Your lawful basis analysis under Article 6, your Article 35 data protection impact assessment for high-risk processing, your processor agreements under Article 28, none of these map cleanly onto FERPA's framework. If you're treating FERPA compliance as your ceiling rather than your floor, you're building risk into every new technology deployment.
Myth 2: "Parents Can Consent for Everything"
Reality: Parental consent sounds straightforward until you examine what Article 7 actually requires: freely given, specific, informed, and unambiguous indication of the data subject's wishes.
Consider a "required" app for virtual classroom participation. If parents must consent to data processing that includes behavioral tracking, ad personalization, and third-party analytics just so their child can attend class, that consent isn't freely given. The GDPR doesn't recognize consent extracted through educational necessity.
You need a different lawful basis, typically Article 6(1)(e) (public task) for core educational functions, potentially Article 6(1)(f) (legitimate interests) for ancillary processing, but only after completing a legitimate interests assessment that demonstrates you've considered less intrusive alternatives. When Marc Groman and Amelia Vance discussed protecting children's privacy during COVID-dominated school years, this tension between parental rights and valid consent conditions was central to the conversation.
The practical implication: Stop using consent forms as a legal catch-all. Map each processing activity to its appropriate lawful basis, and reserve consent for genuinely optional services.
Myth 3: "Our Vendors Handle Their Own Compliance"
Reality: Article 28 makes clear that you remain the controller, which means processor non-compliance becomes your liability.
When you contract with an educational technology platform, you don't transfer your GDPR obligations, you extend them through a processor relationship. Your processor agreement must specify the subject matter and duration of processing, the nature and purpose of processing, the type of personal data, and the categories of data subjects. It must require the processor to implement appropriate technical and organizational measures, restrict sub-processor engagement without your authorization, and support your ability to respond to data subject rights requests.
Most importantly: you must actively verify these commitments, not just file the contract. When a parent submits a DSAR requesting all data the learning platform holds about their child, you're responsible for delivering a complete response within one month under Article 15. If your processor can't or won't provide that data, you're the one facing supervisory authority scrutiny.
The myth that "vendors handle compliance" collapses the moment you receive your first parental complaint or supervisory authority inquiry.
Myth 4: "We Can Figure Out Retention Schedules Later"
Reality: Article 5(1)(e) requires that you keep personal data no longer than necessary for the purposes for which it's processed. "Later" means you're already non-compliant.
COVID-19 created a retention crisis in schools. You're now collecting daily health attestations, temperature readings, contact tracing data, and remote learning session recordings. Each category requires a defensible retention period tied to a specific purpose.
Health screening data collected to prevent COVID-19 transmission serves an immediate safety purpose, it doesn't need to live in your systems for seven years alongside academic transcripts. Video recordings of virtual classes might support educational continuity during an absence, but that purpose expires weeks after the session, not years.
Without defined retention schedules, you're creating two problems: mounting storage costs and escalating breach risk. Every byte of unnecessary personal data is a liability in a personal data breach scenario. When you must notify a supervisory authority under Article 33, they'll ask why you were retaining data you no longer needed.
Build retention schedules before you deploy new collection, not after.
Myth 5: "Privacy Is the DPO's Job"
Reality: Article 39 defines the data protection officer's tasks as monitoring compliance, advising on obligations, and serving as the supervisory authority contact point. It doesn't make the DPO responsible for every privacy decision across your institution.
The confusion is understandable, schools often have lean privacy teams. But when you treat the DPO as the sole privacy owner, you create bottlenecks and diffuse accountability. The teacher selecting a new classroom app, the IT administrator configuring access controls, the nurse recording health data, they're all making privacy decisions whether they recognize it or not.
Effective school privacy programs distribute responsibility through clear policies and training. Your procurement team should understand processor agreement requirements before signing contracts. Your communications staff should know transparency obligations before drafting parent notices. Your security team should implement appropriate technical and organizational measures as standard practice, not special projects.
The DPO provides guidance and oversight. Your entire organization implements privacy.
What to Do Instead
Replace these myths with operational discipline:
Conduct a processing inventory. Document every system collecting children's data, the lawful basis for each processing activity, and the retention period. Update it quarterly, not annually.
Audit your processor agreements. Verify they meet Article 28 requirements and that processors actually comply with their commitments. Request evidence.
Build retention into procurement. Before you deploy any new technology, define how long you'll keep the data it collects and configure automated deletion where possible.
Train beyond the DPO. Identify privacy decision points across your organization and train the people making those decisions on their specific obligations.
Test your DSAR process. Submit an internal test request and measure how long it takes to collect data from all your systems. If you can't meet the one-month deadline internally, you won't meet it when a parent requests it.
Children's data deserves more than inherited assumptions. It deserves systems built on what the regulation actually requires.
