Data Processing Agreements for EdTech Vendors

Plenty of districts now run a simple rule at the procurement desk: no signed data privacy agreement, no purchase, no exceptions. That rule kicks in before anyone on the district side even looks at a demo, a pricing sheet, or a glowing case study. A vendor can have the best product on the market, and it will sit untouched until legal has a signed DPA in hand. The DPA is not a formality bolted onto the sale. It is the legal instrument that gives a vendor the right to touch student data in the first place, not a voluntary pledge of good behavior that a vendor can substitute with a line in a sales deck claiming "we're FERPA compliant." That claim, on its own, means nothing to a procurement officer, because FERPA compliance is a function of the contract terms, not a badge a company awards itself. A typical district runs a large number of EdTech tools across a single school year, and every one of them needs this exact legal relationship sorted out before data starts flowing.

What activates the "school official" exception

FERPA lets schools hand education records to outside vendors without getting a permission slip from every parent, but only when that vendor qualifies as a "school official." The DPA is the document that makes that qualification real. Under 34 CFR § 99.31(a)(1), an outside party clears that bar only by meeting three specific conditions. The vendor has to perform a service the school would otherwise staff itself. The vendor has to use student data strictly for the purposes the disclosure was made for, a requirement spelled out in 34 CFR § 99.33(a). And the vendor has to meet the criteria laid out in the school's own annual FERPA notification about who counts as a school official with a legitimate educational interest.

If the contract doesn't spell out, in writing, that the vendor is operating as a school official, the district has no legal footing to share student data without individual consent. Written compliance is what counts.

The condition vendors underestimate most often is "direct control." The "direct control" condition means the school stays in charge of how student data gets used, stored, and deleted, no matter whose infrastructure it's sitting on. A DPA has to pin down data handling obligations in terms a court could enforce, rather than in the breezy language of a privacy policy. The FTC backs this up with real teeth: misrepresenting FERPA compliance in a procurement questionnaire is a violation on its own. The agency doesn't need to show that a specific student got hurt to bring an action. Saying the wrong thing on a form is the violation.

This is the operating logic districts are required to follow, and understanding it is how a vendor stops treating the DPA like red tape and starts treating it like the contract that actually lets the product ship.

The regulatory stack a DPA must satisfy

A DPA built only to satisfy FERPA will get bounced back across a procurement officer's desk, because FERPA is just the first of three overlapping legal regimes a vendor has to clear at once. The second layer is COPPA, which the FTC overhauled with significant amendments finalized in January 2025 and published in the Federal Register in April 2025. Compliance is required by April 22, 2026. Under the amended rule, operators have to keep a written data retention policy on file, and indefinite retention of children's data is explicitly off the table. Platforms serving kids under 13 now need explicit opt-in consent before sharing data with third parties, plus documented methods for verifiable parental consent. A standard SaaS data processing agreement, built for enterprise software sold to adults, doesn't touch any of this.

The third layer is state law, and it's a patchwork rather than a single standard. California's AB 1584, codified at Education Code § 49073.1, requires nine specific contract clauses in every agreement between a school and an EdTech vendor, covering who owns the data, banning its use for advertising, and spelling out security and deletion procedures. Under CCPA and CPRA, larger companies face mandatory annual cybersecurity audits, with the regulations taking effect January 1, 2026, and first audit certifications due April 1, 2028, for companies above the relevant revenue threshold. Some states go further and require a named data protection officer or adherence to the NIST Cybersecurity Framework. SOPIPA adds another restriction on top of FERPA: it bars vendors from commercializing the collection of covered student data at all, which is a tighter rule than FERPA's use-restriction language.

A DPA built for a single state, or built only around federal law, will need a dedicated addendum for every additional state a vendor's customers operate in.

Eight clauses every compliant DPA needs

