EdTech Student Data Privacy Compliance: FERPA, COPPA, and State Laws for Startups Selling to Schools

Most edtech founders we talk to share the same assumption: "FERPA applies to schools, not to us. We just build the software." It's a reasonable instinct — and it's wrong. The moment your product touches student records, you step into a regulatory framework that creates direct obligations for your company, not just for the school district that buys your product. Between federal law (FERPA, COPPA), a rapidly expanding patchwork of state student privacy statutes, and procurement processes that now demand privacy certifications and signed data protection agreements, the gap between "we just build the software" and "we hold regulated student data" is where startups get exposed.

The three layers that govern every edtech vendor are FERPA's school official exception, COPPA's consent requirements, and state-level vendor laws like California's SOPIPA. Each creates direct obligations on your company — and each has specific technical and contractual requirements you must satisfy before you can close a school district contract.

FERPA's School Official Exception: Why Vendors Aren't Off the Hook

The Family Educational Rights and Privacy Act (FERPA), codified at 20 U.S.C. § 1232g and 34 CFR Part 99, is the foundational federal law governing the privacy of student education records. FERPA generally prohibits schools from disclosing personally identifiable information from education records without parental consent. But the law includes a critical exception that pulls vendors directly into the compliance picture: the school official exception.

Under 34 CFR § 99.31(a)(1)(i)(B), a school may disclose education records to a "contractor, consultant, volunteer, or other party to whom [the school] has outsourced institutional services or functions" — meaning an edtech vendor — without parental consent, provided the vendor meets three conditions:

1. Performs an institutional service or function for which the school would otherwise use employees;
2. Is under the direct control of the school with respect to the use and maintenance of education records; and
3. Is subject to the requirements of § 99.33(a), which governs the use and redisclosure of personally identifiable information from education records.

In plain terms: when a school district deploys your platform and directs it to process student data as part of an educational function, you become a "school official" under FERPA. That designation comes with strings attached. You cannot use the data for any purpose other than the authorized educational function. You cannot redisclose it without meeting FERPA's stringent conditions. And you must operate under the school's "direct control" — which in practice means your contract with the district must specify permissible uses, prohibit unauthorized disclosures, and give the school mechanisms to monitor and enforce compliance.

The U.S. Department of Education's Student Privacy Policy Office, which operates the Privacy Technical Assistance Center (PTAC), has published extensive guidance for vendors on these obligations. PTAC's resources make clear that FERPA compliance is not a one-time contract-signing exercise — it requires ongoing operational discipline, including access controls, data minimization, and breach response procedures aligned with the school's FERPA obligations.

If your product processes student records and you don't have a signed data sharing agreement with the school district that addresses FERPA's § 99.33(a) requirements, you're already out of compliance — even if the school hasn't asked for one yet. We've covered how this plays out when edtech products add AI features in our deeper look at AI in EdTech and FERPA/COPPA compliance.

COPPA: The Federal Floor for Children's Data in EdTech

While FERPA governs education records held by schools and their vendors, the Children's Online Privacy Protection Act (COPPA) imposes its own obligations on operators of websites and online services directed to children under 13 — including edtech products. COPPA is enforced by the Federal Trade Commission and codified at 16 CFR Part 312.

The core COPPA requirement that catches edtech founders off guard is verifiable parental consent. Under 16 CFR § 312.5(a), an operator must obtain verifiable parental consent before collecting, using, or disclosing personal information from children. The regulation enumerates specific approved methods — including signed consent forms, credit card verification, government ID checks, and knowledge-based authentication — and the FTC has been increasingly aggressive about enforcement.

For edtech products used in schools, the FTC has historically allowed schools to provide consent on behalf of parents in certain contexts — but this "school consent" framework is narrow and comes with conditions. The operator must still provide direct notice to parents, limit data collection to what's necessary for the educational purpose, and refrain from using children's personal information for commercial purposes like behavioral advertising. The FTC's 2025 amendments to the COPPA Rule tightened these requirements further, as we analyzed in our guide to COPPA's 2025 amendments for edtech operators.

