Why can ransomware risk remain high even when fewer organisations report being hit?

Reported volume can fall for reasons that have nothing to do with true risk reduction. Criminal groups may splinter, organisations may underreport, and activity may shift seasonally. At the same time, attackers may pursue larger payouts. That means leaders should evaluate ransomware using exposure, recovery readiness, and business impact, not headlines about a temporary decline.

Ransomware can be a volume illusion: fewer reports do not necessarily mean less attacker pressure. Organisations may underreport, threat groups may fragment into smaller cells, and campaigns often shift with seasonality or law-enforcement disruption. At the same time, criminals can chase larger targets and bigger payouts, so exposure and impact can stay high even when headline counts dip.

Why the reported number can fall without the threat falling

The number of victims who publicly report ransomware is only one signal, and it is often theisiest one. Reporting bias, delayed disclosure, and changes in attacker strategy can all make activity look quieter than it really is. A decline in visible cases can simply reflect concealment, not a reduced ability to compromise organisations or extort payment.

That distinction matters because ransomware is a business-risk problem as much as it is a malware problem. If one year brings fewer public disclosures but attackers are taking longer dwell time, selecting higher-value targets, or improving their extortion leverage, the operational risk may be unchanged or worse. Leaders should therefore separate observed volume from actual exposure.

What changes when crews split or targets get larger

When criminal groups splinter, the market effect can be fewer large, recognisable campaigns and more distributed activity across affiliates, brokers, and smaller crews. The total number of reported incidents may fall while the ecosystem becomes harder to track. That makes trend lines less useful unless they are paired with intelligence on intrusion paths, data theft, and extortion patterns.

Target selection also changes the meaning of the count. If attackers shift toward larger organisations, each event can create more downtime, more legal exposure, and a bigger recovery burden. A single successful intrusion may therefore carry more business impact than several smaller incidents, which is why “fewer reports” is not a reliable proxy for lower risk.

How leaders should judge ransomware risk instead

Decision-makers should evaluate ransomware through exposure, recovery readiness, and business impact. Exposure includes the attack paths most likely to be abused, the data and systems most attractive to extortion actors, and the third-party dependencies that widen blast radius. Recovery readiness includes backups, restoration testing, segmentation, and incident coordination. Business impact includes outage tolerance, regulatory pressure, and the cost of prolonged disruption.

That lens is more useful than a simple incident count because it tells you whether the organisation can withstand a compromise even during a quieter reporting period. A low-volume quarter can still be the period when recovery weaknesses are most dangerous, especially if attackers are choosing their victims more selectively.

Risk and Threat Considerations

Ransomware reporting often understates the real threat because visibility is distorted by underreporting, uneven disclosure, and attacker adaptation. The practical risk is that leaders may mistake a temporary decline in public cases for reduced exposure and delay recovery improvements until the next major event.

Failure mechanism: Criminals continue to compromise organisations while reporting becomes less complete, which breaks the link between observed case counts and actual attack pressure. Selective targeting, seasonal shifts, and fragmented crews can all preserve or increase harm while making the environment look calmer.

Impact: Organisations that rely on volume trends alone may underinvest in backup validation, restoration speed, segmentation, and response readiness, leaving them more exposed when the next high-impact ransomware event arrives.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Ransomware trend signals should be weighed through enterprise risk decisions, not incident headlines.
	RC.RP-01 — Recovery Plan Execution	The answer centers on recovery readiness when attack volume and impact may diverge.
	ID.RA-01 — Asset Vulnerabilities Identified and Recorded	Exposure and recovery readiness depend on knowing which assets and dependencies create ransomware risk.
Recommendation — Assess ransomware using risk appetite, exposure, and recovery tolerance instead of raw event counts. Test and validate recovery plans so ransomware impact stays bounded when incidents occur. Identify the assets and dependencies that would most amplify ransomware disruption.
CIS Controls v8	CIS-11 — Data Recovery	Recovery readiness is a primary control theme for ransomware risk despite changing incident counts.
	CIS-17 — Incident Response Management	Underreporting and delayed disclosure make response readiness more important than visible case volume.
Recommendation — Validate backups and restoration procedures against ransomware-driven loss scenarios. Prepare and rehearse ransomware response so incidents are contained quickly.
NIST SP 800-53 Rev 5	CP-4 — Contingency Plan Testing	Recovery ability is central to judging ransomware exposure when public reports dip.
	IR-4 — Incident Handling	Ransomware risk remains high because response effectiveness determines business impact.
Recommendation — Test contingency plans under realistic ransomware recovery conditions. Use incident handling procedures that support rapid containment and restoration.

Practitioner Guidance

What to verify: Treat ransomware reporting as a situational indicator, not a control signal. Verify whether your backup restore tests, isolation boundaries, and incident decision paths still hold under a full-environment recovery scenario, not just a tabletop exercise.

What to prioritise: Prioritise the systems whose outage would force payment pressure, especially identity, core transaction, and shared infrastructure components. If those dependencies are fragile, the organisation remains highly exposed even in a period of lower public incident counts.

Practitioner takeaway: The right question is not “are fewer organisations reporting ransomware?”, but “would we absorb the loss if we were next?” Exposure and recoverability matter more than headlines.