FERPA Compliance Requirements for EdTech Integrations

FERPA compliance for EdTech tools comes down to a specific, checkable list: contracts, technical controls, and data-handling rules a vendor either satisfies or doesn't. Get any one of them wrong and you're not "mostly compliant." You're exposed, and so is the school that trusted you with 30 kids' disciplinary records.

FERPA lives at 20 U.S.C. § 1232g and 34 CFR Part 99. It applies to basically every public K-12 school and most colleges, because it applies to any institution that takes federal education funding, and almost all of them do. The definition of "education record" is simple on paper: anything directly tied to a student that the school (or someone acting for the school) maintains. In practice, that definition covers more than most vendors expect.

Transcripts and grades are the obvious ones. Attendance, disciplinary files, health records, financial aid records, sure. But class lists count too. So do course schedules, behavioral pattern data, and metadata that most engineers wouldn't think twice about logging. The real test is whether a reasonable person in the school community could identify a specific student from the information in front of them. "The freshman in yearbook club" sounds anonymous until you remember there are maybe four freshmen in yearbook club. That's personally identifiable information under FERPA.

Parents, and students once they turn 18, get real rights here: they can inspect records within 45 days of asking, request corrections, and control who those records go to. FERPA regulates schools, not vendors. There's no private right of action against vendors written into the statute, and no direct compliance requirement sitting on your shoulders. The data lands on your servers because a school decided to share it, and the school is the one holding the legal bag.

Why EdTech adoption has raised compliance stakes

LearnPlatform by Instructure runs an EdTech Top 40 report built on a genuinely enormous dataset, 64 billion interactions across 3.7 million students and 546,000 educators. Their number for the 2024-25 school year: the average K-12 district accessed 2,982 distinct EdTech tools, up almost 9% from the year before. Other estimates land a bit lower, around 2,591 tools actually in use per year and roughly 1,403 active in a given month, but all of those numbers point to the same conclusion: districts are running an enormous portfolio of software every day.

Every tool in that portfolio that touches student records needs a valid FERPA exception behind it. And that exception only holds up if the vendor genuinely meets the conditions attached to it, not if the vendor's sales materials say they do. Most procurement offices don't have the bandwidth to check this carefully. One nonprofit's analysis found that 96% of apps used in schools share student data, including things like email addresses and birthdates, with third parties like advertisers, frequently without real consent behind it.

The result is thousands of implicit legal determinations happening every year inside district IT offices, made by people who are not lawyers, about vendors who often don't fully grasp what they signed up for either. Which raises the obvious next question: what actually makes that paperwork valid?

How the school official exception actually works

FERPA's baseline rule is strict: no sharing student PII without written consent. The school official exception lets schools share data with outside parties who meet a specific set of conditions. Congress widened this in 2008 specifically to cover service providers, such as student information systems, running on a school's behalf.

Qualifying requires clearing four conditions, and all four, not three out of four:

You have to perform a function the school would otherwise handle itself. You operate under the school's direct control over how the data gets used. You agree by contract to follow FERPA's requirements. And you don't re-disclose student PII except in ways the school has explicitly authorized.

None of this happens automatically. The exception doesn't activate just because a school likes your product or a teacher signs up for a free trial. It requires a real, enforceable contract, usually a Data Privacy Agreement or a Student Data Privacy Addendum, with every single district you serve. "Direct control" itself is one of those phrases that sounds precise until you go looking for federal guidance defining it, at which point you find very little. That gap is documented. Skip the contract, and you're outside the exception entirely: the school is in violation for sharing, and you're holding data with zero legal basis to have it.

What a compliant Data Privacy Agreement must contain

The DPA is the mechanism that turns the school official exception from a legal theory into something you can point to in an audit.

A compliant DPA needs a tightly defined scope: exactly which categories of student data get shared, matched to what FERPA actually covers rather than whatever's convenient for your product roadmap. It needs a use restriction limiting you to purposes the school has authorized, with no repurposing data for new features or marketing experiments. It needs retention and disposal terms, specifying how long you keep data and confirming you're responsible for destroying it securely when the relationship ends. It needs breach notification language with an actual deadline attached, not a vague promise of notifying "as soon as practicable." It needs documentation that staff handling this data have been trained on their obligations. It needs indemnification language putting liability on you, the vendor, rather than the school. And most well-drafted agreements now specify data residency, keeping student records on U.S. servers.

State law adds a second layer, and it's usually stricter than the federal floor. New York's Education Law § 2-d requires encryption and sets specific breach timelines. California's SOPIPA puts liability directly on vendors, meaning a school cannot fully indemnify you out of that exposure even if both parties want to. The practical approach: draft to the toughest state standard you'll encounter, and the federal floor takes care of itself.

FERPA doesn't actually require schools to have written contracts with vendors at all, which means you cannot assume the district will hand you a solid DPA to sign. If you're the vendor, you need to show up with the agreement ready to go.

What FERPA forbids vendors from doing with data