The practical takeaway: if your edtech product is directed to children under 13 — or if you have "actual knowledge" that children under 13 are using it — you must build COPPA compliance into your product architecture from day one. That means age-gating, parental consent flows, data minimization by default, and strict limits on third-party disclosures. Our practical COPPA compliance guide for tech and edtech walks through the implementation details.

State Student Privacy Laws: SOPIPA and the Expanding Patchwork

Federal law is only the beginning. Since 2014, state lawmakers have passed nearly 150 student privacy laws across 47 states and Washington, DC, according to the Public Interest Privacy Center. A significant portion of these laws regulate edtech vendors directly — not through the school, but as standalone legal obligations on the companies themselves.

California's SOPIPA: The Model Vendor Law

California's Student Online Personal Information Protection Act (SOPIPA), codified at California Business and Professions Code § 22584, is the most influential state student privacy law for edtech vendors. SOPIPA applies directly to "operators" — defined as entities with actual knowledge that their site, service, or application is used primarily for K-12 school purposes and was designed and marketed for K-12 school purposes.

SOPIPA prohibits operators from engaging in three activities that many consumer tech companies take for granted:

• Targeted advertising on the operator's platform based on information acquired through student use of the service (§ 22584(b)(1));
• Profiling — amassing a profile about a pupil for any purpose other than K-12 school purposes (§ 22584(b)(2));
• Selling student data — though this prohibition does not apply to mergers or acquisitions, provided the successor entity remains subject to SOPIPA (§ 22584(b)(3)).

SOPIPA also requires operators to implement and maintain reasonable security procedures appropriate to the nature of the covered information (§ 22584(d)(1)), and to delete student data upon request from the school or local educational agency (§ 22584(d)(2)). Critically, SOPIPA allows operators to use deidentified data to improve their educational products — but the deidentification must be robust enough to prevent reidentification.

More than 20 states have adopted laws modeled on SOPIPA, creating a web of overlapping but not identical obligations. If your edtech product serves schools in multiple states, you need to map each state's requirements individually.

New York Education Law 2-d

