This database is organised around organisations that were breached. For most of them the affected people had some relationship — a customer, a patient, an employee.
The data broker files at 26-0502, 26-0207 and the identity aggregation at 26-0219 describe a different category, and it is worth stating the consumer position plainly.
There Is Nothing To Withdraw From
When a retailer is breached, an affected person can close the account, change the password, stop shopping there. The relationship is a thing they can act on.
A person in a broker’s dataset has no account. They cannot log in, cannot delete, and in most jurisdictions cannot compel deletion without first identifying which of many brokers holds them — which requires knowing they exist.
Notification Usually Does Not Reach Them
Breach notification depends on contact details and, practically, on the organisation being able to explain who it is. A broker notifying millions of people it has never contacted, about a relationship they did not know existed, is an exercise with no precedent and no incentive.
That is part of why exposures in this category surface as research findings — as at IDMerit and the aggregated credential store in 26-0615 — rather than as notification letters.
Why We File Them Anyway
Our standard is that the database records what happened to data, which is why it includes accidental publication at 26-0428 and misconfiguration at 26-0219 alongside intrusions.
Excluding this category because the affected people cannot be counted, notified or identified would make the database a record of organisations with customers, and the exposure here is at least as real for being invisible.
This is an analysis file built on published regulatory material and research, listed below, read against files previously published by this desk. Corrections: corrections@forensicpost.com.