If your SaaS platform serves K-12 schools, colleges, or universities in any capacity, FERPA is the legal framework your entire data operation rests on. The Family Educational Rights and Privacy Act controls how educational institutions and their technology vendors handle student education records. Get it wrong, and the institution loses federal funding. More immediately, the school stops doing business with you, and you face significant legal exposure for data practices your engineers thought were routine.
EdTech companies typically encounter FERPA not as a company they directly comply with, but as vendors who access student data through their institutional customers. This indirect relationship does not reduce your legal responsibility. FERPA’s “school official” exception, which allows institutions to share student data with vendors, comes with specific contractual obligations that must appear in your SaaS agreement and data protection agreement. If those obligations are not there, the school is in violation of FERPA for sharing data with you, and your platform cannot legally operate in that relationship.
This article covers what FERPA requires of EdTech vendors, what your agreements must contain, how AI and analytics features create specific compliance risk, and why a well-structured data processing agreement is the difference between a school district signing your contract and walking away from your proposal entirely.
1. How FERPA Applies to EdTech Companies
FERPA is administered by the U.S. Department of Education and applies to any educational institution that receives federal funding. The law gives parents (and eligible students over 18) rights over education records, including the right to inspect and correct them, and restricts the school from disclosing those records without written consent.
EdTech vendors access education records under the “school official” exception in 34 C.F.R. § 99.31(a)(1). This exception allows a school to share student data with a vendor who performs services that the school would otherwise use its own employees to perform, such as providing an LMS, student information system, assessment tool, or communication platform. To qualify for this exception, the vendor must:
Be under “direct control” of the school with respect to the use of education records. This means the school, not the vendor, controls how student data is used, and the vendor can only use it for the specific purpose the school authorized. Use education records only for the purposes for which the school disclosed them. FERPA strictly prohibits using student data for purposes other than what was authorized, including advertising, product development, sale to third parties, or training AI models on student-generated content without explicit authorization. Have legitimate educational interest in the records they access. The vendor’s access must be necessary to perform the contracted service.
2. The Problem with Standard SaaS Agreements in the Education Market
Most SaaS agreements are written for enterprise or commercial customers, not regulated educational institutions. A standard SaaS agreement typically includes broad rights for the vendor to: use customer data for product improvement, create aggregated or de-identified data for benchmarking, share data with subprocessors without limitation, and retain data after contract termination for a reasonable period.
Every one of these provisions is potentially incompatible with FERPA when the customer is a school and the data includes student education records. Schools that have reviewed enough vendor contracts now look for these provisions specifically, and a contract that gives the vendor unlimited rights over student data will fail procurement review at most serious institutions.
Beyond the procurement problem, using student data in ways that violate FERPA creates direct legal risk for your company. While FERPA’s enforcement mechanism runs against the institution (loss of federal funding), state laws like the California Student Online Personal Information Protection Act (SOPIPA), New York’s Education Law 2-d, and similar statutes in over 40 states create direct liability for operators of student-facing online services. These state laws follow FERPA’s framework but apply to the vendor directly.
3. What Your SaaS Agreement Must Include for FERPA Compliance
Your SaaS agreement for educational customers needs a FERPA addendum or must integrate FERPA-specific provisions throughout the agreement. These provisions must address:
Definition of Education Records and Authorized Use
Your agreement must define “education records” in alignment with FERPA’s definition at 20 U.S.C. § 1232g(a)(4)(A): records, files, documents, and other materials directly related to a student that are maintained by an educational agency or institution or by a person acting for such agency. The agreement must then specifically identify the categories of education records your platform will receive and limit your use to the specific educational service being provided.
Prohibition on Unauthorized Use
Your agreement must explicitly prohibit: using student data for behavioral advertising or targeted marketing, selling student data or disclosing it to third parties for commercial purposes, using student data to build user profiles unrelated to the educational service, and using student data to train AI models or improve features unless specifically authorized by the institution and compliant with applicable student privacy laws.
Data Sharing and Subprocessor Restrictions
You cannot share education records with subprocessors without ensuring those subprocessors meet the same FERPA obligations you do. Your agreement must require approval for new subprocessors who will access education records, mandate that subprocessor agreements include equivalent FERPA restrictions, and give the school a mechanism to object to subprocessors that create compliance risk.
Breach Notification
FERPA does not specify a breach notification timeline, but state laws do, and some are quite short (as few as 30 days). Your agreement needs a breach notification provision that triggers immediately upon discovery of unauthorized access to education records, specifies who gets notified and in what form, and coordinates with state breach notification requirements. Many school districts require notification within 5-10 business days for security incidents involving student data.
4. Data Protection Agreements: The Document Schools Actually Need
In practice, most schools now require a standalone Data Protection Agreement (DPA) rather than relying on a FERPA addendum embedded in your SaaS agreement. State Student Privacy Alliances and groups like the Student Data Privacy Consortium have created model DPAs that districts can use as a baseline.
Your DPA needs to address, at minimum:
The specific data elements your platform will receive and process. Schools need to know exactly which fields in their student information system you will access, and the DPA should enumerate them. A broad “student information” definition is not sufficient for a well-run procurement process.
Data retention and deletion timelines. FERPA and state laws require that education records be returned or deleted when the contract ends, and in some cases when a student leaves the school. Your DPA must include specific timelines and a certification process confirming deletion. Schools that have been caught in breaches after contract termination almost always discover the vendor retained student data in a backup or analytics system.
Access controls and security requirements. Your DPA must describe the technical and organizational measures protecting student data: encryption standards, access logging, penetration testing frequency, and incident response procedures. Many schools require SOC 2 Type II certification or equivalent evidence of security controls.
The school’s right to audit. FERPA’s “direct control” requirement means the school must be able to verify your compliance. Your DPA should include an audit right allowing the school (or its designee) to review your data practices related to their student records. This is a deal-breaker for some districts if your agreement does not include it.
5. AI and Analytics Features: Where EdTech FERPA Violations Happen Now
The most active area of EdTech compliance risk in 2026 is artificial intelligence. Platforms that use student interaction data to train AI models, improve recommendation algorithms, or build predictive analytics face specific FERPA issues that generic privacy agreements do not address.
Using student-generated content or interaction data to train a machine learning model is not automatically authorized under the school official exception. The school official exception is tied to performing specific contracted services. Unless your contract explicitly authorizes using student data to improve your AI features, doing so likely falls outside the scope of your authorized use under FERPA.
Courts and regulators have not yet fully resolved the FERPA implications of AI training on student data, but the practical risk is clear: if a district discovers your platform has been using student interaction data to improve your AI without explicit authorization, you lose that district as a customer, and you face potential enforcement action under state student privacy laws. Your privacy policy and DPA must address AI training data practices specifically.
6. COPPA Considerations for K-12 Platforms
If your platform is used by students under 13, COPPA applies alongside FERPA. The Children’s Online Privacy Protection Act requires either parental consent or school consent (acting as agent for parents) before collecting personal information from children under 13. Under the school consent model (sometimes called the “school agent” model), the school must have provided COPPA-compliant notice to parents, and your platform must limit data collection to what is needed for the educational service.
Your agreements need to address both COPPA and FERPA in the K-12 context. A DPA that only addresses FERPA without COPPA-specific provisions is incomplete for platforms serving elementary or middle school students. A technology contracts attorney who understands the interplay between FERPA, COPPA, and state student privacy laws can structure your agreements so you are not creating liability by omission.
7. The Procurement Reality: What Schools Are Looking For
If you are selling to public school districts, you need to understand that procurement staff, general counsel offices, and information security teams all review vendor agreements. The bar has risen significantly in the last three years as high-profile EdTech data breaches put student privacy in the news. Districts that previously signed a standard SaaS agreement now require:
A signed DPA before any pilot or trial that involves real student data. Reference to the applicable state student privacy law (not just FERPA). Specific representations about your data retention, deletion, and breach notification practices. Clarity on your AI and analytics data practices. A security questionnaire or standardized security assessment (many districts use the Cloud Security Alliance CAIQ or similar).
Having a properly drafted SaaS agreement and DPA is not just a compliance issue. It is a business development issue. Districts that encounter a vendor whose agreements do not address these requirements simply move to the next vendor on their list.
Frequently Asked Questions
Does FERPA apply to EdTech companies directly or only to schools?
FERPA’s enforcement mechanism runs against institutions, not vendors. However, your access to student data is only lawful under FERPA if your contract with the school includes the obligations the “school official” exception requires. State laws like SOPIPA and New York’s Education Law 2-d apply directly to operators of student-facing online services and create direct liability for vendors.
Can we use student data to improve our platform’s AI features?
Only if your contract explicitly authorizes it and the institution has provided appropriate notice to students and parents under applicable law. Using student data for purposes beyond the contracted educational service falls outside the school official exception and likely violates both FERPA and applicable state student privacy laws. This must be addressed in your DPA before you build any AI feature that uses student interaction data.
What is the difference between a FERPA addendum and a Data Protection Agreement?
A FERPA addendum is typically a section or exhibit appended to your SaaS agreement that addresses FERPA-specific obligations. A standalone DPA is a separate agreement that covers all data protection obligations, which may include FERPA, COPPA, state student privacy laws, and general cybersecurity requirements. Many districts now require a standalone DPA in addition to or instead of a FERPA addendum.
Do we need separate agreements for higher education vs. K-12?
FERPA applies to both K-12 and higher education, but higher education students are typically adults, so COPPA does not apply. The FERPA obligations are substantially similar, but state student privacy laws often apply only to K-12 or have different requirements for higher education. Your agreements should be tailored to the specific educational context you are serving.
How long can we retain student data after a contract ends?
FERPA does not specify a retention period, but state laws vary from immediate deletion upon request to 30-60 days after contract termination. Your DPA should specify a clear timeline and include a process for certifying deletion to the institution. Retaining student data in backups or analytics systems after the authorized period ends creates significant legal exposure under state student privacy laws.
Get Your EdTech Agreements FERPA-Ready
Selling to schools requires agreements that go beyond standard SaaS contract templates. If your SaaS agreement was drafted without FERPA, COPPA, and state student privacy law requirements in mind, you are operating with legal exposure that your commercial customers would never tolerate in their own data agreements. Getting your DPA and SaaS agreement properly structured is a prerequisite for serious EdTech sales, not an afterthought.
Contact Hansen Tong at TOSLawyer.com to get SaaS agreements and data protection agreements that meet the real requirements of educational institution procurement.