MSSP Dark Web Monitoring: 5 Promises to Make, 3 to Never Make

An MSSP can honestly promise five things about dark web monitoring: a named scope, an alert clock it controls, the detail behind every hit, a confidence label, and a next step with an owner.

And three it should drop for good: covering the whole dark web, catching every leak before it's used, and preventing breaches. That last one is the hardest to let go of.

Simple to say. Harder to hold to when a prospect wants to hear "we catch everything".

The short version

• Your alert clock starts when a breach is indexed. When the data was stolen is out of your hands, so don't promise on it.
• Across the 147 breaches we added to our catalog in the 52 weeks to 5 October 2026, the median gap between the breach date and indexing was 73 days.
• We read 28 pages that rank for this topic. The phrase "real time" is on 11 of them, and none gives a measured time from breach to alert.

What is MSSP dark web monitoring, really?

MSSP dark web monitoring is a managed service. You watch a defined set of breach and leak sources for a client's domains and email addresses, and you tell them when something new turns up. That's all it is, and done well it's plenty.

The "dark web" part is looser than it sounds. The FTC describes it as "places on the internet not indexed by traditional search engines". Most stolen data is traded in fairly ordinary places: forums, chat channels, shared download links.

Clients ask for it by that name anyway. In a 2023 vendor survey of more than 500 MSSPs in the US and UK (reported by ITPro ), 65% said customers had asked for dark web intelligence and 56% were already offering monitoring.

So the question is coming, if it hasn't landed already. We covered how to answer it in what to tell clients who ask about the dark web.

The harder part comes next. What do you put in the proposal, the contract and the monthly report?

Why does the wording matter so much?

Because the promise is the part that gets repeated back to you a year later. And most of the wording on offer is written to close a sale.

We went through 28 pages that rank or get cited for MSSP dark web monitoring (5 October 2026). They're mostly product pages and "why you should sell this" posts. The lines run to a type: find it "before it can be weaponised", know "the moment" it appears, "prevent" the breach.

The phrase "real time" is on 11 of the 28. Not one page gives a measured time from breach to alert, and we couldn't find a sample service level an MSSP could put in a contract. (A few do admit limits, usually in one buried sentence.)

Those lines are fine on a billboard. In a signed scope of work they become your liability the first time a monitored client gets hit anyway.

Our view, from the partner conversations we've had: a smaller promise kept every month does more for the renewal than a big one that slips.

What can you promise? Five things

1. A named scope

Say exactly what you watch: these domains, against this catalog of sources. Ours held 787 breaches and 11.63 billion records on 5 October 2026.

(Records, not people. One person turns up in plenty of breaches.)

A named scope also means saying what sits outside it. Clients rarely think about this until an incident, so put it in writing on day one.

Does the right-hand column weaken the pitch? We've seen the opposite. A buyer who's read three vendor pages that promise to see everything tends to trust the one provider who draws the edge.

2. An alert clock you control

You can't promise when a breach will surface. You can promise how fast you move once it has.

Our own catalog shows why the difference matters. For the 147 breaches added in the 52 weeks to 5 October 2026, the median time between the breach date and the day we indexed it was 73 days. Only 2 of the 147 were indexed within a week of the breach.

That lag isn't a pipeline problem. Breaches surface late (some are found years on), breach dates are often estimates, and we verify before we index. But it means "real time" can only describe the last leg.

