What a leak site is for
It is a media channel, not a file server. Its design follows from that.
The sequence is staged and timed. Name the organisation with a countdown, post a partial sample as proof of possession, then release the rest, increasingly by torrent. The Cl0p campaign against MOVEit is the best documented example: exploitation began on 27 May 2023 and names started appearing on 14 June, a deliberate gap of about two and a half weeks, with a fixed window for exploited organisations to make contact first. Maze issued what it called press releases aimed at journalists, and ALPHV once published a regulatory complaint it had filed against a victim for not disclosing fast enough.
Behind the public page sits a larger estate. The LockBit seizure revealed 28 affiliate servers across three countries, and in the KillSec case law enforcement secured at least 110 terabytes of data. Operators hold far more than they publish.
Because the site is built for reach, your regulatory and communications clock can be started by a journalist's call rather than the attacker's deadline.
Overcounting, and the mechanisms that cause it
Six mechanisms push counts upward. None pushes downward.
Re-listing of old attacks. The LockBit case gives the only quantification that exists: 68 percent of post takedown entries were re uploads of attacks predating the seizure, 10 percent were victims of other groups including ALPHV and RansomHub, and 7 percent were pulled shortly after posting.
Claims of attacks that never succeeded. From seized infrastructure the National Crime Agency identified 194 affiliates active up to February 2024, of whom roughly 114 had paid to participate and never received a ransom payment.
The same victim claimed twice. Affiliates migrate between brands, data gets resold, partnerships repost each other's material, groups leak each other's data during feuds, and some claims are opportunistic. Breachsense states that where multiple groups claim one company it counts the company once. Not every tracker says what it does.
Third party victims listed as direct victims. MOVEit again: one vulnerability in one file transfer product produced hundreds of listings, many of them organisations whose data sat with a processor rather than on infrastructure of their own. The unit of observation is an organisation named, not an intrusion, so growth can be driven by a single supply chain event. See exploited vulnerability prioritisation for why that class of product keeps producing them.
Brand proliferation. Group counts rose from 98 to 138 in one tracker's annual comparison, another counted 124 groups in 2025 of which 73 were new, and Europol recorded more than 120 active brands. Most published group counts are cumulative ever rather than currently active, and are quoted as though they measured activity.
Tracker disagreement, which is the cleanest evidence of all. For the same two months of 2026, Check Point reported 732 and 684 victims where Breachsense reported 677 and 680, a spread of roughly 5 to 8 percent on identical months. The merge study puts a number on the same problem from the other direction. Lea Müller and York Yannikos of Fraunhofer SIT and ATHENE, in "Analyzing Concentration, Temporal Routines and Targeting in Public Ransomware Leak Site Data", posted to arXiv as 2605.24559 on 23 May 2026 and still an unrefereed preprint in its first version, merged the two leading open trackers. They collected the data on 4 March 2026 and restricted the analysis to incidents from January 2018 to that date. After deduplication within each source, RansomLook held 25,761 leak posts from 257 groups and Ransomware.live held 25,656 leak posts from 298 groups: near identical post volumes against a 41 group difference in breadth, which is our reading of their counts rather than a comparison the authors draw. Merging the two produced 28,127 entries from 325 unique groups. Removing 498 non incident entries, such as announcements informing site visitors about new channels or collaborations, left 27,629 leak posts. Nationality was identified for 18,041 victims, 65.30 percent, and sector for 16,868 victims, 61.05 percent.
That paper is also useful for what it does not do. It acknowledges duplicate listings, recycled posts and outright false claims as threats to the validity of its data, and it quantifies none of the three. The hard numbers it does give are the 498 non incident entries out of 28,127 merged, about 1.8 percent, and 791 listings in which the victim's name had been anonymised. Nobody should read a general error rate out of either figure.
Undercounting, at the same time
The counts are also far too low, on a different population. Leak sites miss victims who stopped the exfiltration, who paid to prevent publication, who were never posted, or who reported through other channels. The Ransomware Task Force's incident map recorded 13 incidents in Singapore from leak site data against 132 cases reported by the national cyber security agency for the comparable period. The capture recapture work found no modelled dependence between police reports and leak pages, implying the two capture almost disjoint populations, and noted that leak page data skews toward larger companies.
These two errors do not cancel. The missing incidents are small and quiet, the spurious listings large and loud.
The documented incentive to claim data you do not have
A peer reviewed study in Computers and Security built a signalling model calibrated on 452 Dutch cases drawn from police reports and one incident response firm. Claiming exfiltration raised the payment rate from 28.9 percent to 37.5 percent, and raised the mean ransom from 467,000 euros to 2.96 million euros. In roughly half of cases the exfiltration status was unknown even to the victim. The authors conclude that criminals are likely to claim exfiltration whether or not it is true, and that false claims confer an advantage absent any real compromise.
Set that against the business model. Posts are the advertising layer of an extortion business and brand credibility is the currency, which makes re-listing rational when capacity falls. Payments, insurance claims and police reports are generated by parties with no interest in inflating a count. This dataset is generated by the only party that benefits from a larger number. Check Point says as much about its own data, warning that operators may post recycled or fictional reports and hedging its analysis with the phrase assuming these are genuine reports.
A number we will not repeat
You will have seen the claim that a ransomware attack occurs every eleven seconds. It traces to a commercial forecasting firm and was published as a prediction about a future year, not a measurement. No methodology, sample or data source was ever published and we could not locate one, which makes it uncheckable by construction. It was then restated in the present tense by news outlets, cited by vendors citing those outlets, and absorbed into roundup pages that brand themselves as verified.
Where this implicates us
Openly, because the criticism lands on our own category.
Threat intelligence providers, this one included, report leak site derived victim counts, and those counts inherit every defect above. We publish them because they are the only near real time signal on this activity. We should not pretend they measure attacks.
No tracker we examined publishes a quantified accuracy or false positive rate. ENISA is the most epistemically honest institutional source, stating that open sources and voluntarily shared information do not constitute a complete picture and that the authenticity or currency of breach claims could not be verified. It is also an aggregator of open sources by its own description, so its ransomware figures inherit leak site contamination too. Europol has the opposite profile, a genuinely different dataset drawn from member state operational intelligence, published almost entirely qualitatively. Europe has no authoritative ransomware incidence statistic.
Does paying prevent publication
The strongest evidence is from law enforcement and it is negative. After seizing LockBit's systems, the National Crime Agency found that some of the data held belonged to victims who had already paid, and said so explicitly as evidence that payment does not guarantee deletion. That is operator side evidence rather than self report from either party to a negotiation. It also establishes that a group's holdings and its publications are different populations.
The market has drawn the same conclusion. Coveware's second quarter 2026 data puts the payment rate for exfiltration only extortion at 15 percent, the lowest of any category, attributed to growing victim scepticism about post payment outcomes. In the same quarter the average ransom rose 176 percent to 1.88 million dollars while the median fell 50 percent to 150,000 dollars, a divergence driven by a handful of unusually large exfiltration cases. Use the median, and remember the population: these are outcomes among organisations that detected an incident and hired a negotiation firm.
The European clock, and what a listing does to it
Publication is evidence of a personal data breach rather than the trigger for notification.
GDPR Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. Unauthorised access is enough. Publication is not required.
Article 33(1) requires the controller, in the case of a personal data breach, to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The words fixing the start point are after having become aware of it. The clock runs from the controller's awareness, not from the breach occurring and not from a third party's discovery.
Article 34 is where the misunderstanding sits. It requires communication to the data subject, without undue delay, when the breach is likely to result in a high risk to their rights and freedoms. It contains no hour figure at all. The 72 hours appears only in Article 33(1), so any 72 hour deadline attached to telling data subjects is not traceable to the text.
The threshold asymmetry is deliberate. Article 33's carve out speaks of a risk. Article 34's trigger speaks of a high risk. A breach can therefore be notifiable to the supervisory authority and not communicable to data subjects, which is the normal case rather than an edge case.
Sequence it and the practical point falls out. Exfiltration is detected, awareness arrives, the Article 33 clock starts and the Article 34 assessment begins. A listing weeks later is corroborating evidence that may change the Article 34 assessment, because loss of confidentiality is now demonstrated rather than presumed, but it does not create or restart the Article 33 duty. A controller waiting for a listing before notifying is already out of time. One case inverts this: where a processor was breached and you were never touched, as happened downstream of a breached payroll provider in the MOVEit campaign, the listing genuinely can be the moment you become aware.
A separate reporting regime may also apply. Entities in scope of NIS2 face incident reporting obligations to a different authority on a different test, running in parallel with the data protection duties rather than replacing them. We are deliberately not stating deadlines or article references, because the directive text could not be retrieved during research and we will not supply legal text from memory.
What to do when a supplier is listed
Treat it as a scope question before a security question. Your data can sit in a dump where you are never named, so monitoring has to cover your processors and theirs, not only your own name. Name matching alone will also miss a material fraction of listings, because a substantial share of victims cannot be classified by name or sector at all. Resolving whose data is actually present requires inspecting samples, which is where the legal question becomes operational.
And hold the epistemics. A listing proves that a group asserts it holds data. It does not prove a breach of your systems, it does not prove the data is what the group says it is, and on the evidence above it does not reliably prove an attack happened at all. Credential material surfacing in stealer log monitoring, or access being sold by an initial access broker, are earlier and often more reliable signals, because they appear before the extortion stage rather than after it.