FERPA Violations in the AI Era: 10 Real Cases and What They Will Cost in 2027

People assume a FERPA violation looks like a headline breach. A ransomware group posting a district's SIS export, a stolen laptop, a misconfigured S3 bucket. Those cases get the press. They are not the ones the Department of Education actually spends its time on. The overwhelming majority of what the Student Privacy Policy Office (SPPO) reviews are routine access-audit failures: a vendor that could not produce a list of who touched a student's record, a district that could not show a parent the sub-processor chain, a "school official" exception invoked over a contractor with no written direct-control documentation. None of it looks dramatic in the moment. All of it becomes expensive once an inspection or a records request opens the file.

The 2027 posture changes what "access" means. When a district signs a chatbot, a tutoring copilot, or an AI-mediated IEP tool, the number of parties reading student prompts and responses is no longer just the vendor's application tier. It is the model provider, the retrieval store, the moderation API, the analytics pipeline the vendor bolted on last quarter to improve retention. Ten cases below, some named and some composite patterns marked as such, show what SPPO and state regulators have been reviewing, and what the same review will look for in the AI era.

What a FERPA violation actually is

FERPA is not a data-security statute. It is a records-access statute. The core prohibition is disclosure of a student's education records to a third party without the written consent of the parent (or the eligible student, once 18). Everything that gets called a "FERPA violation" traces back to that: an unauthorized disclosure, or a failure to produce records the parent has the right to see. Breaches enter the picture when the unauthorized recipient is the internet. But the SPPO complaint log is dominated by cases where a specific person saw a specific record they should not have, and the vendor or district could not prove otherwise.

There is no private right of action. Gonzaga v. Doe (2002) settled that. The enforcement lever is federal funding: the Department of Education can, in theory, cut off funds. It has never done so. What it does instead is issue formal findings, require corrective-action plans, and publish letters that district counsel and vendor counsel then have to explain to boards and buyers. The reputational damage and the procurement fallout are the real cost.

Ten cases and patterns

1. LAUSD and AllHere (2024): the AI-chatbot collapse

Los Angeles Unified School District rolled out "Ed," an AI-powered student assistant built by AllHere Education, in the spring of 2024. In June, a former senior engineer (Chris Whiteley) went public with allegations that AllHere had piped student data through OpenAI and Anthropic infrastructure in ways not covered by the district's DPA, and had not implemented the access-audit controls the contract required. AllHere furloughed most of its staff within weeks and filed for Chapter 7 bankruptcy. LAUSD's district-side FERPA exposure was not the breach. No dump ever appeared. It was the inability to reconstruct, after the fact, who had access to what and under what consent basis. That is the shape of the AI-era FERPA case.

2. Illuminate Education breach (2022): the vendor with everyone's data

Illuminate Education, a K-12 SIS and assessment vendor, disclosed a breach in early 2022 that ultimately affected over 820,000 New York City students alone, with additional exposure across multiple other states. The regulatory response was scattered because FERPA does not fine directly. What did happen: multi-state class actions, an NYC DOE investigation, contract non-renewals, and a New York AG settlement in 2024 requiring specific security-program upgrades. The lesson for vendors is that the enforcement action rarely arrives through FERPA itself. It arrives through state student-privacy statutes (New York Ed Law 2-d, Illinois SOPPA, California AB 1584) that piggyback on FERPA's definitions but come with real fines and injunctive relief.

3. Pearson (2020-2021): the SEC disclosure case

Pearson's 2018 breach affected roughly 13,000 school, district, and university customer accounts on its AIMSweb 1.0 assessment platform, holding rows for millions of students. What made it novel was the enforcement lever: the SEC pursued Pearson for misleading investor disclosures about the incident and settled for $1 million in August 2021. FERPA never showed up in the order. But the pattern (a vendor's downstream disclosure obligations to a market it did not think of when writing its DPA) is now on every EdTech buyer's checklist.

4. Chegg (FTC, 2022): student data outside the K-12 boundary

The FTC's October 2022 consent order against Chegg required data-security programs, deletion of unnecessary consumer data, and multi-factor authentication after four separate incidents between 2017 and 2020. Chegg is post-secondary, so FERPA scope is thinner. But districts and higher-ed compliance teams now cite the order as the reference for what "reasonable security" looks like in ed-adjacent SaaS. The FTC's 2024 finalization of the COPPA rule closes some of the same gaps for under-13 users.

5. Minneapolis Public Schools ransomware (2023): the Medusa dump

The Medusa group posted approximately 92 GB of MPS data after the district refused to pay, including files with identifiable student records, disciplinary notes, and IEP details. The district's response, and the SPPO scrutiny that followed, focused less on the ransomware itself than on the retention question: why were records from years earlier still on live shares? Vendors serving districts should expect the same question about their own retention posture, because districts are now asking it in DPA renewal.

6. Fairfax County Public Schools (2015 SPPO letter): the disability-records case

SPPO's finding against FCPS in 2015 involved disclosure of disability-related education records without adequate access controls internal to the district. The letter is old, the pattern is not: role-based access to sensitive categories (special education, discipline, mental-health referrals) is where district-side FERPA cases still concentrate. Vendors that give districts a single "teacher" role and let the district figure out the rest are recreating this failure mode.

7. Composite pattern: the "school official" exception without direct control