A DPA that will actually survive district review has to cover eight substantive areas, and missing even one of them is enough to get the contract sent back for revision. The first is scope of data: the agreement needs to name the exact fields of student data the product touches, not a vague gesture at "educational records," because vague language is what gets flagged first in procurement review. The second is purpose limitation, which says the vendor may use student data only for the educational service described in the contract, not for advertising, not for building a product roadmap, not for profiling, and not for any other commercial purpose, a restriction that maps directly onto the § 99.33(a) use requirement already baked into FERPA. The third is data ownership, and the contract has to state that pupil records remain the property of the school district at all times, with the vendor acting only as a custodian rather than an owner, a point California law requires in explicit terms. The fourth is sub-processor disclosure: every third-party service that touches student data has to be named, disclosed, and bound to the same data protection standards as the vendor itself, because a school official exception that quietly falls apart once data passes to an unnamed sub-processor was never really an exception. The fifth is data retention and deletion, where the DPA has to specify how long student data sticks around and what event triggers its deletion, typically a fixed window after the contract ends. Indefinite retention is now flatly prohibited under the 2025 COPPA amendments, so the vendor needs a written retention policy on file and ready to produce. The sixth is security measures, where the contract has to describe the actual technical controls in place, including encryption, access controls, multi-factor authentication, audit logging, and incident response procedures, because a security promise with nothing behind it is exactly the failure that turned the Illuminate Education case into the sector's cautionary tale. The seventh is breach notification, which has to define the process for telling a district when student data has been compromised. Timeframes vary by state and by contract, ranging from 72 hours in state laws like Minnesota's and New Jersey's and in several model DPA templates to over a week in other jurisdictions. The eighth is parent and student rights, where the agreement has to acknowledge FERPA rights directly and spell out how the vendor will support the district when a parent or student asks to access or correct a record.

Generic SaaS agreements, the kind written for selling project management software to a marketing department, consistently fail on three of those eight: data ownership, sub-processor disclosure, and retention and deletion. Those three are the education-specific requirements that standard commercial contract templates were never built to include, and they happen to be the first three things a district's procurement office checks. Engaging a lawyer who understands EdTech, student privacy law, and FERPA to draft a proper DPA template is a one-time cost that pays for itself on every school deal that follows.

Illuminate Education and what enforcement looks like

The Illuminate Education case is the clearest real-world demonstration of what happens when a DPA makes promises the company's actual systems don't back up. Illuminate had told its customers that student information would be encrypted. Much of it was stored in plaintext instead. The company's access controls were inadequate, and its systems for catching intrusions were inadequate too.

On November 6, 2025, California, Connecticut, and New York reached a multistate settlement over the breach. That settlement marked the first enforcement action under California's KOPIPA and under Connecticut's Student Data Privacy Law, and it became the second major action brought under New York Education Law § 2-d. The FTC gave final approval to its modified consent order on June 5, 2026, after public comment pushed the agency to tighten the wording around data deletion and to strengthen the requirement that Illuminate maintain a publicly available data retention schedule. That detail matters beyond this one company: it signals that retention and minimization now sit alongside encryption and access control in regulators' enforcement priorities.

The breach notification failure compounds the picture. School districts comprising hundreds of thousands of students weren't notified until nearly two years after the breach occurred, a direct failure of the exact obligation every DPA is supposed to nail down in writing. The breach happened at the vendor, not at the district, yet the district is the party holding the liability. That's the arrangement districts are protecting themselves against every time they insist on a signed DPA before a purchase order goes through.

On March 27, 2025, a class action lawsuit was filed against Instructure, the parent company of Canvas, alleging violations of children's federal and state privacy rights. That case is a reminder that the exposure here doesn't stop at a regulatory consent order. It extends into civil litigation too.

How AI features break standard DPA templates

Adding an AI feature to an EdTech product can crack a carefully built DPA at the sub-processor level, specifically wherever student interactions get routed through a third-party LLM API. The school official exception can hold perfectly well for the primary vendor and still fail the moment data crosses into a large language model provider's hands, unless the DPA explicitly spells out what that provider is allowed to do with it.

The legal mechanism here traces straight back to § 99.33(a): education records shared under the school official exception may be used only for the purpose the disclosure was made for. Feeding those same records into a commercial AI model's training pipeline goes well beyond that purpose, and it can trigger a FERPA violation no matter how airtight the primary vendor's own DPA reads on paper. A vendor using a third-party LLM API needs written confirmation that the provider doesn't train on customer inputs, doesn't hold onto data past the processing window, and offers its own data processing terms that are compatible with FERPA's use restrictions.

Three categories of AI feature carry this exposure directly: AI tutoring chatbots, because the conversations themselves count as education records; adaptive learning engines, because they tie learning patterns to individual students; and automated grading tools, because they handle assessment responses and grades.

Telemetry logs don't offer an escape route either. In generative AI systems, operational data meant to track performance, including latency measurements, prompt length distributions, and prompt error logs, frequently carries fragments of the original classroom prompts buried inside, including actual student queries or drafts of individualized education plans. De-identified behavioral telemetry has a demonstrated tendency to get linked back to the individual student it came from. A DPA that doesn't account for that risk has moved the compliance gap somewhere harder to detect.