One Login, Four Months: What the California Student Data Breach Teaches Every Board

California has just told millions of families that a vendor lost their children's data. According to the state, an unauthorized party used a single compromised login credential to reach a file-transfer site run by the Educational Testing Service (ETS), a nonprofit contractor that administers California's state-required student testing. The intruder had access from May 22 to September 18, 2026. ETS spotted the activity on September 25. Families began receiving notices on October 16.

Do the arithmetic. Counting from the first day of access, roughly four months passed before anyone noticed. That is not a story about a clever attack. It is a story about a door nobody was watching.

What the state has confirmed

The California Department of Education (CDE) says the copied files include student names, birth dates, home addresses, schools, districts, grade levels, and state and local student ID numbers. Depending on the student, they also include race or ethnicity, primary language, English learner status, disability and Section 504 status, testing accommodations, and eligibility for programs such as Title I and McKinney-Vento (the federal program supporting homeless students).

CDE says information about all students enrolled in the three previous school years was accessed, plus former students going back to 2006 whose transfer to another school was never confirmed. It has not published a victim count. The state says Social Security numbers, financial account information, passwords, and parent or guardian information were not involved. ETS says its web monitoring has found no evidence the data has been made public, and no group has claimed responsibility.

That "no evidence" language deserves care. It means ETS has not found the data for sale yet. It does not mean the data is safe.

Why this is a board story, not a technical one

This incident has no exotic malware and no zero-day. The reported cause is a stolen or leaked credential on a file-transfer site. The official notices do not explain how the credential was compromised, and I will not guess. But the governance failure pattern is familiar, and it maps directly to the Three Questions I put to every board in Cyber Risk Is Business Risk:

1. What are we protecting? Student records are a textbook example of data that is worth far more to an attacker than to the organization holding it. Disability status and testing accommodations are the kind of detail families never expect to see outside a school. If a company cannot say where its most sensitive data moves and who holds copies, it cannot answer the first question.

2. How would we know if it were compromised? Four months is the answer here, and it is a poor one. A file-transfer site with a single credential and no one noticing unusual copying is a detection gap, not a mystery. Boards should ask how long a stolen login can be used in their environment before a human sees it.

3. What happens when it is? California is now "reviewing ETS's compliance with applicable data security and contractual requirements." The state is learning, after the fact, whether its vendor met the contract. That is the wrong time to learn it.

Compliance versus security, in one contract

Notice the phrase "compliance with contractual requirements." Many organizations treat vendor security as a paperwork exercise: a questionnaire at signing, a certificate on file, a box checked. A contract can require strong controls and still leave you exposed, because paper does not detect anything. The question is never "does the vendor have a policy?" It is "would we find out within days if their access to our data went wrong?"

If you are a public company, this matters even more. When a vendor holds your customers' or employees' data, their failure becomes your disclosure problem, your regulatory problem, and eventually your board's personal-liability problem. Directors are expected to show they asked reasonable questions about third-party risk before the incident, not after it.

What to ask your CISO this week

1. Which of our vendors hold copies of sensitive data, and how do they receive it? Ask specifically about file-transfer sites, shared drives, and email attachments. Old, quiet channels are where credentials go to be forgotten.
2. Do those channels require multi-factor authentication? A password alone should not be enough to copy a database.
3. Who reviews unusual download or transfer activity, and how fast? Ask for the actual detection time in the last exercise or incident, not the policy target.
4. Do our contracts require vendors to notify us promptly, and have we tested that they would? The gap between a vendor's discovery and your notification is time your customers spend exposed.
5. Do we know the data we send is the minimum necessary? Data you never shared cannot be stolen from a vendor. Ask whether a vendor really needs every field, and how long they keep it.

The budget conversation

None of these steps requires a large new purchase. They require ownership. Someone has to be accountable for the inventory of vendor data flows, for retiring credentials that no longer need to exist, and for watching the quiet channels. When a board hears "that would cost too much," the answer is to compare it with the cost of a four-month blind spot and the lawsuits, notification costs, and lost trust that follow.

ETS is a nonprofit contractor, and the reputational damage is landing on California's education system as well. That is the lesson for every organization that hands data to someone else: you can outsource the work, but you cannot outsource the accountability.