What FERPA and COPPA Actually Require From EdTech Software

Education technology sits under two federal privacy laws that are routinely mentioned in the same breath and that work very differently. FERPA binds schools and reaches vendors through contract. COPPA directly binds the operator of an online service. A product can be subject to both, to one, or to neither, and the answer changes what you build, not just what you write in a privacy policy.

The distinction became more consequential in 2026. The amended COPPA Rule, finalized by the Federal Trade Commission in January 2025 and effective 23 June 2025, carried a full compliance deadline of 22 April 2026. Obligations that used to be good practice are now rule text.

FERPA - the school's obligation that lands on the vendor

The Family Educational Rights and Privacy Act (20 U.S.C. section 1232g, implemented at 34 CFR Part 99) applies to educational agencies and institutions that receive funding from the US Department of Education. It gives parents and students, once they turn 18, the right to inspect education records, request corrections, and control the disclosure of those records.

Software vendors are not directly regulated by FERPA. They are reached through the school official exception at 34 CFR 99.31(a)(1), which lets a school share education records with an outside party without consent, provided that party performs a service the school would otherwise perform itself, is under the school's direct control with respect to the use and maintenance of the records, uses the data only for the authorized purpose, and does not redisclose it.

"Direct control" is the clause that does the work. In practice it means the school decides what the vendor may do with the data, and the contract has to say so. A term that allows the vendor to use student data to improve unrelated products, train models, or market to families breaks the exception and, with it, the school's lawful basis for sharing in the first place.

One more FERPA concept has product consequences: directory information. Schools may designate certain fields - name, grade level, participation in activities - as disclosable without consent, but must give families a chance to opt out. If your product displays or exports those fields, it needs to respect the opt-out flag, which means the flag has to exist in your data model.

COPPA - the operator's obligation, and what changed this year

The Children's Online Privacy Protection Act (15 U.S.C. sections 6501-6506) and its implementing rule (16 CFR Part 312) apply to operators of online services directed to children under 13, or that have actual knowledge they collect personal information from them. The core requirement is verifiable parental consent before collection. FTC guidance has long recognized that a school can provide that consent in the limited context of educational use, which is why classroom products are workable at all, but the permission is narrow and does not stretch to commercial purposes.

The 2025 amendments added obligations that are specific enough to design against:

• Separate consent for third-party disclosure: Sharing a child's personal information with third parties now requires its own parental consent, distinct from consent to collect. Disclosure of compensation, advertising, or training of artificial intelligence always requires it.
• A written retention policy, published: Operators must maintain a written policy limiting retention to what is reasonably necessary for the purpose of collection, and that policy has to appear in the online notice rather than in an internal document.
• A written security program: Operators must establish and maintain a written children's personal information security program with appropriate safeguards. A separate program is not required where existing procedures already cover children's data - but "existing procedures" means documented ones.
• A wider definition of personal information: Biometric identifiers are now in scope, including fingerprints, voiceprints, handprints, retina and iris patterns and genetic data, as well as templates derived from biometric imagery.

Where the two overlap, and where they do not

Age is the first divergence. COPPA stops at 13. FERPA covers every student whose records a covered institution holds, from kindergarten through university. A high-school product can be fully outside COPPA and squarely inside FERPA.

Enforcement is the second. COPPA is enforced by the FTC, with civil penalties for each violation. FERPA has no private right of action, and its ultimate sanction is withdrawal of federal funding - which is why, in commercial reality, FERPA risk reaches vendors as contractual liability and lost renewals rather than regulatory fines.

The third difference is who holds the obligation. Under FERPA, the school is accountable and pushes requirements down through its contract. Under COPPA, the operator is directly accountable, regardless of what the contract says.

What This Means Inside the Product

Collect Less

Every field is a liability under both regimes. The question to ask of each one is which feature stops working without it. The date of birth is often collected out of habit, when a grade band would suffice.

Make Deletion Real

Retention limits are only meaningful if deletion propagates - to backups on a defined schedule, to analytics stores, to the data warehouse, to any subprocessor. Most products can delete from the primary database and nowhere else.

Audit Your SDKs

This is the most common practical failure. An advertising or attribution SDK added for growth measurement puts student data in front of a third party for a commercial purpose, which breaks the school official exception and, after April 2026, triggers the separate-consent requirement. Session replay tools raise the same problem.

Keep a Subprocessor List

Schools increasingly ask for one before signing, and you cannot produce it retroactively with any confidence.

Write the Security Program Down

The rule asks for a written program. An undocumented set of good habits does not satisfy it.

State law stacks on top

Federal law is the floor. California's Student Online Personal Information Protection Act, in force since 2016, prohibits targeted advertising based on student data, profiling for non-educational purposes, and the sale of student information. New York's Education Law section 2-d and its implementing regulations impose their own contractual and security requirements on vendors serving New York districts. Many districts also standardize on the National Data Privacy Agreement published by the Student Data Privacy Consortium, which sets terms beyond federal minimums.

If you sell nationally, assume the strictest applicable state standard rather than maintaining per-state behavior in the product.

Questions worth asking before you sign

• Which of our data flows involve students under 13, and which do not?
• Does the contract restrict use to the authorized educational purpose, with no secondary use?
• Is there a written retention schedule, and does deletion actually reach every store?
• Which third parties receive student data, and under what agreement?
• Is the security program written down, and when was it last reviewed?
• How are directory information opt-outs represented in the data model?

Those questions are also a reasonable way to compare custom EdTech software companies when you are choosing a build partner, because a team that cannot answer them about its own past projects will not answer them about yours.

Compliance in education software is less about legal interpretation than about architecture decided early. Data maps, retention schedules, and subprocessor discipline are cheap at design time and expensive once a district's security review is underway.