Quick answer
It depends entirely on what the breached company stored, and breaches vary from an email address alone to full identity records. The most useful way to judge severity is not how sensitive a field sounds, but whether you can change it. Passwords are serious and repairable. Dates of birth and government identifiers are less dramatic to read and permanent, which eventually makes them worse.
The rule worth remembering
Sort every exposed field into one of three buckets:
- Changeable. Passwords, security answers, payment cards. Serious in the short term, fixable in minutes to days.
- Semi-permanent. Email addresses, phone numbers, physical addresses, usernames. Changeable in principle, disruptive in practice, so treat them as sticky.
- Permanent. Date of birth, name, government identifiers, biometric data. You will not be changing these. Exposure is one-way.
The instinct is to panic about passwords and shrug at dates of birth. The permanence rule inverts part of that: a password exposure is an emergency that ends, and a date of birth exposure is a mild event that never does.
The categories, and what each one means
These are the field types that commonly appear, and the ones this product's result normalisation recognises when a provider reports them.
Email addresses
How common: almost universal. If there was an account, there was an address.
What it enables: phishing aimed at you, correlation of your accounts across services, and being added to lists that get resold. On its own it is the mildest exposure there is.
Can you change it: in principle. Rarely worth it — see the response checklist for why changing an address usually costs more than it saves.
Usernames
How common: very.
What it enables: linking your accounts across sites, especially if you reuse a distinctive handle. Someone can build a picture of where you have accounts, which makes targeted phishing and account-recovery social engineering easier.
Can you change it: sometimes, per service.
Passwords and password hashes
How common: frequent, and the single most consequential category.
What it enables: direct access to the breached account, and to every other account where you reused it. This is what credential stuffing runs on.
A word on hashes. A notification saying passwords were "hashed" is not automatically reassuring. Hashing covers everything from a modern slow algorithm with a per-user salt, which is a genuine obstacle, to an unsalted fast hash, which for a common password is barely better than plain text. Unless you know the algorithm and know your password was long and unique, treat it as exposed.
Can you change it: yes, immediately, and you should. See what to do about an exposed password.
Names
How common: very.
What it enables: little on its own; a great deal in combination. A name plus a date of birth plus an address is the raw material for impersonation.
Can you change it: no, realistically.
Phone numbers
How common: common.
What it enables: smishing, voice phishing, and — the serious one — SIM-swap attempts aimed at accounts where the phone is a recovery method or a second factor. That is one reason to prefer an authenticator app over SMS.
Can you change it: yes, disruptively.
Physical addresses
How common: common where the service shipped anything or handled billing.
What it enables: convincing phishing and postal fraud, and in rare cases physical risk. An exposure that includes both a home address and a name is qualitatively different for someone with a safety concern.
Can you change it: only by moving.
Dates of birth
How common: common in financial, health and age-gated services.
What it enables: identity verification bypass. A date of birth is used as a proof of identity by banks, telecoms and government services, which is precisely the problem — it is treated as secret while being permanent and widely leaked.
Can you change it: no. Ever.
Security questions and answers
How common: less than it was, still present in older datasets.
What it enables: account recovery bypass, including on services entirely unrelated to the breach — because everyone's mother's maiden name is the same answer everywhere.
NIST's current guidance in SP 800-63B-4 states plainly that verifiers "SHALL NOT prompt subscribers to use knowledge-based authentication". Where you cannot avoid setting one, treat the answer as a second password: make it a random string and store it in your password manager.
Can you change it: yes, per service, and you should if it was exposed.
IP addresses
How common: common in logs and session tables.
What it enables: approximate location and an ISP. Modest on its own; useful for correlation and for making a phishing message more convincing.
Can you change it: it usually changes by itself.
Payment-related data
How common: less common than people fear, because compliant merchants generally do not store full card numbers. Last four digits, expiry, and billing address are more typical.
What it enables: convincing phishing ("we need to confirm the card ending 4412"). Full card data enables fraud directly.
Can you change it: yes — request a new card. If full card details were involved, do that rather than waiting for a fraudulent charge.
Government identifiers
How common: uncommon, and severe when present. National identity numbers, passport or licence numbers, tax identifiers.
What it enables: identity theft in the strict sense — accounts and credit opened in your name.
Can you change it: almost never, and the process where it is possible is onerous. This is the category where a credit freeze and the identity-monitoring category are genuinely relevant, which is a different product from breach checking. See breach checks versus identity theft protection.
Why two breaches of the same size are not the same event
A notification that says "40 million records" tells you nothing useful. Severity is driven by three things:
- Which fields. Email addresses only, versus credentials, versus identity documents.
- Whether the fields combine. Name, date of birth and address together are far more dangerous than the sum of the three separately, because that combination is what identity verification checks.
- Whether the data is still true. A ten-year-old password you have since changed is inert. A date of birth from the same dataset is exactly as valid as it was.
That third point is the one people miss when they see an old breach and dismiss it.
How this shows up in a breach search result
When a provider reports a match, the result here is normalised into a fixed vocabulary of data classes — the same categories described above — rather than passed through as free text. Two consequences worth knowing:
- The result tells you the category of data involved, not the values. It will say a dataset contained passwords; it will not show you a password.
- Unrecognised labels from the provider are discarded rather than displayed, so the list you see may be narrower than the provider's own description. It is a floor, not a ceiling.
You can check which datasets an address appears in, and how it works documents the normalisation in detail.
What to do with this
Read the notification, list the fields, and sort them:
- Any password? Treat as urgent, change it everywhere it was reused.
- Security answers? Change them where they are still in use.
- Full payment card? Get a new card.
- Government identifier, date of birth, or a name-plus-address-plus-DOB combination? Consider a credit freeze if your jurisdiction offers one, and expect this exposure to be permanent.
- Email address, username, IP only? Not an emergency. Expect phishing, and be sceptical of unexpected urgency.
For the ordered version of the response, see the breach exposure guide.