Data Protection Officer Requirements for EdTech Companies

EdTech companies don't just do "SaaS plus GDPR." They sit at the crossroads of education law, children's data law, and general data protection law, all running at once, all with their own definitions of what counts as personal data. No single US federal law covers education privacy on its own. FERPA sets the floor, COPPA adds extra rules for children under 13, and then each state adds its own law on top of that.

A single platform sold to one school district can be governed by FERPA, COPPA, and a state student privacy statute simultaneously, with whichever clause is strictest winning in the contract.

The average school district now runs over 200 EdTech tools, and procurement offices are running this exact compliance matrix against every vendor in their stack, one contract at a time Secure Privacy. Nearly 400 student privacy bills have appeared across 49 states since 2014 CyberNut / Vendor Compliance 2026 Checklist. SETDA's 2025 EdTech Quality Indicators Guide puts "Safe" (student data privacy and security) as the first pillar districts check before adopting a tool, so a compliance gap can eliminate a vendor before anyone reads the pricing page.

For an EdTech SaaS company, data protection has become a sales and procurement problem as much as a legal one. Addressing it proactively becomes a selling point; falling behind becomes the reason a district declines to engage.

Three GDPR triggers that make a DPO mandatory

GDPR doesn't ask how large a company is or how much revenue it generates. For private-sector EdTech, the operative triggers are systematic monitoring and special category processing at scale.

An EdTech platform tracks learning behavior, engagement patterns, assessment scores, and sometimes attention or mood indicators by design. That is precisely the kind of activity Article 37 was written to capture. A five-person startup with a large school district customer base can be just as exposed as an enterprise vendor, because the test concerns the nature and purpose of processing, not company headcount or turnover.

Germany adds its own requirement. Under BDSG Section 38, any company with at least 20 people regularly performing automated personal data processing needs a DPO, regardless of whether monitoring or special category data is involved. In a software company, that threshold includes virtually everyone touching production systems, support tickets, or the CRM.

Naming a DPO voluntarily does not create a lighter version of the role. The moment a company designates someone as DPO, Articles 37 through 39 attach in full: independence, direct reporting to leadership, protection from dismissal for performing the role, adequate resources, mandatory involvement in every data protection decision, and registration with the regulator. The EDPB has stated this clearly: a voluntary DPO carries the exact same obligations as a mandatory one. If the product tracks student progress, flags behavioral patterns, touches health or special needs data, or runs learning analytics at any real scale, Article 37 applies.

UK GDPR's DPO rules after the 2025 Act

Since Brexit, the UK operates under the UK GDPR and the Data Protection Act 2018 (DPA 2018). The DPO triggers mirror the EU's three-part Article 37 test almost exactly, with no divergence on the core mechanics.

An earlier reform proposal considered replacing the DPO model with a "senior responsible individual." The Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025, did not take that route. The Article 37 DPO regime remained fully intact.

No employee threshold exists under UK GDPR; the triggers concern what the organisation does and what its core activities involve. Infringements of Articles 37 through 39 fall under Article 83(4), with a standard maximum penalty under DPA 2018 section 157(6) of £8.7 million or 2% of global annual turnover, whichever is higher Recording Law. For any EdTech vendor selling into UK schools, the UK GDPR analysis must run alongside the EU GDPR analysis.

What the ICO's 2026 EdTech audit found

The ICO published "Edtech examined," a report covering audits of 28 EdTech providers across UK primary and secondary schools, carried out through 2024 and 2025 ICO / Burges Salmon. The scope covered management information systems, safeguarding tools, behavior management platforms, learning management systems, classroom apps, and data integration services. The audits generated 596 compliance recommendations, 98% of which were implemented, though the ICO continued working directly with 12 of the 28 providers after the audits concluded ICO / Burges Salmon.

Nominated DPOs and compliance managers, in a number of cases, did not fully understand their responsibilities. Some did not understand that a DPO reports directly to the board, not through a chain of legal or compliance managers.

Over 40% of providers had not carried out a data protection impact assessment at all, often because they had incorrectly concluded they were acting solely as processors ICO / Burges Salmon. About 80% of the DPIAs that did exist lacked enough detail to be meaningful. Around 70% lacked proper oversight and governance for their DPIAs, including missing DPO input, limited consultation with key stakeholders, and no agreed process for completing them.

The consequences extended beyond the 28 audited companies ICO / Burges Salmon. On 9 July 2026, the Department for Education added a new section to its Data Protection in Schools guidance titled "Procuring educational technology (EdTech)," directing schools to the ICO's findings when evaluating vendors. The ICO is also in discussion with the DfE and devolved authorities about whether a dedicated EdTech code could strengthen protection for children's data across the sector. For vendors, a DPO setup that would have passed internal review a year ago may now fail a district's vendor questionnaire.

US frameworks that impose DPO-equivalent obligations

FERPA does not use the term "Data Protection Officer." However, it requires schools and vendors to operate under contracts that carry FERPA's privacy and security requirements, using the school official exception as the legal mechanism, which demands documented, direct control over the data. In March 2025, the Department of Education required every state educational agency to certify FERPA and PPRA compliance by April 30, 2025, following investigations into California and Maine.

New York goes further and names the role explicitly. New York's Education Law §2-d requires schools to appoint a data protection officer; vendors must comply with a Data Security and Privacy Plan but are not themselves required to appoint a DPO, making New York one of the clearest US-based DPO mandates in the EdTech context.

