Two US laws govern student data in edtech. FERPA protects education records at federally funded schools, where a vendor acts as a “school official” under the school’s control. COPPA governs how you collect data online from children under 13, and it demands verifiable consent. Most K-12 products have to satisfy both, and COPPA’s amended rule comes due on 22 April 2026.
What do FERPA and COPPA require from edtech in 2026?
Student data ranks among the most sensitive personal information a product can hold, and in the United States two laws decide how edtech may handle it. Most founders meet those laws the hard way: in a district's procurement questionnaire, or in a university's security review that lands weeks before launch. So here is the whole landscape upfront, before it ambushes you:
- 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 rights over their child's education records, and those rights pass to “eligible students” once they turn 18 or start college. You can inspect the records, ask for corrections, and control who else sees the personally identifiable information inside them. The law binds the school rather than the vendor directly. Yet the moment a school pushes student data into your platform, you get pulled into FERPA's orbit — through the very mechanism that makes edtech possible in the first place.
The "school official" exception
FERPA lets a school hand education records to a vendor without separate parental consent, provided that vendor performs a service the school would otherwise run itself — a “school official” with a “legitimate educational interest.” That clause is the legal basis on which your SaaS gets to hold gradebooks, attendance or assessment data. It comes with strings. You have to sit under the direct control of the school for how the records are used and maintained, you may touch the data only for the authorized purpose, and you cannot re-disclose it to anyone without permission. Put plainly: the school owns the relationship with the data, and you are a processor acting on its instructions.
What this means for your product
FERPA publishes principles, not a control checklist, so districts and universities are the ones who translate it — into contract terms and a long security questionnaire. Sign on as a school official and the asks are fairly predictable: keep data strictly for the contracted educational purpose; give the school access, correction and deletion on request; protect records with reasonable safeguards such as access control, encryption and logging; commit to breach notification; and return or delete the data when the contract ends. None of this is exotic engineering. It is disciplined custom software development that treats privacy as a first-class requirement. The teams that come unstuck are usually the ones who shipped a consumer app first, then tried to make it “FERPA-ready” after the fact.
COPPA: the 2026 deadline and what changed
COPPA covers operators of online services aimed at children under 13, plus anyone who has actual knowledge they are collecting personal information from under-13 users. It dates back to 1998, before the modern web took shape, but the FTC has just handed it its most significant update since 2013. This time a hard deadline comes with it.
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
Chasing individual parental consent for every app in a classroom is hopeless, so the FTC lets a school consent on behalf of parents instead — as long as the service serves a purely educational purpose and the data never travels beyond it. The privilege has sharp edges. Use that same data to improve an unrelated product, to build advertising profiles, or to train a model for some other purpose, and the school's consent simply does not stretch that far; now you need parental consent for those uses. So your product has to distinguish school-authorized use from everything else and lock the data down the moment that line is crossed.
Where FERPA, COPPA and state law overlap
For a K-12 product both federal laws land at once. FERPA governs the education records the school entrusts to you; COPPA governs the act of collecting personal information from an under-13 child. The two do not conflict. They simply look at the same data from different angles, and you owe compliance to both. The table below sets them side by side.
| Dimension | FERPA | COPPA |
|---|---|---|
| Enacted | 1974 | 1998 (major amendments effective 23 June 2025) |
| What it protects | “Education records” held by federally funded schools | Personal information collected online from children under 13 |
| Who it binds | The school; vendors act as a “school official” under its control | Any operator directed to, or knowingly collecting from, under-13 users |
| Consent basis | School-official exception — no separate parental consent for the educational purpose | Verifiable parental consent, or school authorization for the educational context only |
| Enforcement & penalties | US Dept. of Education; ultimate sanction is loss of federal funding (no private right of action) | Federal Trade Commission; civil penalties over $50,000 per violation, adjusted annually for inflation |
| Key 2026 change | Text unchanged, but districts now demand SOC 2 and signed data-processing agreements | Full compliance due 22 April 2026: biometrics in scope, separate sharing consent, retention limits |
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.
These state laws bind vendors wherever they are headquartered, so a national edtech product ends up building to the strictest common denominator. Once your learners cross the Atlantic, the GDPR and UK GDPR govern those users as well — our guide on GDPR for US founders selling to the EU covers what that adds. Much of it rhymes with what FERPA and COPPA already demand: lawful basis, data minimization, retention limits, subject rights.
The engineering checklist: privacy by design
Here is the good news buried in all that regulation: every regime converges on the same build. Treat the list below as the baseline architecture for any product that touches student data. Design it in from the first sprint, since each item costs far less to build up front than to retrofit under the pressure of 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 features teams are most eager to ship 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 how a learner behaves. Three principles keep features like these 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 stacks transparency and risk obligations on top; our EU AI Act checklist for SaaS walks through them. Wiring models into an existing product responsibly is a discipline of its own. We handle that engineering in our generative AI integration work, where data governance is built into the integration rather than deferred to a separate project.
Building a compliant edtech product
Whether you build in-house or bring in a partner, the same handful of questions separates a product that sails through procurement from one that stalls in it. Run your team — or your vendor — against the checklist below.
1. Privacy designed in, not bolted on
Minimization, RBAC, encryption, logging and retention belong in the very first architecture diagram. Counterintuitively, a team that treats them as launch-blockers from day one ships faster than one that scrambles to “add compliance” right 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 off the top of their head, without reaching for a generic privacy-policy template. The specifics are what decide the architecture.
3. Evidence, not assurances
Districts trust artifacts: a SOC 2 report, a signed data-processing agreement, a clear data map. A partner who produces them on request, instead of promising to “look into it,” saves you a whole 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. Both are architectural, so they have to be right early; leave them late and they turn expensive to fix.
5. A team that stays for the lifecycle
Rules change, and the COPPA update is the proof sitting right in front of you. A team that owns the product over time keeps it compliant as the regulations and your own feature set move, instead of handing over a snapshot that quietly 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.
