Actionable threat intelligence for security teams

Threat Reports

Ransomware Threat Report Checklist: 12 Questions to Ask Before Trusting a Vendor's Claims

Ransomware Threat Report Checklist: 12 Questions to Ask Before Trusting a Vendor's Claims

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.

Start With the Data Sources

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.

Counting Rules, Timelines, and Definitions

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 and Confidence Language

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.

Incentives, Sponsorship, and Verification

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.

The Twelve Questions, Condensed

  1. What is the source mix, and in what proportions?
  2. Are raw counts and denominators published?
  3. How was the sample selected, and who is excluded?
  4. What is the collection window and refresh date?
  5. What unit is counted: victims, posts, samples, or payments?
  6. How is ransomware defined for this report?
  7. Is the attribution to a brand, a tool, or an affiliate?
  8. Is confidence stated on a consistent scale with evidence behind it?
  9. Are competing explanations considered and dismissed?
  10. What does the vendor sell that this conclusion supports?
  11. Are sponsorship and conflicts disclosed up front?
  12. Have independent sources corroborated the headline findings?

Using This Without Slowing Down

You do not need to interrogate every report. You need a filter that takes five minutes.

  • Ask methodology questions of the analyst who wrote the report, not the account manager who sent it.
  • Request the appendix or the underlying counts. A vendor that shares them is usually worth more trust.
  • Keep a source log with the date, publisher, definition used, and the one number you actually relied on.
  • When two vendors disagree, cite the range rather than picking the scarier figure.
  • Before a number goes into a board deck or a filing, confirm it against at least one non-vendor source.

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

Related Posts

Local Threat Intelligence: How to Assess Cyber Risks Specific to Your City or Region

News

Local Threat Intelligence: How to Assess Cyber Risks Specific to Your City or Region

Build a regional risk picture by collecting local incident reports, mapping your area's industry mix, and tracking...

How to Write an IOC Report That Analysts Actually Use

Indicators

How to Write an IOC Report That Analysts Actually Use

Indicator reports fail when they list data without context. Here is how to structure, score, and distribute IOC...