EdTech Privacy Compliance Checklist: FERPA and COPPA
Student data privacy is one of the few compliance areas where getting it wrong doesn't just create legal risk — it can end your ability to pilot with real schools at all, since a district's IT and legal team will screen for exactly this before a teacher's enthusiasm ever reaches a purchase decision. This checklist covers the compliance surface every edtech founder needs to understand before touching real student data: FERPA, COPPA, the growing patchwork of state student-privacy laws, and the district data agreements that formalize all of it.
Quick Answer: Before piloting with minors or schools, understand your obligations under FERPA (governing education records at federally funded institutions), COPPA (governing data collection from children under 13 online), relevant state student-privacy laws (which vary and are expanding), and be prepared to sign a district-specific data privacy agreement — treat all four as real, non-optional diligence, not a formality to handle after a pilot is already underway.
The Privacy Compliance Checklist, Grouped by Law
FERPA (Family Educational Rights and Privacy Act)
- You understand FERPA applies to education records at institutions receiving federal funding, and that a school or district sharing student data with your product typically makes you a "school official" bound by FERPA's use restrictions.
- You know FERPA restricts how education records can be used and disclosed — generally limited to the educational purpose for which they were shared.
- You have a clear, written policy on what happens to student data if a school stops using your product.
COPPA (Children's Online Privacy Protection Act) 4. You know whether your product is "directed to children under 13" or has actual knowledge it's collecting data from children under 13, which triggers COPPA obligations. 5. You understand COPPA generally requires verifiable parental consent before collecting personal information from children under 13, with a school-consent exception for data used strictly for educational purposes. 6. You've documented which specific data elements you collect from users under 13 and why each is necessary.
State Student Privacy Laws 7. You've researched the state-specific student data privacy law(s) relevant to your target states — many states have their own requirements beyond FERPA and COPPA, and this list is actively growing. 8. You know whether your target state requires a specific data privacy agreement addendum (some states have standardized ones, like the National Data Privacy Agreement used by a number of US states). 9. You're tracking that this area changes over time and requires periodic re-checking, not a one-time review.
District Data Agreements 10. You have a data privacy agreement (DPA) template ready before a district asks for one — many districts will not proceed without a signed DPA. 11. Your DPA addresses data security measures, breach notification obligations, data retention and deletion terms, and sub-processor disclosure. 12. You understand your target district's specific procurement or IT review process for new vendors, including any timeline it typically requires.
Item-by-Item Rationale: Sources to Consult and Why Each Matters
For FERPA (checks 1–3), the source to consult is the US Department of Education's Family Policy Compliance Office guidance directly, not secondhand vendor marketing that may overstate or understate real requirements — understanding the "school official" exception specifically matters because it's the legal basis that lets schools share student data with your product at all without separate parental consent for each disclosure, provided you stay within the educational purpose the school authorized.
For COPPA (checks 4–6), the source to consult is the Federal Trade Commission's COPPA guidance, since the FTC enforces this law — the school-consent exception matters enormously for edtech specifically, because it allows a school to consent on behalf of parents for data used strictly for educational purposes, which is why many edtech products can operate in classrooms without collecting individual parental consent for every child, provided the data use stays genuinely educational and doesn't extend into other purposes like marketing.
For state student privacy laws (checks 7–9), the sources to consult are state-specific — California's Student Online Personal Information Protection Act (SOPIPA) was an early, influential example, and many other states have since passed their own requirements with varying specifics. This is the fastest-moving part of the compliance landscape, which is why check 9 explicitly calls out ongoing monitoring rather than a one-time review.
For district data agreements (checks 10–12), having a template ready before you need it — rather than scrambling to draft one when a district's IT team asks — can be the difference between a pilot that proceeds smoothly and one that stalls for weeks while you catch up. Many districts now use standardized agreement frameworks specifically to reduce the burden of negotiating custom terms with every vendor, so researching whether your target states use one of these standardized frameworks can significantly speed up your own process.
Worked Example: A Founder's First District Data Agreement Request
A founder building a formative-assessment tool for middle school math had been running informal pilots with individual teachers for months, collecting only anonymized quiz performance data, without much friction. When one enthusiastic teacher pushed to get the tool approved district-wide, the district's IT office requested a signed data privacy agreement before proceeding — and the founder, who had no template ready, spent nearly three weeks scrambling to draft one, delaying the approval into the next semester and missing the September onboarding window entirely.
Learning from this, the founder researched the specific state's student data privacy framework, discovered it used a standardized national agreement template, and pre-filled that template with the company's actual data practices — what's collected, where it's stored, retention and deletion terms, and named sub-processors — well before any district evaluation began. The next district evaluation, six months later, moved from initial IT contact to a signed agreement in under two weeks, specifically because the founder could hand over a completed, standardized document immediately rather than starting the drafting process from a district's request forward. The lesson generalizes: this compliance work is far cheaper done proactively, once, than reactively, under time pressure, for every new district.
Failure Modes This Checklist Prevents
| Missing compliance area | What it blocks during validation |
|---|---|
| No clear FERPA "school official" understanding | District legal/IT review flags uncertainty about your data-use rights, stalling or killing the pilot |
| No documented COPPA analysis | A district or state regulator questions your under-13 data collection practices, creating real legal exposure |
| No awareness of target state's specific requirements | A pilot proceeds informally, then stalls when formal district procurement discovers a missing state-specific requirement |
| No data privacy agreement template ready | Weeks of delay drafting a DPA from scratch once a district requests one, often missing a seasonal onboarding window entirely |
Key Takeaways
- FERPA's "school official" exception is what lets schools share student data with your product without individual parental consent for each disclosure — provided you stay within the authorized educational purpose.
- COPPA's school-consent exception matters enormously for classroom-focused edtech. Understand exactly what data you collect from under-13 users and why each element is necessary.
- State student privacy law is the fastest-moving part of this landscape. Treat check 9's ongoing monitoring as a real, recurring task, not a one-time box to check.
- Have a data privacy agreement template ready before a district asks for one. Drafting one reactively under time pressure is one of the most common, avoidable causes of a stalled pilot.
- This compliance work is far cheaper done proactively than reactively. A founder who prepares once can move from IT contact to signed agreement in weeks instead of months.
- Understanding this compliance landscape is part of validation, not a post-validation formality. A pilot that can't legally proceed teaches you nothing about product-market fit.
Frequently Asked Questions
Do I need a lawyer to handle edtech privacy compliance, or can I do this myself as a founder?
Understanding the basics yourself — enough to have an informed conversation and draft a reasonable first version of a data privacy agreement — is valuable and achievable using primary sources like the Department of Education's FERPA guidance and the FTC's COPPA guidance, but having a lawyer review your actual agreements and data practices, especially before scaling beyond early pilots, is a reasonable and often necessary investment given the real legal stakes involved.
What data can I safely collect from students without triggering additional compliance requirements?
There's no universal safe list — it depends on the specific data elements, your users' ages, and your target states — but a general principle worth following is to collect only what's genuinely necessary for the educational function your product serves, since minimizing data collection both reduces your compliance burden and reduces the risk profile a district's review will flag.
How is COPPA different from FERPA?
COPPA is a federal law focused specifically on protecting children under 13 online, applying broadly across the internet, not just in schools; FERPA is specific to education records at institutions receiving federal funding and governs how schools and their designated "school officials" (which can include your product) handle those records. An edtech product used with children under 13 in a school setting often needs to satisfy both simultaneously.
What happens if a district discovers my product isn't compliant after I've already started a pilot?
This varies by severity, but at minimum expect the pilot to be paused or ended immediately while the issue is addressed, and in more serious cases, expect it to seriously damage your credibility with that district and potentially others who hear about it — this is exactly why proactive compliance work, done before a pilot begins, is far cheaper than a reactive fix discovered mid-pilot.
Do these requirements apply if I'm selling directly to individual families rather than through schools?
Some do and some don't — COPPA still applies fully if you're collecting data from children under 13 regardless of the sales channel, but FERPA is specific to education records handled through an educational institution, so a direct-to-consumer product selling to families outside a school relationship generally isn't subject to FERPA in the same way, though it's still worth confirming this distinction carefully for your specific product and data practices.