California builds the obligation through layered requirements rather than a title. California's AB 1584 mandates nine specific contract clauses in all school-vendor agreements, SOPIPA prohibits targeted advertising and non-educational data profiling of students, and CCPA adds data rights obligations for vendors above certain size thresholds plus mandatory annual cybersecurity audits for larger companies, with those regulations effective January 1, 2026, and first certification submissions phased in from April 1, 2028 to 2030 based on company revenue. CCPA violations can reach $7,500 per violation CyberNut / Vendor Compliance 2026 Checklist.

Selling into New York schools creates a statutory DPO or equivalent expectation. Selling into California creates a contractual and privacy stack that functions like a dedicated privacy role even without that label. A US-only EdTech company that assumes it has no structured privacy governance requirement almost certainly has several, each worded differently.

COPPA 2025 amendments raise the EdTech compliance bar

The FTC finalized a major overhaul of the COPPA rule on January 16, 2025. It took effect June 23, 2025, with a compliance deadline of April 22, 2026, and no grace period. Several changes have significant implications for EdTech products.

Personal information now explicitly covers biometric identifiers, including fingerprints, handprints, retina and iris patterns, genetic data, voiceprints, gait patterns, facial templates, and faceprints, along with precise geolocation data specific enough to identify a street and town. The FTC stopped short of including broader "data derived from voice, gait, or facial data" language in the final rule, though operators running speech or facial recognition should verify obligations under the enumerated categories that were already covered.

Consent requirements also became more stringent. Sharing a child's data with third parties for targeted advertising now requires its own separate, verifiable parental opt-in; burying that consent inside general terms of service is no longer sufficient. Retention policies must be documented, with clear purposes, business justification, and defined timeframes, since indefinite retention is explicitly prohibited and the policy must appear in the public-facing notice.

Third-party accountability was also tightened: every SDK, analytics tool, or external service touching children's data now falls inside the compliance perimeter, and operators must actively monitor and restrict what those sub-processors do with that data. The FTC's preamble states explicitly that disclosing children's personal information to third parties to train or develop artificial intelligence technologies is not integral to the underlying service and therefore requires separate verifiable parental consent. The school authorization exception does not cover this. It applies only to collection for educational purposes, so using school-authorized data for product analytics, AI training, or marketing falls outside it regardless of what a privacy policy claims.

FTC civil penalties currently run $53,088 per violation per day, and for a platform with a substantial population of child users, a single non-compliant practice generates a violation per affected child, per day Promise Legal. Cognosphere paid $20 million in 2025 to settle COPPA violations tied to collecting children's data without consent, along with separate FTC Act charges over deceptive loot box practices DEV Community / Bhavesh Pawar.

The 2025 amendments require structured data mapping, a sub-processor inventory, separate consent workflows, and documented retention schedules, which is precisely the infrastructure a DPO or dedicated privacy lead builds and maintains.

Where the DPO role breaks down in EdTech

Core DPO responsibilities under Articles 37 through 39, applicable under both EU and UK GDPR, include conducting and overseeing data protection impact assessments, with priority given to higher-risk processing such as special category data or processing with significant individual impact.

In an EdTech company, that scope covers the entire data lifecycle: ingesting student records from school systems, behavioral analytics, AI-assisted grading or tutoring tools, every sub-processor relationship, and data deletion at contract end.

The ICO's audit identified recurring patterns of failure ICO / Burges Salmon. DPOs consistently misunderstood their own accountability structure, treating the role as an internal compliance checkbox rather than an independent function that reports directly to the board. Over 40% of audited providers skipped DPIAs entirely, roughly 80% of the DPIAs that existed were too thin to be useful, and about 70% had no meaningful DPO involvement or governance in the process. These are failures of the role's central responsibility, not peripheral weaknesses.

Controller versus processor confusion also appeared repeatedly in cases where children's data was pulled into product development or internal analytics, and that confusion directly affects whether anyone identifies that a DPO is legally required.

A DPO cannot carry a company's entire privacy posture alone. Product managers need to understand how new features interact with data rights. Engineering leads need privacy requirements incorporated before code ships. The DPO coordinates that work but does not replace it.

Many EdTech companies appoint a privacy lead even when no legal trigger requires it, partly because it supports procurement conversations with schools and universities. Once that appointment is made, however, full Articles 37 through 39 obligations apply regardless of intent. Treating the role as an informal or incomplete title creates the same legal exposure as a mandatory appointment, without the documentation to support it.

Assess your DPO obligation before procurement does

Start with the processing itself. Determine what the product actually does with student data: whether it tracks behavior over time, runs learning analytics, flags patterns tied to performance or wellbeing, or touches special category information such as health or special needs status. If the answer is yes at any meaningful scale, the Article 37(1)(b) and (c) triggers require a serious review, since GDPR Article 37(1) lists three mandatory triggers and no size or revenue threshold.

Then examine the parallel tracks separately. Check whether any German entity crosses the 20-person automated-processing threshold under BDSG Section 38, since that requirement is independent of monitoring or sensitive data. Review where the company sells in the US: California's AB 1584 mandates nine specific contract clauses in all school-vendor agreements, and COPPA imposes age-specific constraints for children under 13.

Finally, consider what a school district's procurement questionnaire will ask. Following the ICO's 2026 audit, those questions are becoming more specific and more difficult to answer with a vague privacy policy reference CyberNut / Vendor Compliance 2026 Checklist ICO / Burges Salmon. A company that works through this assessment independently can enter procurement with answers prepared. A company that waits may discover mid-RFP which threshold it crossed months earlier.