Quick answer
Breach exposure monitoring means checking whether an identifier of yours — usually an email address — appears in datasets taken from companies that were breached. It can tell you that your address was in a specific dataset. It cannot tell you that you are safe, because no service knows about every breach. The useful part is not the lookup. It is what you change afterwards, and in what order.
What this actually is
A breach happens at a company, not at you. An attacker takes a copy of that company's user records, and those records circulate: sold, traded, eventually collected into large aggregated datasets. Services in this category index those datasets so you can ask a narrow question — does this identifier appear in any of them?
That is a lookup against a historical archive. It is worth being precise about the difference between that and monitoring in the sense of a sensor:
- A sensor watches something live and tells you when it changes. A door alarm.
- A lookup searches a record of things that already happened. A library catalogue.
Breach services are the second. Some add a subscription that re-runs the lookup for you on a schedule and emails you about new matches, which is a convenience layer on top of the same archive — useful, but it does not change what is being searched.
Compromised runs point-in-time searches. You ask, it queries the configured breach intelligence provider, it returns what that provider reports at that moment. There is no continuous monitoring, no saved alerting and no domain-wide scanning. That is a deliberate scope, and knowing it is what lets you use the result correctly.
For the definition of a breach itself — how they happen, the common causes, the categories — see what a data breach is. The rest of this guide assumes it.
The three things "exposed" can mean
The single most common misreading in this subject is treating every match as the same event. Three quite different things get described with the same word, and they call for different responses.
Identifier exposure
Your email address, phone number or username appeared in a dataset. That is all it means. It says a company you had an account with lost its user list. It does not mean anyone has your password, and it does not mean anyone has accessed anything.
The realistic consequence is more spam, more phishing, and your address being present in lists that get resold. Annoying, occasionally dangerous if a convincing phishing message arrives, but not an account emergency.
Credential exposure
A password appeared alongside an identifier. This is materially worse, and it is worse in a specific way: the exposure is not limited to the site that was breached. If that password was used anywhere else, every one of those accounts is now reachable by anyone with the list. The mechanism is called credential stuffing, and it is automated.
Account compromise
Someone actually signed in. This is a different category again, and breach data is a poor way to detect it — the evidence lives in the account itself: unfamiliar sessions, changed recovery details, sent mail you did not send, security notifications you did not trigger.
A breach checker cannot tell you which of these three you are facing. It can only tell you that an identifier is present in data it can see. Sorting out which one applies is a job for you, and the article on how to check an email address walks through it case by case.
For the closely related question of what the words breach, leak and credential exposure mean when used precisely, see breach, leak and credential exposure.
What kinds of data end up exposed
Breaches differ enormously in severity, and the difference is almost entirely about which fields were in the stolen table. An email-only mailing list and a table containing passwords, dates of birth and government ID numbers are both "a breach", and treating them as equivalent is how people end up either panicking or ignoring something serious.
The categories that commonly appear include email addresses, usernames, names, phone numbers, physical addresses, dates of birth, passwords or password hashes, security questions, IP addresses, payment-related data and government identifiers. Very few breaches contain all of them. Which fields tend to appear, and why severity varies so much covers this properly.
What a lookup can and cannot prove
This is where most guidance in this category is quietly dishonest, so it is worth stating flatly.
A match proves one thing: the identifier you searched appears in data the service can see. It is evidence, and it is actionable.
A non-match proves almost nothing. Specifically, it does not distinguish between these cases:
- You have genuinely never been in a breach.
- You have been in a breach that has not been discovered.
- You have been in a breach that was discovered but never published or aggregated.
- You have been in a dataset this particular provider does not hold.
- The provider held it, but the response was partial.
No service can rule those out, because no service knows what it does not have. Any product that answers "you are safe" is making a claim it cannot support. Compromised does not operate its own comprehensive breach corpus and cannot establish any provider's total coverage — which is why a zero result here is labelled as "nothing was found in the data checked" rather than as an all-clear.
That limitation is not a reason to skip checking. It is a reason to treat the result as one input rather than a verdict, and to keep the baseline protections in place regardless of what any check says.
The response workflow
If something is found, the order matters more than the speed. Working through it in the wrong order is how people spend an hour changing low-value passwords while the account that controls all password resets is still using the leaked one.
- Identify which service was breached. The result names a dataset. That tells you which account to deal with first.
- Secure your email account first, before anything else. Email is the recovery channel for almost every other account. If its password was exposed or reused, changing that one password is worth more than the next twenty combined.
- Change the exposed password wherever it was used. Not a variant of it — a new, unique one. The leaked copy stays leaked permanently; what you are doing is making it useless.
- Turn on multi-factor authentication on email, banking, and anything holding money or identity documents. Prefer an app or a security key over SMS.
- Check recovery settings. A recovery address or phone number that is not yours is a persistence mechanism, and it survives a password change.
- Review active sessions and sign out everything you do not recognise.
- Expect targeted phishing. Exposed data makes convincing messages easy to write. Treat urgency in an unexpected message as a warning sign in itself.
The full version of this, with the reasoning behind each step and the four things that do not help, is in the response checklist.
What actually reduces your exposure
Checking is diagnosis. These are the controls that change the outcome, and they matter whether or not a check ever finds anything:
- Unique passwords everywhere. This is the highest-value habit in the whole subject, because it caps the damage of any single breach at one account. Why uniqueness beats complexity explains why this is a bigger lever than password strength.
- A password manager, because unique passwords are not achievable by memory and the alternative is a pattern, which is not unique.
- Multi-factor authentication on accounts that matter. It is not a cure — what MFA does and does not protect against is worth reading before relying on it — but it defeats the specific attack that follows most credential exposures.
- Long passwords over complex ones. NIST's current guidance, in SP 800-63B-4, requires a minimum of 15 characters where a password is the only factor, explicitly prohibits composition rules such as forced character mixes, and explicitly prohibits requiring periodic password changes. Change on evidence of compromise, not on a calendar.
How often to check
There is no regulatory answer and no industry mandate, and anyone quoting one should be asked for the citation. What there is: a sensible cadence for a personal account, a different one for an administrator, and specific events that should always trigger a check — a breach notification, a suspicious login alert, an employee leaving. How often to check sets out the cadences and the triggers.
For teams
The individual workflow does not scale by repetition. A company checking employee addresses has extra concerns: authorisation to check an address at all, privileged accounts that deserve priority, shared mailboxes that nobody owns, and the offboarding gap where a departed employee's credentials outlive their employment.
Compromised searches one identifier at a time and does not scan a domain, so a team process here is deliberate rather than automatic. Checking corporate email addresses for breach exposure describes what that process actually looks like, and building a credential exposure response playbook covers what happens after a hit.
Where this sits among the other things called "monitoring"
Two adjacent categories get confused with this one constantly:
- Dark web monitoring is usually the same breach datasets with a more dramatic name, sometimes plus material from closed forums. It has real limits that vendors rarely state. See what dark web monitoring can and cannot tell you.
- Identity theft protection is a different product solving a different problem — credit files, financial account opening, and often insurance and restoration services. It overlaps with breach checking hardly at all. See breach exposure checks versus identity theft protection.
Knowing which of the three you actually need saves money and, more usefully, prevents the belief that you are covered for something you are not.
Checking safely
Entering an email address into a reputable checker is low risk — the address is already in the datasets being searched, and it is not a secret.
Entering a password is a different question, and the answer depends entirely on whether the tool receives it. Compromised's Password Check hashes the password in your browser and sends only the first five characters of that hash; the comparison happens locally against a set of candidate suffixes. The server never receives the password or its full hash. That model is worth understanding before typing a password into anything, and is it safe to use a breach checker sets out the four questions to ask of any tool in this category.
You can check an identifier against known breach data without an account. How a search is handled end to end — what is sent, what is stored, and what is deliberately never logged — is documented in how it works.
Frequently asked questions
Does a breach match mean I was hacked?
No. It means an identifier of yours was in data taken from a company. Whether anyone has used it, and whether any account of yours was accessed, are separate questions with separate evidence.
If a checker finds nothing, am I safe?
No, and this is the most important limit to internalise. It means nothing was found in the data that service can see. Undiscovered, unpublished and unindexed breaches all look identical to a clean result.
Can I get my data removed from a breach?
No. Once a dataset has circulated, it exists in copies nobody controls. Services that promise removal from breach data are selling something that cannot be delivered. What you can change is whether the exposed information still works — a password can be replaced; a date of birth cannot.
Is continuous monitoring worth paying for?
It depends entirely on whether you would act on the alert. A notification about a new dataset is only valuable if it prompts a password change you would not otherwise have made. If your passwords are already unique and MFA is on, the marginal value is small.
Should I change my email address?
Almost never. The address is not the vulnerability; the reused password usually is. Changing an address breaks your recovery paths, your account history and your contactability, and the old address stays in the dataset regardless.