Why FERPA matters for EdTech companies
If your SaaS product is used by K-12 schools, school districts, colleges, or universities in the United States, FERPA affects your business — even though FERPA was originally written for educational institutions, not software companies.
The mechanism is the school official exception (34 CFR §99.31(a)(1)). This is the legal basis most EdTech companies operate under. Get it wrong, and you're either violating FERPA (exposing your school customers to compliance risk) or failing school procurement requirements (losing deals).
This guide covers what FERPA actually requires of EdTech companies, what the school official exception demands, what you can and cannot do with student data, and how state student privacy laws layer on top.
What FERPA is — and who it actually applies to
The Family Educational Rights and Privacy Act (20 U.S.C. § 1232g; 34 CFR Part 99) gives parents and eligible students (18+) rights over educational records:
- Right to inspect and review (§99.10): Educational records must be accessible within 45 days of request
- Right to request amendment (§99.20): Inaccurate or misleading records can be challenged
- Right to consent before disclosure (§99.30): PII from education records cannot be disclosed without written consent — with defined exceptions
FERPA directly applies to educational agencies and institutions that receive federal funding from the U.S. Department of Education. EdTech companies are not directly subject to FERPA. But through the school official exception, you take on FERPA-equivalent obligations when you receive student education records from a school.
The school official exception: what it actually requires
The school official exception (34 CFR §99.31(a)(1)) allows educational institutions to disclose education records to a school official — including an outside vendor — without consent, if ALL of the following conditions are met:
| # | Requirement | What This Means for Your SaaS |
|---|---|---|
| 1 | Under direct control of the institution | Your use of student data must be controlled by the school — not just for your own business purposes. The school tells you what data to process and for what purpose. |
| 2 | Legitimate educational interest | Your access to the records must be for the purpose of performing the service you were contracted for — not for analytics, product improvement, or other purposes. |
| 3 | No re-disclosure without consent | You cannot share student education records with any third party (including your sub-processors) without the school's authorisation, except as FERPA otherwise permits. |
| 4 | Specified in the annual notification | The school's annual FERPA notification to parents/students must include vendors acting as school officials. This is the school's obligation, but you should know it exists. |
All four conditions must be met simultaneously. Meeting three of four does not qualify you for the exception.
What you cannot do with student education records
This is the list that trips up EdTech companies — especially those coming from consumer software backgrounds where data use is broader:
- No targeted advertising to students: You cannot use education records (or information from education records) to target advertising at students or their parents. This prohibition is explicit and absolute.
- No commercial profiling: You cannot build profiles of students for any non-educational purpose. Even de-identified aggregate data cannot be used to build student profiles if those profiles are used commercially.
- No selling student data: Sale of education records is prohibited. Some state laws define "sale" broadly enough to cover certain data sharing arrangements.
- No product improvement using student data without consent: Using student education records to improve your product (train ML models, tune algorithms) requires either: (a) explicit consent from the school/parents, (b) genuine de-identification that removes all individual identifiers, or (c) it's incidental to providing the contracted service.
- No re-disclosure to sub-processors without authorisation: If your platform uses third-party services that process student data, those sub-processors must be identified and authorised by the school.
What your school data processing agreement (DPA) must contain
Every school that uses your platform should sign a data processing agreement that establishes your school official exception eligibility. Here are the minimum required provisions:
- Purpose limitation: Specify exactly what services you're providing and that student data will only be used to provide those services
- Legitimate educational interest definition: Define what constitutes "legitimate educational interest" for your employees' access to student records
- Prohibited uses list: Explicitly prohibit targeted advertising, commercial profiling, and selling student data
- Re-disclosure restrictions: List any sub-processors who may access student data and the school's authorisation of those sub-processors
- Data security requirements: Specify the technical and organisational measures protecting student data
- Breach notification: Define the breach notification process and timeline (state laws may impose shorter timelines than you'd expect)
- Data deletion/return: Define what happens to student data when the contract ends
- Student rights assistance: Commit to assisting the school in responding to student access and amendment requests within the 45-day FERPA window
FERPA + COPPA: the under-13 intersection
If your EdTech product is directed to students under 13, COPPA (Children's Online Privacy Protection Act, 15 U.S.C. §§ 6501-6506) applies in addition to FERPA.
The school authority mechanism: Under the FTC's COPPA Rule, schools can consent to a COPPA-covered operator's collection of student data on behalf of parents, as long as the operator's use is limited to educational purposes. This means:
- Your school DPA can serve as both the FERPA school official agreement and the school COPPA consent mechanism
- But only if your use of the data is genuinely limited to educational purposes (no advertising, no commercial profiling)
- If your platform collects data beyond what's needed for the educational service, you may need direct parental consent under COPPA
Key COPPA obligations that apply: privacy policy disclosing what data you collect from under-13 users, right for parents to review and delete their child's data, no conditioning participation on collecting more data than necessary.
State student privacy laws: the compliance layer schools actually check
FERPA is the federal floor. Many states have significantly higher requirements — and it's often the state laws that determine whether your DPA is acceptable to school procurement teams.
| Law | Key Requirement for EdTech Vendors | Practical Impact |
|---|---|---|
| California AB 1584 / SOPIPA | Execute Student Data Privacy Agreement; prohibit advertising, commercial profiling, selling data | Required for California schools. SDPC NDPA often acceptable. |
| New York Education Law §2-d | Parents' Bill of Rights attachment to contracts; data protection plan; vendor registration with NYSED | NY schools require specific DPA addendum; some require NYSED vendor listing. |
| Texas HB 18 (SCOPE Act) | Data protection impact assessments for products with student data; additional DPA provisions | Newer requirements; Texas school districts increasingly require compliance documentation. |
| Colorado SB 267 | De-identification standards, data breach notification, prohibited commercial uses | Colorado districts require compliant DPAs before signing contracts. |
| SDPC NDPA (multi-state) | National Data Privacy Agreement template adopted by 40+ states | Signing SDPC NDPA streamlines procurement in participating states. Highly recommended. |
The Student Data Privacy Consortium (SDPC) shortcut
The SDPC maintains the National Data Privacy Agreement (NDPA) — a standard student data privacy agreement that's been adopted by 40+ states and thousands of school districts. If you sign the SDPC NDPA and register your product, many school districts will accept it directly without negotiating a custom DPA.
For EdTech companies looking to scale, SDPC membership and NDPA signing is one of the highest-ROI compliance investments you can make. It eliminates a major friction point in school procurement.
Practical checklist for EdTech SaaS companies
- Execute a written DPA with every school customer (at minimum covering the 8 provisions above)
- Ensure your sub-processors who access student data are listed and authorised in your school DPA
- Enforce that student data is used only to provide the contracted service — review your analytics pipeline and ML training data sources
- Have a breach notification procedure that meets the fastest state requirement you're subject to (some are 72 hours; California's is 30 days but many districts want faster)
- For K-12 products, verify COPPA compliance if you have users under 13
- Consider signing the SDPC NDPA to streamline multi-state school procurement
- Document your de-identification process if you use any student data for product analytics or research
Use the free FERPA Compliance Checklist Generator to assess your current posture and get a detailed remediation report. For related privacy documentation, see the Privacy Policy Generator and the GDPR Data Processing Agreement Generator if you also serve European schools.