Local Threat Intelligence: How to Assess Cyber Risks Specific to Your City or Region
October 11, 2026 - News
Ransomware reports arrive every quarter with confident graphics and round numbers. Most are worth reading. A few are marketing with a methodology section bolted on. The difference rarely shows up on the cover page. It shows up in the footnotes: how the sample was built, what counted as an incident, and how much uncertainty the authors were willing to admit. Before a vendor's figures land in your board deck or your budget request, run them through the twelve questions below.
Ask for the source mix before you look at a single chart. Vendor telemetry from endpoint agents or incident response engagements is strong evidence, but it is a biased sample: it only contains organisations that bought the product or called the team. Leak-site scrapes capture victims whose data was published, which skews toward non-payers. Payment figures tend to come from a narrow set of cases. Each source has a place. Treating one as the whole picture does not.
What share of the data is first-party, and what share is scraped or resold? A report that blends five sources without saying how much weight each carries is impossible to audit. Look for a line like "most incidents in this report come from our own IR caseload." That tells you what you are actually reading.
Do you get denominators, or only percentages? "Ransomware detections rose 43%" means nothing without a base. Forty-three percent of what: 14 incidents or 14,000? A jump can be a real surge or a new customer, a product update, or a change in how alerts get labelled.
How was the sample selected, and who is missing from it? A dataset drawn from mid-market customers says little about hospitals, manufacturers, or government agencies. Note the population before you generalise from it.
Two vendors can examine the same month and publish wildly different numbers, because they are counting different things. Pin down the mechanics.
What is the collection window, and when was the data last refreshed? Quarterly reports often recycle earlier data, and a chart from last spring may still be presented as current. Check the date on the underlying dataset, not the publication date on the PDF.
Is an "incident" a victim organisation, a leak-site post, a malware sample, or a payment? Leak sites get re-posted, mirrored, and re-listed after takedowns. Counting posts instead of victims inflates totals, sometimes substantially, without anyone lying outright.
How does the report define ransomware? Encryption only? Encryption plus data theft? Pure extortion with no encryption at all? Vendors that fold data-theft-only cases into the ransomware bucket will always show higher numbers than those that keep them separate. Neither approach is dishonest, but the two figures cannot be compared directly.
Attribution is the part of a report most likely to be quoted out of context, and the part most often over-simplified. Three levels get mixed together constantly: the criminal brand, the malware or tooling, and the affiliate who carried out a specific intrusion. A report saying "LockBit was behind this" may mean nothing more than that a leaked builder was used.
Does the report separate actor, family, and affiliate? If it does not, treat the attribution as a label rather than a finding.
Is confidence stated explicitly, on a consistent scale? "We assess with moderate confidence, based on infrastructure overlap and shared code" is a usable statement. "Linked to" with no supporting detail is not.
Are alternative explanations considered? Ransomware tooling gets leaked, sold, and copied. A report that never weighs a copycat or a shared affiliate tells you more about the authors' certainty than about the evidence.
Ask who benefits from the conclusion. If a report finds that attacks are rising sharply and that the answer is a particular category of product, note that the vendor sells that product. This does not make the finding false. It makes it worth checking.
Is there a disclosure? Sponsors, co-authors, and named customers should be visible near the methodology, not buried in an appendix. It is also worth noting whether the vendor's own products appear among the recommendations.
Can the key claims be checked elsewhere? National CERT advisories, law enforcement bulletins, other vendors' telemetry, and victim statements are the usual cross-checks. Three independent sources pointing the same way make a claim solid. One source alone means you cite it as one vendor's observation.
You do not need to interrogate every report. You need a filter that takes five minutes.
One habit saves trouble later: record the definition next to the number. "Ransomware incidents, counted by victim organisation, first-party IR caseload, Q1" is a citable fact. "Ransomware up 40%" is a headline looking for a headline. When a vendor cannot answer even half of the twelve questions, that is still useful information. You can read the report and cite it clearly as a single vendor's view rather than the state of the threat. And if the figure is going into a disclosure, a contract, or a regulatory filing, have your own advisers review it before you rely on it.
Photo: RDNE Stock project / Pexels
Copyright © 2026 Threat Intel Desk. All Right Reserved.