FERPA Directory Information Rules for EdTech Products

FERPA is the federal law that decides who can touch student data and under what conditions, and it's older than most of the technology it now governs. This law applies to basically every public K-12 school and most colleges, because it attaches to federal funding, not to student count or building size. Here's the part EdTech teams get wrong constantly: the law regulates schools, not vendors. Your compliance obligation exists because you signed a contract with a school, not because the U.S. Department of Education has your company on file somewhere.

That distinction sounds like a technicality. It isn't. It's the whole ballgame, and it explains why the contract with the district matters more than your terms of service, your privacy policy, or whatever compliance badge is sitting in your footer.

What qualifies as an education record — and where the edges are

An education record is any record tied directly to a student that a school (or someone acting on its behalf) keeps on file. Grades, transcripts, disciplinary write-ups, attendance sheets. The obvious stuff.

The identifiers that make a record "about" a student stretch further than people assume. Name, address, Social Security number, and photos are the easy ones. Date of birth, detailed location data, and unique metadata count too, and there's a catch-all clause covering anything a "reasonable person within the school community" could use to figure out who the student is. That's a deliberately fuzzy standard, and it's fuzzy on purpose, so it can flex with context.

Some things are carved out entirely: law enforcement records kept solely by a school's police unit, employee records unconnected to the person's status as a student, and treatment records held by a physician or psychiatrist.

Here's where it gets interesting for EdTech specifically. Usage logs, in-app behavior tracking, AI-generated assessment scores; none of that existed in 1974 when this law got written, and none of it was on anyone's mind. If that data is directly related to a student and your platform is maintaining it on behalf of a school, though, it can meet the definition of an education record whether you designed it to or not. Plenty of vendors are sitting on records they never labeled as such, simply because nobody built the product with FERPA's 50-year-old vocabulary in mind.

Directory information: the defined subset FERPA treats differently

Directory information is the one category FERPA treats like a lighter version of the rules. It covers stuff that wouldn't embarrass or endanger a student if it got out: name, address, phone number, email, photo, birth date and place, field of study, grade level, enrollment status, attendance dates, sports and activities participation, athletic team height and weight, honors and degrees, and the last school attended.

Because it's low-risk information, schools can release it without asking for written consent first. That's the entire point of the category, and it's what separates it from every other education record, which generally needs consent before it moves anywhere.

Two hard rules bookend the category. Social Security numbers can never be labeled directory information, full stop, no exceptions. A student's electronic ID or unique identifier, meanwhile, can only qualify as directory information if it's useless on its own, meaning someone would still need a password or PIN to actually get into any real records with it.

Worth sitting with for a second: this category was built for yearbooks, playbills, and honor roll announcements in the local paper. The Department of Education's own model notice still talks about it that way. Now it's the legal basis for handing student rosters to attendance apps and communication platforms nobody in 1974 could've dreamed up. The statute didn't stretch to meet EdTech; EdTech just found a doorway that happened to still be unlocked.

How schools must give notice and manage opt-outs before sharing directory information

Before a school can release a single piece of directory information, it has to publish an annual notice. That notice needs to spell out exactly what counts as directory information at that school, tell parents and eligible students they can opt out of any or all of it, and give a deadline for doing so in writing.

Once that notice goes out and nobody's opted out, the information is fair game, and it can technically go to anyone who asks, inside the school or out. Districts can narrow this themselves though. A school can specify in its notice that directory information only goes to certain recipients or gets used for certain purposes, and if it makes that promise, it's stuck honoring it.

Opting out usually works as an all-or-nothing switch. Some districts, including ones in Maryland, Montana, and North Carolina, have built a menu system instead, letting parents pick and choose which categories to shield. FERPA doesn't require the menu option, but it also doesn't stop schools from offering it.

One carve-out trips people up constantly: a student who opted out of directory information disclosure entirely can still have their name, ID, and school email visible inside a class they're actually enrolled in. So your gradebook tool, your roster feature, your in-class messaging system, none of that gets blocked by an opt-out. The opt-out governs external sharing, not internal classroom function.

Schools also can't force the issue. They can't make a FERPA waiver a condition of using an educational service, meaning a district can't tell a family "use this app or your kid fails the class" if using the app requires giving up privacy rights. For vendors, the takeaway is blunt: every piece of directory information landing in your database traveled through the school's notice and opt-out process first. If that process had holes in it, your data pipeline has holes in it too, whether you knew it or not.

The school official exception: the main channel through which vendors receive non-directory student data

