A ransomware gang is threatening to publish our data - what should we do?

Behind "we have your data, pay or it gets published" there are usually four situations, each calling for a different response:

So the first move is verification, not a reply: does the file listing or sample match your internal data, are the newest timestamps later than any known earlier breach, and could the data have come from a supplier or cloud service rather than your own systems? We advise against contacting the attackers to ask for "proof" - the moment you do, you are inside the negotiation rhythm they designed.

Do not underestimate speed either. CISA's Akira advisory, updated in November 2025, notes that in some incidents data was exfiltrated just over two hours after initial access. "We caught the encryption early, so there was no time to steal anything" does not hold.

The evidence falls into four types, and a conclusion holds only when they corroborate each other:

The toolkit CISA recorded for Akira is typical: FileZilla and WinRAR to collect data, 7-Zip to compress it, WinSCP and Rclone to move it out, with Ngrok tunnels and cloud storage such as MEGA. Specific tools vary between families, but the collect-package-exfiltrate chain is broadly the same.

One more reference point is often overlooked: the attacker's own samples. Their directory structure, file paths and server names frequently point straight at the machine and share that was read, which in turn narrows the time window.

State conclusions in grades: confirmed, highly likely, undetermined. Where traffic logs are missing, only a likelihood can be drawn from host artefacts, and our forensic report labels that uncertainty instead of presenting inference as fact. And a caution: "no evidence of exfiltration found" is not the same as "no exfiltration", so whether that justifies not notifying is a call for legal and compliance.

Do not count on it. The public evidence all points the same way:

• When the UK's National Crime Agency announced Operation Cronos against LockBit in February 2024, it disclosed that some of the data on LockBit's systems belonged to victims who had already paid, which it said showed that paying does not guarantee deletion, whatever the criminals promise.
• Coveware's quarterly report of November 2020 listed broken promises after payment: Sodinokibi re-extorted paying victims weeks later with the same data set; Netwalker and Mespinoza published data of companies that had paid; Conti offered fake files as proof of deletion. Coveware's advice was that paying victims should assume the data will be traded, sold or held for another extortion attempt.

The logic is simple: data can be copied endlessly, several members and affiliates handle it, and deletion cannot be verified. The same applies to brokers offering to "delete the data" or "take the listing down" - they cannot verify deletion either, and in substance they are still paying the attacker.

Our position is that we do not pay ransoms and do not negotiate on anyone's behalf. The full risk picture is in should we pay the ransom. Time spent scoping the exposure, meeting notification duties and closing the exfiltration route produces outcomes you can actually control.

That depends on what data was taken, how many people it concerns and what kind of entity you are. The provisions most directly relevant in China:

• PIPL Article 57: where personal information is or may have been leaked, altered or lost, the processor must take remedial measures immediately and notify the authority responsible for personal information protection and the individuals concerned. The notice must cover the categories of information, the cause and the possible harm; the remedial measures taken and what individuals can do to reduce harm; and the processor's contact details. If the measures effectively prevent harm, individuals need not be notified, but the authority may still require notice if it considers harm possible.
• Network Data Security Management Regulations, Article 11: where a network data security incident harms the lawful rights of individuals or organisations, the processor must promptly inform the affected parties of the incident and risks, the consequences and the remedial measures taken, by phone, text message, instant messaging, email or public notice.
• Data Security Law, Article 29: on a data security incident, inform users and report to the competent authorities as required.
• CAC incident reporting measures: a leak of personal information on 1 million or more people, or a leak of important data threatening national security and social stability, is among the quantitative indicators of a relatively major incident, triggering the 1-hour or 4-hour reporting deadlines. Channels and materials are covered in how to report ransomware to the police.

Regulated sectors, listed companies and organisations with data protection clauses in customer or partner contracts often face their own deadlines and formats. Where overseas entities or individuals are affected, local law applies too - under the UK GDPR, for instance, a personal data breach likely to pose a risk to individuals' rights and freedoms must be reported to the ICO within 72 hours of becoming aware of it, where feasible.

This summarises the rules; it is not legal advice. Whether notice is required, to whom, when and in what words is for the authorities and your legal counsel to confirm. We supply the exfiltration scope and technical facts that decision rests on.

The two most common communication failures are denying too early and speaking too late. A few principles:

• State only verified facts. Separate "confirmed", "under investigation" and "not yet determined"; do not guess at scope, and do not promise "no data left" to reassure people.
• One message, one voice. Appoint a spokesperson and give support, sales and legal the same lines; keep every version and a record of what was sent to whom.
• Tell people what they can do. Warn customers about emails and calls in your name asking to change bank details or requesting passwords or one-time codes, and ask them to verify payment changes by calling a number they already hold; where relevant, suggest changing passwords they used on your systems. Some groups go around the victim and email or call customers and partners directly, so warning them first reduces panic and secondary fraud.
• Do not let customers learn it from a leak site. The order and content of notices to regulators, police, affected individuals and customers follow legal counsel's advice - but they need to go out before the news does.
• Preserve evidence for legal purposes. Keep the original extortion emails, the attacker's sample listings, and leak-site screenshots with capture times, all hashed; whether notarisation or trusted timestamping is warranted is for legal counsel to decide.

Data already taken cannot be recalled, but a second theft can be prevented. While the leak threat plays out, the attackers often still have a way in:

• Close the exfiltration route. Move server egress to an allowlist and temporarily block cloud drive and file-sharing services; remove Rclone and similar tools with their configuration, and check scheduled tasks and services for exfiltration scripts.
• Rotate credentials everywhere: domain admin and service accounts, VPN and remote access accounts, database connection strings, cloud console and API keys, SaaS OAuth tokens. Changing passwords on the encrypted servers alone is nowhere near enough.
• Hunt persistence. Unknown accounts, remote-access tools, web shells and tunnelling tools - confirm they are gone before restoring normal egress.
• Add detection. Alert on large outbound transfers, off-hours bulk reads from shares and execution of transfer tools, and keep watching the leak site and related channels for new material about you for some time.

If the entry point stays open and credentials stay the same, the same group - or whoever buys the access from them - will be back; see why ransomware keeps coming back. When containment, forensics and hardening all need to happen at once, our incident response team can take it on.