AEPD Resolution: EXP202406420

The Incident (The "Digital Classroom Trap"): A parent filed a complaint with the AEPD on 24 April 2024 against a private British-system Catholic school in Madrid (referred to here as "the School"). The parent alleged that the school had been using Google Workspace for Education (GWE), specifically its free "Fundamentals" version, to educate their primary-school-age children without providing adequate information about the platform's data processing. The parent claimed their children, enrolled in primary education, could access non-educational content such as YouTube and video games through the platform, and that the parent had never received proper information about its use.

The Institutional Setup: The School had been using GWE since the 2021/2022 academic year. A total of 531 students had nominative (personally identifiable) accounts, of whom 395 were under 14 years old and 136 were over 14. Students from Year 2 onwards were given personal accounts using the format initial+surname@student.hmschool.es. The school provided Chromebook devices, shared from a trolley for younger pupils (Years 1-6) and individually assigned from Year 7 upwards.

The School relied on Google's core services: Classroom, Drive, Docs, Gmail and Calendar. It claimed that all "additional services" from Google were disabled and that it used monitoring software (GoGuardian) to supervise student activity. The School argued it had informed parents through enrolment documents, start-of-year meetings and an ICT policy document available on the parent communication platform (iSAMS, later migrated to a new app).

The AEPD Investigation: Three Critical Failures

The AEPD's investigation uncovered three distinct violations:

1. No Valid Legal Basis (Article 6.1 GDPR): The School claimed its legal basis for processing children's data through GWE was "compliance with a legal obligation" under Article 6.1(c) GDPR, citing Spain's Education Act (LOE) and LOPDGDD. The AEPD accepted that educational legislation can legitimise certain data processing but found a fundamental problem: the actual data processing went far beyond what is necessary for education. Google's own privacy documentation revealed that, even for "core services," data is collected not just to deliver the educational service but also to "formulate recommendations," "optimise usage," "provide and improve other services" and "provide support." These purposes serve Google's commercial interests, not the school's educational mission. The AEPD ruled that a legal obligation to provide digital education does not automatically legitimise every form of data processing that a chosen technology platform performs. The School, as data controller, bears responsibility for selecting a tool whose processing activities exceed the educational purpose invoked as the legal basis.

2. Lack of Transparency (Article 5.1(a) GDPR): The School's transparency failures were extensive. Its enrolment documents and privacy policy mentioned only basic identification data (name, surname, password, school year) as being processed. However, the GWE platform actually collects far more: device information, IP addresses, browsing data, usage logs, content viewed and uploaded, cookies and location data, all linked to the students' identifiable accounts. The School failed to inform parents about international data transfers, despite acknowledging in its own Transfer Impact Assessment that Google stores data in centres worldwide, including outside the EEA, and that the "Fundamentals" version offers no option to restrict data storage to specific regions. The School also could not prove that parents had actually received the ICT policy document. It admitted it had no signed copies and that the previous platform (iSAMS) did not track whether parents viewed documents. An Excel spreadsheet presented as evidence of the new tracking system showed the "Signature" columns completely empty. Furthermore, the school's email domain (@student.hmschool.es) included the school's name, "Holy Mary Catholic School," which the AEPD noted could indirectly reveal the students' religious beliefs, a special category of data that was never disclosed to parents.

3. Inadequate Data Protection Impact Assessment (Article 35 GDPR): The School had conducted a DPIA in August 2021 but the AEPD found it fundamentally deficient. It was based on the false premise that only "identification data" were being processed and explicitly stated that no special category data was involved. It failed to assess the risks of international data transfers, despite the School's own acknowledgement that data could be stored anywhere Google operates. The necessity and proportionality analysis was superficial, simply stating the platform was "necessary for educational activities" without genuinely evaluating whether the extent of data processing was proportionate. A comparative analysis of four platforms (Microsoft 365, GWE, Apple School Manager and Moodle) was submitted later but focused on functional features rather than data protection risks. The DPIA's own recommendations, to periodically review policies, configurations and the DPIA itself, were never demonstrably implemented.

Additional Technical Concerns: The investigation also flagged that the School had configured Chrome's "Enhanced Safe Browsing" mode, which sends real-time browsing data (including URLs visited and page content samples) to Google. The Chrome Web Store was configured to "allow all apps" by default rather than blocking all and whitelisting only approved ones. Chrome OS crash reporting was enabled, which could transmit memory contents including page content, payment information and passwords to Google.

Based on Resolution EXP202406420, here is the compliance protocol for any school or organisation using cloud-based educational technology platforms:

1. Audit What Your EdTech Platform Actually Collects Do not rely on the vendor's marketing materials or your own assumptions about what data is processed.

Action: Before deploying any educational technology, obtain and review the platform's full privacy notice, data processing addendum and subprocessor list. Map every category of data the platform collects, including metadata, device data, usage logs, IP addresses, cookies and location data, not just the data you input at account creation. Your Record of Processing Activities must reflect the complete picture, not just names and email addresses.

2. Match Your Legal Basis to the Actual Processing A legal obligation to provide digital education does not give you blanket authority to process unlimited data.

