What FERPA Actually Requires of an Edtech Platform

"FERPA compliant" sits on almost every edtech landing page, usually next to a small shield icon, and it is one of the most misunderstood claims in the industry. It is treated like a badge you earn and display. It is not. There is no FERPA certificate, no government audit that blesses your product, and no agency that will ever email you the words "you are now FERPA compliant."

What FERPA actually is, once you strip away the marketing, is a set of obligations that flow from schools into the contracts they sign and the systems they buy. If you build or sell learning software that touches student data in the United States, those obligations become design decisions and contract terms whether you planned for them or not. This post explains what the law really asks, how a vendor is even allowed to handle student records, what you have to build to hold up your end, and the other laws that sit in the room alongside FERPA. As with anything on this topic, treat it as a practical guide rather than legal advice, and confirm your specific obligations with counsel.

FERPA in one paragraph

FERPA, the Family Educational Rights and Privacy Act, is a US federal law from 1974 that protects the privacy of student education records. It applies to schools, districts, colleges, and universities that receive funding from the US Department of Education, which is nearly all of them. It gives parents, and students once they turn 18 or enter college, the right to see their education records, to ask for corrections, and to control who else gets to see them. An "education record" is broadly any record that directly identifies a student and is maintained by the school or by someone acting for it.

The key phrase there is "acting for it." FERPA binds the school, not your company directly. But the moment a school hands you student data to run its platform, you are acting for the school, and the school's obligations become your problem through the agreement you sign.

The claim that means nothing on its own

Because FERPA has no certification, "FERPA compliant software" is a statement about intent, not a verified fact. No one hands it out. This matters in both directions.

If you are buying, a vendor saying "we are FERPA compliant" tells you very little by itself. The useful questions are specific: what happens to the data, who can access it, how long is it kept, and will they sign a real data agreement that commits them in writing. A vendor who leans on the badge and cannot answer those is telling you something.

If you are building, the same is true of your own marketing. Claiming compliance is easy. Being able to stand behind it, with the access controls, retention rules, logging, and contract terms that make it real, is the actual work. The claim is only worth what the architecture underneath it can support.

How a vendor is even allowed to touch student data

This is the part most people miss. FERPA generally forbids a school from disclosing a student's records without consent. So how do thousands of edtech vendors legally process student data every day without collecting a signed consent form for each child? Through a specific carve-out called the school official exception.

Under this exception, a school may treat an outside vendor as a "school official" with a "legitimate educational interest," and share records with it without separate consent, but only if a few conditions hold:

• The vendor performs a function the school would otherwise do itself. Running the learning platform counts. Selling advertising does not.
• The vendor is under the school's direct control regarding how it uses and maintains the records. In practice this is what the contract establishes.
• The vendor uses the data only for the authorized purpose and does not re-disclose it to anyone else without permission.

That third point is the sharp edge. Data a school gives you to run its courses cannot quietly become data you use to train an unrelated model, sell to a partner, or build advertising profiles. The exception that lets you hold the data at all is also the leash on what you may do with it. Cross that line and the school has a FERPA violation, and you have a broken contract and a reputation problem.

What FERPA actually asks you to build

Once you are handling records under that exception, the law's promises to families turn into features and controls your platform has to support. None of these are exotic, but they are easy to skip when nobody is asking for them yet.

Two of these deserve a flag. Access logging is the one teams skip earliest and regret most, because without it you cannot even investigate a suspected leak, let alone prove what happened. And real deletion is harder than it sounds, since student data tends to spread into backups, analytics, and third-party tools, all of which have to be part of the deletion story. These are the same architectural muscles that protect you generally, which is why this pairs so closely with a student-data security checklist and with the lesson from the Canvas breach, where the failure was not a clever hack but ordinary access design at scale.

FERPA is not the only law in the room

Building to FERPA alone is not enough, because more than one law usually applies to the same student data at once. The three you are most likely to meet are these.

The one that surprises US builders most is the state-law column. FERPA binds the school and reaches you through contract. Laws like California's SOPIPA regulate the vendor directly, and they tend to be blunt about it: do not sell student data, do not use it for targeted advertising, and do not build profiles of students for anything other than the educational purpose you were hired for. Many states now have their own versions. If your platform serves multiple states, you are effectively building to the strictest one.

The document that actually governs it

Since there is no certificate, the thing that actually pins down your obligations is a contract, usually a Data Privacy Agreement, sometimes called a DPA or a student data privacy agreement. This is the document a school's procurement or legal team will put in front of you, and it is where the abstract law becomes concrete promises: what data you receive, what you may do with it, how you secure it, how long you keep it, what happens on a breach, and how it gets deleted when the relationship ends.

Many US districts have standardized this through the Student Data Privacy Consortium, which publishes common agreement templates so schools and vendors are not renegotiating the same terms from scratch every time. If you sell into schools, expect to sign one of these, and expect it to commit you to exactly the controls described above. Reading a standard DPA closely is, honestly, one of the fastest ways to understand what "FERPA compliant" is supposed to mean in practice, because it lists the real requirements in plain contractual language.

What "compliant" does and does not buy you

Meeting these obligations is genuinely valuable. It lowers your legal and reputational exposure, and it clears procurement, which for anyone selling into schools is often the difference between closing a deal and dying in a security review. Increasingly it is table stakes: the questionnaire arrives early, and a vendor who cannot answer it is out before the demo.

What it does not buy you is a finish line. Compliance here is not a badge you earn once and file away. It is a set of ongoing commitments, written into contracts and enforced by how your platform actually behaves every day. Every new feature, every new subprocessor, every new place the data flows is a fresh chance to break a promise you made in a DPA. The teams who handle student data well treat it the way they treat security and accessibility, as a standing property of the system rather than a one-time project. Those regulatory properties tend to travel together, which is why FERPA sits naturally beside what WCAG 2.2 AA requires as the other compliance duty that quietly shapes an edtech build.

The through-line is the same one that runs under security and accessibility. The obligations that protect students, and protect your business, are decisions you make in the architecture and the contract, early, while they are still cheap to honor. FERPA is not a sticker for the footer. It is a promise about how your system is built and how it behaves, and the only version of it that means anything is the one your platform can actually keep.