(Our own alert figure is measured the same way. For a domain you've onboarded, the alert goes out within 15 minutes of a breach landing in our index, and it covers nothing before that.)

So promise the last leg. "We alert you within one business day of a new breach being indexed for your domain" is a line you can keep.

Why a business day, when our part takes minutes? Because the rest of that window is yours: somebody checks the hit, adds the label and writes to the client.

With xonThreatIntel+ the alert reaches you by email, or by webhook on the larger plans. Each client gets its own alerting rules, so that clock is yours to set.

3. The detail behind every hit

"Fourteen of your addresses appeared." What is the client meant to do with that?

Promise three facts with every alert: which breach, when it happened, and what kinds of data sat alongside the email address. Our catalog holds a breach date and an indexed date for every entry. So an old hit gets labelled as old.

And the data types change the conversation. In those same 147 breaches, names were exposed in 115 (78%), phone numbers in 92 (63%) and physical addresses in 77 (52%). That's phishing and impersonation material, which is a different briefing from a login problem.

There's a privacy side to this promise too, and none of the 28 pages tells an MSSP how to answer it. Your client's HR lead will ask who at your firm can see staff passwords. With our data the answer is nobody: what comes back is exposure facts (which breach, when, what kinds of data), never the stolen records, and we never store plaintext passwords.

4. A confidence label

Of the 787 breaches in our catalog, 34 (4.3%) carry an unverified flag. That means the affected organisation hasn't acknowledged the breach. We show those and we label them, so you can do the same for your client.

Tell clients this before the first alert goes out. A hit in an index is a signal, not a verdict.

Age matters as well. A hit from a decade-old breach is a tidy-up job. A fresh entry from an infected laptop is a live problem that needs the device looked at, and we walk through that difference in stealer logs explained for MSSPs.

One line per alert does it: verified or not, how old, and where it came from. It also stops the Friday-evening panic call about a breach from nine years ago.

5. A next step, with an owner

Finding exposure is only half a service. Somebody has to act on it, and the contract should say who.

It matters because an alert with no owner tends to sit. In a Google and UC Berkeley study, "Data Breaches, Phishing, or Malware?" (ACM CCS 2017), the median hijacked account took 168 days to get back into its owner's hands. Part of the reason was that nobody had reached the owner.

Those were personal accounts and not staff logins. The lesson still carries to a client: name the person, and tell them directly.

Write the split down.

You triage and notify within your window. The client's IT contact forces the credential change and ends open sessions (or you do it under a managed tier). Then you record that the client was told, and when.

That last record is easy to skip. Don't. If a client ignores three alerts and gets breached, your log of who was told on which date is the most useful document you own.

For the full sequence after a serious hit, we wrote up the first 48 hours step by step.

What should you never promise? Three things

"We monitor the entire dark web"

Nobody does. Not us, not anyone with a bigger logo.

A monitoring service sees what has surfaced in places it collects from. A database sold privately to one buyer, or sitting on an attacker's drive, is invisible to every vendor until it moves.

So the claim fails on day one, quietly. It only gets noticed later, when a client's data turns up somewhere your scope never reached.

"We'll catch it before attackers use it"

You'll manage it some of the time, which is exactly why it's tempting to promise. The research says don't.

One study leaked the logins of 100 test webmail accounts on purpose and watched what happened. For the ones posted on paste sites, 80% of all unique accesses came within 25 days of the leak ("What Happens After You Are Pwnd" , ACM IMC 2016). It was a small study from 2016, so read it as a direction.

That clock starts the day the logins go public. Ours starts earlier, at the breach date, and the median breach we added last year took 73 days to get from there to our index.

Two different clocks, so we won't stack them. But they point the same way: stolen data gets used quickly once it's out, and much of it sits out of sight for weeks before that. No index sees it in that stretch (ours included).

There's a second problem with the line. An exposure alert tells you a credential is out there.

Has anyone logged in with it? The alert can't say, because monitoring watches leak sources and your client's sign-in logs are a different job.

So what do you say? Try "You'll know sooner than you would have, and you'll know exactly what to do." That one survives contact with an incident.

"This prevents breaches"

A client who hears "prevents" will read a quiet month as "we're safe". Monitoring lowers risk, and that's all it does until somebody acts.

Exposure and ransomware do keep company. The Verizon 2025 DBIR checked a sample of organisations named on ransomware extortion sites. For 54% of them, the company's domain showed up in at least one infostealer log or marketplace posting.

Verizon lists its own caveats, so treat that as a strong hint. And the Google study mentioned earlier (personal accounts, again) put breach-exposed ones at roughly 10 times the hijack odds of a random account.

A warning only pays off when somebody acts on it. Credentials changed, sessions ended, MFA switched on where it was missing.

The same goes for removal. Clients mix up taking down a phishing site with deleting a leaked record, and once data has been copied around, nobody can pull it back. Don't promise it, and say so the first time they ask.

What should the proposal actually say?

Swap the billboard lines for ones you can keep.

Have your own counsel read the final wording. Contracts vary by client and by country, and we're a data provider that can't give legal advice.

What do you tell a client in a quiet month?

No new findings doesn't mean no exposure. It means nothing new was indexed for their domains in that period. Put that second sentence in the report as written.

Then show the work. How many breaches the catalog held, how many were added that month (ours has averaged close to three a week over the past year), and where their standing exposure sits.

A quiet month is also when the renewal gets decided, so use it. Report the things you can measure per client: exposures found to date, days from indexing to your alert, days from your alert to the fix. Leave "breaches prevented" off the page, since nobody can count those.

What should you ask your data provider first?

Your promises can only be as good as the data behind them. Five questions, before you sign anything:

1. Where does the data come from, and do you ever buy it from the people who stole it?
2. Does every breach carry a breach date and a date you added it?
3. How do you mark an unverified source?
4. Will my analysts ever see client passwords in plain text?
5. Can I scope alerts and reports per client, under my brand?

We publish our answers on the Our Data page: public sources only, nothing bought, exposure facts and not raw records. For the longer version, there's 12 questions to ask any breach monitoring vendor.

And test it before you sell it. Run your own company's domain through the free check at xposedornot.com/domain and read the result the way a client would.

Where xonThreatIntel+ fits

Everything above is easier to keep when the tooling already works that way. That's what the MSSP mode of xonThreatIntel+ is built for.

Each client is a separate tenant with its own alerting rules and reports, which covers promises one and two. Every finding names the breach, when it happened and the exposed data types.

Your logo goes on the dashboards, the reports and the alert emails. As far as the client can tell it's your service (which it is).

The numbers are public, which helps when you're pricing a small promise. Partner plans start at $99 a month for up to 10 client domains, billed monthly with no lock-in. You set the client price.

The calculator on the same page gives a worked example. Ten clients billed $99 a month each comes to $11,880 a year, against $1,188 for the plan.

Your pre-sale checklist

Before the next proposal goes out:

• Domains in scope are listed by name.
• The out-of-scope list is written into the document. Yes, all of it.
• Your alert window starts at indexing and has a number on it.
• Every alert template shows breach name, breach date, data types and a confidence label.
• The contract names who resets, who ends sessions, and who records it.
• "Entire dark web", "before attackers", "prevents" and "removal" appear nowhere. Search the PDF.
• The quiet-month sentence is in your report template.
• You've run your own domain first.

Quick answers

Where the numbers came from

• Catalog figures (787 breaches, 11,633,142,187 records, 147 added in the 52 weeks to 5 October 2026, breach-to-indexing gaps, data types, unverified flags): the public XposedOrNot catalog at api.xposedornot.com/v1/breaches, fields breachedDate, addedDate, exposedData and verified, pulled 5 October 2026.
• One caution on those gaps. Some breach dates are only known to the month or the year, and we've counted older breaches that surfaced late as well, so the figures show when exposure becomes visible. They aren't a speed test.
• Page review: 28 pages ranking or cited for "mssp dark web monitoring" and close variants in US Google results, read on 5 October 2026. Counts are ours, and "real time" is a phrase count.
• MSSP demand: survey of more than 500 MSSPs in the US and UK, published February 2023, as reported by ITPro . It's a vendor survey, so treat it as a direction.
• Thomas et al., "Data Breaches, Phishing, or Malware? Understanding the Risks of Stolen Credentials" , ACM CCS 2017: roughly 10 times hijack odds for breach-exposed accounts, 168-day median for a hijacked account to be re-secured (personal accounts).
• Onaolapo, Mariconti and Stringhini, "What Happens After You Are Pwnd" , ACM IMC 2016: 80% of unique accesses to paste-site leaks within 25 days, 100 test accounts.
• Verizon 2025 Data Breach Investigations Report : in a sample of organisations named on ransomware extortion sites (those Verizon could tie to an email domain), 54% had domains in an infostealer log or marketplace posting.
• FTC, "The dark web: What your business needs to know" , October 2017: definition.
• Plans and features: xonThreatIntel+ for MSSPs, as published on 5 October 2026.