Learn how to build multi-client dark web monitoring workflows that scale with your MSSP.
• Missing assets during onboarding means missed alerts later. Gather every domain and email upfront, then run an initial scan before the first report
• Manual alert sorting breaks down past a handful of clients. Use per-client webhooks so the right analyst gets the right ticket automatically
• Clients don’t care about alert counts. Show what leaked and what you did about it. Then tell them what to do next
• When a shared vendor gets breached, you can query every client domain at once instead of checking them one at a time
Your clients’ credentials are leaking right now, and most of them don’t know it.
Running dark web monitoring for one company is straightforward. Running it across dozens of clients with different domains and alert preferences is a different problem entirely.
This playbook covers the operational workflows MSSPs need. Not why you should offer dark web monitoring. Instead, how to actually run it across your client base.
Each section below walks through a specific workflow, from onboarding a new client to handling a breach that hits five clients at once.
How Do You Onboard a New Client?
Getting a new client into your dark web monitoring workflow starts before you touch any tools.
You’ll see “stealer log” throughout this playbook. Here’s what it means.
Stealer log is a collection of credentials and session tokens stolen by infostealer malware running on someone’s device. The malware grabs saved passwords and cookies from browsers, then uploads everything to attacker-controlled servers. These logs show up for sale on criminal markets within hours of infection.
Step 1: Gather the full asset list
Don’t just ask for the client’s primary domain. You need every domain they own, including subsidiaries and acquisitions. Ask about any IP ranges they own and VPN endpoints.
Missing assets here means missed alerts later. A client who forgot to mention their subsidiary domain won’t thank you when that domain’s credentials show up in a stealer log.
Step 2: Configure monitoring
Set up the client’s domains as monitored assets in Breachsense. Configure a dedicated webhook endpoint for this client. Point it at whatever ticketing or SIEM system handles their alerts.
Step 3: Run the initial scan
Query the Breachsense APIs for all historical exposures across the client’s domains. This first scan usually surfaces years of accumulated credential leaks. Sort results by recency and breach source.
Step 4: Deliver the first exposure report
Your initial report sets the tone for the entire engagement. The Verizon 2025 DBIR found stolen credentials in 88% of basic web application breaches, so clients need to see this data. Show the client exactly what’s exposed: how many credentials leaked and which breach sources they came from. Flag any passwords that are still active. Flag any session tokens immediately. Those need same-day action.
This first report is also your best upsell moment. Clients rarely expect the volume of exposed credentials they actually have.
With onboarding done, you need a system to handle the ongoing flow of alerts across all your clients.
How Do You Route Alerts Across Multiple Clients?
Manual alert sorting doesn’t scale past a handful of clients. You need automated routing from day one.
Webhooks are central to that automation. If you haven’t used them before, here’s the short version.
Webhook is an automated HTTP callback that fires when a specific event happens. When Breachsense detects a new credential exposure, it sends a webhook to your endpoint with the alert details. Your ticketing system or SIEM receives the data instantly without polling for updates.
Webhook configuration per client
Breachsense lets you configure separate webhook endpoints for each monitored asset group. Point each client’s webhooks to a dedicated channel:
PSA integration. Route alerts directly into your ticketing system with client tags attached. Each alert creates a ticket under the right client automatically.
SIEM routing. If you run a shared SIEM, tag incoming webhook data with client identifiers. Your analysts can filter by client without switching between dashboards.
Slack or Teams channels. For smaller client counts, dedicated channels per client work well. Analysts watching a specific client see only that client’s alerts.
Priority-based routing
Not every alert needs the same response speed. Build routing rules that separate high-severity alerts from routine findings:
High severity. Session token detections and fresh stealer log matches. These go to your IR team immediately. Attackers with a valid token skip authentication entirely, so the response window is minutes, not hours.
Medium severity. New credential exposures from recent breaches. These need password resets within 24 hours.
Low severity. Historical credential matches from old breaches. Queue these for the next scheduled report.
Once alerts are flowing to the right places, your clients will want to see what you’re finding and what you’re doing about it.
What Should Client Reports Include?
Clients will ask for “breach reports” without specifying what they want. Define the format early and focus on outcomes, not raw alert volume.
Report structure that shows value
Executive summary. Two to three sentences on what happened this period. Lead with the most critical finding. Example: “We detected 14 employee credentials in a fresh stealer log and forced resets within 2 hours.”
Credential exposure breakdown. Show numbers by source type: third-party breaches and stealer logs. Include combo lists separately. Break down by domain if the client has multiple.
Remediation actions taken. List what your team did. Password resets triggered and sessions revoked. Include client notifications you sent. This is where you prove your value.
Recommendations. What the client should do on their end. Maybe enforce MFA on accounts that didn’t have it. Maybe investigate a device that showed up in a stealer log.
Reporting frequency
Monthly works for most clients. Clients in regulated industries or those with recent incidents may want weekly. Don’t over-report. A monthly report with real findings beats a weekly report padded with noise.
Generate reports using API queries filtered by date range and client domain. Pull credential counts and breach sources directly from your ticketing system.
Routine reporting handles steady-state operations. But when a big breach drops and hits multiple clients at once, you need a different workflow.
How Do You Handle a Breach That Hits Multiple Clients?
A SaaS vendor gets breached. That vendor serves six of your clients. Now you have six exposure assessments to run and six notification calls to make. Here’s how to handle it without chaos.
Step 1: Assess scope across your client base
Query every client domain against the breach data using the Breachsense API. Don’t check clients one at a time. Script a batch query across all your monitored domains and sort results by client.
Step 2: Prioritize by exposure severity
Rank clients by what was exposed. A client with 200 credentials and active session tokens gets attention before a client with 3 old email/password pairs. Focus on:
Session tokens first. Any client with exposed session tokens gets immediate notification. These are active attack vectors.
Fresh passwords second. Credentials from recent breaches are more likely still in use.
Historical matches last. Older breach data still needs resets, but the urgency is lower.
Step 3: Batch notification with client-specific detail
Send notifications to all affected clients quickly, but don’t send a generic blast. Each client needs to know their specific exposure: how many credentials were exposed and what you’re already doing about it.
Template your notification emails but fill in client-specific numbers and affected accounts. Generic “you may be affected” messages undermine trust.
Step 4: Track remediation per client
Create a tracking sheet or ticket per client. Log which credentials were reset and which sessions were revoked. Track which clients still have outstanding actions. You’ll need this for the next report cycle.
Cross-client breaches are also where third-party risk monitoring proves its value. If you’re monitoring vendor domains alongside client domains, you’ll catch the breach before your clients even know their vendor was hit.
Handling one-off incidents is necessary. But automating the repetitive parts of your workflow saves hours every week.
How Do You Automate MSSP Workflows?
The Breachsense REST API returns JSON, which makes it straightforward to build automation around it.
Automated ticket creation
When a webhook fires, have your integration layer create a ticket in your PSA tool. Include the client name and affected email addresses. Tag the breach source and severity level. Your analyst picks up a pre-populated ticket instead of reading raw webhook data.
Credential reset triggers
For clients where you manage their identity provider, you can chain webhook alerts to automated password resets. When Breachsense detects a compromised credential, your automation forces a reset and logs the action. The analyst reviews and confirms rather than doing the reset manually.
Important. Breachsense identifies the exposed credentials and delivers alerts through webhooks. Your identity management tools handle the actual reset. Breachsense doesn’t directly access client Active Directory or identity providers.
Scheduled exposure scans
Set up daily or weekly API queries that scan all client domains for new exposures. Compare results against your last scan to find anything new. This catches anything that might slip through real-time alerting.
Client notification templates
Build notification templates that auto-populate with breach details from the API response. Include the number of affected accounts and the breach source. Add recommended actions for the client. Personalized notifications take seconds instead of minutes per client.
With the operational workflows running, the question becomes how to grow dark web monitoring into a scalable service line.
How Do You Scale Dark Web Monitoring as a Service?
Adding dark web monitoring to your MSSP stack takes API work and webhook setup. But it also generates recurring revenue.
Packaging the service
Bundle dark web monitoring with your existing managed detection services. Most MSSPs charge a monthly per-client fee based on the number of monitored domains. Tiered pricing works well: basic monitoring with monthly reports at one price, real-time alerting with incident response at a higher tier.
The initial scan as a sales tool
Run an initial scan during prospect meetings. The Breachsense API returns historical credential exposures in seconds. Showing a prospect their exposed passwords on screen closes deals faster than any slide deck. The dark web scan tool can also give prospects a quick preview of their exposure.
Refining before you scale
Start with a small client base and refine your workflows before scaling. Get your alert routing and reporting templates locked in with 5-10 clients. Then scale to 50+ without hiring proportionally more analysts.
The enterprise response playbook covers alert-specific response steps in detail. Use it as a foundation and adapt the workflows for multi-client operations.
NIST’s Cybersecurity Framework provides a good structure for mapping your monitoring service to industry-standard controls. Clients in regulated industries will ask how your service aligns with frameworks like this.
What makes an MSSP’s monitoring program stick
The MSSPs that retain clients aren’t the ones with the most data. They’re the ones who show what they did with it. Every report, every alert, every notification should prove you caught something the client would have missed on their own.
If you’re already running dark web monitoring for your MSP clients and want to formalize the practice, start with the onboarding workflow above. Get that right and the rest falls into place.
MSSP Dark Web Monitoring Playbook FAQ
Most MSSPs complete onboarding in under a day. The bulk of the time goes into gathering the client’s full domain list, including subsidiaries and acquisitions. Once domains are configured in Breachsense, the initial scan runs in minutes and you can deliver the first exposure report the same day.
Yes. Breachsense supports per-client webhook configurations. You can point each client’s alerts to a different Slack channel or ticketing queue. This keeps alert routing automatic so analysts don’t waste time manually sorting which client an alert belongs to.
Focus on what leaked and the actions you took. Include credential counts by source and any session token alerts. Add compromised credential resets you triggered. Skip vanity metrics like total alerts. Clients care about outcomes, not raw numbers.
Query every client domain against the breach source using the Breachsense API. Prioritize clients with the most exposed credentials and any session token matches. Batch your notifications but customize each one with client-specific exposure details.
Breachsense’s API lets you query any domain, so you can build multi-tenant workflows on top of it. Configure separate monitored domains and webhook endpoints per client. Many MSSPs integrate Breachsense into their existing PSA or SIEM platforms for centralized management.
Session tokens bypass MFA entirely, so they’re more urgent than password alerts. When Breachsense detects a stolen session token from a stealer log, your team needs to notify the client and revoke that session within minutes. Don’t batch these with regular credential alerts. Treat them as high-severity incidents.