Breach notifications are written to be survivable, which makes them poor instructions. This separates the categories of data a breach can expose by how long each stays dangerous, and gives the reader a way to decide what to do that does not depend on the wording of the notice.
The notice is not the incident
A breach notification is drafted under legal review, to be accurate and survivable at the same time. The result is usually true and rarely useful. "We have no evidence that" is a statement about the state of an investigation, not about what happened.
This is not bad faith. The same document has to satisfy regulators, avoid asserting things that later prove wrong, and not invite claims — and those constraints produce careful wording even when everyone involved is trying to help. It does mean the notice cannot be read as an account of the event. It is the most defensible true thing that could be said by the deadline.
Categories, not severity
What matters is not how serious the breach sounds. It is which categories of data were in it, sorted by how long each stays dangerous.
Rotatable in minutes. Passwords, session tokens, API keys. Annoying, bounded, fixable — provided you hear in time and the credential was not reused. If it was reused, the exposure is not one account. It is every account sharing it, and the attacker will find them by trying, which costs nothing.
Rotatable with effort. Payment cards, phone numbers, email addresses. Changeable, but the change propagates: a new number means every bank, every recovery flow, every service that sends codes to it. The cost is not the change, it is everything downstream of it.
Not rotatable at all. Date of birth. Place of birth. Mother's maiden name. National identifiers. Biometric templates. Address history. Medical history. These cannot be reissued, and they are precisely what identity verification leans on when it wants to be sure who it is speaking to. A breach of this material is not an event you recover from. It is a condition you now live with, and it does not expire.
Behavioural and relational. Who you talk to, what you looked up, where the device was. Almost never the headline, frequently the most revealing, because it is the material from which conclusions about a person get drawn — not what you are, but what you do.
Why hashing is the first question and not the last
Hashing is worth asking about. Done properly — slow, salted — it means the attacker did not walk away with a list of passwords ready to use.
It covers that and nothing else. Not the email addresses sitting beside them. Not the rest of the record. Not the fact that the attacker now knows you hold an account with that service, which is itself a useful thing to know about you. "Passwords were hashed" reassures far past its actual scope, which is why it appears so early in the notice.
What the timeline does to you
Most of the harm happens in the gap between compromise and disclosure, and that gap is routinely long. It is not dead time. Reused credentials are being tested elsewhere, and the non-rotatable material is being joined to material from other breaches.
That joining is the thing to understand. One breach is rarely the problem. The date of birth from one, the address history from another and the phone number from a third assemble into something none of them was alone — and the assembled version is what gets used to pass a verification question somewhere you have not been notified about yet.
What to actually do
Ordered by how much it helps.
Change the password there, and everywhere it was reused. Reuse is the actual finding; the breach is just how you learned about it.
Turn on a second factor that is not a text message. SMS is better than nothing and worse than the alternatives, because a number can be moved to someone else's control by a person who is good at sounding convincing on the telephone.
Treat everything non-rotatable in the exposed set as permanently public, and plan on that rather than hoping otherwise. In particular, stop using any of it as an answer to a security question, because that is the exact use it has now been disqualified from.
Expect approaches that use the leaked detail to sound legitimate. Someone who knows your address and the last four digits is demonstrating that they have the breach, not that they are your bank. The knowledge that would once have proved identity is now the cheapest thing to acquire about you.
The question to ask before the breach
A service cannot lose what it never held. One that did not ask for your date of birth cannot leak it, whatever happens to it later.
That is the only control genuinely available to a user, and it is exercised at sign-up rather than afterwards — noticing when a form asks for more than the service needs to function, and declining it or supplying an alias where the field is not load-bearing.
Breaches are not avoidable. What is adjustable is how much of you is in the one that eventually happens.