Four Months of Copying: What the California Student Data Breach Teaches About Vendor File Transfers

Dark navy graphic with the headline 'Four Months Unnoticed' and a timeline showing files being copied from a file transfer site from May 22 to September 18, with discovery on September 25.

Between May 22 and September 18, 2026, an unauthorized party repeatedly copied files from a secure file transfer site run by Educational Testing Service (ETS), the nonprofit that helps administer California's statewide student tests. According to The Record, ETS did not discover the activity until September 25.

The California Department of Education (CDE) says the stolen records cover students enrolled in the state's public schools over the past three years, plus some former students going back to 2006. The state reported more than 5.7 million students enrolled in 2025-26 alone.

It is easy to read this as a story about one vendor's login. The real lesson is about what lives on file transfer sites, how long it stays there, and who is accountable for it when the data belongs to someone else.

What Happened

CDE contracts with ETS to run testing for K-12 public schools, including the CAASPP and ELPAC exams. Student data moves between districts, the state, and the testing contractor, and a secure file transfer protocol (SFTP) site was part of that exchange.

As Malwarebytes reports, the intruder used compromised login details to reach that site and copied files at various times over roughly four months. Public reporting does not explain how the login was compromised, and ETS did not respond to The Record's request for comment. We will not guess at the cause.

ETS says it disabled the account used in the theft, took the site offline, and built a new platform. It also paused some enrollment data processing and testing while it reviews its systems. CDE says it has found no evidence on the web that the data has been published, and that it is reviewing ETS's compliance with data security and contractual requirements. Family notifications began October 16 and continue through November, and affected people are offered two years of free identity protection.

What Was in the Files

The exposed fields vary by person, but the list is broad. Per The Record and Malwarebytes, it includes names, birth dates, home addresses, schools, districts, grade levels, Statewide Student Identifiers (SSIDs), and local student IDs. It also includes race or ethnicity, primary language, country of origin, English learner status, disability and Section 504 status, testing accommodations, program eligibility, and statewide assessment results.

CDE says Social Security numbers, financial account information, passwords, and parent or guardian information were not involved. That is meaningful, and we note it plainly. But this is still data about children that does not expire. A birth date, a home address, and a disability record cannot be reset the way a password can.

Four Months Is a Long Time to Copy Files

The access window is the detail that stands out. From May 22 to September 18, files left the site on multiple occasions without triggering a response. Detection came a week after the last copy.

Dwell time changes the math of a breach. A short intrusion takes what is in reach on a given day. A long one takes whatever arrives next, and file transfer sites are built to receive a steady flow of new files. We saw the same pattern in Nine Months Undetected: when files sit in readable form and an attacker holds a valid way in, time is on the attacker's side.

A Valid Login Is Not the Same as a Legitimate User

When someone signs in with working credentials, most systems do what they are asked. The files open, the transfers complete, and the logs show an authorized account doing normal things. That is the weakness of protecting data only at the door.

The question is not only whether the login was strong. It is what the login could reach, and whether the files were useful to anyone who held it. If a transfer account can read years of full student records in clear form, then one stolen credential equals one very large breach.

This is also a close cousin of the problem we covered in the Aesto Health breach: data handed to a vendor stays sensitive, and often stays around longer than anyone intended.

Shared Data, Shared Accountability

Education is a textbook case of the sensitive data supply chain. A student record moves from a school to a district, to the state, to a testing contractor, and sometimes onward to researchers or other service providers. Each handoff produces another copy. Each copy has its own access rules, its own retention period, and its own weakest login.

The Record notes that education service providers such as PowerSchool, Instructure, Illuminate Education, McGraw Hill, and Kaplan have been repeatedly targeted. Attackers have noticed that these vendors hold concentrated data about millions of people. For the schools and agencies that are the data owners, the contract does not transfer the risk. It only moves the data.

We should also be fair to the organizations involved. Once ETS found the problem, it shut the account and site down, and CDE began notifying families within weeks. Notification matters. The harder question is what could have been in place before the first file was copied.

Five Questions to Ask About Data Sent to Contractors

  1. What exactly are we sending? Does the vendor need names, birth dates, and addresses to do the job, or would masked or tokenized identifiers work?
  2. How long does it stay? Files that have served their purpose should be retired on a schedule, not kept for years in a transfer folder.
  3. Is the data protected after it lands? Encrypting the connection protects the trip. It does nothing once an authorized account opens the file.
  4. What can a single account reach? Scope access by task and by dataset, so one credential cannot open every year of records.
  5. Would we notice unusual reads? Repeated copying over four months should look different from routine transfers, if someone is watching access patterns at the file level.

OnData's Take

The ETS incident is a reminder that sensitive data does not become safe because it sits behind a login, even a secure-sounding one. Student records stay sensitive wherever they are copied, and the people they describe will live with the exposure far longer than any contract lasts.

This is the problem OnData SecureFile is built for: discovering and classifying sensitive files wherever they sit, encrypting them, and controlling who can open them, so a copied file is not automatically a readable one. For data that flows into databases and analytics, OnData SecureDB applies identity-based access control and protection at the data layer, and OnData SecureAI helps prepare and de-identify sensitive data before it is shared for analytics.

A login should not be the only thing standing between a stranger and millions of children's records. Protect the data itself, and a stolen credential stops being the whole story.