The first day of a ransomware incident decides how much you lose, how long recovery takes and whether you can later explain what happened. The instinct is to switch everything off and start restoring. Slow down just enough to contain the attack without destroying the evidence you will need.
Hour 0 to 1: contain without destroying evidence
Disconnect affected systems from the network: unplug the cable, disable Wi-Fi, shut the switch port or use your endpoint tool's isolation feature. If several systems or whole subnets look affected, isolate at the switch level rather than machine by machine.
Do not power machines off unless you cannot disconnect them. The CISA #StopRansomware Guide treats power-down as a fallback for devices that cannot be taken off the network, because shutting down destroys evidence held in memory. Do not wipe, reimage or run clean-up tools yet either.
Leave the ransom note and the encrypted files where they are. Take photos of screens showing the note.
Move your communication out of band
Assume the attacker can read your email and chat. CISA recommends out-of-band methods, such as phone calls, to coordinate the response without tipping them off. Set up a phone bridge or a messaging group on devices that were not part of the affected environment.
Name one incident lead. Start a written log with timestamps for every decision and action. You will need it for regulators, insurers and your own post-incident review.
Preserve evidence
Before anything is rebuilt, capture what the investigation will need:
- a disk image and a memory capture from a sample of affected machines, as CISA recommends
- logs from firewalls, VPN, endpoint protection, domain controllers, email and cloud services
- the ransom note, a few encrypted files and the file extension the malware added
Logs on affected systems may have been changed or deleted. The European Data Protection Board warns that a missing log entry does not prove data was not exfiltrated, and recommends forwarding logs to a central server. Export what you have before retention settings overwrite it.
Work out the scope
The encrypted files show where the attack ended, not where it started. CISA advises hunting for earlier-stage malware and for signs of data theft. Try to answer four questions:
- Which systems and data are encrypted or affected?
- Which accounts did the attacker use? Look for new accounts, accounts with newly raised privileges and unusual activity by administrators.
- How did they get in? Check, for example, remote access without MFA, unpatched internet-facing systems and recent phishing emails.
- Was data copied out? Check firewall and proxy logs for large outbound transfers.
The last question decides much of your legal position, so treat any uncertainty as "possibly yes" until you can rule it out.
Reset credentials in the right order
Assume every credential used on, or stored on, an affected system is known to the attacker. Reset from a clean device, never from a machine in the affected network.
Resetting while the attacker still has a foothold can simply hand them the new passwords. CISA's checklist places the full reset after the environment has been cleaned and rebuilt. You may still need an emergency reset of the most powerful accounts earlier, to cut off access. Agree the order with your responders. A sensible sequence is:
- Domain and cloud identity administrators, and any break-glass accounts
- Backup, hypervisor and storage administrators
- Remote access, VPN and firewall administrators
- Service accounts, especially those with broad rights
- In Active Directory, the
krbtgtaccount, twice. Microsoft's forest recovery guidance explains why two resets are needed and how long to wait between them. - All remaining users, with existing sessions and tokens revoked
Check your backups before you rely on them
CISA notes that many ransomware variants look for accessible backups and delete or encrypt them. Before you plan recovery, confirm which backup copies are intact, when the last clean one was taken, and whether you can restore from it.
Restore into an isolated environment first. CISA warns that dropper malware and similar earlier-stage tools must be found before you rebuild from backups. Otherwise you may restore the problem along with the data.
Legal and regulatory clocks
Several deadlines may start the moment you become aware of the incident. They run in parallel.
| Rule | Applies when | Deadline | Report to |
|---|---|---|---|
| GDPR Article 33 | Personal data is affected, unless the breach is unlikely to result in a risk to people | Without undue delay, and where feasible within 72 hours | Data protection supervisory authority |
| NIS2 Article 23 | You are an essential or important entity and the incident is significant | Early warning within 24 hours, notification within 72 hours, final report within one month | National CSIRT or competent authority |
| KVKK (Türkiye) | Personal data processed under Turkish law is affected | Without delay, and at the latest within 72 hours | Personal Data Protection Board |
Ransomware is usually a breach of availability, and often of confidentiality too. In the EDPB's worked examples, an attack with a good backup and no exfiltration may not need notifying, but must still be documented internally under Article 33(5). An attack with no usable backup, or with data stolen, generally must be notified. If people face a high risk, such as stolen identity documents, they must be told as well.
You do not need full answers to meet these deadlines. NIS2 reporting is staged by design, and under GDPR Article 33(4) information can be provided in phases without undue further delay. Also check your cyber insurance policy, which may set its own notification requirements, and report the crime to the police.
To pay or not to pay
The UK NCSC and UK law enforcement do not encourage or condone paying. Payment does not guarantee you get your data back. Your systems will still be infected, and you may become a target again. The No More Ransom project, backed by Europol and the Dutch police, publishes free decryption tools for some ransomware families, so check there first.
Payment can also be unlawful. The US Treasury's Office of Foreign Assets Control (OFAC) has warned that ransomware payments to sanctioned persons can violate US sanctions rules. Civil penalties can apply on a strict liability basis. EU Regulation 2019/796 on cyber-attacks prohibits making funds available to the persons it lists. Any payment decision belongs with management, legal counsel and law enforcement, not with the IT team in the middle of the night.
What not to do
- Do not power off machines unless you cannot isolate them.
- Do not reconnect or restore systems before you know how the attacker got in.
- Do not negotiate with the attacker, or reply to them, without expert and legal advice.
- Do not discuss the incident on company email or chat that may be monitored.
- Do not delete anything, including the ransom note.
Where to start, before it happens
- Print your incident plan and contact list, and keep copies off the network.
- Agree in advance who can authorise taking systems offline.
- Keep at least one backup copy that administrator credentials cannot delete, and test restores.
- Write down your GDPR, NIS2 and KVKK reporting contacts now.
- Line up incident response support before you need it.
If you are dealing with an incident now, our incident response team can help you contain it and work through these steps.
