A ransomware incident rarely announces itself politely. Maybe it's a help desk ticket about a spreadsheet that won't open. Maybe it's a ransom note printing out of every network printer at once, or a folder full of files that suddenly carry an extension nobody recognises. However it surfaces, the next sixty minutes shape everything that comes after: how much data you keep, how clean your evidence is, and how much leverage you still hold when recovery or negotiation begins.
What follows is a checklist, not a policy. Adapt the order to your environment, but keep the logic intact: stop the bleeding, understand the wound, preserve what you know, then bring in the right people.
Minute 0–5: Contain the spread
The goal is to stop encryption from reaching the next server without destroying the information you will need later. Both halves of that sentence matter.
- Disconnect the network cable from affected machines and switch Wi-Fi off. If you can isolate the port from a switch or management console instead of touching the endpoint, do that.
- Leave the machine powered on. Memory holds encryption keys, running processes, and often the attacker's tooling. Cutting power erases it.
- Isolate by VLAN or firewall rule when a whole segment is hit, rather than chasing hosts one by one.
- Disable shared drives, mapped folders, and any service accounts the affected hosts can reach.
There is one exception to "don't power it off": if a machine is actively wiping data, or you are watching a hypervisor encrypt virtual machines in real time, cut it. Saving the data beats saving the memory dump.
Minute 5–15: Work out what you are dealing with
You cannot contain what you have not scoped. Before anyone starts cleaning, answer four questions and write the answers down with timestamps:
- How many hosts are affected, and are any of them business-critical?
- Is encryption still in progress, or has it stopped?
- What does the ransom note say, and what file extension is being appended?
- Is there evidence the attacker still has remote access?
Assign one person as scribe. Every action, every observation, every decision gets a time next to it. That timeline will be worth more than you expect — for the insurer, for your legal team, and for the post-incident review.
Minute 15–25: Preserve evidence before anyone cleans up
The instinct to start deleting infected files and running cleanup tools is strong and usually wrong. Once you wipe a ransom note or quarantine the binary that dropped it, you have made the investigation harder for everyone downstream.
Capture what you can, quickly and cheaply:
- Photograph or screenshot ransom notes, desktop wallpapers, and error messages.
- Copy the ransom note text and any contact addresses into your incident log.
- Export relevant logs — endpoint, authentication, firewall, backup — before retention windows roll over.
- Record file extensions, affected paths, and any suspicious accounts or scheduled tasks.
- Do not pay for "decryption tools" advertised inside the ransom note, and do not let staff contact the attackers.
If law enforcement or your insurer is likely to be involved, take note of who touched what and when. Good documentation is what turns a messy morning into usable evidence.
Minute 25–40: Move to out-of-band communications
Assume email, chat, and the corporate phone system are compromised or monitored. Attackers frequently lurk in mailboxes during the early hours, reading exactly how you plan to respond.
Set up a bridge line by phone, or a separate messaging channel on personal devices over cellular data. Keep the group small — the incident lead, one technical person, one decision-maker, and the scribe. Others get updates when there is something to say. Write a single shared timeline document and keep it in one place so nobody is working from a different version of events.
Speed matters in the first hour. Panic costs more than a deliberate two-minute pause.
Minute 40–55: Notify in a deliberate order
Who you call, and in what order, depends on your organisation. A workable default looks like this:
- Incident response lead or managed security provider — get expert hands on the problem immediately.
- Executive sponsor — someone senior enough to authorise taking systems offline.
- Legal counsel — especially if personal data may be involved. Counsel can also engage forensics in a way that keeps findings protected.
- Cyber insurer hotline — most policies have notification deadlines and approved vendors.
- Law enforcement — in many countries, reporting a ransomware incident is expected or required. Your counsel can confirm what applies to you.
- Regulators and privacy authorities — breach notification clocks can be short. This is a legal question; get professional advice rather than guessing.
- Staff — a short, plain script. Tell people what to do and what not to do, and nothing more until facts are confirmed.
Resist the urge to brief everyone at once. Half-formed information spreads faster than corrections do.
Minute 55–60: Freeze backups and lock down credentials
Check that your offline and immutable backups are genuinely untouched, and take backup infrastructure off the network if there is any doubt. Attackers hunt backups early because destroying them removes your options.
Then start tightening access: disable dormant and service accounts, rotate privileged credentials, and reset passwords for anyone who logged in from an affected host. Do this in a planned order, and watch closely afterwards. Re-entry is common, and the initial access route — an unpatched appliance, a valid VPN account, a phishing foothold — is often still open.
What to prepare before the clock starts
None of this works well if the plan only exists inside someone's head. Print a contact card and keep an offline copy somewhere other than the network. Decide in advance who can authorise pulling a production system offline, because that decision will be needed at 3 a.m. with incomplete information. Keep a spare laptop and phone that are not part of the domain. Run a tabletop exercise once a year and invite the people who would actually be on the call, not just the security team.
The organisations that recover fastest from ransomware are rarely the ones with the fanciest tools. They are the ones where everyone already knew their first three moves.
Photo: Engin Akyurt / Pexels
