How to Choose a Breach Monitoring Vendor: 12 Questions

Every breach monitoring demo looks the same. A domain goes in, a red number comes out, and somebody says "real time".

You can sit through five of them and still not know which vendor you'd trust with thirty client domains.

So here's the short answer to the title: choose on answers you can verify yourself.

Run the vendor against domains whose breach history you already know. Get their indexing lag in days, in writing. Confirm they never return passwords.

Those three checks sort most of the field, and nine more cover the rest.

At xonPlus we get all twelve ourselves, in RFPs (requests for proposal) and security questionnaires. MSSPs send most of them (managed security providers, the shops that run monitoring for a roster of clients):

1. Where's the data from, and what do you check before it goes in?
2. Can I test your coverage on domains I already know, before I sign?
3. What is a "record" in your numbers?
4. What don't you cover?
5. When you say real time, which clock do you mean?
6. What's your own indexing lag, in days, in writing?
7. How are my clients kept apart from each other?
8. Will you show me a raw response from the live service?
9. What will my client see, and whose name is on it?
10. How do you stop a 2013 breach from looking like this morning's emergency?
11. Do you ever hand back passwords?
12. What's the bill at 10, 50 and 200 domains, and what's still mine if I leave?

Only got ten minutes with them? Ask 2, 6 and 11.

