Hit by Ransomware? The First Hours, Step by Step

Minute 0–15: contain, without destroying evidence

• Isolate affected machines from the network. Pull the network cable, disable Wi-Fi and mobile connections, disconnect VPN sessions and shared-storage mounts, or isolate the switch port/VLAN. The goal is to cut the attacker's reach and stop the spread.
• Note the time and, if you can, which machine showed symptoms first. The timeline you write in the first hour is the one everyone — responders, insurer, authority — will rely on later.
• Alert your response chain now, not after you have “investigated a bit”: whoever owns IT, leadership, and your external responder if you have one. Speed beats completeness.

“Do we restart? Do we shut down?” — Isolate first.

The decision logic, in order:

1. Isolate first. A machine cut off from every network can do little further harm — and it still holds its evidence.
2. Preserve evidence when safe. Keep isolated systems powered on where possible: memory can hold the running malware, attacker tooling and, in some cases, material that later helps recovery. A reboot can also overwrite forensic artifacts.
3. If isolation is impossible and encryption is actively spreading, follow your incident responder's instructions. CISA recommends powering the device down as a last resort to prevent further spread, while recognizing that volatile forensic evidence may be lost.
4. Do not reconnect the system once isolated or powered down — not “just to check something”.
5. Coordinate high-impact decisions with an incident responder. Servers, hypervisors, storage platforms and identity infrastructure are not laptop-grade decisions; a wrong move there multiplies the damage.

Minute 15–60: protect recovery options, scope the damage

• Recovery infrastructure first. Ransomware operators frequently target accessible backups. Restrict unnecessary access to backup administration and recovery infrastructure, preserve relevant logs, and coordinate high-impact changes with the incident-response team. Avoid destructive actions that could remove evidence or disrupt known-good recovery copies.
• Rough scoping, not perfection: which systems show the ransom note or encrypted files? Are the domain controllers affected? Is the file server hit? Is anything still untouched — and can it be isolated before it stops being untouched?
• Preserve, do not clean: keep the ransom note (photo + file, including the exact filenames), keep a few encrypted samples, capture screenshots where it is safe to do so, and preserve logs that rotate quickly — EDR, firewall, VPN, authentication, backup and cloud (e.g. Microsoft 365 sign-ins). Delete nothing.
• Protect privileged accounts. Assume admin credentials are compromised: review and restrict privileged access, and stage credential resets with your responder so you do not lock yourselves out mid-response.
• Move communications out-of-band. If the attacker had domain access, assume they read your email. Coordinate on phones or an external messenger until the tenant is cleared.

The panic mistakes that cost weeks

• Wiping and reinstalling “patient zero”. You have just destroyed the machine that explains the intrusion — and the gap it proves will still be open after you rebuild.
• Restoring backups into the infected network. Restored systems get re-encrypted, and now your clean copy has been mounted in a hostile environment. Containment and recovery planning come first; restoration second.
• Running random “decryptors” from the internet. Fake decryptors are a known second-wave scam, and even legitimate tools used on the wrong family can damage data. Identification first — No More Ransom is the safe place to check.
• Emailing “we've been hacked” from the compromised tenant — to colleagues, clients or your bank. The attacker may be reading, and it can trigger their end-game.
• Contacting the attackers casually or paying in panic. Every early message weakens your position. That decision has its own process — made with facts, counsel and specialists, not at minute 40.
• Public statements before facts. “We see an incident and are investigating” is enough for day one.
• Treating an assessment tool as incident response. Do not run exposure-assessment software — including our own StopRansomware Probe — as a substitute for incident response during an active attack. Assessment answers “how exposed am I”; an active incident needs containment, forensics and recovery.

In parallel: the clocks that may already be running

• Legal requirement — NIS2: the reporting timeline begins when the organisation becomes aware of a significant incident under the applicable legal test — not automatically when the first suspicious event is observed. Assess against your documented criteria early: if the test is met, the 24-hour early warning to your CSIRT or authority (in Romania: DNSC) applies.
• Legal requirement — GDPR: if the incident results in a personal data breach, GDPR notification obligations may apply. Notification to the supervisory authority is generally required unless the breach is unlikely to result in a risk to individuals' rights and freedoms. This assessment is separate from the NIS2 significance test.
• Contractual: cyber-insurance policies require prompt notice — and many insist on approving the responders and any negotiation. Call the insurer early, not after decisions are made.
• Good practice: notify law enforcement.

The first-hours checklist

1. Isolate affected systems from wired, wireless, VPN and shared-storage connections; keep them powered on when safe isolation is possible.
2. Record exact times; start an incident log (who did what, when).
3. Restrict access to backup and recovery infrastructure; preserve its logs; no destructive changes without the response team.
4. Preserve ransom notes and filenames, encrypted samples, screenshots where safe, and EDR, firewall, authentication, backup and cloud logs. Delete nothing.
5. Move team communications out-of-band.
6. Protect privileged accounts; stage resets with your responder.
7. Call professional response, your insurer and legal — in parallel, not in sequence.
8. Assess NIS2/GDPR duties against their legal tests; report when the criteria are met.
9. Do not start restoration before containment and recovery planning; do not run random decryptors; do not reconnect isolated devices.
10. Make no contact and no promises to the attackers.

And if this is not a drill: our 24/7 response line — free, and you do not need to be a client.

This is general incident-response guidance, not advice for a specific incident — real attacks differ, and a responder who can see your environment beats any checklist. Legal reporting duties (NIS2, GDPR, sector rules) depend on your situation and jurisdiction.