Slowing ransomware means reducing attacker speed, payment success, or operational momentum through pressure such as sanctions, enforcement, and financial disruption. Eliminating ransomware would mean removing the capability and incentive entirely, which is far harder. In practice, sanctions can suppress attacks by making monetisation difficult, but resilient criminal groups can still operate, regroup, and continue targeting victims.
How slowing ransomware differs from eliminating it
Slowing ransomware is a pressure strategy: raise the cost, reduce the payout rate, and make campaigns less efficient so fewer operators can profit at scale. Eliminating ransomware would mean removing the criminal capability and the incentive to run it at all. That is a much higher bar, because resilient groups can adapt, rebrand, and keep attacking even after disruption.
The practical difference is between reducing throughput and removing the business model. Sanctions, law enforcement, and financial disruption can all slow monetisation, but they rarely erase the ecosystem that supports intrusion, extortion, and payment collection.
Why disruption can work without ending the threat
Ransomware operators depend on speed, volume, and conversion. If defenders increase friction around cash-out, infrastructure reuse, or partner services, attacks may become less frequent or less lucrative. That can change attacker behaviour even when the underlying malware, access brokers, and extortion playbooks still exist.
Elimination would require a far deeper collapse, such as persistent arrests, strong victim resilience, reduced payment success, and sustained pressure on the infrastructure and financial channels that make extortion profitable. In a live criminal market, that is difficult to achieve and even harder to hold over time.
For context on the broader threat environment, CISA cyber threat advisories and the ENISA Threat Landscape both show ransomware as a continuing operational threat rather than a one-time campaign.
What practitioners should conclude from the distinction
Teams should treat slowing ransomware as a real, measurable win, but not as a signal that the problem has been solved. The right question is whether disruption is reducing attacker return on effort, not whether it has permanently removed the threat class.
What to verify: look for evidence that disruption is affecting attacker economics, such as lower payment success, faster takedowns of infrastructure, or reduced reuse of the same tooling and channels. If those signals are absent, assume the adversary can absorb the pressure and continue.
Decision rule: if the control only makes ransomware slower or more expensive, keep investing in resilience, recovery, detection, and containment as if future attempts will still occur. Do not trade operational readiness for the assumption that external pressure will eventually eliminate the threat.
Practitioner takeaway: Slowing ransomware is a legitimate defensive objective, but elimination is not a realistic planning assumption, so resilience must remain built for repeat attacks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1486 — Data Encrypted for Impact | Ransomware extortion is central to the comparison of attack disruption versus eradication. |
| Recommendation — Map observed ransomware behaviours to ATT&CK and tune detections around encryption, extortion, and recovery stages. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | Slowing ransomware depends on response speed, containment, and recovery coordination. |
| Recommendation — Practice ransomware response playbooks and test containment, restoration, and communications under time pressure. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan is Executed | The distinction matters because disruption does not remove the need to recover from repeat incidents. |
| Recommendation — Validate that recovery plans restore critical services even when attackers remain active. | ||
