Ransomware: the first 24 hours

You will not follow this perfectly on the day. Nobody does. The point of a runbook is that when your working memory is gone, and it will be gone by hour three, the next right action is written down somewhere you can find it.

This covers the first 24 hours from the moment ransomware is confirmed. It assumes a mid-market organisation: an IT team of a handful of people, possibly an MSP in the mix, no 24/7 SOC. Adjust up or down.

Before anything else: three decisions you can make right now

While reading this on a quiet day, decide these three things and write the answers into your incident response plan. They are the decisions that cost the most time when made under pressure.

• Who can authorise disconnecting systems that make money. Taking the order system or the production line offline is a business decision, not an IT one. Name the role that can make it, and a deputy for when they are on a plane.
• Who calls the insurer, and when. Most cyber policies require notification before you appoint external help, and many name a panel you must use. Ringing your favourite IR firm first can void the cover that would have paid for them.
• Where you will talk when email is down. Pick the out-of-band channel now. A WhatsApp or Signal group with the core team in it, created today and left dormant, costs nothing.

Hour zero to one: confirm and stop the spread

The first hour is about scope control, not investigation. Resist the pull to work out how they got in. That question keeps until tomorrow.

• Confirm it is actually ransomware. One encrypted file share plus a ransom note is confirmation. Do not wait for a second opinion to start moving.
• Isolate, do not power off. Disconnect affected machines from the network. Pull the cable, disable the adapter or use your EDR’s isolation function. Do not shut machines down: memory holds encryption keys, running processes and evidence that disappear at power-off.
• Sever the paths ransomware travels. Disable or restrict the protocols and accounts it spreads through: block SMB laterally where you can, disable the domain admin accounts you do not strictly need, and consider pausing VPN access until you understand the entry point.
• Protect the backups before anything else. Modern operators go for backups first. Verify your backups still exist, then get a copy offline or into an account the domain cannot touch. If your backup console uses domain credentials, assume it is a target.
• Start the log. One person, one running document: time, what was seen, what was done, who decided. Every hour of the incident, this log pays for itself. It is also the raw material for the insurer, the regulator and the lessons learned.

Hour one to four: stand up the response

• Declare the incident and name the incident lead. One person coordinates. Not necessarily the most technical person; the one who can run a checklist under pressure and chair a call. Everyone else gets a lane: containment, comms, evidence, business liaison.
• Notify the insurer. Now, not after you have “got a handle on it”. Ask them explicitly: which IR firm, which legal counsel, and what do you need from us to keep cover intact. Note the claim reference in the log.
• Get legal in the loop early. Whether in-house or external, counsel shapes two things from hour one: privilege over the investigation, and the regulatory clock. In the UK, if personal data is likely involved, the ICO notification window is 72 hours from awareness. Other jurisdictions vary; some are shorter.
• Move to the out-of-band channel. Assume the attacker can read your email and possibly your chat. Coordination of the response moves to the channel you set up on that quiet day. If you did not set one up, create it now on personal devices and keep membership tight.
• Brief the executive once, properly. Fifteen minutes: what we know, what we have done, what happens next, when the next update comes. Then give them a cadence, every two to three hours at first, and hold to it. A predictable rhythm of updates is the single best defence against the incident being run by whoever shouts loudest.

Hour four to twelve: scope, preserve, decide

• Map the blast radius. Which systems are encrypted, which are suspect, which are believed clean. Three lists, kept current on a whiteboard or shared doc. Everything else hangs off this.
• Assume data was taken until shown otherwise. Most ransomware groups now exfiltrate before encrypting. Check egress: firewall logs, proxy logs, cloud storage audit trails, unusual outbound volumes in the days before detection. The double-extortion question changes your legal position, your regulatory position and your communications, so it gets asked on day one.
• Preserve before you rebuild. Before any machine is wiped and reimaged, capture what you can: disk images of key systems where practical, memory captures if the machine is still isolated and running, and copies of relevant logs to somewhere the attacker cannot reach. Your future forensics, insurance claim and possibly court position depend on what you keep in this window.
• Do not touch the ransom note beyond photographing it. Note the group name, the contact route, the deadline. Do not open the negotiation channel yourself. If negotiation happens at all, it happens through specialists, with legal and the insurer in the loop, not from a personal Proton account at midnight.
• Check whether the payment question is even legal. Depending on who the group is and where you operate, payment can be unlawful under sanctions regimes. This is a legal question with personal consequences for directors. Park the “should we pay” debate until counsel has answered “may we pay”.

Hour twelve to twenty-four: stabilise and set up day two

• Establish the recovery order with the business, not for them. Which service coming back first actually matters commercially? Finance systems before the wiki. Get the priority list agreed by someone who owns the P&L.
• Test one restore before promising anything. Restore a single meaningful system from backup into a clean, isolated segment and verify the data. Until one restore has worked end to end, do not give the board a recovery timeline.
• Draft the holding statements before you need them. One for staff, one for customers who ring in, one for the press if it comes. Approved tonight, they take an hour. Improvised tomorrow under a journalist’s deadline, they go wrong.
• Rotate the credentials that matter. Domain admin, backup consoles, remote access, cloud tenancy global admins. Assume every credential the compromised systems ever saw is burned.
• End day one with a handover, not a collapse. Thirty minutes: the three lists, the log up to date, the next-day priorities written down, and everyone told when to be back. Tired responders make day-two mistakes. The incident will still be there at 7am.

The five most common day-one mistakes

• Powering off machines and destroying the evidence in memory.
• Rebuilding systems before anyone captured an image or worked out the entry point, so the attacker walks straight back in.
• Calling an IR firm before the insurer, and finding the costs are not covered.
• Letting the 72-hour regulatory clock start quietly while everyone was heads-down technical.
• Nobody keeping the log, so the sequence of events is unreconstructable within a week.

One-page checklist

Isolate, do not power off. Protect the backups. Start the log. Name the lead. Call the insurer. Get legal in. Move comms out of band. Brief the exec and set the update cadence. Map the blast radius. Check for exfiltration. Preserve evidence before rebuilding. Photograph the note, touch nothing else. Confirm payment legality before debating payment. Agree recovery order with the business. Test one restore. Draft holding statements. Rotate the credentials that matter. Hand over and go home.

Practitioner Runbooks are working documents, not standards. Spotted something that does not match how it works in your environment? Email hello@incidentresponse.com and we will improve it, credited to you.