Every time a school adopts a new educational technology tool, student data is at stake. Even a simple Chrome extension that reads text aloud might collect browsing history, page content, student identifiers, or usage patterns. As an IT administrator or school leader, you need to know what data a tool collects, how it's stored, and whether using it could put your district out of compliance with federal and state privacy laws.
This article explains FERPA in practical terms, gives you a concrete checklist for evaluating any EdTech tool, and covers the adjacent laws (COPPA, SOPIPA, state laws) that many districts overlook.
FERPA in Plain English
The Family Educational Rights and Privacy Act (FERPA) is a federal law that protects the privacy of student education records. It applies to any school that receives federal funding — which is virtually every public school and most private schools in the United States.
At its core, FERPA says two things:
- Parents (and eligible students over 18) have the right to access and review their child's education records.
- Schools cannot disclose personally identifiable information (PII) from education records without consent, except under specific permitted exceptions.
The penalty for non-compliance is severe but blunt: the U.S. Department of Education can withdraw federal funding. In practice, this rarely happens, but FERPA violations can trigger complaints, investigations, and significant reputational damage.
What Counts as PII Under FERPA?
PII isn't just names and Social Security numbers. Under FERPA, PII includes:
- Student name
- Parent or family member names
- Student address
- Social Security number or student ID number
- Date of birth
- Place of birth
- Mother's maiden name
- Biometric records
- Any information that, alone or in combination, would allow a reasonable person to identify the student — this catch-all is broader than most people realize
That last point is critical. A tool that collects a student's school name, grade level, and browsing history might not collect their name — but the combination of data could still be sufficient to identify them. That's PII under FERPA.
The "School Official" Exception
Schools can share student data with EdTech vendors without parent consent under the "school official" exception — but only if specific conditions are met:
- The vendor performs a function that the school would otherwise perform itself
- The vendor is under the direct control of the school regarding use and maintenance of the data
- The vendor uses the data only for the purpose for which it was shared
- The vendor meets the criteria set by the school's annual FERPA notification for who qualifies as a "school official"
In practice, this exception is what allows schools to use Google Workspace, Canvas, and hundreds of other tools. But it requires the school to have contractual control over how the vendor handles data — which is where Data Processing Agreements come in.
The EdTech Evaluation Checklist
Before adopting any new tool that will be used by students, run through this checklist. These questions apply to any EdTech product — LMS platforms, assessment tools, reading extensions, math apps, anything.
1. What Data Does the Tool Collect?
Ask the vendor for a complete, specific list of data collected. Don't accept vague answers like "minimal data" or "only what's necessary." You need to know:
- Does it collect student names or email addresses?
- Does it collect student IDs or other identifiers?
- Does it collect browsing history or URLs visited?
- Does it collect page content (the text the student is reading)?
- Does it collect location data?
- Does it collect behavioral data (clicks, time on page, mouse movements)?
- Does it collect device information (IP address, device ID, browser fingerprint)?
For text-to-speech tools specifically: Does it store the text content of pages students visit, or does it only process text transiently (process it, generate audio, discard the text)? There's a significant privacy difference between a tool that logs every page a student reads and one that only generates audio on demand.
ReadingVox, for example, stores a student identifier (email or external ID) and aggregate usage counts. It does not store the text content of pages students visit, does not collect browsing history, and does not collect behavioral analytics.
2. Does the Vendor Sign a Data Processing Agreement (DPA)?
A DPA (sometimes called a Data Privacy Agreement or Data Sharing Agreement) is the contractual mechanism that establishes the school's direct control over student data. Without a DPA, you're relying on the vendor's privacy policy — which can change at any time and wasn't written for your benefit.
A proper DPA should include:
- Purpose limitation: Data is used only for providing the educational service
- No secondary use: Data is not used for advertising, marketing, profiling, or sale to third parties
- Data minimization: Only necessary data is collected
- Security requirements: Specific technical and organizational measures to protect data
- Breach notification: Vendor must notify the school within a defined timeframe (72 hours is standard) of any data breach
- Data deletion: Upon termination of the agreement, the vendor deletes all student data within a defined timeframe
- Subprocessor disclosure: If the vendor shares data with third parties (cloud providers, analytics services), those subprocessors are listed and bound by the same terms
If a vendor won't sign a DPA, that's a red flag. Walk away.
Pro tip: Many states have standardized DPA templates through the Student Data Privacy Consortium (SDPC). If your state participates, using the SDPC National Data Privacy Agreement simplifies the process — the vendor signs once and it covers all participating districts in the state.
3. Where Is Student Data Stored?
This question has two dimensions:
Geographic location. Is data stored in the United States? Some vendors use cloud infrastructure in other countries, which can create complications under FERPA and state laws. For most schools, data stored in the U.S. on major cloud providers (AWS, Google Cloud, Azure) is acceptable.
Infrastructure. Is data stored in the vendor's own infrastructure or a major cloud provider? Smaller vendors running on their own servers may not have the same security posture as those using AWS or Google Cloud, which have SOC 2 Type II certifications and extensive security controls.
4. Does the Vendor Sell or Share Data for Non-Educational Purposes?
This should be a hard "no." Any vendor that sells student data, uses it for targeted advertising, or shares it with data brokers is disqualified — not just ethically but legally in most states.
Ask specifically:
- Do you sell student data to any third party?
- Do you use student data to display targeted advertisements?
- Do you use student data to build profiles for non-educational purposes?
- Do you share student data with any party not listed in your DPA?
5. What Happens to Data When the Contract Ends?
When you stop using a tool, what happens to the student data it collected?
The right answer is: deleted within a defined timeframe (30–90 days is typical). The wrong answer is: "retained indefinitely," "de-identified and kept for research," or "we haven't thought about that."
Ensure the DPA specifies:
- Data is deleted upon contract termination or upon school request
- The vendor provides written confirmation of deletion
- De-identified data retention (if any) is specifically disclosed and limited
6. What Security Measures Are in Place?
You don't need to audit a vendor's entire security program, but you should ask:
- Is data encrypted in transit (HTTPS/TLS)?
- Is data encrypted at rest?
- Does the vendor have SOC 2 Type II certification?
- Does the vendor conduct regular penetration testing?
- Does the vendor have an incident response plan?
- How does the vendor handle access controls (who at the company can see student data)?
For smaller vendors and startups, SOC 2 certification may not yet be in place — and that's not automatically disqualifying. But encryption in transit and at rest, access controls, and a breach notification plan should be non-negotiable.
7. Is the Tool COPPA Compliant?
The Children's Online Privacy Protection Act (COPPA) applies to children under 13 and requires verifiable parental consent before collecting personal information. In a school context, the school can provide consent on behalf of parents — but only if the data is used for educational purposes.
For EdTech tools used in elementary schools, COPPA compliance means:
- No personal information collected from children under 13 without school consent
- No behavioral advertising targeted at children
- No social features that allow children to publicly share personal information
- Parental notification through the school
If a tool is used in K-5 classrooms, ask explicitly: "Is this tool COPPA compliant?"
8. Does the Tool Comply with Your State's Student Privacy Law?
FERPA is the federal floor, but many states have enacted stronger protections. Some notable examples:
- California (SOPIPA): Prohibits K-12 EdTech providers from selling student data, using it for non-educational advertising, or building non-educational profiles. Requires deletion on request.
- New York (Education Law 2-d): Requires DPAs with specific provisions, parent notification of third-party data sharing, and a data security plan.
- Colorado (Student Data Transparency and Security Act): Requires a data inventory and public transparency about what data EdTech vendors collect.
- Illinois (SOPPA): Requires DPAs, annual review of vendor compliance, and parental notification.
- Connecticut, Virginia, Maryland, and others have adopted or strengthened student privacy laws in recent years.
Check your state's specific requirements. Your state education agency or school board attorney can advise on applicable laws.
A Practical Workflow for Evaluating New Tools
Here's how this checklist translates into an actual evaluation process:
Step 1: Teacher requests a new tool. Instead of saying "no" or "let me think about it for six months," have a standard intake form. Ask the teacher what the tool does, what student data it might access, and whether there's a free or pilot version.
Step 2: Initial screening (15 minutes). Visit the vendor's website. Read their privacy policy. Search for them on your state's SDPC DPA list — if they've already signed your state's standard DPA, you're ahead. Check the Common Sense Privacy Program for independent evaluations.
Step 3: Vendor questionnaire. Send the vendor the checklist above. A legitimate EdTech vendor will answer these questions without hesitation. If they're evasive or can't answer, that tells you something.
Step 4: DPA execution. If the tool passes screening, execute a DPA before deployment. Use your state's standard template if available.
Step 5: Deploy and document. Add the tool to your district's EdTech inventory. Document what data it collects, under what DPA, and who approved it. This inventory is increasingly required by state law.
Step 6: Annual review. Once a year, review your vendor list. Are you still using each tool? Has the vendor changed its privacy practices? Has your DPA expired?
Where ReadingVox Stands
Since we're writing this article, we should be transparent about our own practices:
- Data collected: Student identifier (email or external ID), license key association, aggregate usage counts. No browsing history, no page content storage, no behavioral analytics.
- DPA: We sign Data Processing Agreements with every school and district. We support the SDPC National DPA template.
- Data storage: United States, on AWS infrastructure.
- Data selling: No. Student data is never sold, shared for advertising, or used for non-educational purposes.
- Data deletion: Student data is deleted within 30 days of contract termination or school request.
- COPPA: Compliant. No personal information is collected from students beyond the school-provided identifier.
- Encryption: All data encrypted in transit (TLS 1.2+) and at rest (AES-256).
We designed ReadingVox to collect as little student data as possible — not because privacy regulations forced us to, but because we don't need student data to provide text-to-speech. The less data we collect, the less data we have to protect, and the simpler the compliance picture for schools.
The Bottom Line
FERPA compliance isn't a one-time checkbox. It's an ongoing practice of evaluating tools, executing agreements, and verifying that vendors do what they said they'd do. The checklist in this article applies to any EdTech tool — not just text-to-speech, not just ReadingVox.
The good news is that most legitimate EdTech vendors understand FERPA and have processes in place. The vendors who can't answer these questions clearly — or won't sign a DPA — are the ones to avoid, regardless of how good their product looks in a demo.
Your students deserve both great tools and strong privacy protections. Those two things aren't in conflict.