FERPA Compliance for EdTech: What Schools Should Ask Every Vendor
FERPA in 60 Seconds
The Family Educational Rights and Privacy Act (FERPA) is a federal law that protects the privacy of student education records. In practical terms, it means:
- Schools must have written consent from parents (or eligible students aged 18+) before disclosing personally identifiable information (PII) from education records
- Schools can share student data with EdTech vendors only under the "school official" exception — which requires a formal agreement and legitimate educational interest
- Vendors who receive student data must protect it according to FERPA requirements and use it only for the purposes specified
Violations aren't theoretical. Schools that improperly share student data can face federal complaints, loss of federal funding, reputational damage, and lawsuits. And in practice, it's the school — not the vendor — that faces the consequences if student data is mishandled.
Why This Matters More Than Ever
Schools are adopting EdTech at unprecedented rates. The average school district now uses over 1,400 EdTech tools per month. Every one of those tools that touches student data creates a potential FERPA exposure point.
The challenge is that many EdTech companies — particularly startups and smaller platforms — don't fully understand FERPA requirements. They may:
- Collect more student data than necessary
- Use student data for advertising, analytics, or product improvement beyond the educational purpose
- Store data without adequate encryption or access controls
- Retain data indefinitely, even after the school relationship ends
- Share data with third-party subprocessors without the school's knowledge
Schools need a systematic approach to evaluating EdTech vendors — and it starts with asking the right questions before signing anything.
The Essential Questions to Ask Every EdTech Vendor
1. What student data do you collect, and why?
Why it matters: FERPA requires that data collection be limited to what is necessary for the legitimate educational purpose. Vendors should be able to articulate exactly what data they collect and justify each element.
Green flags:
- A clear data inventory listing every field collected
- A stated purpose for each data element that ties to educational functionality
- No collection of data that isn't directly relevant to the product's function
Red flags:
- Vague answers like "We collect standard user data"
- Collection of data that seems unrelated to the product's purpose (e.g., a career guidance tool collecting browsing history)
- Inability to provide a data inventory
2. How do you use student data?
Why it matters: Under FERPA's school official exception, vendors may only use student data for the purposes specified in their agreement with the school. Using data for advertising, selling data to third parties, or building marketing profiles from student information is a FERPA violation.
Green flags:
- Data is used exclusively for the educational purpose specified in the contract
- No advertising, data brokering, or creation of student profiles for commercial purposes
- Clear policies against using student data for AI model training beyond the product's educational function
Red flags:
- Terms of service that allow "aggregated" or "de-identified" data use for any purpose
- Revenue models that depend on data monetization
- Ambiguous language about "improving services" or "enhancing the product experience"
3. Do you have a signed Data Privacy Agreement (DPA)?
Why it matters: FERPA's school official exception requires schools to maintain "direct control" over how vendors use student data. A Data Privacy Agreement (also called a Data Sharing Agreement) formalizes this control.
What a DPA should include:
- Scope of data shared and purpose of use
- Vendor obligations for data security, breach notification, and incident response
- Prohibition on secondary use of student data
- Data retention and deletion policies
- Subprocessor disclosure requirements
- Annual compliance certification
Industry standard: Many schools now use the Student Data Privacy Consortium's National DPA template, which standardizes these requirements across vendors. Ask the vendor if they've signed the national DPA or your state's version.
4. Where and how is student data stored?
Why it matters: Data storage practices directly affect security. Schools should understand where data lives, how it's protected, and who can access it.
Questions to ask:
- Where are your servers located? (Domestic vs. international hosting has different regulatory implications)
- Is data encrypted at rest and in transit?
- What encryption standards do you use? (AES-256 is the current standard for data at rest; TLS 1.2+ for data in transit)
- Who within your organization can access student data? What access controls are in place?
- Do you use third-party cloud providers (AWS, Azure, GCP)? If so, what are their compliance certifications?
5. What happens when the relationship ends?
Why it matters: FERPA doesn't just govern how data is used — it governs what happens to it after the vendor relationship ends. Schools should know their data won't linger in a vendor's systems indefinitely.
Green flags:
- Contractual commitment to delete all student data within a specified timeframe (30-90 days) after contract termination
- Ability for the school to export their data in a standard format before deletion
- Written confirmation of data deletion upon request
Red flags:
- No data deletion clause in the contract
- Claims that data is "anonymized" rather than deleted
- Retention policies that extend beyond the contract period
6. What is your breach notification process?
Why it matters: When a data breach occurs — and in today's threat landscape, it's "when" not "if" — schools need to know immediately so they can comply with their own notification obligations.
What to look for:
- Contractual obligation to notify the school within 24-72 hours of discovering a breach
- A clear incident response plan that the vendor can share
- Details on how the vendor will cooperate with the school's investigation
- Evidence of previous incident handling (a vendor that's never had to handle a breach may be less prepared than one that has — and handled it well)
7. Do you sell student data or share it with third parties?
Why it matters: This should be a hard "no." Any vendor that sells student data, shares it with advertisers, or provides it to data brokers is operating in direct violation of FERPA's school official exception.
What to look for:
- An unambiguous "no" to data sales
- Disclosure of all third-party subprocessors who have access to student data
- Contractual restrictions on subprocessor use of student data
- Compliance with state student privacy laws (many states, including California's SOPIPA, explicitly prohibit the sale of student data)
Beyond FERPA: State and International Requirements
FERPA is the baseline, but many states have additional student privacy laws:
- California (SOPIPA): Prohibits targeted advertising to students, sale of student data, and creation of student profiles for non-educational purposes
- New York (Education Law 2-d): Requires vendor data privacy and security plans, annual risk assessments, and breach notification within 60 days
- Colorado (SB 22-016): Requires school districts to publish EdTech vendor contracts and data practices
- GDPR (European schools): Stricter consent requirements, data minimization, right to erasure, and data processing agreements
If your school operates internationally or has students from multiple jurisdictions, your compliance obligations may be more complex. Ensure your vendor can support multi-jurisdictional compliance.
A Practical Evaluation Checklist
Use this checklist when evaluating any EdTech vendor:
- Vendor provides a clear data inventory
- Data use is limited to the stated educational purpose
- A signed DPA is in place (national or state template preferred)
- Data is encrypted at rest (AES-256) and in transit (TLS 1.2+)
- Vendor has a documented breach notification process (24-72 hours)
- Vendor does not sell or share student data with third parties
- Data retention and deletion policies are contractually defined
- Vendor can support data export in a standard format
- Subprocessors are disclosed and contractually bound
- Vendor holds relevant certifications (SOC 2, ISO 27001, or equivalent)
- Vendor complies with applicable state student privacy laws
- For international schools: GDPR compliance is documented
The Bottom Line
FERPA compliance isn't a feature — it's a requirement. Every EdTech vendor that touches student data should be able to answer these questions clearly, completely, and without hesitation. If they can't, that's your answer.
The schools that protect student privacy most effectively aren't the ones with the biggest IT departments. They're the ones with a systematic evaluation process that asks the right questions before any data is shared.
TEX is built for student data privacy — with encrypted data storage, role-based access controls, comprehensive DPAs, and compliance with FERPA, GDPR, and ST4S standards. Learn about our security practices or request a demo.