Quick answer
Work through your addresses in priority order — administrators and finance first, then shared mailboxes, then everyone else — and check each one against known breach data. Do it when people join and leave, when a supplier you use is breached, and a couple of times a year otherwise. Before you start, make sure you have a documented reason to be doing it and that your team knows. The point is not the finding; it is having a defined response ready when one arrives.
Why company addresses are a separate problem
An employee's work address ends up in the same places a personal one does: conference registrations, SaaS trials, vendor portals, newsletters, support tickets. Any of those can be breached, and the address is now in a dataset alongside whatever password was used.
The organisational risk follows from one behaviour: if that password was also the password to a company system, the breach at an unrelated service becomes an entry point into yours. Attackers automate exactly this — taking known address-and-password pairs and trying them elsewhere. That is credential stuffing, and no amount of internal policy affects the breach at the third party where the credential leaked.
Which means checking exposure is not really about the other company's breach. It is about finding out whether your people have reuse before someone else does.
Start with authorisation, not with checking
This step gets skipped and should not be.
A corporate email address is a company asset and also personal data associated with an identifiable person. Whether checking it against breach data is straightforward or needs care depends on your jurisdiction, your employment contracts and your internal policies. This is not legal advice and your situation may differ from the general case.
What holds up almost everywhere:
- Have a documented reason. "Protecting company systems against credential-based attack" is a legitimate security purpose. Write it down before you start rather than after someone asks.
- Tell people it happens. A line in the acceptable use or security policy is usually enough. Discovering this is being done, and never having been told, is what turns a reasonable control into a grievance.
- Scope it to company addresses. Checking an employee's personal address is a different act with a different basis, and you almost certainly do not have one. Do not do it.
- Limit who sees the results. Exposure findings name a person and imply something about their habits. Treat them like any other sensitive personnel-adjacent record.
- Do not use it to evaluate people. A hit means a service someone used was breached. It is not evidence of carelessness, and treating it that way guarantees nobody tells you the next time they think something is wrong.
Get advice appropriate to your jurisdiction if you are operating somewhere with strict works-council or employee-monitoring rules.
Priority order
Small teams cannot treat forty addresses as equally urgent, and they do not need to. Order by what an attacker gains.
First: administrative and privileged accounts
Identity provider admins, cloud console owners, domain registrar and DNS accounts, the email tenant administrator, source control owners.
These are the accounts where one compromise means everything. If you check nothing else, check these — and confirm they have phishing-resistant multi-factor authentication.
Second: finance and payment authority
Anyone who can move money, change bank details, or approve invoices. Business email compromise targets these addresses specifically, and exposure data makes the approach more convincing.
Third: shared and role-based mailboxes
support@, billing@, info@, admin@. These are high-risk for a structural reason: shared accounts tend to have shared passwords, passwords that do not change when staff change, and no single owner who feels responsible.
If a shared mailbox appears in breach data, the remediation is usually to stop having a shared password at all — convert to a distribution group or delegated access, so individuals authenticate as themselves.
Fourth: externally visible addresses
Anyone whose address is on the website, in press coverage, in app store listings or in domain registration records. These are the ones attackers find first.
Fifth: everyone else
Worth doing, lower urgency, and reasonable to batch into a scheduled review.
The offboarding gap
This is the highest-value item in this article and the least discussed.
When someone leaves, their company address is usually disabled. What survives:
- Personal accounts on third-party services registered with that address, still active.
- Passwords they used at work and reused elsewhere, unchanged.
- SaaS tools bought on a company card with an individual login nobody else knows about.
- Their address sitting in old breach datasets forever, still associated with your domain.
The credential risk does not end with the account. If a departing employee reused a work password on a service that gets breached next year, that password is still in your ecosystem if anyone else ever used it, and the pattern is still in your organisation if it came from a shared convention.
Practical steps at offboarding: disable the account, revoke sessions and tokens rather than only changing the password, rotate any shared credential that person knew, review what they had access to in third-party services, and check the address for exposure once as part of the process.
Doing the checks
Compromised searches one identifier at a time. There is no domain-wide scan, no bulk upload and no scheduled re-check — a search is a point-in-time query against a configured breach intelligence provider. That shapes the process: this is a deliberate review you run, not a dashboard that watches for you.
For a small team that is workable. Twenty addresses in priority order is a short task, and the priority ordering above means the valuable ones are done first even if you stop early.
For each address, record three things: whether anything was found, which datasets, and what you did about it. The record is what turns a one-off into a process, and it is what makes the second review take ten minutes instead of an hour.
You can check an address without an account; what a plan includes covers volume if you are checking regularly.
When something comes back
A finding is the start of the work, not the end of it. The short version:
- Establish what was exposed. An address alone means expect phishing. A credential means act now.
- Ask the person whether that password was used on company systems. Ask it in a way that gets an honest answer — which means making clear this is not a disciplinary conversation.
- Reset the company credential if there is any doubt, and invalidate sessions as well as changing the password. A password change alone leaves live sessions live.
- Verify MFA is enrolled and that a weaker fallback is not still enabled. CISA's guidance is that SMS and push-based factors are susceptible to common bypass techniques and that phishing-resistant options should be prioritised.
- Check related accounts — the same person's other company accounts, and any shared credential they had.
- Write down what happened. Two lines is enough.
The full version, with the decision points and who does what, is in a credential exposure response playbook. Build it before you need it; the middle of an incident is a bad time to be deciding who has authority to lock an account.
What actually reduces the risk
Checking is detection. These are the controls that change the outcome, and they are worth more than any monitoring subscription:
- Single sign-on, so there is one credential to protect rather than forty scattered across SaaS tools.
- Phishing-resistant multi-factor authentication on the identity provider, then on everything sensitive. What MFA protects against and what it does not is worth reading before treating it as complete.
- A password manager for the team, which is what makes "unique passwords everywhere" achievable rather than aspirational.
- Breached-password screening at password change, which NIST SP 800-63B-4 requires: compare a prospective password against a blocklist of known compromised values. The same document tells you not to force periodic rotation — that pushes people towards predictable patterns.
- No shared passwords. Delegated access and groups instead.
- A real offboarding checklist, with credential rotation on it.
How often
Event-driven beats calendar-driven. The events that matter: someone joins, someone leaves, a supplier or SaaS vendor you use announces a breach, someone reports a suspicious message, or an account shows an unusual sign-in.
Between events, two to four reviews a year of the priority addresses is proportionate for a small team. How often to check goes into the reasoning, including why "quarterly" is a convention rather than a requirement.
One caution to carry into any vendor conversation: no regulation requires you to query a breach database on a schedule. Obligations to protect personal data, detect incidents and notify are real; a checking cadence is a control you choose. Ask for the citation when someone tells you otherwise.
For the wider subject, see the breach exposure guide.