Action: If you rely on Article 6.1(c) or (e) GDPR (legal obligation or public interest), you must demonstrate that every category of data processed is strictly necessary for that educational purpose. If your platform collects data for the vendor's own purposes (improving services, analytics, recommendations), those processing activities fall outside your claimed legal basis. Either negotiate contract terms that eliminate non-essential processing, choose a platform that does not engage in it, or identify a separate lawful basis for each additional purpose.

3. Conduct a Genuine DPIA, Not a Box-Ticking Exercise A DPIA that understates the data being processed is worse than no DPIA at all because it creates a false sense of compliance.

Action: Your DPIA must accurately identify all data categories (including platform-generated metadata), assess the specific risks of international data transfers (especially if your platform version does not allow data localisation), conduct a genuine necessity and proportionality analysis that considers less invasive alternatives, and be regularly reviewed and updated when configurations or platform terms change. If your chosen platform version lacks data residency controls, this must be explicitly assessed as a risk factor.

4. Provide Complete, Provable Transparency Telling parents about your ICT policy in a meeting is not enough. You must be able to prove that specific information reached specific individuals.

Action: Ensure that the information required by Article 13 GDPR is provided in writing at the point of data collection (i.e., enrolment or account creation). This must include all categories of data processed (not just identification data), the existence of international transfers and the safeguards relied upon, all purposes of processing (including any processing by the platform provider for its own purposes) and the identity of data recipients including subprocessors. Implement a system that creates a verifiable record of delivery: digital signatures, confirmed read receipts or equivalent mechanisms with actual traceability. An Excel spreadsheet with empty signature columns does not constitute proof.

5. Scrutinise "Free" Platform Versions The free version of an educational platform may cost you more in compliance risk than a paid version with better privacy controls.

Action: Evaluate whether the free tier of your platform offers adequate data protection controls. In this case, the "Fundamentals" version of GWE did not allow the school to choose data storage regions, meaning children's data could be stored in any country where Google operates. Paid versions may offer data residency options, enhanced administrative controls and more restrictive default configurations. Factor the compliance cost of using a less controllable platform into your procurement decision.

6. Configure Default Settings to Maximum Restriction Permissive default configurations expose your students to unnecessary data collection.

Action: Configure your platform to block all applications and extensions by default, whitelisting only those specifically approved (do not use "allow all, block some"). Disable crash reporting and diagnostic data sharing that could transmit sensitive information to the platform provider. Disable "Enhanced" browsing protection modes that send real-time browsing data to the provider and use "Standard" protection instead. Review and document every configuration decision as part of your privacy-by-design obligations.

7. Address the Religious Data Question If your school's name reveals religious affiliation, your email domain may constitute special category data processing.

Action: Schools with religious, political or philosophical identities should consider whether their institutional email domains (e.g., @student.catholicschool.es) could indirectly reveal students' beliefs when processed alongside platform usage data. If so, this must be disclosed in your privacy information and assessed in your DPIA. Consider using a neutral domain that does not reveal the school's character.

8. Don't Confuse Vendor Compliance with Your Own Google's ISO certifications and GDPR compliance do not automatically make your use of its platform compliant.

Action: As data controller, you are responsible for the lawfulness, fairness and proportionality of the processing, not your vendor. Google acting as a certified processor does not absolve you of the obligation to verify that the processing you authorise is necessary, proportionate and properly disclosed. Review subprocessor lists, data centre locations and the vendor's own stated purposes for processing, and assess whether these align with your claimed legal basis.

9. Take International Transfers Seriously Referencing Standard Contractual Clauses in your contract is not sufficient. You must conduct an actual transfer impact assessment.

Action: Your TIA must identify the specific countries where data may be processed (including subprocessor locations), assess the legal framework in each relevant jurisdiction (not simply state that "no evidence suggests non-compliance"), evaluate whether supplementary measures are needed beyond SCCs and be updated when the vendor changes its subprocessor list or data centre locations. Simply reproducing the vendor's own assurances is not an independent assessment.

10. Implement Ongoing Review and Document It Compliance is not a one-time exercise. If you recommend periodic reviews in your DPIA, you must actually carry them out.

Action: Schedule and document regular reviews of platform configurations, privacy policies, subprocessor lists and your DPIA. When platforms update their terms of service or privacy notices, assess whether changes affect your compliance posture. Maintain records of all reviews conducted, findings identified and actions taken.

Summary of Business Risk: This resolution sends a stark message to every school and educational institution in Spain: using a well-known, widely adopted educational technology platform does not guarantee GDPR compliance. The School had a Data Protection Officer, conducted a DPIA, implemented monitoring software and chose a platform with industry-standard certifications, yet was still found to have committed three separate GDPR violations. The total fine of €20,000 (reduced to €12,000 after voluntary payment and acknowledgement) may appear modest, but the corrective measures imposed are significant: the School must either demonstrate a valid legal basis for the full scope of GWE's data processing within three months or cease processing entirely and delete the data. For the approximately 2,500 private and semi-private schools in Spain that use similar platforms, this resolution establishes that the "legal obligation to educate" defence has strict limits. It covers only processing that is genuinely necessary for education, not the broader data collection that commercial platforms perform for their own purposes.