FERPA's 2008 regulations expanded the school-official exception to cover contractors performing functions the district would otherwise handle. The catch is the "direct control" requirement: the district must maintain direct control over the contractor's use and maintenance of the records. Composite of dozens of district-side reviews: a vendor was designated a school official in the DPA, then subcontracted analytics to a third party the district never approved. Direct control breaks. The disclosure becomes unauthorized. The vendor's sub-processor register is the artifact that either saves the district or hangs it.

8. Composite pattern: the parent records request the vendor cannot fulfill

A parent asks the district for a complete record of interactions their child has had with an AI tutoring product. The district asks the vendor. The vendor's system was built to show a teacher a summary, not to export a per-student conversational history in a records-office-readable form. The delay itself is a FERPA issue: parents have the right to inspect within 45 days. This pattern shows up in state student-privacy complaints more than in federal ones, and the resolution is always the same operational fix: a per-student export the district can hand a parent without engineering effort.

9. Composite pattern: training-data leakage

An AI-mediated tool's DPA says student data is not used for training. The vendor's model provider's terms say aggregated usage may inform product improvement. The two are not reconciled. A district records officer asks the question in year two of the contract, the vendor cannot produce a clean answer, and the district issues a cure notice. No formal FERPA case ever opens. The procurement damage is done regardless.

10. Composite pattern: the sub-processor no one told the district about

Vendor onboards a new moderation API mid-contract to handle a spike in flagged content. The moderation vendor sees student prompts. The district's DPA lists a sub-processor register that has not been updated. When the district audits (or a parent's records request forces the audit), the disclosure to the moderation vendor was unauthorized under the terms of the DPA. The remediation is straightforward. The trust cost is not.

What the 2027 enforcement posture actually looks for

SPPO's public review pattern has been shifting since the FCC E-Rate cybersecurity pilot and the FTC's COPPA finalization put more evidence artifacts on the table. State regulators (New York, Illinois, Texas, Colorado) have leaned into that shift because their statutes give them fines and injunctive relief that FERPA does not. In 2027, three things will be different in practice.

What EdTech vendors and districts should do before the 2027-28 filing window

The list below is short because the pattern is repetitive. Districts and vendors that produce these five artifacts on demand handle the enforcement shift without incident. The ones that treat them as future work carry the exposure into a year when the review posture has changed under them.

• 1. Per-student access log, exportable to the records officer: For every product touching student data, a query that returns the full access history for a specific student in a records-office-readable form. Not a screenshot. Not a summary. A file the district hands to a parent under FERPA's 45-day rule without asking engineering.
• 2. Live sub-processor register with consent basis per row: Every third party (model provider, retrieval store, moderation API, analytics pipeline, support tooling that sees student data) with the consent basis under which they see it. Change of sub-processors triggers a district notification, not a silent update.
• 3. AI-model provenance and training-data attestation in the DPA itself: The DPA names the model provider, the terms under which prompts and responses flow, and the written attestation that student data is not used to train models. If the model provider's terms conflict, the DPA governs, and the vendor is on the hook for the reconciliation.
• 4. Deletion attestation with hash of the deletion log at termination: Districts are moving to DPA templates that require a signed attestation and a hash of the deletion log. Vendors that ship this artifact by default clear the largest single friction point in contract offboarding.
• 5. First-quarter tabletop on the parent records request scenario: Not the breach scenario. The records-request scenario. Thirty minutes with engineering, customer success, and legal on: parent asks for their child's full AI interaction history, district forwards the request Friday afternoon, what happens in the first four hours. This is the single highest-yield preparation for the 2027 posture.

The through-line for vendors and districts

FERPA violations are not dramatic. They are the boring end of records administration, and they compound with every sub-processor a vendor adds without updating the register. The AI era does not change the statute. It changes the number of parties reading student records under the umbrella of a single DPA, and the number of artifacts a district's records officer has to produce when a parent asks. Vendors and districts that ship the five artifacts above by default are handling the 2027 posture as an operational upgrade. Everyone else is handling it as a series of cure notices. The gap between the two is a filing window.

What "good" looks like on a real records request

A parent files a records request under §99.10. The district turns it around to the vendor. Inside the 45-day statutory window, the vendor delivers a single response bundle that answers four things without a re-audit:

• A per-record access log naming every teacher account, admin account, and service account that touched this student's records, with timestamps and the classroom activity that triggered each access.
• The sub-processor list active at the time of each access, pulled from the DPA version live at that moment (not the current one).
• Every model provider that received a prompt referencing this student, cross-referenced to the retention window active on that date.
• The consent basis and school-authorization scope that governed each access, so the district's records officer can point at the DPA clause behind every entry.

That is what a records officer needs to answer the parent's question in-window, without opening a discovery project. Vendors that ship this response format by default are handling the 2027 posture as an operational upgrade. Everyone else is handling it as a series of cure notices, and the gap between the two is a filing window.

Where vCISO Lite sits in this

We build the compliance surface districts are now asking EdTech vendors to prove: per-record access logs bound to their DPA versions, a live sub-processor register the district can pull without emailing you, records-request drills that stage the response bundle before a parent files, and evidence bundles the district's records officer can hand to SPPO without editorial work. The vertical playbook, current pricing, and the DPA-ready evidence pack live at vCISO Lite for EdTech.