Mid-market ransomware exposure is shaped by revenue bands and visibility gaps

At a glance

What this is: This is a methodology report explaining how Black Kite defines and measures mid-market ransomware exposure across incident data and externally visible risk findings.

Why it matters: It matters because practitioners need to understand the denominator, scope and blind spots before using ransomware exposure data to prioritise IAM, NHI and resilience controls.

By the numbers:

• The exposure snapshot was taken in June 2026 and is explicitly point in time.

Context

This report is not a threat brief in the usual sense. It is a methodology note that explains how ransomware incidents and observable exposure data were filtered, counted and bounded before any trend claims were made.

For practitioners, that matters because the validity of any ransomware benchmark depends on the denominator, the revenue bands and the disclosure rules behind it. In other words, the measurement model shapes the security conclusion as much as the incident data itself.

Key questions

Q: How should security teams interpret ransomware benchmarks that use different counting rules?

A: They should treat the methodology as part of the result. If a benchmark uses revenue bands, disclosure dates or publication filters, those choices affect the denominator and can shift the apparent risk profile. Compare like with like, and do not use a single headline figure to justify programme decisions without checking what was counted and what was excluded.

Q: Why do incident counts often understate ransomware exposure?

A: Because incident counts usually capture only publicly disclosed events, not every attack, and they often exclude cases without sufficient data to classify them. That means the visible set is shaped by disclosure behaviour, legal decisions and reporting thresholds. The practical result is that incident data can show pressure patterns, but it cannot prove full attacker volume.

Q: What is the difference between an incident dataset and an exposure snapshot?

A: An incident dataset records events that have already been disclosed, while an exposure snapshot describes the state of systems or organisations at a specific point in time. The first is retrospective and incomplete by nature, the second is current but not causal. Teams need both, but they answer different governance questions.

Q: How can security teams use external risk data without overstating certainty?

A: Use it to identify where to validate controls, not as proof that a specific control failure caused a breach. External risk data is strongest when it highlights blind spots, uncatalogued assets or recurring exposure patterns. It becomes weaker when it is used as if it were a complete inventory of compromise.

Technical breakdown

How revenue banding changes ransomware analysis

The report uses annual revenue, not employee count, to place companies into lower mid-market, core mid-market and upper mid-market bands. That choice affects every downstream comparison because a firm can be in scope for one analysis and excluded from another depending on whether revenue can be assigned. In practice, this is a classification model, not just a segmentation preference. It also means sector and subindustry results are only meaningful when the underlying revenue denominator is clear.

Practical implication: Validate whether your own reporting segments companies by revenue, employee count or both before comparing ransomware exposure figures.

Why disclosed incident counts are not the same as attack volume

The incident set includes only publicly disclosed ransomware and data extortion events, and each distinct disclosure is counted separately. If the same company is claimed twice on different dates, it appears twice. That is useful for studying disclosure behaviour and attacker pressure, but it is not the same as counting unique victim organisations. The report also excludes incidents that were not ready for publication, which further narrows the observable set.

Practical implication: Treat published ransomware counts as disclosure-led evidence, not a complete map of attacker activity.

What externally observable exposure can and cannot prove

Black Kite’s exposure dataset is a snapshot of 120,128 monitored mid-market companies taken in June 2026. Because it is point in time, it can show the state of visible risk but not causality or trend by itself. That distinction is important for identity governance too, because exposed services, misconfigurations and credential paths often sit outside formal control evidence until an incident forces them into view. See the Incident Response Plan Template.

Practical implication: Use exposure snapshots to prioritise control review, but avoid treating them as trend data without repeated measurement.

NHI Mgmt Group analysis

Measurement design is the real security decision in this report. Black Kite’s framework shows that ransomware analysis is only as credible as the counting rules behind it. Once disclosure timing, revenue bands and publication thresholds are fixed, the report becomes a governance instrument rather than a raw threat tally. Practitioners should evaluate ransomware benchmarks the same way they evaluate control evidence: by asking what was excluded before the headline number was produced.

