At 6:40 on a Tuesday, a finance manager can't open a spreadsheet. By 7:15, three colleagues report the same error. Someone in IT finds a text file with a countdown and a payment address, and the word ransomware finally gets said out loud.
What happens next is rarely decided by the attackers. It is decided by the people in the room, and by a handful of habits that separate a bad week from a lost year. Some of those habits are technical. Most are not. These are the mistakes that show up again and again, in companies of every size, in every industry.
1. Rebooting and "Tidying Up" Mid-Attack
The instinct to reboot a misbehaving machine is deeply ingrained, and mid-incident it is one of the most damaging things you can do.
A restart wipes RAM, which often holds encryption keys, running processes, network connections, and the commands an attacker typed minutes earlier. On some strains it also lets the encryption routine resume, or lets a scheduled task finish the job. Powering off has the same effect, as does rushing a "cleanup" or restoring over a live system because it seems faster.
There is a second version of this mistake that has nothing to do with power buttons. A helpful employee deletes the ransom note, empties a suspicious folder, or runs a cleanup utility to free up disk space. Every one of those actions erases something an investigator would have used to work out which systems were touched, when the attacker got in, and whether data left the building.
Isolate instead of shutting down: unplug the network cable, disable Wi-Fi, leave the machine powered on. Tape a note to the keyboard so nobody helpfully power-cycles it. If your team has never done this, get an incident response firm on the phone and follow their instructions rather than improvising. A five-minute call can preserve evidence that would otherwise vanish for good.
"The note is evidence. The memory is evidence. The thing everyone wants to delete at eight in the morning is the thing we need most at eight in the evening."
— a line you will hear from almost any incident responder
2. Paying Quickly — and Negotiating Without Help
Ransomware creates the worst possible conditions for a financial decision: incomplete information, no time to verify claims, and enormous pressure from people whose work has stopped. That combination pushes leadership toward the fastest exit, and the fastest exit usually looks like paying.
Paying is a decision with consequences most teams only discover afterward. Decryption keys sometimes fail on large or corrupted files, leaving you with a partial restore and a drained account. Payment can breach sanctions rules, turning a bad week into a legal problem. It marks the company as a payer, and stolen data is often sold or reused regardless. Meanwhile, the deadline in the note is almost always negotiable: attackers set it to manufacture urgency, not to enforce it.
The mistake is not "always refuse to pay." It is deciding alone, in the dark, within four hours. Professional negotiators, your insurer's breach team, and law enforcement have done this hundreds of times. They know which groups honor deals, which are simply resellers, and where free decryption tools already exist. Involve them before you reply to anything, including a friendly "just checking in" message from the attacker.
3. Treating It as an IT Problem
IT owns the technical response. It does not own the decisions the incident will force: whether to stop a production line, whether to notify customers, whether to pay, whether to go public, whether to hand a laptop to police. Those calls need people above the IT manager, and they need to be made quickly.
Assemble a small group early: an executive with real authority, IT or security leadership, legal counsel, communications, HR, and your insurer. Name one incident commander and one scribe. Two people with the same authority is effectively nobody with authority.
Include someone who knows the business, not just the systems. The order in which systems come back should be driven by revenue, safety, and legal obligations, not by whichever server happens to restore most neatly.
4. Assuming the Backup Is Fine Because It Exists
Most companies have backups. Far fewer have backups they can actually restore, on the day it matters, within the downtime the business can survive.
- Connected backups. If the backup server sits on the same domain with the same credentials, the attacker encrypted it too.
- Untested restores. A job that reports success is not a restore that finishes. Test quarterly, and time it.
- Unknown recovery time. Rebuilding 200 servers takes days, not hours. Set that expectation before the crisis, not during it.
- No offline or immutable copy. At least one copy should be unreachable, either offline or immutable, ideally both.
- No documentation. If only one person knows how recovery works, and that person is asleep, you have a problem.
The best version of this is unglamorous: several copies, on different media, one of them disconnected, with a dated restore test and a name attached to it.
5. Communicating on Channels the Attacker Can Read
If email is compromised, the attackers read every message about the incident, including the one telling staff not to use email. The same is true of a chat platform with a foothold behind it.
Agree on an out-of-band channel in advance: a phone bridge, a messaging app that is not part of your normal stack, or a printed call tree kept in a drawer. Keep the group small and share details on a need-to-know basis. Do not announce anything to all staff, customers, or social media until legal and communications have agreed on the wording. Attackers watch public statements and adjust their demands to match the pressure they see.
A note on internal silence
Keeping quiet externally is not the same as keeping staff in the dark. Rumors fill a vacuum within minutes and usually make things worse. A short, plain update — what is known, what is not, what people should do — buys you patience and keeps well-meaning employees from "helping."
6. Losing the Timeline
During an incident, everyone remembers the ending and nobody remembers the order. Weeks later, your insurer, your regulator, your lawyers, and possibly your customers will all ask the same questions: when did you know, what did you know, and what did you do about it?
Designate a scribe from the first hour. Log decisions, timestamps, names, and the reasoning behind each call, including the calls that turn out to be wrong. Preserve notes, screenshots, and system logs. It feels like busywork at 3 a.m. It becomes the difference between a defensible response and a story nobody can prove.
7. Treating Restored Systems as the Finish Line
Getting the business running again is a milestone, not an ending. Ransomware is often the loud second act; the quiet first act was weeks of access. Groups frequently keep a foothold, return later, or sell that access to someone else.
After recovery, rebuild rather than clean. Rotate every credential, including service accounts and anything stored in scripts. Close the entry point, verify whether data was exfiltrated, and check for the persistence mechanisms that survive a restore. Then confirm that the person who let them in is not still sitting on a valid VPN login.
The First Sixty Minutes
- Isolate affected systems from the network without powering them off.
- Tell the right three people, and agree who is in charge.
- Move communication off email and off any channel that may be compromised.
- Call your insurer and an incident response firm. They have hotlines for exactly this.
- Start the timeline and preserve evidence.
- Do not pay, negotiate, or reply to the attacker yet.
- Give staff a short, honest update so the rumor mill does not run the response.
A Short Pre-Incident Checklist
Every mistake above is easier to avoid if the decision was made before it was needed. Keep a printed one-page plan — on paper, because your file server may not be available — with names, numbers, roles, and the first five actions.
- A named incident commander and a deputy.
- An out-of-band communication channel, tested this year.
- Insurer and incident response contacts, printed, not stored on the network.
- One offline or immutable backup with a recent, documented restore test.
- A one-page decision framework for payment, disclosure, and downtime.
- Outside legal counsel who has handled a breach before.
None of this requires a large budget. It requires a few decisions made on a calm afternoon, by people who would otherwise be making them at 6:45 on a Tuesday morning, with a countdown running in the corner of a screen.
Photo: Mikhail Nilov / Pexels
