An EdTech founder walks into a procurement conversation with an Illinois district and says the four words that stop the deal: "We are FERPA-compliant." The district's compliance officer nods politely and sends a fourteen-page SOPPA addendum. Two weeks later the same founder tries the same line with a New York district and gets back a Parents Bill of Rights, a Data Security and Privacy Plan template, and a request for evidence of NIST Cybersecurity Framework alignment. Both districts have similar student populations. Both have similar security postures. Neither of them cares that the vendor is FERPA-compliant, because FERPA is not the question they are asking.
State student-privacy statutes have quietly become the operative compliance surface for EdTech selling to K-12. FERPA is the floor, and vendors treat it like the ceiling. The five state laws that actually decide whether a district contract closes on time (Illinois SOPPA, California SOPIPA, New York Ed Law 2-d, Colorado SDTSA, and the newer Ohio provisions taking effect in the 2026-27 school year) each demand specific evidence that FERPA never asked for. What follows is the state-by-state map for vendors selling into more than one of them, and the reason the Student Data Privacy Consortium's National Data Privacy Agreement got adopted precisely to short-circuit the per-state re-answer cycle.
Why FERPA-compliant is not a passing answer
FERPA is a federal statute written in 1974. It grants parents rights over educational records and requires schools to obtain consent before disclosing them. It says almost nothing about what a vendor has to prove operationally. The "school official" exception (34 CFR 99.31(a)(1)(i)(B)) is what lets vendors touch student data in the first place, but the exception itself imposes only three requirements: direct control, a legitimate educational interest, and use limited to the school's purpose. That is the entire operational footprint FERPA gives a vendor.
The state laws piled on top of FERPA because that footprint was too thin for a market where districts were signing up for hundreds of cloud-based tools per year. Every state law addresses the same underlying gap: what specific things does the vendor have to do, document, and prove, so that the district contracting with them is not signing an unbounded liability. The gaps close differently in different states.
State-by-state: what each law actually asks for
Passed in 2017, amended in 2019, in force since July 2021. Requires a written contract between the district and any operator handling covered information. Requires the district to publish a list of all such operators on its website. Requires the operator to publish, on its own website, a list of subcontractors that receive covered information. Requires breach notification to the affected school within 30 days of discovery. Prohibits selling, renting, or trading student data. The SOPPA addendum most Illinois districts hand to vendors is not optional; it is the statutory contract requirement.
Passed in 2014, effective January 2016. Places obligations on the operator (not the school) of any site, service, or app designed and marketed for K-12. Prohibits targeted advertising based on covered information. Prohibits using covered information to create a student profile for any non-school purpose. Prohibits selling covered information. Requires reasonable security procedures. California does not require a specific district-vendor contract template, but the operator obligations apply whether or not there is one, which is the enforcement lever the AG has used.
Ed Law 2-d passed in 2014; the Part 121 implementing regulations took effect January 2020 and are the operative rulebook. Requires every "third-party contractor" with access to student, teacher, or principal PII to sign a Data Sharing Agreement, produce a Data Security and Privacy Plan aligned to the NIST Cybersecurity Framework, and adopt the district's Parents Bill of Rights supplemental information. Requires notification of any breach or unauthorized disclosure to the district within seven calendar days. NIST CSF alignment is the specific piece that catches vendors off guard: the plan has to name the functions and categories, not gesture at them.
Passed in 2016. Distinguishes between "school service contract providers" (formal district contract) and "school service on-demand providers" (self-signup used by teachers or students). Prohibits targeted advertising, sale of PII, and building non-school profiles for both categories. Requires the school service contract provider to be listed publicly on the Colorado Department of Education website, with the categories of data collected and the security practices in place. The public-registry piece is what changed the diligence pattern: parents and journalists check the list, and vendors that appear on it inconsistently across districts get flagged.
Ohio Revised Code 3319.325, enacted October 24, 2024 through SB 29 (135th General Assembly) and amended December 9, 2024 through HB 432, prohibits Ohio school districts from selling or transferring student data to for-profit entities and adds vendor-side data-handling attestations and prohibitions on certain AI-based profiling of students. The Ohio provisions are the newest of the five and the ones most likely to shift again before the 2027-28 school year. Vendors selling into Ohio districts should treat the current framework as a moving target and build the evidence base broadly enough to survive amendment.
Where FERPA stops and state law starts, in one comparison
What is changing for the 2026-27 and 2027-28 school years
Three moves are worth tracking through the 2027 legislative calendar. The first is the continued extension of state laws to AI-specific data handling. Illinois amended SOPPA in the 2024 session to strengthen the operator definition; further amendments have been discussed for the 2025-26 cycle and are on the docket for 2027. New York's NIST CSF alignment requirement effectively pulls AI-model-related controls in through the framework's own updates. The second is the rise of parent-side private rights of action. California SOPIPA has always had AG enforcement; several state legislatures have proposed adding parent-level standing, which changes the exposure math for vendors from "regulator risk" to "class-action risk." The third is procurement standardization through the SDPC, which is worth its own section.
The SDPC NDPA: the short-circuit
The Student Data Privacy Consortium is a coalition of school districts, state agencies, and vendors that maintains a template contract called the National Data Privacy Agreement (NDPA). The NDPA is currently at version 2.2 and is deliberately structured so that a vendor executes one core agreement and then signs a short state-specific exhibit for each state where a district is contracting. The exhibits map the vendor's obligations to the state statute (Illinois exhibit references SOPPA, New York exhibit references Ed Law 2-d, and so on).
The NDPA got adopted because the per-state re-answer cycle was consuming weeks of vendor time per district. Signing the NDPA does not exempt a vendor from state-law compliance; it prevents the vendor from having to re-negotiate the boilerplate every time. Vendors who have signed the NDPA and posted their signed agreement on the SDPC registry are, in practice, moved through district legal review substantially faster. The public registry is the searchable artifact that district counsel checks first.
Vendors who say "we are FERPA-compliant" and stop there spend the sales cycle re-answering the same state-law questions over and over. Vendors who sign the SDPC NDPA, post the signed agreement, and produce the state-specific evidence (Illinois subprocessor list, New York DSPP with NIST CSF crosswalk, Colorado registry entry) get through district legal review in a fraction of the time. The gap is not effort; the gap is where the effort was spent.
What to do about it, if you are the vendor
- Step 1. Sign the SDPC NDPA and post the signed agreement: Execute the current NDPA core agreement and post it on the SDPC registry at studentdataprivacy.org. Add the state exhibits for every state where you have district customers or expect to acquire them. This is the single move that most reliably shortens the district legal cycle.
- Step 2. Build the Illinois SOPPA subprocessor list on your own site: SOPPA requires operators to publish the list on their own website. Even if your district customers are outside Illinois today, the list becomes the source of truth every other state law's disclosure requirement points at. Update it when subprocessors change; make it dated.
- Step 3. Produce the New York-shaped Data Security and Privacy Plan: The NIST CSF crosswalk is the piece New York districts look at first. Write it once at the function-and-category level (Identify, Protect, Detect, Respond, Recover), attach it to the DSA, and reuse it. It also becomes the security-narrative artifact you send into every other state's diligence.
- Step 4. Confirm you meet the SOPIPA prohibitions in the product itself: No targeted advertising based on covered information, no student profiles for non-school purposes, no sale of covered information. These are product-level commitments, not policy-level ones. Confirm the feature set matches and update marketing pages that imply otherwise.
- Step 5. Set breach-notification runbooks to the tightest state window: The tightest active window in this cluster is New York's 7 calendar days. Set your internal runbook to seven days for all districts, and 30 days for the Illinois-specific school-notification step. Do not run two clocks; you will miss one.
What "good" looks like on a real subprocessor change
A district in Chicago asks for a subprocessor update mid-year. Inside five business days, the vendor delivers a single bundle that answers four states at once:
- The updated Illinois SOPPA subprocessor list, posted on the vendor's own site under 105 ILCS 85/, dated as of the change.
- Reference to the current SDPC NDPA v2.2 core agreement and the Illinois exhibit already signed with the district, so nothing new needs to enter district legal review.
- A NIST CSF crosswalk showing where the added subprocessor sits in the Identify/Protect/Detect chain — the same document New York districts read first, and the same document Colorado's SDTSA reviewers look at.
- A breach-notification runbook that names 7 days as the internal ceiling — the NY Ed Law 2-d window — and confirms the added subprocessor is bound to that same window through the DPA's flow-down clauses.
Same bundle covers four of the five state statutes without rewriting. That is what building against the NDPA plus state exhibits buys — a repeatable response format, not a per-district scramble.
Where vCISO Lite sits in this
We build the state-privacy response surface as production infrastructure for EdTech vendors: signed SDPC NDPA v2.2 templates ready for state-exhibit stacking, a live subprocessor register the district can pull without an email chain, breach-notification runbooks that fire against the tightest active state window automatically, and DPA versioning that survives an audit request. Nothing about state student-privacy compliance is glamorous, but it is the surface that moves district contracts from "under legal review" to "signed" in weeks instead of quarters. The vertical playbook lives at vCISO Lite for EdTech.