A scorecard you can paste into an RFP is further down. So are our own answers, weak ones included (it'd be a bit rich otherwise).

The data itself: questions 1 to 4

Everything downstream inherits the answer to question 1. Sources in this business are a mess: forum dumps, combolists (email and password pairs stitched together from older dumps), stealer logs (credentials harvested by malware on infected machines), scrapes, and now and then a fake built to be sold.

Expect the source types named and a verification step described. Give extra credit to anyone who admits that some entries couldn't be fully verified, and shows you which. Ask for that flag.

If a catalog of several hundred breaches is 100% "verified", nobody's looking very hard.

Question 2 is the fastest filter we know. Pick three domains whose history you already know: your own, a client's that had a public incident, one that ought to be clean. Then ask what comes back, before you sign anything.

Vendors who refuse tend to say the data's too sensitive to show pre-sale. Odd thing to say about data that's already been passed around criminal forums.

Our snapshot check runs on any domain with no account, if you want a baseline to hold the other results against.

Then the counting. Big numbers in this market are slippery, and most of the time nobody's lying; the units just differ. A record might be a row, an email address, a unique email address or, in the worst decks, a person.

Take the stealer-log collection that surfaced in February 2025: roughly 23 billion rows, going by the reporting at the time . In our hands that boiled down to 299,646,818 unique email addresses. Other catalogs landed on different totals from the same files, and none of those figures is a headcount.

So when a deck leads with billions, ask what the unit is. And ask whether an address that appears in five breaches was counted once or five times.

And question 4, which people feel rude asking. Nobody covers everything. A breach that ended in a quiet ransom payment and never leaked isn't in anyone's index.

Closed forums, Telegram channels, stealer logs bought at source: coverage there varies a lot from vendor to vendor, and the price usually tracks it. Every vendor has gaps, so pick one who'll sketch theirs on a whiteboard when you ask.

Which clock is "real time"?

"Real time" turns up in nearly every pitch. It can describe three different stretches of the journey: breach to public, public to indexed, indexed to alert. They differ by years.

We went through all three in the account takeover guide, so only the buyer's version here. A vendor controls the last two, and a single latency number almost always belongs to the last one alone.

(Some of our own product pages still quote one number without saying which leg. It's the last leg, and relabelling those pages is on our list.)

Which is why question 6 asks for days, in writing. Any catalog that stores a breach date and an added date can produce the figure in an afternoon. Ours, from the public catalog on 21 September 2026:

(Breach dates in the catalog are kept to the month, so read the small gaps as approximate. The gap also runs from the breach itself, so it includes time when the data wasn't public yet. Treat it as a ceiling on our indexing lag.)

Not flattering everywhere, is it? That 5,190 is a 2011 breach we only got round to in February 2026. Two large aggregates took us 499 and 617 days, and we published those when we could have buried them.

But you can see the shape of this year. Half of what we added in 2026 arrived inside about two months of its breach date. Behind that comes a long tail of old material, still trickling in.

If a vendor can't produce this table, ask why. We'd worry more about one that could and won't.

When the domains belong to your clients

Buying for yourself, you could stop at six. For an MSSP, the next four decide whether this becomes a service line or a support burden.

Thirty clients in one console means thirty chances to show client A something about client B. So ask how tenants (each client's walled-off slice of the console) are separated.

Then ask the follow-up most people skip. Are alert rules and reports set per tenant, or is it one global setting with filters on top? Filters get forgotten.

Question 8 sounds petty. Architecture diagrams all look competent, though, and a raw response is what your analysts and your integration will live with every day. This is one entry from our public catalog endpoint, trimmed for length:

{
  "breachID": "Adobe",
  "breachedDate": "2013-10-01T00:00:00+00:00",
  "addedDate": "2023-11-08T06:30:03+00:00",
  "domain": "adobe.com",
  "industry": "Information Technology",
  "passwordRisk": "easytocrack",
  "verified": true,
  "breachType": "DataBreach",
  "exposedData": ["Usernames", "Passwords", "Email addresses"],
  "exposedRecords": 152403035,
  "referenceURL": "https://krebsonsecurity.com/2013/10/adobe-breach-impacted-at-least-38-million-users/"
}

Boring, which is what you want. You can tell when it happened, when we indexed it, what kind of source it was, which data classes were exposed, whether we verified it, and where the public reporting lives. Look at exposedData as well: a list of categories, and no password anywhere in the response.

Those same fields answer question 10. A hit from 2013 and a hit from last month shouldn't reach a client looking identical.

With breach date, source type and data classes on every alert, the triage rule more or less writes itself. Without them every alert is an emergency until a human proves otherwise. Combolists and stealer logs will bury your analysts in recycled material.

Which leaves 9. Ask three salespeople what white label means and you'll get three answers.

A logo stuck on a PDF. Your colours in the portal. Or the full version, where alerts go out from your own domain and the vendor never shows.

Pin down which one you're buying. That monthly report gets forwarded to your client's board sooner or later, and somebody on it will want to know who wrote the thing.

Do they ever hand back passwords?

If the answer to question 11 is yes, in any form, plaintext or "partially masked", we'd stop the evaluation there. A vendor that returns credentials leaves you holding working passwords for your clients' staff, and that changes your liability and theirs. It's also the one item on this list your legal team will have an opinion on within the hour.

Exposure monitoring needs to know that a password was exposed, how it was stored, and when. The password itself adds nothing.

While you're there, ask what gets logged about your lookups. The domains you query are a client list.

What does it cost, and what do you keep when you leave?

Price is the easy one to test. Is it on the website?

Can you work out the bill at 10 domains, at 50, at 200, without a call? Is there an annual commitment, and what's the refund position if month one goes badly?

Then the exit, which nobody asks about during a purchase. When you leave, do you keep the alert history and the reports you've already sent to clients, in a format you can open? You told your clients you'd be watching, and you'll need the receipts after the contract ends.

How do you turn the twelve into an RFP section?

Score the evidence. 0 for no answer, 1 for a claim, 2 for a claim you verified yourself without the vendor's help. Twenty-four is the ceiling, and in our experience the vendors who score 2 on questions 2 and 6 rarely collapse on the rest.

There's a second use for this. The RFP your client sends you about "dark web monitoring" asks the same twelve things one level up, in clumsier words. Choose a vendor whose answers you can paste into yours, and you've done both jobs at once.

(The conversation that usually comes before that RFP is covered in what to tell a client who asks about the dark web.)

Our own answers, weak ones included

Right, our turn. When we pulled the public catalog on 21 September 2026 it held 783 breaches and 11,621,497,431 records.

One caveat on that big number. It's records, not people, and we simply add up each breach's count, which means an address sitting in five breaches gets counted five times. The catalog and the API are open, so 2, 3 and 8 are done.

Question 1: every entry carries a verified flag. 749 of the 783 are marked verified and 34 aren't, and the 34 stay visible with the flag set to false.

We'd rather show you an entry we couldn't fully confirm than pretend it isn't circulating. How we source and verify is written up on our data page.

Question 4 is where we're weakest, so plainly: we index breaches once they've become public. Of those 783 entries, 776 are classic breach dumps, five are combolists, one is a stealer log and one is a scrape.

If stealer logs bought at source are the heart of the service you're building, we aren't your only vendor. We'd tell you that on the first call.

Five and six you've seen. The table is our answer to 6, slow cases and all.

On 5 we'd only give ourselves a 1 today. That table measures from the breach date, and we haven't published the public-to-indexed leg on its own yet.

Seven and nine: xonThreatIntel+ for MSSPs isolates each client as its own tenant, with its own alerting rules, watchlists and reports. Everything carries your logo, colours, email templates and (optionally) your own domain.

By our own scoring rule that's a 1 until you've watched it work with two test tenants. Ask us to show you exactly that.

Ten: breach date, source type and data classes sit on every catalog entry, as in the sample.

Eleven: no. Our lookups match on email address and domain, and nothing we return contains a credential. The snapshot check processes lookups in memory without logging them.

And twelve. Prices are on the site: $99, $243 and $447 a month for up to 10, 25 and 50 client domains (read 21 September 2026).

Billing is monthly, with a 30-day refund where a trial would be. Above 50 domains you'll have to talk to us.

On the exit, plans run month to month, you cancel from the dashboard with no fee, and our terms say you can export your data before you close the account. What that export holds in practice is a fair thing to make us show you, so it's a 1 until you've seen it.

Where exactly the free side stops and the paid side starts has its own post.

Not a clean sweep. Start with your own domain.

Quick answers

Where the numbers came from

• Catalog size (783 breaches, 11,621,497,431 records), verified flags (749 true, 34 false) and source types (776 / 5 / 1 / 1): api.xposedornot.com/v1/breaches , pulled 21 September 2026. Records, not individuals; the total is a sum of per-breach counts.
• Indexing-lag table: same pull, entries with an added date in 2026 (125), gap measured from breachedDate to addedDate. Breach dates are stored to the month.
• 499 and 617 days on two large aggregates, and the 299,646,818 unique-address count: Stealer Logs for MSSPs, August 2026. The "roughly 23 billion rows" figure is from the infostealers.com analysis of that collection.
• The three clocks: Account Takeover Prevention Guide, September 2026.
• Sample API entry: live response for the Adobe entry, 21 September 2026, fields trimmed (logo, description, searchable, sensitive). The reference URL inside it is Brian Krebs's 2013 report.
• xonThreatIntel+ plans and refund terms: plus.xposedornot.com/pricing, read 21 September 2026. Cancellation and data export: plus.xposedornot.com/terms and the FAQ on the MSSP page, same day. Tenant isolation and white-label scope: products/threat-intel/mssp, same day. Lookup logging: the FAQ on exposure-check, same day.
• Related: Build, License or White-Label, which carried a six-question version of this list for people building a product on breach data.