TL;DR — the rules in one minute
Student data is some of the most sensitive personal information there is, and in the United States two laws decide how edtech may handle it. Founders usually meet them the hard way — in a district's procurement questionnaire or a university's security review, weeks before a launch. Here is the landscape upfront:
- FERPA (the Family Educational Rights and Privacy Act, 1974) protects education records held by schools that receive federal funding. As a vendor you usually process those records as a "school official" under the school's control — not as the data owner.
- COPPA (the Children's Online Privacy Protection Act) governs the online collection of personal information from children under 13, including in schools. It requires verifiable consent before you collect.
- Most K-12 products are subject to both at once. A learning tool used by under-13 students triggers FERPA for the records and COPPA for the children's data. Higher-ed and corporate training are usually FERPA-only (or neither).
- COPPA changed. The FTC's amended rule became effective 23 June 2025, with full compliance required by 22 April 2026 — new rules on biometrics, third-party sharing consent and data retention.
- State laws and the GDPR stack on top. California (SOPIPA), Illinois (SOPPA) and New York (Ed Law 2-d) add contractual and deletion duties; EU and UK learners bring the GDPR.
FERPA: what it protects and who it binds
FERPA gives parents — and "eligible students" once they turn 18 or enter college — rights over their education records: the right to inspect them, to ask for corrections, and to control who else sees the personally identifiable information in them. It binds the school, not directly the vendor. But the moment a school sends student data to your platform, you are pulled into FERPA's orbit through the mechanism that makes edtech possible at all.
The "school official" exception
FERPA lets a school disclose education records without separate parental consent to a party performing a service the school would otherwise do itself — a "school official" with a "legitimate educational interest." That is the legal basis under which your SaaS holds gradebooks, attendance or assessment data. The catch is the conditions attached: you must be under the direct control of the school for the use and maintenance of the records, you may use the data only for the authorized purpose, and you may not re-disclose it without permission. In plain terms: the school owns the relationship with the data; you are a processor acting on its instructions.
What this means for your product
Because FERPA publishes principles rather than a control checklist, districts and universities translate it into contract terms and a security questionnaire. To sign as a school official you will typically be asked to: keep data strictly for the contracted educational purpose; grant the school access, correction and deletion on request; protect records with reasonable safeguards (access control, encryption, logging); commit to breach notification; and delete or return data at the end of the contract. None of that is exotic engineering — it is disciplined custom software development with privacy treated as a first-class requirement. The teams that struggle are the ones who built a consumer app first and tried to make it "FERPA-ready" afterwards.
COPPA: the 2026 deadline and what changed
COPPA applies to operators of online services directed to children under 13, or who have actual knowledge they are collecting personal information from under-13 users. It predates the modern web (1998), but the FTC has just given it the most significant update since 2013 — and there is a hard date attached.
What the 2025 amendments changed
- Biometrics and identifiers are now personal information. The definition of "personal information" expressly includes biometric identifiers — facial-recognition data, voiceprints, fingerprints, retina patterns — and government-issued identifiers. Proctoring, voice tools and photo features are squarely in scope.
- Separate consent for third-party sharing. A single blanket consent no longer covers everything. You now need separate, verifiable parental consent before disclosing children's data to third parties for purposes such as targeted advertising. Consent to run the service is not consent to share downstream.
- No indefinite retention. Operators may keep children's personal information only as long as reasonably necessary for the purpose it was collected for, and must adopt a written data-retention policy. Indefinite "we might need it" storage is now a violation.
- The school exception stayed, and stayed narrow. A school can still authorize collection in place of a parent — but only for the educational context, never for advertising or profiling.
The school-consent mechanism
In a classroom setting, getting individual parental consent for every app is impractical, so the FTC allows a school to consent on behalf of parents — provided the service is used solely for an educational purpose and the data is used only for that purpose. This is a privilege with sharp edges: if you also use the data to improve unrelated products, build advertising profiles, or train models for other purposes, the school's consent does not stretch to cover it, and you need parental consent for those uses. Your product has to be able to tell school-authorized use apart from anything else and lock the data down accordingly.
Where FERPA, COPPA and state law overlap
For a K-12 product the two federal laws apply together: FERPA governs the education records the school entrusts to you, while COPPA governs the act of collecting personal information from the under-13 child. They are not in conflict — they cover different angles of the same data — but you have to satisfy both. And then the states pile on, often with stricter and more specific rules:
- California — SOPIPA: bars using K-12 student data for targeted advertising or to build non-educational profiles, and requires reasonable security and deletion.
- Illinois — SOPPA: imposes detailed contract requirements between schools and vendors, breach-notification timelines, and public transparency about the data collected.
- New York — Education Law 2-d: requires specific data-security and privacy terms, a parents' bill of rights, and vendor commitments on encryption and deletion.
Because these laws bind vendors regardless of where you are headquartered, a national edtech product effectively builds to the strictest common denominator. If your learners cross the Atlantic, the GDPR and UK GDPR apply to those users too — our guide on GDPR for US founders selling to the EU covers what that adds, and much of it (lawful basis, minimization, retention, subject rights) rhymes with what FERPA and COPPA already ask for.
The engineering checklist: privacy by design
The reassuring part is that all of these regimes converge on the same build. Treat the following as the baseline architecture for any product that touches student data — design it in from the first sprint, because every item is far cheaper to build than to retrofit before a security review.
- Data minimization. Collect only the fields the educational purpose needs. The data you never collect is the data you never have to protect, consent for, or delete.
- Role-based access control (RBAC). Teachers, students, parents, admins and your own staff each see only what their role warrants. Every record access is authorized and attributable.
- Encryption everywhere. TLS in transit and strong encryption at rest for education records and children's data, with sensible key management.
- Audit logging. An immutable trail of who accessed or changed which records, retained long enough to satisfy district contracts and to investigate an incident.
- Retention and deletion. A written retention policy with automated deletion when data is no longer needed or when a contract ends — now an explicit COPPA requirement, not just good hygiene.
- Consent and purpose tracking. Record the basis on which you hold each child's data (school authorization vs parental consent) and enforce that the data is used only for that purpose.
- Tenant isolation. One district's data must never leak into another's. For most edtech this is a multi-tenant SaaS architecture decision made early, not a patch.
- Evidence on demand. A SOC 2 report, a data-processing agreement and a clear data map turn a months-long security review into a checkbox — see our SOC 2 Type II guide for startups for how to get there.
AI features, biometrics and the new rules
AI is where edtech compliance gets sharpest in 2026, because the most exciting features touch exactly the data the new rules care about. An AI tutor reads a child's free-text answers; a proctoring tool processes a face or a voice; an adaptive engine profiles a learner's behavior. Three principles keep these features on the right side of the line:
- Biometrics are personal information now. Facial recognition, voiceprints and fingerprints fall under the 2025 COPPA definition, so any feature that uses them for under-13 students needs a lawful basis and, frequently, separate consent — not a buried clause in your terms.
- Sending data to a model is a disclosure. Passing children's data to a third-party AI provider, or using it to train or fine-tune a model, is a data use the educational-context exception may not cover. Keep children's data out of training by default, and put a contract in place that forbids the provider from training on it.
- Document every flow. If you can't draw where a child's data goes when they ask your AI tutor a question, you can't prove compliance. Treat any AI feature as in-scope for the privacy review from day one.
For EU and UK learners the EU AI Act layers transparency and risk obligations on top — our EU AI Act checklist for SaaS walks through them. Wiring models into an existing product responsibly is its own discipline; we cover the engineering in our generative AI integration work, where data governance is part of the integration, not a separate project.
Building a compliant edtech product
Whether you build in-house or with a partner, the same questions separate a product that sails through procurement from one that stalls. Use this as a checklist for your team or your vendor.
1. Privacy designed in, not bolted on
Minimization, RBAC, encryption, logging and retention should appear in the first architecture diagram. A team that treats them as launch-blockers from the start ships faster than one that "adds compliance" before a review.
2. Fluency in the actual rules
Look for people who can explain the school-official exception, the COPPA school-consent mechanism and the 2026 changes without reaching for a generic privacy-policy template. The specifics decide the architecture.
3. Evidence, not assurances
A SOC 2 report, a signed data-processing agreement and a data map are what districts trust. A partner who produces them on request — rather than promising to "look into it" — saves you a sales cycle.
4. Multi-tenant and deletion done right
Tenant isolation and reliable, automated deletion are the two places edtech most often fails a review. They are architectural, so they have to be right early or they are expensive to fix.
5. A team that stays for the lifecycle
Rules change — the COPPA update is proof. A team that owns the product over time keeps it compliant as regulations and your feature set evolve, rather than handing over a snapshot that drifts out of date.
FAQ
Does FERPA or COPPA apply to my edtech product?
It depends on who uses it and how old they are. FERPA applies when you handle education records for a US school, district or university that receives federal funding — usually as a "school official" under the school's control. COPPA applies when you collect personal information online from children under 13, including in schools. Many K-12 products are subject to both at once. Products for users 13 and older in higher-education or corporate-training contexts are usually FERPA-only or neither, though state laws and the GDPR may still apply.
What changed in COPPA for 2026?
The FTC finalized the first major COPPA amendments since 2013. The rule became effective on 23 June 2025, with full compliance required by 22 April 2026. Key changes: biometric and government-issued identifiers are now "personal information"; you need separate verifiable consent before sharing children's data with third parties for purposes like targeted advertising; and you can no longer retain children's data indefinitely — a written retention policy and timely deletion are required. The school-authorization exception remains but covers the educational context only.
Can a school give consent on behalf of parents under COPPA?
Yes, within limits. A school can consent in place of a parent when the service is used solely for an educational purpose and the data is used only for that purpose — not for advertising, profiling or unrelated commercial use. Anything beyond delivering the educational service needs separate verifiable parental consent. Your product must distinguish school-authorized use from other uses and restrict the data accordingly.
What security controls does FERPA require from a vendor?
FERPA sets principles rather than a fixed checklist, but to act as a school official you are expected to protect education records with reasonable safeguards: role-based access control, encryption in transit and at rest, audit logging, data minimization, secure deletion and retention limits, breach-notification commitments, and use of the data only for the authorized purpose. Districts increasingly want this evidenced with a SOC 2 report and a signed data-privacy agreement, and several states require extra contract terms.
Do FERPA and COPPA apply if my users are in the EU or UK?
FERPA and COPPA are US laws covering US students and schools. For learners in the EU or UK, the GDPR and UK GDPR apply instead, with their own rules on lawful basis, minimization, retention and children's data. A product sold on both sides of the Atlantic satisfies FERPA and COPPA for US users and the GDPR for EU and UK users at the same time — but the underlying engineering largely overlaps, so one privacy-by-design architecture can serve all of them.
How do AI tutors and chatbots affect children's-data compliance?
AI features often process children's text, voice or images — including the biometric identifiers the 2025 COPPA changes scrutinize. Using children's data to train a model, or sending it to a third-party AI provider, is a use and disclosure the educational-context exception may not cover, so it can require separate consent and a vendor agreement that forbids training on the data. For EU and UK learners the EU AI Act and GDPR add obligations. Minimize what the AI sees, keep children's data out of training by default, and treat any AI feature as in-scope for your privacy review from the start.
Last updated 29 June 2026. This article is general information about FERPA, COPPA and related student-privacy laws for US and EU edtech teams; it is not legal advice. Regulatory requirements change and depend on your specific product, users and jurisdictions — confirm your obligations with qualified counsel before launch.