Directory information covers the easy stuff. Everything else, the actual education records, needs a different legal pathway, and that pathway is called the school official exception.

Under this rule, schools can share protected student data without consent with "school officials" who have a legitimate educational reason to see it. In 2008, regulators expanded that definition to include outside vendors and contractors, not just employees. That expansion is the reason your product can legally receive gradebook data, IEP information, or behavioral records at all. It's the load-bearing wall of the entire EdTech data economy.

To qualify, a vendor has to check three boxes. It has to be doing work the school would otherwise assign to its own staff. It has to operate under the school's direct control regarding how it uses and maintains the records. It also has to follow the re-disclosure limits laid out in the regulations, meaning it can't just pass that data along to someone else.

That middle condition, "direct control," sounds precise and isn't. Nobody has defined what direct control actually requires in practice, and there's no standard checklist a vendor can point to and say "see, we're controlled." It's a legal phrase doing a lot of work with very little definition behind it.

One line is drawn clearly though: student PII from education records can't be used for advertising or marketing without consent. That's not a gray area, and any EdTech business model leaning on ad targeting from student data is building on a foundation the law explicitly forbids.

Here's the structural twist that makes all of this matter: FERPA doesn't give the federal government a way to punish vendors directly. There's no FERPA police showing up at your office if you misuse student data. The school takes the regulatory hit, not you, which is exactly why the contract between you and the school isn't paperwork, it's the entire legal mechanism holding the arrangement together.

Why the school-vendor contract is the operative compliance instrument

No contract, no data. That's the practical rule. Without a signed agreement spelling out permitted uses, banning re-disclosure, and giving the district audit rights, the school has no legal basis to share FERPA-protected records under the school official exception in the first place.

Most districts figured this out a while ago and stopped accepting a vendor's standard terms of service as sufficient. They want a separate document now, usually called a Data Protection Addendum or a Data Privacy Agreement. The Student Data Privacy Consortium's National Data Privacy Agreement, Version 2, released in April 2024, has become the closest thing to an industry standard template, and plenty of districts now default to it or something modeled on it.

A contract that actually holds up covers a specific set of ground. It defines exactly what student information the vendor gets, spells out permitted uses (and just as importantly, bans everything outside those uses), sets rules for where the data lives and how long it's kept, mirrors the federal re-disclosure restrictions, lays out what happens during a data breach, and gives the district the right to audit how the vendor is actually handling things.

The system has real cracks though. There's no federal security standard a vendor has to meet before touching student data, and there's no federal requirement that a written contract even exist, which means some data flows are happening on nothing but trust and good intentions. Plenty of districts, especially smaller ones, don't have the staff or legal budget to negotiate these agreements even when they know they should.

For product teams, the DPA isn't a document legal reviews after the features ship. Its permitted-use clauses decide, at the feature level, what your product is allowed to do with the data the second it lands in your system. Build the feature first and check the contract later, and you might discover you built something you're not allowed to run.

Where FERPA's framework leaves genuine gaps for modern EdTech

The honest answer is that a law written in 1974 was never going to anticipate adaptive learning algorithms or AI-generated behavioral flags, and it doesn't. Whether an AI-produced risk score about a student counts as an education record is a question the statute simply doesn't answer, which means schools and vendors are left interpreting old text for a new kind of output.

The directory information category has the same problem in a different flavor. It was built for yearbook photos and honor roll lists, and now it's being stretched to cover data feeding recommendation engines and analytics dashboards. That works, more or less, but it works through extrapolation, not because the regulation was written with that use case in mind.

"Direct control," the key phrase in the school official exception, still has no operational definition. No certification process exists, and no standard audit mechanism exists either. Vendors and schools are largely making it up as they go, guided by best practice rather than binding rule.

State law has stepped into some of that gap, and increasingly, that's where the sharper teeth are. Several states have passed student privacy laws that put direct obligations on vendors, something FERPA itself never does. Any EdTech team operating across state lines needs to track those rules separately, because they vary by state and don't always line up neatly with each other.

Still, a few things are clear enough to build a compliance strategy around. Follow the directory information notice and opt-out process to the letter, or the lighter treatment simply doesn't apply. Get the DPA signed before any data moves, not after. And treat the advertising prohibition as a wall, not a suggestion; any feature that depends on using student PII for ad targeting is dead on arrival, no matter how clever the growth team thinks it is. Products built around the minimum data actually needed for the educational function they claim to serve, wrapped in a contract that spells out exactly what's allowed, hold up a lot better than products retrofitting compliance after the fact.