Fifty states, one codebase: student privacy law as config

This describes how state student privacy law shapes system design. It isn't legal advice.

Every US state has passed something about student data privacy. Depending on how you count, there are well over a hundred statutes on top of FERPA and COPPA.

You can't read them all, and you don't need to. Most impose contract terms rather than system behaviour, on top of the federal floor covered in FERPA for engineers, and those are satisfied by signing the right agreement. A small number impose things your software has to actually do.

The test: does this law contain a clock, a named framework, or a right somebody can exercise against my system? If yes, it's an engineering concern. If it's a list of prohibited uses, it's a contract concern, and you shouldn't be doing those things anyway.

The laws that change architecture

New York: Education Law 2-d and Part 121

The most demanding of the common ones, and a good design target, because meeting it tends to mean meeting most others.

Third-party contractors handling student data for New York educational agencies must adopt a data security and privacy plan aligned to the NIST Cybersecurity Framework, and each contract requires supplemental information describing what data is involved, how it's protected and when it will be destroyed. Agencies must publish a Parents' Bill of Rights.

The engineering consequence is the clock. A contractor must notify the educational agency of a breach no more than seven calendar days after discovery. Seven calendar days, not business days, is short enough that it has to be a rehearsed runbook with the notification path already known, not a decision made during an incident.

Illinois: SOPPA (105 ILCS 85)

Requires a written agreement between the school and each operator, gives parents inspection and correction rights, and requires schools to publish their agreements.

Its clock is thirty days from determination of a breach.

Which is the whole point of this post. New York gives you seven days and Illinois gives you thirty. A single global runbook saying "notify customers promptly" satisfies neither, and you find that out during the worst week you'll have.

California: SOPIPA and AB 1584

SOPIPA (Education Code 22584) prohibits targeted advertising based on student data, prohibits building non-educational profiles, and prohibits selling student information. AB 1584 sets required contract terms including parent access, correction and data destruction.

Mostly contractual, but "no profile building for non-educational purposes" is a real constraint on analytics and on any recommendation system reaching beyond the educational service.

Colorado, Connecticut, Texas, Utah, Virginia and others

Several states require agreements to be published, or vendors to appear on a public list of school service contract providers. Texas adds cybersecurity requirements through its own statutes, and for cloud services sold to state agencies, TX-RAMP certification comes into play. Worth knowing it exists even if a district purchase doesn't usually trigger it.

The five axes that actually vary

Read enough of these and they resolve into five variables:

Axis	What differs
Breach notification clock	How long, from what trigger, in calendar or business days
Named security framework	NIST CSF most often, sometimes a state standard
Parent rights	Inspection, correction, sometimes deletion, and whether exercised through the district or directly
Publication	Whether the agreement or the vendor must appear publicly
Prohibited uses	Advertising, profiling, sale. Broadly consistent, and you shouldn't be doing any of it

That's a schema. Which means the answer is configuration.

Hold jurisdiction rules as data

jurisdictions (code, breach_notify_hours, breach_trigger,
               breach_unit, framework, parent_rights[],
               publication_required, agreement_type, notes_url)
districts     (id, jurisdiction_code, agreement_id, …)

Each district carries its jurisdiction. Each jurisdiction carries its rules.

Your incident runbook then reads the clock from the affected districts rather than from memory. Your retention defaults derive from the jurisdiction rather than being uniform. Your data subject request tooling knows which rights apply.

The property this buys you is the one that matters during an incident. At 02:00, with a real breach, nobody is looking up New York's notification deadline. The system already knows which districts are affected, which jurisdictions they sit in, and what the shortest clock among them is.

That's a query, and it should be one.

The National Data Privacy Agreement

The single most useful thing in this area, and consistently unknown to teams new to the market.

The Student Data Privacy Consortium, part of the Access 4 Learning Community, publishes the National Data Privacy Agreement: a standard DPA with state-specific exhibits, adopted by state alliances of districts. Rather than negotiating bespoke paper with every district, you sign the NDPA for that state.

The part that changes your economics is Exhibit E, the General Offer of Privacy Terms. Signing it means any other district in that state alliance can adopt the same agreement without renegotiating. Signed agreements are listed in the SDPC Resource Registry, where a district's privacy officer will look you up before they contact you.

The difference between knowing this and not is the difference between one legal negotiation per state and fifty. Teams who don't know it experience this market as having an inexplicably long sales cycle.

What to build, and what to sign

Build:

• Jurisdiction as a first-class attribute of every district record.
• An incident runbook computing the shortest applicable clock from affected districts, with notification templates per jurisdiction.
• Retention defaults derived from jurisdiction, overridable per contract.
• Data subject request tooling (inspect, correct, delete) that works regardless of which state asked, because the strictest version isn't much harder than the loosest.
• A security plan written against NIST CSF. One state names it, several imply it, and everybody's questionnaire gets easier once it exists. See passing a district security review.

Sign:

• The NDPA for each state alliance where you have districts, with Exhibit E.
• And keep the registry entry current, because it's a discovery surface.

The realistic scope

You don't need fifty implementations. You need one implementation of the strictest common denominator, plus configuration for the four or five axes that genuinely differ.

Concretely, a team operating nationally is in good shape with: a seven-day breach notification capability, a NIST CSF-aligned security plan, per-student export and correction, a real deletion job, a published retention schedule, and the NDPA signed where they operate.

That set covers the demanding states, and everything else is a subset. Building to the loosest state and then discovering New York is the expensive order to do it in.