Mid-market exposure reporting creates a visibility gap that identity teams should not ignore. The article separates publicly disclosed incidents from externally observable risk findings, which is the right distinction, but it also shows how much security posture remains outside formal incident records. That is where account inventory, privileged access review and non-human identity visibility become relevant, because exposed services and unmanaged credentials often never appear in incident-only reporting. incident response plan template is useful here because measurement gaps become response gaps when a breach occurs.

Revenue-based segmentation will keep mattering because it changes who gets compared to whom. A company with the same operating profile can move between bands depending on revenue, and that changes the way exposure and ransomware figures are interpreted. For security leaders, the lesson is not about market size alone. It is about whether governance models, risk appetite and reporting thresholds are aligned to the segment actually being measured.

The most useful insight here is not the incident volume but the auditability of the method. The report is explicit about what it counts, what it excludes and where it cannot infer trends. That discipline is what makes external threat data usable in programme planning. Security teams should demand the same transparency from any benchmark that will influence investment, staffing or control prioritisation.

What this signals

Exposure snapshots are only useful when the programme knows what they exclude. This report’s strongest lesson is that point-in-time visibility is not a substitute for continuous inventory and classification. When a security team cannot reconcile external exposure findings with internal asset and identity records, ransomware analysis becomes a measurement exercise rather than a control-improvement exercise.

Ransomware reporting is becoming a governance problem, not just a threat-intelligence problem. The method used to count incidents now matters as much as the incidents themselves because it determines how leaders allocate budget, compare peers and justify remediation priorities. That pushes identity, asset and response owners to align on one reporting model instead of competing interpretations of risk.

For practitioners

• Set a reporting denominator before using ransomware benchmarks Document whether your programme measures by revenue band, employee count, geography or business unit so external data can be compared without distortion.
• Separate disclosure counts from unique victim counts When reviewing ransomware intelligence, distinguish between repeated public claims against the same organisation and truly distinct victim organisations.
• Treat point-in-time exposure snapshots as control review inputs Use externally visible risk findings to trigger configuration, account and service reviews, but do not infer trend without repeated measurements over time.
• Align incident classification with response thresholds Make sure the way a ransomware event is categorised in reporting matches the severity tiers and escalation paths in your incident response process.
• Cross-check exposure findings against identity inventory Reconcile externally visible services and access paths with authoritative account and service inventories to find blind spots before they become incident evidence.

Key takeaways

• The report is fundamentally about how ransomware exposure is measured, not about any single attack trend.
• Disclosure filters, revenue bands and point-in-time snapshots shape the conclusions as much as the raw incident data.
• Practitioners should compare benchmarks only after validating the denominator, the exclusions and the classification logic.

Related NHI Mgmt Group resources: Incident Response Plan Template · Breach and Attack Simulation (BAS) Guide · Security Exceptions and Risk Acceptance Guide

Key terms

• Disclosure-Led Incident Dataset: A disclosure-led incident dataset includes only events that have been made public and meet the publisher’s retention criteria. It is useful for comparing published ransomware pressure, but it does not represent every attack that occurred or every organisation that was affected.
• Point-in-Time Exposure Assessment: A point-in-time exposure assessment is a snapshot review of current security risk at a specific moment. It measures what identities, systems, permissions, vulnerabilities, and misconfigurations are exposed right now, rather than over time. In identity security, it helps identify standing access, excessive privileges, and active attack paths before they are exploited.
• Revenue-Based Market Segmentation: Revenue-based market segmentation groups organisations by annual turnover rather than by employee count or industry label. In security analysis, it changes which victims are counted together and can materially alter how ransomware and exposure figures are interpreted.
• Victim Counting Methodology: Victim counting methodology defines how a report treats repeated claims, duplicate disclosures and grouped entities such as chains or holding companies. It is a governance choice because it determines whether the resulting figure reflects unique organisations, public claims or another unit of analysis.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.