A manufacturer arrives on Monday to find every file server encrypted and a ransom note sitting in the print queue. Two weeks later, a professional services firm learns its systems are perfectly intact — but a pile of client documents is now listed on a leak site with a countdown clock. Both events get filed under "ransomware." The response to each should not be the same, and confusing them costs time you will not get back.
Encryption Attacks Are Loud
Pure encryption is a blunt instrument. The intruder gets in, escalates privileges, disables or deletes the backups they can reach, then runs the encryptor as widely as possible. The ransom note is not really a message to you; it is an advertisement designed to be found. Downtime is the product being sold.
That noise is a hidden advantage. You know you have a problem. You can see which systems are affected, isolate them, and start the recovery conversation with a question people understand: which backup do we trust, and when was it last verified? Containment, eradication, restore, validate. The work is miserable, but the path is lit.
Data Extortion Is Quiet — and Easier to Miss
Data extortion flips the leverage. The intruder spends days or weeks moving through mailboxes, file shares and cloud storage, copying anything that looks valuable: contracts, payroll records, source code, customer lists, board minutes. Nothing breaks. Nobody calls the help desk. The first signal often comes from a human decision rather than a technical alert — a leak-site listing, a journalist's email, or an extortion demand sent to an executive's personal address.
Some groups skip encryption entirely. Others encrypt one or two servers purely to make sure someone notices, then lean on the stolen data as the real threat. The pressure is reputational and regulatory: pay, or we publish, sell to your competitors, or contact your clients one by one.
Most Real Incidents Are Both at Once
Treating these as separate categories is useful for planning, but the incident in front of you is probably a hybrid. A typical intrusion steals data first, then encrypts as a finale to raise the stakes. Some crews add harassment on top: calls to customers, distributed denial-of-service bursts, emails to your staff from a spoofed internal address.
That means your incident response has to run two tracks simultaneously — an availability incident and a data breach — even if only one of them is visible yet. Assume theft until your logs prove otherwise.
How Response Priorities Change
If files are encrypted
- Stop the spread first: isolate segments, disable compromised accounts, revoke active sessions and tokens.
- Find the last known-good backup and confirm it is both complete and uninfected before restoring anything.
- Check identity systems and virtualization management, because attackers who reached those can re-encrypt after you rebuild.
- Restore in order of business dependency, not alphabetical order of servers.
If data was stolen
- Preserve logs before they rotate out — egress, cloud storage access, VPN, email rules and forwarding.
- Work out what was taken and how sensitive it is, which determines who must be told and when.
- Lock down outbound paths the attacker may still be using, then hunt for the access that allowed the transfer.
- Bring in legal counsel early, since notification duties, contractual clauses and sanctions rules vary by sector and jurisdiction.
If it is both
Do not let the encryption push the breach investigation aside. The decryptor, if you ever get one, does nothing about the copy of your data sitting on someone else's server. Teams that fix the servers and forget the exfiltration typically face a second demand weeks later.
Recovery restores your operations. It does not recall your data.
Evidence: What to Preserve, and When
The evidence that matters differs sharply between the two cases. For encryption, you want the payload sample, the ransom note and its metadata, the timeline of encryption across hosts, and proof of how far the attacker moved. For theft, you want transfer logs, staging archives, the credentials used, and any record of what data was accessed versus merely stored.
None of this exists if logging was switched off to save money or if retention is measured in days. Check your retention windows now. A 90-day window sounds generous until you learn the intruder arrived five months ago.
Pressure, Payment and Public Statements
Paying for a decryptor is a transaction with a known failure rate; paying for a promise of deletion is a transaction with no enforceable terms at all. Whether payment is permitted also depends on your jurisdiction, your sector and who the recipients are, and sanctions exposure is a real consideration. That is a question for counsel, not for the incident bridge at 3 a.m.
Keep communication tight. One spokesperson, one negotiating channel if you choose to have one, and no side conversations between employees and the attacker. Outside the company, say less than you know and never speculate about the scope of stolen data — corrected statements damage trust more than a short, accurate one.
A Short Checklist for Your Next Tabletop
- Run two scenarios, not one: encryption with no confirmed theft, and theft with no encryption. See how differently your team reacts.
- Prove you can identify the last trusted backup without relying on a single administrator's memory.
- Confirm who can authorise an emergency restore, an external forensic firm, and a public statement — before anyone needs to.
- Verify that outbound data flows are logged and that alerts fire on unusually large transfers.
- Rehearse the notification decision as a business problem: who calls customers, who calls regulators, who calls insurers.
The gap between these two attack styles is not academic. It decides whether your first hour goes into rebuilding servers or into figuring out what left the building. Plan for both, because the crews you are up against already do.
Photo: cottonbro studio / Pexels
