Student data privacy law is one of those topics where the stakes are high but the guidance is scattered across federal statutes, state laws, and vendor contracts that nobody reads. If you are a school IT administrator responsible for vetting edtech tools, you need to understand three overlapping legal frameworks: FERPA, COPPA, and SOPIPA (plus whatever your state has added on top). This article breaks them down in plain English and explains what to look for — and what to watch out for — when evaluating any technology vendor that touches student data.
FERPA: The Foundation
The Family Educational Rights and Privacy Act (1974) is the oldest and broadest student privacy law. It applies to any educational institution that receives federal funding, which is essentially every public school in the United States.
FERPA protects "education records" — any records directly related to a student that are maintained by the school or a party acting on behalf of the school. This includes grades, attendance records, disciplinary records, and increasingly, data generated by edtech tools the school deploys.
Key provisions for IT admins:
- Schools control student data, not vendors. When a school shares student data with a technology vendor, that vendor acts as a "school official" under FERPA. The vendor can only use the data for the purpose the school authorized.
- Directory information exception. Schools can designate certain data (name, grade level, enrollment status) as "directory information" that can be shared without consent. But this exception does not give vendors carte blanche to use student names for marketing.
- Legitimate educational interest. Vendors can access student data only when they have a "legitimate educational interest" — meaning the data is needed to provide the service the school contracted for. A TTS tool needs to know which student is using it (for license management). It does not need to know that student's GPA.
- No re-disclosure. Vendors cannot share student data with third parties unless the school authorizes it or another FERPA exception applies.
FERPA is enforced by the U.S. Department of Education's Student Privacy Policy Office (SPPO). Enforcement is complaint-based, and penalties can include loss of federal funding — a serious consequence, though enforcement actions against vendors are rare.
COPPA: Protecting Children Under 13
The Children's Online Privacy Protection Act (1998, updated 2013) is enforced by the Federal Trade Commission and applies specifically to children under 13. Unlike FERPA, which regulates schools, COPPA regulates the companies that collect data from children.
Under COPPA, a website or online service directed at children (or that has actual knowledge it is collecting data from children) must obtain verifiable parental consent before collecting personal information. "Personal information" under COPPA is broad: it includes names, email addresses, screen names, photos, audio recordings, geolocation data, and persistent identifiers like cookies or device IDs.
Here is where it gets relevant for schools: COPPA allows schools to consent on behalf of parents in the context of educational technology used in the classroom. The FTC has explicitly stated that schools can provide the required consent when a vendor's service is used solely for an educational purpose and not for commercial exploitation.
What this means in practice:
- The school, not each parent, can authorize a vendor to collect data from students under 13. This is how tools like Google Workspace for Education, Canvas, and ReadingVox can operate in elementary schools without requiring individual parental consent forms for every student.
- The school must ensure the vendor collects only what is needed. The consent is valid only for data that is "reasonably necessary" for the educational service. If the vendor is also collecting browsing habits, interests, or behavioral data for advertising, the school's consent does not cover that.
- The school takes on responsibility. By consenting on behalf of parents, the school is vouching that it has reviewed the vendor's data practices. This is why vetting vendors before deployment matters — the school is on the hook.
COPPA violations carry real penalties. The FTC has issued fines in the millions against companies that violate COPPA, including edtech companies. In 2023, Epic Games paid $275 million for COPPA violations related to Fortnite.
SOPIPA: California's Student-Specific Law
The Student Online Personal Information Protection Act (2014) was California's response to growing concerns about edtech companies monetizing student data. While it is a California law, its influence extends far beyond the state because many national edtech vendors comply with SOPIPA standards across all their products rather than maintaining separate practices for California students.
SOPIPA applies to operators of websites, online services, and apps that are "designed and marketed for use in K-12 school purposes." Its key provisions:
- No selling student data. An operator cannot sell student information or use it for non-educational purposes. Period.
- No targeted advertising. An operator cannot use student data to target advertising to students. This means no behavioral profiles, no interest-based ads, no selling access to student attention.
- No building profiles for non-educational purposes. Even if the vendor does not sell the data, it cannot build profiles on students for purposes unrelated to the school's use of the service.
- Security requirements. Operators must implement reasonable security measures to protect student data.
- Deletion requirements. Operators must delete student data when the school or district requests it.
SOPIPA is enforced by the California Attorney General. Several other states have adopted similar or identical laws, including New York (Education Law 2-d), Colorado, Connecticut, and Illinois.
How These Laws Interact
These three frameworks overlap but cover different ground:
| | FERPA | COPPA | SOPIPA | |---|---|---|---| | Who it regulates | Schools | Companies | Companies | | Who it protects | All students | Children under 13 | K-12 students | | Scope | Education records | Personal information online | Student data from edtech | | Key prohibition | Unauthorized disclosure | Collection without consent | Selling/advertising | | Enforcement | Dept. of Education | FTC | State AG |
For a school deploying a TTS tool to elementary students, all three apply simultaneously. FERPA governs how the school shares data with the vendor. COPPA governs what the vendor can collect from children under 13 (with the school's consent). SOPIPA (and similar state laws) prohibits the vendor from selling data or using it for advertising regardless of age.
The National Data Privacy Agreement (NDPA)
The Student Data Privacy Consortium, a project of the Access 4 Learning Community (A4L), developed the National Data Privacy Agreement to standardize how schools and vendors formalize their data privacy commitments. The NDPA is not a law — it is a contract template that many state student privacy alliances have adopted.
If your state has a student privacy alliance (and most do — check the Student Data Privacy Consortium website), you can check whether a vendor has already signed the NDPA with your state. This saves significant time because the NDPA covers FERPA, COPPA, and most state-specific requirements in a single agreement.
When evaluating a vendor, ask: "Have you signed the NDPA with our state?" If yes, review the signed agreement for any modifications or exclusions. If no, ask if they are willing to sign it. A vendor that refuses to sign the NDPA is not necessarily hiding something, but it does raise the question of why.
Red Flags in Vendor Privacy Policies
After reviewing hundreds of edtech privacy policies, these are the patterns that should make you pause:
Vague language about data sharing. If the privacy policy says "we may share data with our partners, affiliates, and service providers" without specifying who those parties are and what they do with the data, that is a problem. "Partners" can mean advertising networks. "Affiliates" can mean parent companies with entirely different business models.
No Data Processing Agreement (DPA) available. If a vendor has no DPA template and seems unfamiliar with the concept, they likely have not done the work to ensure FERPA compliance. A DPA should specify what data is collected, how it is used, how it is secured, and when it is deleted.
Data stored outside the United States. This is not automatically disqualifying, but it adds complexity. FERPA and COPPA are U.S. laws, and enforcement across international borders is uncertain. If student data is stored in another country, ask what legal protections apply.
No breach notification policy. Every vendor should have a documented process for notifying schools if student data is compromised. If the privacy policy does not mention breach notification at all, that is a gap.
Retention without limits. If a vendor retains student data indefinitely "to improve our services," that conflicts with the data minimization principles in COPPA and SOPIPA. Data should be retained only as long as necessary and deleted when the contract ends.
Requiring student accounts with personal email. A TTS tool used in K-12 should not require students to create accounts with personal email addresses. This creates unnecessary personal data collection and potential COPPA liability.
How ReadingVox Approaches Student Privacy
We designed ReadingVox's architecture with these regulations in mind from the start, not as an afterthought:
Minimal data collection. ReadingVox collects only what is needed to manage the license: a student identifier (which can be an opaque ID rather than a real name), the school's license key, and usage metrics (pages read, not content of pages). We do not store the text students read. We do not build behavioral profiles. We do not track browsing history.
No advertising, no data sales. ReadingVox's business model is straightforward: schools pay $1 per student per year, and that is our entire revenue from schools. There is no second revenue stream from student data because student data has zero commercial value to us.
School-controlled authentication. Students are auto-registered under their school's site license. The school controls the student roster. When a school's license expires or they request deletion, all student records are removed.
Data stays in the U.S. Audio generation happens via AWS infrastructure in US regions. Data at rest is encrypted. Data in transit uses TLS.
Signed DPAs available. We provide a Data Processing Agreement to any school or district that requests one, and we participate in state student privacy alliance agreements where available.
COPPA-compliant by design. Because schools consent on behalf of students under 13, and because we collect only the minimum data necessary to provide the service, our data practices fall within the COPPA school consent exception.
What You Should Do Next
If you are evaluating any edtech tool — not just TTS products — here is a practical checklist:
- Read the privacy policy. Not the marketing page about privacy. The actual legal privacy policy. Look for the red flags described above.
- Request a DPA. If the vendor does not have one, that tells you something about their maturity around student data.
- Check your state privacy alliance. See if the vendor has already signed the NDPA with your state.
- Ask about data minimization. What exactly is collected? Can they show you a data inventory?
- Ask about deletion. What happens to student data when your contract ends?
- Document your review. Keep records of your privacy evaluation. If questions arise later, you want to show that you did due diligence.
Student privacy compliance is not optional, and it is not just the vendor's responsibility. Schools that deploy tools without understanding what data those tools collect are taking on risk — legal, reputational, and ethical. The good news is that asking the right questions upfront takes far less time than dealing with a data incident after the fact.