For a decade the standard advice on ransomware was a single sentence: have backups you have tested, and you never have to pay. That advice is now obsolete, and the organisations still relying on it will discover why at the worst possible moment. Since late last year the major ransomware operations have added a second lever. Before encrypting anything, they copy the data out. Then, if you decline to pay, they publish it, in instalments, on a website built for the purpose, with a countdown and a press release. Several groups now run these leak sites as a routine part of the business, one has begun auctioning stolen data to the highest bidder, and this summer a handful of them announced a loose alliance to share infrastructure and publicity. The technical change is small. The consequence is not: a ransomware incident is no longer an availability problem with a disclosure risk attached. It is a disclosure incident that also stops your systems working.
Your restore plan is now half a plan
Run the scenario that every current plan fails. You are hit on a Thursday night. Your backups are clean, immutable and rehearsed, and by Saturday afternoon you are back in production having lost four hours of transactions. Excellent work. On Sunday a website you have never visited publishes a directory listing of your finance shared drive, a sample of thirty employee passport scans and a note saying the remaining four hundred gigabytes will follow in seven days. Everything that matters now happens outside IT. There is a regulatory clock running in every jurisdiction whose residents' data is in that archive. There are customers with contractual notification rights. There are employees whose personal documents are on a public site. There is a board that wants to know whether paying makes it stop, and a general counsel who has to explain that it might not and that paying may not be lawful in any case. The operational recovery was the easy half.
What the payment actually buys
Be precise about this, because it is where boards get confused under pressure. When the incident is encryption only, payment buys a decryption tool. It is a delivery, it either works or it does not, and the criminals have a commercial incentive to make it work. When the incident is exfiltration, payment buys a promise to delete data you cannot see, held by people you cannot identify, who have every incentive to keep a copy. There is no verification, no escrow and no recourse. There are documented cases of victims paying and being extorted a second time, and cases of data appearing after a deletion assurance. The affiliate who did the intrusion is frequently not the same party as the operator who takes the payment, and the data has typically been staged through several systems before it reached anyone's storage. None of this makes paying automatically irrational. It makes it a purchase of a probability, and the board deserves to be told that rather than being allowed to think it is buying deletion.
The detection opportunity moved earlier
The useful consequence of double extortion is that it lengthens the attack. Encryption is a loud event at the end. Exfiltration is a quiet event that takes days or weeks, and it happens inside a network where somebody has already obtained administrative rights. That window is where the defence now lives, and most of what detects it is unglamorous. Watch for large outbound transfers to consumer file-sharing services and cloud storage that nobody in the business uses. Watch for command-line archive creation on file servers, because attackers compress before they copy. Watch for a single account reading enormous numbers of documents across shares it has never touched. Watch for the installation of remote administration and synchronisation utilities on servers. Watch for security agents being disabled, backup catalogues being deleted and volume shadow copies being removed, which are the standard preparation steps. And treat a domain administrator logon from an unfamiliar host as an incident, not a curiosity. Honeytokens help disproportionately here: a folder of attractively named documents on the file server that nobody should ever open, wired to an alert. It costs nothing and it catches exactly the behaviour that precedes a leak. The entry routes, meanwhile, have not changed at all. Exposed remote desktop, an unpatched remote access appliance, a stolen credential without second-factor protection, and a phishing attachment still account for the overwhelming majority of intrusions.
Decide the hard questions before you need them
The organisations that handle these incidents well are the ones that made the decisions in a quiet room months earlier. Who authorises payment, and what is the upper limit. What facts must be established in the first forty-eight hours: which systems, which data, whose data, which jurisdictions, which contracts. Who conducts the sanctions screening, because paying an entity associated with a designated person or region can be an offence independent of everything else, and that check has to happen before any negotiation concludes. Which external counsel is engaged first, so that the investigation runs under privilege. When the insurer is notified, and what the policy actually requires. Who speaks publicly, and what the holding statement says. One timing point is routinely missed. The attackers publish samples in order to apply pressure, which means your customers, employees and journalists may learn about the incident from the leak site before you have told them. Your notification plan has to assume it is racing a criminal's publication schedule rather than proceeding at its own pace.
| Response workstream | Evidence to establish |
|---|---|
| Service recovery and continuity | Restore tests and affected-system scope |
| Disclosure and affected parties | Affected data, parties, rights and obligations |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Ransomware Strategy Review
- Rewrite the plan around disclosure, not just recovery. Add the scenario where recovery succeeds and publication happens anyway, and work out who does what in the first 48 hours.
- Make backups immutable and hold an offline copy. Attackers now target the backup infrastructure first; a backup an administrator can delete is a backup the intruder can delete.
- Instrument egress and archive activity on file servers. Large outbound transfers, consumer cloud storage destinations, command-line compression and mass document reads are the signals that precede a leak.
- Deploy honeytoken files and alert on access. The cheapest high-signal detection available for exfiltration, and it takes an afternoon.
- Close the three entry routes properly. No internet-exposed remote desktop, patched remote access appliances, and second-factor authentication on every external service including administrative access.
- Agree the payment decision rights, limits and sanctions screening process in advance. In writing, approved by the board, with named decision makers and deputies.
- Put counsel, forensics and negotiation support on retainer, with out-of-hours numbers you have tested. The first hour spent finding a phone number is the most expensive hour of the incident.
- Know what is actually on your file shares. The leak risk is a function of what you have accumulated, and most organisations have never looked.
The Regional Angle
Four points matter here, and the first is only three days old. The notification landscape in the Gulf has been changing quietly, and it changed again this month. The DIFC's new data protection law came into force on the first of July, with a breach notification duty and a supervisory authority behind it, joining the ADGM and Bahrain regimes and the sector-specific requirements that central banks, health authorities and telecommunications regulators already impose. Alongside that, most regional groups carry contractual notification clocks of twenty-four or seventy-two hours in agreements with European and multinational customers. The practical effect is that there is no longer a comfortable answer to "do we have to tell anyone", and the answer depends on which entity was hit, which is not a question anybody wants to research during an incident. Map it now: per entity, which obligations apply, to whom, within how long. Second, understand what a leak would actually expose in a regional group, because the risk assessment usually stops at personal data and the damage rarely does. The file servers of a typical family-owned or diversified group hold agency and distribution agreements with commission terms, shareholder correspondence, board minutes, salary schedules, dispute files, tender pricing and the working papers for transactions that were never intended to be public. That material is more damaging to the business than the passport scans, it sits in folders nobody has reviewed for a decade, and it is the first thing an extortion group will index and quote from. Third, remember whose data is on your shares. Group structures here routinely put eight entities, a joint venture partner's project documents and a principal's confidential price lists on the same storage, administered by one small team. A leak is therefore not only your incident: it triggers confidentiality and notification obligations under joint venture and distribution agreements, and potential liability to a partner who never agreed to have their documents on your server. Check what those agreements say before something forces you to read them at three in the morning. Fourth, be realistic about response capability in the region this summer. Specialist forensics and negotiation firms have limited local presence, travel remains constrained, and much of the response will be delivered remotely by people several time zones away. Put a retainer in place that explicitly covers remote-first engagement, confirm the out-of-hours contact works during Eid and August, and make sure someone locally can grant access, ship evidence and make decisions at speed. An incident response plan that assumes a team will fly in is currently a work of fiction.
The objection worth taking seriously
The strongest objection is to the advice industry's favourite line: never pay. It is easy to hold that position from outside the room. It is much harder when the alternative is a hospital that cannot see patient records, a payroll that will miss a run for four thousand workers, or the publication of a named individual's medical file. The organisations that have paid this year mostly did so because the harm of not paying fell on people other than themselves, and pretending that is simple cowardice is dishonest. The second objection is analytical. There is a risk of building strategy around the most dramatic version of the threat. Leak sites are partly a publicity operation, the proportion of victims who are actually published is smaller than the coverage implies, and the great majority of incidents still begin with an exposed remote desktop port and an account without a second factor. An organisation that spends its budget on data-loss tooling and leak-site monitoring while leaving that port open has optimised for the headline rather than the risk. The synthesis is not complicated. Spend on the entry routes and the backups first, because they address every version of this threat. Add exfiltration detection second, because it is cheap and the window is wide. And make the payment decision in advance, with criteria, legal advice and sanctions screening built in, so that the conversation in the room is about applying a policy rather than inventing one at two in the morning with a countdown running.
Common Questions
If we restore successfully, do we still have to notify?
Almost certainly, where data was taken. Notification obligations attach to unauthorised access and disclosure, not to whether your systems came back.
Does paying stop the publication?
Sometimes. It buys an unverifiable promise from an anonymous party, and there are documented cases of both compliance and betrayal. Treat it as a probability, not a remedy.
Will our insurance cover the payment?
Check the policy now rather than later. Coverage varies, notification requirements are strict, and sanctions exclusions apply regardless of what the policy says elsewhere.
What should we expect over the next twelve months?
Expect leak sites to become standard across every significant ransomware operation, and expect auctions and buyer solicitation to spread. Expect attacks to target backup platforms and virtualisation infrastructure directly. Expect insurers to tighten terms and to start requiring evidence of specific controls at renewal. Expect regulators to state clearly that payment does not discharge a notification duty. And expect at least one regional organisation to appear on a leak site and to decide, for reasons that will be entirely understandable, to say nothing publicly about it at all.
Ransomware Strategy Review — we rebuild the plan around disclosure as well as recovery, instrument the exfiltration window, and settle the payment and notification decisions before the countdown starts.