Double extortion ransomware: what backup cannot fix

Double extortion ransomware is an attack that steals your data before it encrypts it, so the attacker holds two separate levers: you cannot work until you decrypt, and you will be exposed unless you pay. The distinction matters commercially, not just technically, because backup answers the first lever completely and the second one not at all. An organisation that restores cleanly from backup has defeated half of a double extortion attack and is still facing a data breach, with every notification obligation that implies. Understanding which half you have actually covered is the difference between a bad week and a regulatory problem.

Why double extortion ransomware became the default

Encryption-only ransomware had an obvious countermeasure, and defenders found it: restore and refuse to pay. Attackers responded by taking a copy on the way in. Exfiltration gives them something that works whether or not your recovery is any good.

The shift is now visible in the technique data rather than just in anecdote. ENISA's Threat Landscape 2026 maps the techniques of the most active ransomware operators in the EU and reports that exfiltration over command-and-control channels (T1041) accounted for 73.3% of observations, while data encryption for impact (T1486) was reported in 13.7%. ENISA's own reading of the distribution is explicit:

This distribution is likely to confirm a broader operational shift in ransomware activity from encryption-based activity towards data exfiltration and extortion-focused operations.

The same report attributes T1041 to all five of the operators it identifies as most active in the EU — Akira, Hunters International, INC Ransom, Qilin and Safepay. Exfiltration is not a premium tier of attack. It is the baseline.

Some campaigns have dropped the encryption half entirely. ENISA records the Clop group's exploitation of a zero-day in Oracle E-Business Suite as "pure extortion", with "large-scale theft of sensitive data from multiple organisations; followed by extortion demands sent to executives to prevent public data release" — no encryption step at all. It also notes an observed trend toward "extortion-only operations" at Hunters International. If your entire ransomware plan is "we restore from backup", a pure-extortion incident does not engage your plan at any point.

The half that backup genuinely solves

This is worth stating plainly, because the rest of this article is about limits and it would be easy to over-correct: a good backup defeats the encryption lever outright. Not partially. If you can restore the affected workloads to a point before the encryption, the attacker's leverage over your availability is gone, and with it the clock that pressures most organisations into paying.

That is a large thing to own, and it is why attackers go after it first. In the same ENISA technique mapping, T1490, "Inhibit System Recovery", is attributed to four of the five most active EU operators — Akira, Hunters International, Qilin and Safepay. Deleting shadow copies, clearing recovery points and disabling backup jobs is a standard step in the playbook, performed before the encryption that everyone notices.

This is the practical argument for the two properties we have written about elsewhere: a copy that cannot be altered or deleted on the attacker's schedule, covered in immutable backup and what the word actually promises, and a copy outside the reach of the compromised control plane, covered in what an air-gapped backup actually cuts. Against T1490 specifically, those are not refinements. They are the difference between having a backup and having had one.

The half that no backup solves

No backup product in existence can un-copy a file. Once data has left your tenant, recovery is irrelevant to it: you can restore the original a thousand times and the attacker's copy is unaffected. This is not a weakness of any particular vendor or architecture, including ours. It is arithmetic.

What makes it a compliance problem rather than merely an unpleasant one is how European law defines the event. GDPR Article 4(12) defines a personal data breach as:

a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed

Note that the definition is a list, and exfiltration satisfies it twice over — "unauthorised disclosure of" and "access to" — entirely independently of the encryption. Restoring from backup repairs the destruction and loss. It does nothing to the disclosure, because the disclosure already happened.

The consequence is Article 33(1):

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.

So "we were hit, but we restored from backup and lost nothing" is an operational success and not a legal defence. The 72-hour clock starts on awareness, not on resolution, and a fast, clean restore does not stop it. If the breach is likely to result in a high risk, Article 34 adds a duty to tell the affected individuals as well. Organisations in scope for NIS2 have a separate incident-reporting track running in parallel on its own timetable — our note on what NIS2 actually requires for SaaS backup covers that side.

One point is routinely garbled in incident meetings and worth getting right. Article 34(3)(a) does provide relief from notifying data subjects where the controller has applied measures "that render the personal data unintelligible to any person who is not authorised to access it, such as encryption". That is your encryption, applied beforehand, making the stolen copy useless to the thief. The attacker's encryption of your live data is the opposite situation and gives you nothing. Encryption at rest that you control is one of the few things that genuinely blunts the exfiltration lever after the fact.

Why SaaS exfiltration is quiet

In a double extortion incident against Microsoft 365, Google Workspace, Slack or Atlassian Cloud, the theft rarely looks like an intrusion. ENISA attributes T1078, "Valid Accounts", as an initial-access technique to Akira, INC Ransom and Qilin. With valid credentials, bulk reading of a mailbox, a Drive, a Slack workspace or a Confluence space is indistinguishable from an employee doing their job, because it is the same API calls. There is no malware to detect and no encryption event to alert on — which is exactly why the pure-extortion variants can run for a long time before anyone notices.

It is also worth being honest about where the most damaging material tends to sit. It is usually not the file server. It is the Slack DMs and private channels where incident response and HR matters get discussed, the Confluence spaces holding runbooks and occasionally credentials, the shared mailboxes carrying contracts and payroll. Retention settings decide how much of that is available to steal — which is why Slack message and file retention is a security control and not just a housekeeping setting.

What actually reduces the second lever

Nothing here prevents a double extortion attack, and you should be sceptical of anything sold on that claim. These measures reduce how much an attacker can take and how long they can take it unobserved:

1. Hold less. Data that aged out cannot be exfiltrated. Retention policies tuned to what you actually need are the only control that reduces the stolen volume to zero for the oldest material.
2. Shrink what one identity can read. Exfiltration scales with the reach of the account used. Broad standing access across every workspace and site is the single biggest multiplier on the size of a leak.
3. Encrypt what you can, with keys you hold. This is the Article 34(3)(a) path, and it is the only measure on this list that reduces the harm after the data is gone.
4. Detect the anomaly, not the malware. Mass download, unusual export volumes, an OAuth application suddenly reading everything — in SaaS these are the signal, because the traffic itself is legitimate.
5. Protect the recovery path first, on the assumption that it will be attacked before the data is, which the T1490 data supports.
6. Decide the notification question before you need it. Who declares a breach, who starts the 72-hour clock, and on what evidence. That decision made under pressure, on day one, is where most of the avoidable damage occurs.

Backup remains necessary throughout. It removes the availability lever, it removes the time pressure that produces bad decisions, and it converts "pay to operate again" into "pay to suppress a leak" — a much weaker demand, treated differently by insurers and law enforcement, and one where paying buys only a promise.

If you want to know which of your SaaS workloads would survive the encryption half cleanly, and how much would be exposed in the exfiltration half, that is what our free SaaS backup assessment establishes: we map your existing recovery paths and retention exposure per workload, and help you choose and deploy a solution that closes the gaps worth closing.