Quick answer
Choose a review schedule according to account risk, provider coverage and any obligations that apply to your organization. A credible breach notice, unfamiliar login or password-manager alert should trigger a prompt review rather than waiting for the next scheduled check.
Why the usual answer is unsatisfying
A calendar interval alone does not explain the risk being managed. Document why you chose a cadence and which events require an earlier check; a generic recommendation may not meet your organization’s needs.
The deeper problem is that interval-based checking assumes the thing you are checking changes at a steady rate. It does not. Your exposure changes in steps, when a company you use is breached and that dataset eventually becomes searchable — which happens at unpredictable intervals and is often discovered years after the fact.
NIST’s authentication guidance distinguishes periodic password changes from changes after evidence of compromise. That does not establish a universal breach-checking schedule or replace sector, contractual or organizational requirements.
Check when these happen
These are the triggers worth acting on. If none of them has occurred, another check will usually return what the last one did.
A company you use announces a breach
The most obvious one, and the most often ignored because the email looks like marketing. Check the address you used with that service, and change the password if you reused it anywhere.
You get a security alert
An unfamiliar sign-in notification, a password reset you did not request, or a browser or password manager warning that a saved password appeared in a breach. All three are direct evidence about your credentials.
An unfamiliar alert sender may warrant investigation before you follow its links. IndieTools Domain WHOIS can show available registration details for the domain, but it cannot authenticate the message. Confirm the alert through the service's known website or app.
You are setting up a password manager
Migrating accounts is the one moment you have a complete inventory of where you have accounts and which passwords repeat. Checking during that process is when the results are most actionable, because you are already changing things.
You discover old reuse
Finding that a password you thought was retired is still in use somewhere is a trigger in itself.
An old address resurfaces
A dormant address that is still the recovery method for something important is worth checking, precisely because you have not thought about it in years.
Someone joins or leaves your team
For a company address: a departing employee's credentials outlive their employment unless someone acts, and a new starter may be reusing a personal password. Both are events, not intervals. A process for company addresses covers this properly.
If the same change also involves a mail-provider migration, make email DNS review a separate checklist item. The IndieTools email DNS checker can inspect the published records; it cannot confirm that an employee's sessions, mailbox permissions or recovery access were revoked.
After any account compromise
If one account was accessed, check the addresses associated with the others.
And otherwise: a baseline
Between triggers, a low-frequency habit is reasonable. What follows is a suggestion, not a standard, and nothing bad happens if you drift.
Personal accounts: two or three times a year. Your primary email address, plus any old address still used for recovery.
High-value personal accounts: the same addresses, but check more attentively — if you hold significant assets, are publicly visible, or have been targeted before, quarterly is defensible.
Administrators and privileged users: more often, because the consequence of a hit is larger. Monthly for the addresses attached to administrative accounts is proportionate.
Small business: a defined review two to four times a year for staff addresses, plus the joiner and leaver triggers above.
The variable that changes all of it
The right frequency depends almost entirely on one thing: whether your passwords are unique.
If every account has its own generated password, a breach at one service exposes exactly one account. You will usually hear about it from the service itself, the fix is one password change, and a breach check adds little. Checking twice a year is plenty.
If you have reuse — and most people do, somewhere — then a single breach can expose many accounts at once, you have no way to know which without checking, and each check is genuinely informative. Check more often, and better still, spend the same effort on removing the reuse. Why unique passwords matter more than complex ones makes the case.
The general principle: detection is worth most where prevention is weakest. If you find yourself wanting to check frequently, that instinct is usually pointing at a preventive gap.
What about continuous monitoring?
Some services re-run the lookup on a schedule and email you about new matches. That converts the frequency question into someone else's problem, which is worth something.
Two caveats. It searches the same datasets a manual check searches, so it does not see more — it sees sooner, and only for sources that service holds. And its value is entirely conditional on you acting on the alert; an unread notification is worth nothing. What monitoring services can and cannot tell you covers the category.
Do not assume that a one-time lookup includes future alerts. Check the provider’s current documentation for monitoring frequency, dataset updates and supported notifications.
Is there a legal requirement?
For individuals: no. No regulation anywhere requires you to check breach databases, and any page implying otherwise is wrong.
For organisations, the picture is different but often misdescribed. Frameworks and regulations impose duties around protecting personal data, detecting incidents, and notifying regulators and affected people within deadlines. Some sector-specific requirements touch credential hygiene. None of that is the same as "you must query a breach database on a schedule", and there is a real difference between:
- A requirement: what a regulator or contract obliges you to do.
- A control: something you do because it reduces risk.
Checking employee credential exposure is a sensible control. Presenting it as a mandate — which some vendors do — is the kind of claim worth asking for a citation on.
Diminishing returns
Checking the same address weekly is not ten times better than checking it monthly. Breach datasets do not update on that cadence, and the same result repeated is not information.
The point at which extra checking stops paying is roughly where you would not do anything differently on a hit. If you already have unique passwords and MFA, you would change one password — which you would also do when the service emailed you. If you have unresolved reuse, every check is potentially the one that finds it.
What to do with a result
A match means an identifier of yours is in a dataset. It does not mean an account was accessed. What to do when your email appears in a breach has the ordered response.
A nil result means nothing was found in the data checked. It is not proof of safety, and it should not change your baseline protections. Keeping that straight is what makes any cadence sensible.
Begin with the email exposure checking guide, then decide on a review cadence that matches your risk and the provider’s actual coverage. Follow the credential exposure response playbook whenever you identify a credible exposure.
Revfaro
