EdTech teams often treat FERPA and COPPA as two names for the same obligation: protect student data. They are different laws, written for different purposes, aimed at different parties. Confusing them leads to predictable mistakes, such as assuming a school contract settles COPPA, or assuming a product used by adults escapes both.
The short version is this. FERPA regulates schools, and reaches you through them. COPPA regulates you directly, if your product collects personal information online from children under 13. Many K-12 products are subject to both at once.
This article sets out how the two differ, which products each one reaches, how schools can authorize collection under COPPA, and how to run one program that meets both. It is not legal advice. Both areas are actively interpreted and have been revised, so confirm your position with counsel.
The core difference
The two laws start from different questions. FERPA asks when a school may disclose information from a student's education records. COPPA asks when an online operator may collect personal information from a young child.
| FERPA | COPPA | |
|---|---|---|
| Source | 20 U.S.C. § 1232g; regulations at 34 CFR Part 99 | 15 U.S.C. §§ 6501 to 6506; FTC rule at 16 CFR Part 312 |
| Who it regulates | Educational agencies and institutions receiving U.S. Department of Education funds | Operators of websites and online services directed to children, or with actual knowledge they collect from children |
| Whose information | Students, at any age | Children under 13 |
| What information | Personally identifiable information from education records | Personal information collected online from a child |
| Whose consent | Parent, or the student once rights transfer at 18 or postsecondary attendance | Parent, by a verifiable method |
| How a vendor fits | Indirectly, usually as a school official under the school's control | Directly, as the operator |
| Who enforces | Department of Education, through the school's federal funding | Federal Trade Commission, and state attorneys general |
The "how a vendor fits" row is the one that matters most. Under FERPA, the school carries the legal obligation and you carry contractual ones. Under COPPA, the obligation is yours.
For more on FERPA's side, see our overview of FERPA for EdTech vendors.
When COPPA reaches an EdTech product
COPPA applies to an operator in two main situations.
Your service is directed to children under 13. The FTC looks at factors such as subject matter, visual content, use of animated characters, child-oriented activities, music, the age of models, and advertising. A reading game for early grades is directed to children whatever your terms of service say about age.
You have actual knowledge that you are collecting personal information from a child under 13. A general audience product that asks for a birth date and receives one showing a user is nine has that knowledge.
Personal information under the rule is broad. It includes names, contact details, and photos or recordings of a child, and also persistent identifiers such as cookies and device identifiers that can recognize a user over time. A product that collects no names can still collect personal information.
Where COPPA applies, the operator must, in summary: post a clear privacy notice, give parents direct notice, obtain verifiable parental consent before collecting personal information (unless an exception applies), let parents review the information and have it deleted, maintain reasonable security, and keep the information only as long as reasonably necessary for the purpose it was collected for.
The FTC amended the COPPA Rule in 2025. The amendments affect areas such as consent for certain disclosures, data retention, and security programs. Read the current text of 16 CFR Part 312 rather than relying on summaries written before the change.
How school authorization fits between them
This is where the two laws meet, and where EdTech vendors most need precision.
Collecting verifiable parental consent from every family is impractical for a product used by a whole class. FTC guidance has long allowed a school to provide consent on parents' behalf in a specific situation: where the operator collects personal information from students for the use and benefit of the school, and for no other commercial purpose.
That condition does real work. A school can authorize collection needed to run the educational service. It cannot authorize collection for your own commercial purposes, such as behavioral advertising or building profiles for use outside the service. If you want to use children's data for those purposes, school authorization does not cover it.
Under that guidance, the operator still gives the school the notice it would otherwise give parents, so the school can make an informed decision. Many schools also want the authorization reflected in a written agreement. Our explainer on student data privacy agreements covers how those agreements usually handle it.
The same condition, use for the school's purposes only, also sits at the heart of FERPA's school official exception. Our article on the FERPA school official exception covers that side. A product designed to stay within one is usually close to staying within the other.
Which products face which law
A few patterns cover most EdTech businesses.
K-12 product used by students under 13, sold to schools. Both laws are likely to apply. FERPA through your school agreements, COPPA directly.
K-12 product used by teachers and staff only. FERPA is likely through the education records you hold. COPPA is less likely, since you are not collecting from children, unless students also log in.
Higher education product. FERPA is likely. COPPA rarely applies, since students are generally over 13, though it can still arise for early college or summer programs for younger students.
Consumer learning app for children, bought by parents. COPPA is likely. FERPA does not apply, because no school is disclosing education records.
Product sold to private K-12 schools. COPPA applies on the usual tests. FERPA may not, since private K-12 schools generally do not receive Department of Education funds. State laws may still apply.
State student privacy laws sit across all of these and often add restrictions on advertising, sale, and profiling that neither federal law imposes in the same terms.
Running one program that meets both
The two laws are distinct, but the controls overlap heavily. Building to the stricter of the two in each area keeps one program instead of two.
Inventory by user type and age. Record which data you collect from students under 13, older students, teachers, and parents, and through which features.
Purpose limitation as a design rule. Student data is used only to provide the service to the school. This keeps you inside school authorization under COPPA and the school official exception under FERPA.
Third-party code review. Analytics, advertising, and support tools embedded in student-facing pages can collect persistent identifiers. Remove or configure them so no third party collects children's personal information for its own purposes.
Notices for schools and parents. A school-facing notice that explains your collection and use, plus a public privacy notice that meets COPPA's content requirements.
Request handling. Route FERPA access and amendment requests to the school. Handle COPPA review and deletion requests, often with the school's involvement where it provided authorization.
Retention and deletion. Set retention periods tied to purpose, delete when the purpose ends, and keep records that show it.
Security program. Document safeguards proportionate to children's data, with access reviews and logging that show who reached student records.
The FERPA framework page summarizes what schools will expect from you on the FERPA side.
How TrustLynce helps
TrustLynce keeps your data inventory, retention schedules, and request handling in its data privacy workflows, and maps controls across frameworks so one control can carry FERPA, COPPA, and contractual references with shared evidence. A readiness dashboard shows where each obligation stands.