Ransomware response playbook: the first hour, 24 hours and 72 hours

A timed ransomware playbook: what to do in the first hour, the first 24 hours and the first 72 hours, from isolation and evidence to reporting, the ransom decision and a clean restore.

This playbook is for IT managers, CISOs, MSPs and the management teams who have to make decisions during a ransomware attack. It turns the general incident response playbook into a timed sequence for the first hour, the first 24 hours and the first 72 hours, and then covers restoration and hardening. Use it next to your incident response plan and the incident reporting playbook, which holds the detailed regulatory deadlines.

Before you start

Ransomware works by putting pressure on your decisions. Prepare these items while you are calm:

• Printed contact sheets: your DFIR retainer, cyber insurer, legal counsel, national CSIRT, police and the main suppliers.
• An out-of-band channel, such as a separate messaging workspace or a phone bridge, that does not depend on your email or identity provider.
• Offline or immutable backups, with a restore test documented in the last six months.
• A pre-approved decision matrix that sets out who may shut down production, who may contact the attacker, and who decides on payment.

Window	Priority outcomes
First hour	Incident declared, spread stopped, backups and identity protected, evidence preserved, core team on the bridge
First 24 hours	Scope known, exfiltration assessed, backups validated, NIS2 early warning and any DORA initial notification filed, police informed, holding statement ready
First 72 hours	Root cause identified, eradication plan agreed, restoration under way, NIS2 notification and GDPR notification filed, ransom decision documented

Phase 1: Declare and isolate (first hour)

Speed matters most at this stage, but keep the actions controlled. The CCB’s advice is to disconnect infected computers from the internet and the network without turning them off^[1]. Powering off destroys the memory evidence and sometimes the encryption keys.

• Declare the incident, assign the incident manager and record the time.
• Isolate affected hosts through EDR network containment, or by unplugging them or disabling the switch port.
• Disconnect backup repositories and protect the backup console credentials. Check whether backup jobs or snapshots are being deleted.
• Disable remote access paths (VPN, RDP gateways, remote management tools) until you know which one the attacker used.
• Protect identity: suspend suspicious privileged accounts and watch for new admin accounts and changes to Group Policy.
• Move all communication to the out-of-band channel.

Phase 2: Preserve evidence (first hours)

Evidence tells you how the attacker got in and what they took. It also supports a criminal complaint and an insurance claim. Capture it before you rebuild anything.

• Capture memory and disk images from a sample of encrypted hosts, at least one domain controller and the likely entry point.
• Export firewall, VPN, EDR, identity provider and cloud audit logs before retention removes them.
• Keep a copy of the ransom note, the attacker’s contact details, any leak-site URL and the cryptocurrency addresses.
• Hash each item and record the chain of custody.

Phase 3: Establish scope and test backups (first 24 hours)

Many ransomware groups steal data before they encrypt it. You therefore have two problems to answer: availability and confidentiality.

• Map which systems, sites and cloud tenants are encrypted, and which are untouched.
• Look for signs of exfiltration: large outbound transfers, archiving tools, cloud sync tools, and the attacker’s own claims on a leak site.
• Identify the initial access vector. Common ones are exposed VPN or RDP, stolen credentials and unpatched edge devices.
• Test your backups: are they intact, when were they last good, and do they predate the attacker’s first activity?
• Check No More Ransom (nomoreransom.org) for a free decryptor for the identified strain. The initiative was founded by Europol and the Dutch police with private partners, and the Belgian Federal Police has released keys through it^[5].

Phase 4: Notify and report (24 to 72 hours)

Ransomware at a NIS2 entity will often be a significant incident, so treat the 24-hour early warning as the default, not the exception. Financial entities check DORA classification first, because the initial notification is due within 4 hours of classifying an incident as major. If personal data was encrypted or stolen, assess GDPR notification within 72 hours. The Dutch police explicitly note that ransomware affecting personal data is likely to be a data breach^[3]. The reporting playbook has the decision flow and the list of recipients.

• File a criminal complaint. In Belgium, file it with the police (the CCB refers businesses to their local police station)^[1]. The Federal Computer Crime Unit of the Federal Police handles serious cybercrime and works with the CCB on ransomware^[7]. In the Netherlands, a business can report online with eHerkenning or make an appointment on 0900-8844^[3]. In Luxembourg, file a complaint with the Police grand-ducale.
• Notify your cyber insurer within the policy deadline, and before you engage any vendor they would need to approve.
• Inform affected customers and partners with a factual message approved by legal counsel.

Phase 5: Decide on the ransom

The CCB and the Dutch police advise against paying. Payment does not guarantee you get your data back or that stolen data is deleted, and it funds further attacks^[2][3]. If management still considers paying, make it a documented decision at board level, taken with:

• Sanctions screening: the EU cyber sanctions regime (Council Regulation (EU) 2019/796) freezes the assets of listed persons and prohibits making funds available to them^[6]. Other EU sanctions regimes, and US rules where you have US exposure, may also apply. Legal counsel must check whether the group can be linked to a listed person.
• Law enforcement: tell the police if you are considering payment. The Dutch police state that payment information helps investigations^[3].
• Insurance and accounting: check the policy terms, and record any payment transparently.
• Reality check: even if a decryptor works, it is slow and imperfect. Restoring from clean backups is often faster.

Paying does not remove any notification duty under NIS2, DORA or the GDPR.

Phase 6: Eradicate and restore (72 hours onward)

Restore into a clean environment. Bringing systems back onto a network the attacker still controls only gets them encrypted again.

• Rebuild the identity foundation first: clean or rebuilt domain controllers, the KRBTGT account reset twice, all privileged and service account passwords rotated.
• Restore systems in business impact order from validated backups, scanning each one before you reconnect it.
• Close the initial access vector: patch it, enforce MFA on all remote access, and remove exposed RDP.
• Keep heightened monitoring in place for at least 30 days and watch for the known indicators of compromise.

Phase 7: Harden and review

Within two weeks of recovery, hold a blameless review and turn the findings into funded actions. Typical outcomes are immutable backups with separate credentials, phishing-resistant MFA for administrators, tiered administration, EDR coverage on every server, and faster patching of edge devices. The companion template includes a timed first-72-hours checklist, a decision log, a contacts sheet and a backup assessment that you can use in an exercise or in a live incident. In Secrato, the hardening actions become tracked risk treatments, so their progress is visible to management.

How this connects to other frameworks

Ransomware readiness relies on controls that most frameworks share: backups (ISO 27001 control 8.13), incident management (5.24 to 5.28), access control and MFA, and vulnerability management. NIS2 Article 21(2) lists backup management, incident handling and MFA explicitly. CyFun and NIS2 assessments therefore reward the same preparation.

Frequently asked questions

Is paying a ransom illegal in Belgium, the Netherlands or Luxembourg?

At the time of writing, there is no general statutory ban on paying in these countries. A payment can still breach sanctions law if it reaches a listed person or entity, and the authorities advise against paying. Take legal advice before any decision.

Should we contact the attackers to buy time?

Only through a designated, experienced negotiator, and only after legal counsel and the police have been informed. Unplanned contact can reveal information and increase pressure on you.

Our backups were encrypted too. What now?

Check for offline copies, cloud snapshots, replicas on other sites and SaaS exports. Check No More Ransom for a decryptor. Ask your DFIR provider whether the strain has known weaknesses.

Do we need to report if no data was stolen?

Possibly. Under NIS2, severe operational disruption alone can make an incident significant. GDPR also covers breaches of availability, so a loss of access to personal data can be a notifiable breach.