Student Data Privacy Laws by State: SOPIPA, the Vendor Rules, and What Belongs in Every Contract
Last updated August 2026 · Obtainer
found
scanned
Assembling the cover letter from the template...
Helps you comply, not legal advice
FERPA binds schools. It reaches an edtech vendor only sideways, through the school official exception and whatever your contract says. The state student data privacy laws work the other way around: they name the operator or the third party contractor and impose duties on it directly, which is why a vendor can be fully FERPA-aligned in its district agreements and still be out of compliance in Illinois, New York, or California. More than twenty states have passed something in this space since 2014. Three of them do most of the real work, and if you build for those three you are close to covered everywhere else.
The short version: California's SOPIPA bans the commercial uses, Illinois SOPPA adds signed agreements and public disclosure, and New York Education Law 2-d adds a seven-day breach notice and a parent challenge process. None of them look like a consumer privacy law. They look like procurement rules with penalties attached.
What is SOPIPA?
SOPIPA is California's Student Online Personal Information Protection Act, Senate Bill 1177, passed in 2014 and effective January 1, 2016. It applies to operators of websites, online services, and mobile applications used primarily for K-12 school purposes and designed and marketed for that purpose. It prohibits an operator from selling student information, using it for targeted advertising, or building a profile of a student for any non-educational purpose, and it requires reasonable security procedures.
What made SOPIPA the model other states copied is where it puts the duty. Earlier student privacy laws regulated schools and told them what to put in contracts. SOPIPA regulates the vendor, whether or not a contract says anything at all. A district that signs a sloppy agreement does not thereby make its vendor's conduct lawful, and a vendor cannot point at the district's paperwork as a defense.
Student data privacy laws by state: which ones impose direct vendor duties
The table covers the states whose student privacy statutes reach edtech operators most directly. Exemptions and definitions in this area are amended often, and several of these laws date to 2014 and 2015 legislative waves, so confirm a row against the current text before you build a process on it.
| State and law | Who it binds | Core prohibitions | Paperwork it forces | In force |
|---|---|---|---|---|
| California SOPIPA (SB 1177) | Operators of K-12 sites, services, and apps | No selling student data, no targeted advertising, no non-educational profiling | Reasonable security procedures; narrow de-identified use | Jan 1, 2016 |
| Illinois SOPPA (105 ILCS 85) | Operators and the districts that buy from them | Same commercial-use bans; retention tied to the contract | Signed data privacy agreement per district; districts publicly post vendors, data elements, contracts, and breaches | Jul 1, 2021 |
| New York Education Law 2-d and Part 121 | Third party contractors receiving student data | No use outside the contract's stated purposes; no redisclosure without consent | Parents' bill of rights in every contract; breach notice to the agency within 7 calendar days; subcontractor controls; data disposal terms | 2014; Part 121 regs 2020 |
| Colorado Student Data Transparency and Security Act | School service contract providers | No selling or targeted advertising | Public data inventory; vendor contract terms | 2016 |
| Georgia SB 89 | Districts and their vendors | No selling or targeted advertising by vendors | Data inventory; parental access; security plans; state Chief Privacy Officer | 2015 |
The three duties that actually change how you build
Reading across those rows, the same three operational requirements keep appearing, and each one is a discovery problem before it is a legal one.
A signed agreement per district, with the data elements named. Illinois SOPPA requires a written data privacy agreement between the district and each operator, and New York requires equivalent contract terms for every third party contractor. Both expect the agreement to specify what categories of data you receive, how long you keep them, who your subcontractors are, and what happens at termination. Vendors routinely sign these and then cannot produce, eighteen months later, an accurate list of which fields they actually hold for a given district. The agreement is a promise about your data map. If you do not have a data map, it is a promise about a guess.
Breach notice on a clock measured in days. New York's Part 121 gives a third party contractor seven calendar days from discovery to notify the educational agency. Illinois requires districts to notify parents within thirty days of a student data breach, which in practice means the vendor has to get the district the facts well inside that window. Seven days is not enough time to start working out which students were affected and which districts they belong to. That determination has to be a query you can run, not an investigation you begin.
A parent access and correction right that FERPA never gave. Illinois SOPPA lets parents inspect, review, and correct their child's data, and New York requires the contract to include a process for parents and students to challenge the accuracy of what was collected. FERPA has an amendment-and-hearing process for schools, but it creates no deletion right and no portability right, and it does not run against a vendor directly. These state laws do. If a parent in Illinois asks what your product holds about their child and asks you to fix an error in it, the district will forward that to you and expect an answer.
Does SOPIPA apply to companies outside California?
Yes, if you serve California K-12 students. These laws follow the student, not your office. An operator based in Texas that sells a reading app to a California district is squarely within SOPIPA, and the same logic puts it under Illinois SOPPA the moment an Illinois district signs. Most vendors of any size are subject to all three of the major regimes at once.
That is the practical argument against building three compliance processes. The strictest requirement in each category wins: New York's seven-day breach notice, Illinois's public vendor disclosure, SOPIPA's commercial-use ban, and a parent correction path that satisfies both Illinois and New York. Build to that composite and the remaining states are largely covered, because the 2014 to 2016 laws in Connecticut, Idaho, Oklahoma, Rhode Island, and West Virginia repeat the SOPIPA prohibitions with local variations rather than adding genuinely new duties.
How do these laws interact with COPPA and FERPA?
They stack rather than displace each other, and a K-12 vendor is usually under all three. FERPA reaches you contractually as a school official under 34 CFR 99.31(a)(1), which requires that you be under the district's direct control and not redisclose. COPPA reaches you directly as an operator collecting personal information from children under 13, and since April 22, 2026 the amended Rule has prohibited retaining that information indefinitely and required a published written retention policy. The state student privacy laws reach you directly as an operator regardless of the student's age, which is the gap that matters for high schools.
One wrinkle is worth knowing if you rely on school consent. In its 2024 rulemaking the FTC proposed defining school and school-authorized education purpose and codifying the school authorization exception into the COPPA Rule. In the final 2025 amendments the Commission declined to finalize any of the ed tech provisions, saying it would first weigh the Department of Education's plans to update the FERPA regulations. The exception survives, but it survives in FTC guidance rather than in the Rule text, and it has always been limited to collection for the use and benefit of the school and no other commercial purpose.
What about AI features in classroom products?
This is where the 2026 procurement conversations are going, and the existing statutes handle it awkwardly because none of them were drafted with generative models in mind. SOPIPA's ban on non-educational profiling and its narrow allowance for de-identified data (improving your product and demonstrating its effectiveness) is the clause most likely to be read against training on student work. Districts have started asking directly whether student inputs reach a model provider, and a vendor that cannot answer at the level of which fields go where tends to lose the renewal. If you are shipping assistant features into a district product, constraining what the model can actually reach is a design decision, and enforcing tool and data boundaries on an AI agent is easier to do before launch than to retrofit under a procurement questionnaire.
Where schools sit under the general privacy laws
Separately from the student-specific statutes, the comprehensive consumer privacy laws are starting to reach educational institutions themselves. Most exempt 501(c) nonprofits and carve out FERPA education records at the data level, which keeps the majority of schools out. Seven states break that pattern, and the details are covered in the breakdown of which states do not exempt schools from their privacy laws. For institutions rather than vendors, the operational side of FERPA requests is covered on the FERPA compliance page, and the general applicability question is worked through in the guide to which state privacy laws apply to your business.
What to do with this
The through line in every one of these laws is that somebody will eventually ask you what you hold about one specific student, and you will have a deadline measured in days rather than weeks. Illinois gives a parent a correction right, New York gives the district a seven-day breach clock, COPPA gives a parent a review-and-delete right and now a retention schedule you have to execute, and FERPA gives the school forty-five days with no extension. Four different regimes, four different requesters, one underlying question.
That question is a discovery problem. Obtainer intakes the request, finds where the person's data actually lives across your product database, analytics, support desk, and vendor systems, compiles one reviewable source-system manifest, and keeps a timestamped record of what was searched and when. A human redacts and approves before anything goes out. Obtainer helps you comply; it is not legal advice, so scope calls and any refusal stay with your counsel.
Run a data subject access request end to end
Obtainer finds where a person's data lives across your systems, compiles it into one manifest, drafts the deadline-safe response, and tracks the GDPR and CCPA clock. You review, redact, and approve what gets disclosed. Helps you comply; not legal advice.