The rule is narrow on purpose. PII you receive under the school official exception can only be used for what the school authorized, and nothing else.

That rules out targeted advertising and behavioral profiling built on student data. It rules out selling or sharing that data with third parties the school hasn't cleared. And it rules out passing data along to subprocessors who were never brought under the same contractual restrictions you agreed to.

Some vendors have tried to route around this through terms of service instead of the DPA, hoping a clickthrough agreement with parents does the work. It doesn't. If a school requires a platform as part of a student's education, that platform has to meet school official standards regardless of how the account signup is structured. The Department of Education's finding against K12 Inc.'s Agora platform made this concrete: requiring parents to accept a ToS that allowed near-total re-disclosure of student PII as a condition of enrollment was ruled an unlawful forced waiver of FERPA rights. Any ToS clause expanding your data rights beyond what the DPA allows is void as far as student PII is concerned.

Schools are supposed to be auditing your compliance, so expect audit rights clauses in your contracts and be ready to document what you're doing, not just assert it.

Technical controls FERPA implies but never names

FERPA never mentions encryption, access control, or any specific security architecture by name. It's a liability standard, not a technical specification. What exists instead is an after-the-fact test: if a complaint lands at the Department of Education, you need to show, through the school, that reasonable protections were actually in place.

Access control is where this gets concrete. Teachers see their own students. Administrators see their school. District staff see their district. The default posture should be no access until someone explicitly grants it, following the classic principle of least privilege. Sessions should time out automatically after inactivity.

Encryption is the other requirement. AES-256, at rest and in transit, is what well-drafted DPAs and laws like New York's § 2-d now specify. And when a parent requests to inspect records, you need to be able to pull that data and hand it to the school within the 45-day window.

Certifications like SOC 2 Type II and ISO 27001 aren't FERPA-specific, and they don't replace a DPA. But they give a procurement team concrete evidence that your controls exist and have been independently tested.

One architecture note for anyone building AI features: RAG systems that retrieve student data at query time, rather than embedding it in model weights through training, sidestep the hardest remediation problem in this space. Once PII is embedded in a trained model, removing it is genuinely difficult, sometimes close to impossible without retraining from scratch.

How generative AI features create new FERPA exposure

Adding an AI tutor, auto-grader, or writing assistant to your product opens a new pathway for student PII to reach places the DPA doesn't cover. Student inputs might get piped through a third-party model API or logged for model improvement without anyone verifying that flow falls within the boundaries of the DPA.

If a teacher pastes disciplinary notes or counseling records into a chatbot to get a quick summary, that data may now sit outside the school's direct control entirely, which can void the school official exception for that specific data flow even if your core DPA is otherwise airtight.

De-identification doesn't eliminate this risk. Attendance patterns, course selections, accommodation records, and disciplinary history stacked together create a behavioral fingerprint distinctive enough to re-identify a student, especially once cross-referenced against public data.

AI features don't just trigger FERPA. They simultaneously implicate COPPA, including the updated rule's expanded biometric identifiers, plus a growing set of state laws restricting automated profiling of minors. Every new AI feature needs a data flow audit checking whether student PII touches a third-party model API, a training pipeline, or a logging system that sits outside what the DPA covers.

FERPA and COPPA compliance must run in parallel

A common and costly misunderstanding: vendors assume that once a school signs a DPA and designates them a school official, the school has also absorbed the vendor's COPPA obligations for students under 13. It hasn't, and it can't.

The FTC's 2023 case against Edmodo is the clearest illustration on record. Edmodo's terms of service told teachers they were "solely responsible for complying with COPPA." The FTC rejected that reasoning and pursued Edmodo directly. The complaint covered collecting personal data from students under 13 without verified parental consent and using that data for advertising. Part of the resolution required deleting machine learning models trained on the improperly collected data, which means deleting not just a dataset but the work product built on top of it.

The COPPA Rule was updated in April 2025, effective June 2025. It expands "personal information" to cover biometric identifiers including fingerprints, voiceprints, facial templates, and genetic data, plus government-issued ID numbers. If you built your consent flow around provisions that didn't survive into the final rule, that architecture needs rework.

A DPA handles FERPA data-use obligations. COPPA consent belongs to you as the vendor, and you cannot transfer it to a school by contract regardless of how the paperwork is worded. Both frameworks must be satisfied independently, on their own terms.

Where vendor FERPA enforcement exposure actually comes from

FERPA's enforcement mechanism is notably weak. The Department of Education relies on voluntary compliance agreements, and the harshest penalty available, pulling federal funding from an institution, has never actually been used. There's also no private right of action, meaning parents and students cannot sue directly under the statute.

Real exposure comes from other directions. The FTC enforces COPPA, as Edmodo found out, with penalties that can include deleting entire trained models. State attorneys general enforce their own student privacy statutes, which frequently carry sharper penalties and direct vendor liability than the federal baseline.

FERPA defines the shape of the obligation. COPPA and state law are where the financial consequences materialize.