A Compromised Login at the State's Test Contractor Exposed Millions of Students. Here's the Part You Can Actually Fix.

On Friday, October 16, the California Department of Education announced a breach that should land differently depending on whether you are a parent in California or just someone who hands documents to other people. For the parent, it is personal. For everyone else, it is the clearest example yet of a rule most people feel but almost nobody applies: the breach you cannot control is the one that happens to the company holding your data, and the part you can control is how much of you they are holding in the first place.

What actually happened

The California Department of Education runs the state's standardized assessments through a non-profit contractor, Educational Testing Service, or ETS. According to the Department, an unauthorized party used a compromised login credential to access a secure file transfer site at ETS and copy files containing California student information. The copy activity ran at various times between May 22 and September 18, 2026. ETS did not discover the incursion until September 25, a week after it ended, and the Department began notifying families on Friday.

The scale is the part that sticks. The Department said the breach affects all students enrolled in the three previous school years. Politico put the total at seven million students across those three years, and the Department's own enrollment figure is more than 5.7 million students for the 2025-2026 school year alone. Reuters confirms the scope.

What came out: names, birth dates, addresses, demographic information, and disability status. What did not come out, per the Department: Social Security numbers, driver's licenses, passports, or financial account information. Parents' and guardians' data was not affected.

The weak link was a vendor with one bad credential

This was not a sophisticated zero-day. It was a compromised login credential on a file transfer site run by a contractor, copied over a window of four months.

That is the whole story, and it is the same story as the AssuranceAmerica and Lennar breaches from earlier this year, just with a new set of names. The attack side is a single reused or exposed password. The defense side is a vendor's security budget, and you will never see it or audit it. That layer is not yours to manage.

So what is yours to manage?

The part you actually do control

A breach can only expose what the breached party was holding. The ETS attackers got names, dates of birth, addresses, and disability status because those fields were in the files ETS was holding for the state. They did not get Social Security numbers, because Social Security numbers were not in those particular files.

Now here is the uncomfortable part, and it is the part the breach coverage almost never draws out. Every one of those same field categories is sitting in documents you have handed to other people on purpose. A child's enrollment form. An IEP or a 504 plan. A medical record. A proof-of-address for a rental. A pay stub to a landlord. A bank statement to a broker. An ID photo to a dozen platforms that asked for "verification."

Each of those is now somebody else's liability, living in an inbox, a shared drive, a vendor's database, a file transfer site you never heard of. And the ETS breach is a live demonstration of how a single credential on the other end of one of those chains can turn a quiet, well-meaning document you sent years ago into a line item in a breach notice.

You cannot recall the file once it is on their side. But you control whether the next file you send carries a full date of birth, a full address, and a medical status the recipient does not actually need to make their decision.

Disability status is the one people forget

Most of the field list in a breach is boring. Name, birth date, address. We are used to those. The field that should change your behavior is the last one: disability status.

It is not a field you casually email to a third party, and yet it is the most likely to be sitting in a document you have already sent. A child's IEP or 504 plan contains a name, a date of birth, a home address, a school, and a description of a disability, all on pages families are asked to share with tutors, specialists, and new schools. A medical record or an insurance form carries the same combination for an adult. Nobody is being careless when they send these. They are doing exactly what they were told. But the document was built for one recipient, and it now contains more than that one recipient needed.

That is the shape of the problem, and it is the shape redaction is built for.

What to actually do

Do the standard things: change the password for the affected service and everywhere you reused it, turn on two-factor authentication, and if a date of birth plus a name and address were involved, consider a credit freeze even when a Social Security number was not reported, because matching a person to a name and an address is the first step of identity theft.

Then add the habit that this breach is actually about. Before you attach a document to an email, a portal, or a file transfer, do this:

Name the decision the recipient is making. A landlord is deciding whether you can afford rent. A school is deciding whether a student is enrolled. That decision almost never needs your full date of birth, your full home address, or a medical status.

Redact everything outside that decision. Black out the date of birth, the address, the account numbers, and any medical or special-education detail that is not required for the specific decision.

Treat special-education and medical records as their own class. IEPs, 504 plans, and insurance forms are where the sensitive status lives. Send the minimum section that proves the point, not the whole file.

Use real redaction, not a drawn box. A black rectangle in a photo app or a PDF that has not been flattened often leaves the underlying text intact and selectable. Use a tool that flattens the export, then reopen the file and try to copy from the redacted area.

Send the minimum, once. Attach the redacted version and skip the follow-up dump of extra documents. If the recipient genuinely needs one more field later, you can send that one field then.

A landlord verifying income needs your name, your employer, the pay period, and the amount. They do not need your date of birth or your direct-deposit account number, both of which sit on a standard pay stub. A broker verifying reserves needs your ending balance and your deposit pattern, not every line item on the bank statement and not your full account number. A platform verifying you are a real adult human needs your face, your name, and your expiration date on an ID. It does not need your license number and your full home address.

The asymmetry is the whole point

Companies have a name for this: data minimization. Collect only what you need, keep it only as long as you need it. It is written into privacy law and into every serious internal policy, and it is the single most effective control there is, because data you never collected cannot leak.

The individual version is the same principle pointed in the other direction. Send only what the recipient needs to make their decision. Redacting a document takes about a minute. The exposure it prevents is permanent, because you cannot rotate a date of birth, a home address, or a medical status the way you rotate a password. When one of those leaks, it is out for good.

You cannot stop the next ETS. You cannot fix a credential you never issued. But you can make sure that when the next breach notice names a company you have ever sent a document to, that company was holding a lot less of you than it could have been.

---

Related: Redact any document online · Redact a bank statement · Redact a pay stub · Redact an ID · Redact a rental application

Ready to try it? Redact a document in your browser → nothing uploads, nothing stored, free to try. For unlimited redactions, check out our plans & pricing.