Quick answer
There is no required schedule and no industry mandate. For most people, two or three times a year is enough — and it matters far less than checking when something actually happens. A breach notification, an unfamiliar login alert, a new password manager audit, or an employee leaving are all better reasons to check than a date in a calendar. If your passwords are already unique everywhere, the value of frequent checking drops sharply.
Why the usual answer is unsatisfying
Search this question and you will be told "every three months" by a dozen pages, none of which explains where three came from. It came from nowhere. Nothing about breach data operates on a quarterly cycle.
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.
This is the same reasoning that led NIST to stop recommending scheduled password changes. SP 800-63B-4 states that verifiers "SHALL NOT require subscribers to change passwords periodically" but must force a change where "there is evidence that the authenticator has been compromised." Evidence, not calendar. The same logic applies to checking.
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.
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.
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.
Compromised does not do this. Searches here are point-in-time: you ask, it queries the configured provider, it answers. There is no saved alerting and no scheduled re-check. That is a deliberate scope, and it is why this article is about your cadence rather than a subscription setting.
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.
You can run a check now, and the breach exposure guide covers the wider subject.