Dark web monitoring for a 12-person startup

By the Crowmark team · Reading time ~6 min · Published 23 August 2026

The phrase “dark web monitoring” does a lot of work in a vendor pitch deck and very little of that work is honest. Most of what gets sold under the label is not monitoring the dark web in the way a researcher means it when she says the words. It is monitoring paste sites, infostealer log shops, breach forums, and Telegram channels where leaked credentials move at the speed of commerce. For a twelve-person startup that already has a way to read a SIEM queue, the right question is not whether the dark web is being watched. The right question is which of those surfaces produces a signal a lean team can actually act on, and which is a checkbox in a procurement memo.

Below is the calm version of that question, told from the data a starter contract actually produces when it’s wired into a small org. The vendors named are the kind of work a modern commercial monitor does — Constella, SpyCloud, Flare, and the breach catalogs the big identity providers bundle in by default. None of what follows requires a vendor you don’t already have a relationship with.

What the surface actually is

The research community uses “dark web” loosely. The part that touches a twelve-person startup is the part an automated crawler can see and a curated vendor can resell: breach corpus dumps, infostealer log marketplaces, paste sites that publish single leaks in plain text, and a small but active set of Telegram channels that resell credentials the moment they’re validated. Onion forums where negotiation happens in escrow exist, but the amount of value they produce for a small org is small and the amount of money the vendor charges to “cover” them is large. Most monitors will tell you they cover them. Few of them can show you an action that came out of one.

The honest summary is that a twelve-person company is unlikely to appear as a target in a researcher’s intelligence feed. They are very likely to appear as a row in a commodity breach corpus — a reused password, an email on a paste, an OAuth token in an infostealer log archive — and that is the surface a starter monitor earns its pay on. Everything else is the vendor’s marketing collateral.

What catches: the four things that actually fired

Over the first six months of a single starter install, the things that caught were not the dramatic ones. They were the ones that mapped cleanly to a one-line action.

First, a contractor’s reused password in a five-year-old corpus breach, sitting next to the corporate SSO password. The monitor caught the corpus hit at the same moment the contractor logged in from a new device. The brief carried one item: rotate the password and add an authenticator app. The contractor found out about it at her next login. No pager. No Slack thread. No forensic write-up.

Second, three employees in a fresh infostealer log dump from a contractor’s personal laptop. The monitor caught the dump the morning after upload, the connector scored the three matches against the running SSO directory, and the brief carried three rows labeled “rotate SSO credential — infostealer compromise, contractor device.” The remediation list totaled nine minutes. The cost of not catching them would have been a full incident.

Third, an OAuth refresh token published to a paste site by a careless integration partner. The monitor caught the paste within an hour. The action was a re-issue of the token, a review of the partner’s retention policy, and a note added to the procurement questionnaire. The cost of not catching it would have been only counted in retrospect.

Fourth, two customer emails in a paste that turned out to be from a sibling product the team had sunset a year earlier. The action was a courtesy notice, a credential reset, and a small addition to the offboarding checklist. None of those items required an analyst. All of them required a monitor that scored the daily corpus against an authoritative list.

What doesn’t catch: the three things the pitch always promises

The pitch always promises the dramatic ones. A targeted campaign against the founders. A ransomware affiliate naming the company. A marketplace listing the corporate domain at a fixed price. Over six months none of those fired. The vendor’s quarterly review materials continued to imply that they could have fired, that the monitor “covers those surfaces,” that the absence of incidents was an absence of signal rather than an absence of targeting. Read that sentence carefully the next time you sit in a renewal meeting.

The right mental model is not “we are monitoring the dark web.” The right mental model is “we score the daily credential and infostealer surface against the SSO directory, and the brief carries the items that need a one-line action.” If the monitor’s quarterly summary cannot show you a per-row attribution between “this caught” and “action taken,” you are paying for a checkbox, not a sensor.

How to read a vendor pitch

Three sentences that turn out to matter more than the slide deck. First: ask for the per-month count of corpus hits that the monitor scored against your SSO directory over the trial period. If the number is in the single digits and large fractions of those are infostealer log hits tied to a specific contractor, the monitor’s value is real but narrow. Second: ask what proportion of those hits auto-contained without a human. If the answer is non-zero, the monitor is integrated; if the answer is zero, you are buying a feed and a UI. Third: ask for the count of the catch that required an active dark-web forum crawl rather than a passive corpus digest. If the number is zero, you are paying for the corpus, not the forum.

The right price for the corpus-only version of that work at twelve engineers is closer to a small retainer than to an enterprise license. The right price for the forum-and-onion version is closer to the difference between hiring a junior analyst and not hiring one. Most starter orgs need the former, not the latter, and the calendar above tells the same story the procurement documents already do: the breach corpus and identity providers do the load-bearing work, and the dark-web monitor is the curated layer on top of them.

Where this fits in the rest of the system

Dark web monitoring is one of five watch surfaces a lean team runs together — endpoints, identity, cloud, dark web, and CVE. None of them is the watch; all of them feed the same brief. The dark-web surface is the one that fires least often and maps most cleanly to a one-line action, and it’s the one the morning brief’s “rotate, revoke, re-issue” rows actually come from. Read the integrations page for the supported source families and tier boundaries, then read the notes on the first thirty days for the calendar of how that picture looks when it ships at a customer, the explainer for the underlying primitives — watch, auto-contain, triage, brief — and a sample morning brief → for the deliverable those rows actually ship in. Against the alternative — an in-house function on the same surface — the cost-vs-build side-by-side is the cleanest read.