New York takes a different but equally rigorous approach. Education Law § 2-d and its implementing regulations (Part 121 of the Commissioner's Regulations) require educational agencies to execute written contracts with third-party vendors that receive student data. These contracts must include specific provisions governing data security, limitations on use, breach notification, and data deletion upon termination. The New York State Education Department's Chief Privacy Officer actively enforces these requirements, and publishes determinations and enforcement actions publicly.

For edtech vendors, New York's framework means that selling to a New York school district requires a contract that meets the state's mandated terms — not just whatever data protection language you'd ordinarily propose. And because New York's regulations specify particular contractual provisions, your standard MSA or DPA may not pass muster.

The Broader State Landscape

Beyond California and New York, states including Colorado, Connecticut, and others have enacted student data privacy laws that impose direct obligations on vendors. The Public Interest Privacy Center's state law database is a useful starting point for understanding which states have vendor-focused requirements. The common thread across these laws: they prohibit using student data for commercial purposes (advertising, profiling, selling), require reasonable data security, mandate data deletion on request or contract termination, and increasingly require written agreements between schools and vendors with specific mandatory terms.

What School District Procurement Now Demands

Even setting aside statutory requirements, the practical reality of selling to school districts has changed dramatically. District technology directors and procurement officers now routinely require:

• Signed Data Protection Agreements (DPAs) that address FERPA's § 99.33(a) requirements, state law obligations, and specific security standards;
• Privacy certifications or registry listings, such as participation in the Student Data Privacy Consortium's (SDPC) National Data Privacy Agreement framework, which standardizes DPA terms across participating districts and states;
• Evidence of data security practices, including encryption, access controls, breach response procedures, and data retention/deletion policies;
• Clear data flow documentation showing exactly what student data is collected, how it's used, where it's stored, and with whom it's shared (including subprocessors and cloud infrastructure providers).

If you can't produce these documents quickly during a procurement process, districts will move on to a vendor who can. Privacy compliance has become a competitive differentiator in edtech procurement — not just a legal checkbox.

Building Compliance Into Your Product Before You Sell

For edtech founders, the practical question isn't whether you need to comply — it's what to build before you start knocking on district doors. Here's what we recommend based on the legal requirements above:

1. Map Your Data Flows

Before you can comply with FERPA, COPPA, or any state law, you need to know exactly what student data your product collects, processes, and stores. Document every data field, every subprocessor, every cloud region, and every downstream use. This data map becomes the foundation for your DPA, your privacy policy, and your responses to district security questionnaires.

2. Implement Data Minimization by Default

FERPA's "direct control" requirement, COPPA's collection limitations, and state laws like SOPIPA all push in the same direction: collect only what you need for the educational purpose, and nothing more. Build your product so that data minimization is the default, not an afterthought. If you're storing data "because we might need it someday," that's a compliance risk.

3. Build Reasonable Security from the Start

SOPIPA's "reasonable security procedures and practices" standard (§ 22584(d)(1)) is echoed across state laws. At minimum, this means encryption in transit and at rest, role-based access controls, audit logging, and a documented incident response plan. These aren't just legal requirements — they're what district security reviews will demand.

4. Ban Targeted Advertising and Profiling

Nearly every state student privacy law prohibits using student data for targeted advertising or profiling for non-educational purposes. If your product has any advertising component — or if you share data with analytics or advertising SDKs — you need to strip those out for the school-facing version of your product. This also means auditing your third-party SDKs and subprocessors for advertising-related data collection.

5. Prepare a DPA Template

Every school district contract will require a Data Protection Agreement. Rather than scrambling when a district sends you their template, prepare your own DPA in advance that addresses FERPA's school official requirements, COPPA's consent framework (if applicable), and the state-specific mandatory terms for the jurisdictions you're targeting. Having a vetted DPA ready signals that you understand the landscape — and speeds up the procurement process.

6. Build Data Deletion Capabilities

SOPIPA and other state laws require operators to delete student data on request from the school or upon contract termination. Technologically, this means you need the ability to identify and selectively delete all data associated with a specific student, school, or district — including data held by subprocessors. If your architecture doesn't support granular deletion, you'll struggle to meet these requirements.

7. Implement Age-Gating and COPPA Consent Flows

If your product is used by children under 13, COPPA applies regardless of whether a school is involved. Build age-gating mechanisms and verifiable parental consent flows that align with the FTC's approved consent methods. If you're relying on school consent, document that process carefully and ensure your product limits data collection to what's strictly necessary for the educational purpose.

Actionable Next Steps

For edtech founders preparing to sell to school districts, here's the sequence we recommend:

1. Audit your data practices now. Map every student data element your product touches, every subprocessor, and every downstream use. If you can't answer "what data do we hold and where does it go?" you can't comply with any of these laws.
2. Determine which laws apply to you. Are you a FERPA "school official" via contracts with districts? Does your product target children under 13, triggering COPPA? Which states do your customers operate in, and what vendor-specific obligations do those states impose?
3. Draft or update your DPA template. Work with counsel to create a Data Protection Agreement that addresses FERPA's § 99.33(a) requirements, COPPA's restrictions (if applicable), and the mandatory terms for each state where you operate. This is your primary compliance instrument with school districts.
4. Prepare for procurement. Gather your security documentation, data flow diagrams, privacy policy, and subprocessor list. If your target districts use the SDPC framework, review the National Data Privacy Agreement template and align your DPA accordingly.
5. Build deletion and security capabilities into your roadmap. If your product can't selectively delete student data on request, or if your security practices don't meet the "reasonable security" standard, prioritize these technical investments before you scale into more districts.
6. Get legal review before your first district contract. The cost of a privacy lawyer reviewing your contracts and data practices before you sign is a fraction of what an enforcement action or a breach will cost you — and districts will expect you to have your legal house in order.

Student data privacy compliance isn't a one-time project. It's an ongoing operational discipline that must be built into your product, your contracts, and your company culture from the beginning. The edtech companies that win district contracts are the ones that treat privacy as a feature, not a tax — and the law increasingly demands that they do.