Ransomware Incident: What to Do in the First 24 Hours?

Isolate, do not power off. Disconnect affected systems physically or logically: unplug network cables, disable Wi-Fi, block affected VLANs or switch ports. The goal is to stop lateral movement and further encryption before it reaches additional servers, file shares, and backups.

Avoid hard-shutting down infected machines where possible. Powering off destroys volatile evidence in memory that is valuable for forensics - such as encryption keys, active processes, or clues about the entry point. If a system cannot be isolated and encryption visibly continues, powering off is justifiable as a last resort; document the time and the reason.

Next, disconnect backup systems from the production network unless they are already offline or immutable. Attackers deliberately target backups to make recovery impossible. Do not alter any data on the affected systems and do not delete anything - including the ransom note.

Form a small, capable crisis team immediately instead of a large meeting. A typical setup: IT management as technical incident lead, executive management for high-impact decisions, one person for documentation and communication, and - as soon as personal data may be affected - the data protection officer. Assign one central decision-maker so that people do not act in contradiction.

Activate external support early. This includes your IT service provider or incident-response partner, specialized forensics if needed, and your cyber insurer if you have one. Many cyber policies require immediate notification and provide their own crisis responders; unauthorized recovery before clearance can jeopardize coverage.

Decide promptly whether to file a criminal complaint. In Germany, the Central Cybercrime Contact Points (ZAC) of the state criminal police offices are the right point of contact for affected companies. Document everything from the first minute: time of discovery, affected systems, actions taken, and responsible persons. You will need this timeline later for authorities, insurers, and the data protection regulator.

Do not make this decision in shock or in the first few hours. Authorities such as Germany's BSI generally advise against paying. Payment does not guarantee full or error-free decryption, funds criminal structures, and marks your company as a known, willing target for follow-up attacks.

Payment can also be legally sensitive, for example if the attacker group is on a sanctions list. Before any consideration of payment, review the legal and liability situation together with legal counsel and your insurer. Negotiations, if at all, are handled by experienced incident-response specialists - not the stressed internal team.

The better lever is preparation: with current, tested backups that are separated from the production network, you can render the extortion ineffective in most cases and recover without paying. This is exactly why yesterday's backup strategy determines today's negotiating position.

Forensics answers the decisive questions: how did the attackers get in, how long were they in the network, which data was accessed or exfiltrated, and is the access truly closed? Without these answers, you risk restoring a still-compromised system and triggering encryption all over again.

Preserve evidence before you clean up or rebuild. This includes forensic images of affected systems, relevant log files from servers, firewalls, VPN, and directory services, plus the ransom note and samples of encrypted files. Logs are often retained only briefly - secure them early before they are overwritten.

This is where continuous monitoring proves its worth: if systems and network traffic are logged comprehensively and anomalies are watched anyway, the attack timeline can be reconstructed much faster. Treat compromised credentials as burned: reset passwords, disable suspicious accounts, and renew affected keys and certificates.

From a data protection perspective, a ransomware incident is almost always a personal data breach - if only because encryption impairs the availability of the data. This triggers Art. 33 GDPR: if the breach is likely to result in a risk to the rights and freedoms of individuals, you must notify the competent supervisory authority without undue delay, where feasible within 72 hours of becoming aware.

The 72-hour clock starts when you become aware of the breach - not only once forensics is complete. You may file a notification even when not all details are known; missing information can be provided in stages. When in doubt, notifying is the safer path, as a failure to report can result in fines.

If a high risk to individuals is also likely - for example after the exfiltration of sensitive HR data - notification of the affected individuals under Art. 34 GDPR is added. Involve the data protection officer early and document the risk assessment. In parallel, check whether reporting duties under other frameworks apply, such as NIS2 or sector-specific rules.

Only begin recovery once two conditions are met: the entry vulnerability is closed and the network is clean, and the backups are verified as not infected. Restoring into a still-compromised environment will just encrypt everything again. Where possible, rebuild on freshly hardened infrastructure that is separated from the old network.

Prioritize by business criticality rather than restoring everything at once. Define in advance which systems must run first (for example directory services, ERP, central file shares) and which RPO and RTO targets apply. Restore from a clean, ideally immutable or air-gapped backup point - not from the most recently available one, which may already be encrypted.

What matters is that recovery was rehearsed beforehand. In an anonymized case we supported, a mid-sized company was operational again after roughly four hours - made possible by separated, immutable backups and a regularly tested restore process. A backup that has never been restored is an assumption, not a safety net. These tested restore plans are a core part of our work in data protection and IT monitoring.

Once the acute phase is over, the follow-up begins. Complete the forensics, document the full incident timeline, and provide outstanding information to the supervisory authority and your insurer. Only then is the situation under control - not with the first server back online.

Derive concrete hardening measures from the incident: multi-factor authentication for all external access, consistent network segmentation, timely patching of exposed systems, immutable offsite backups, and a regularly tested recovery plan. Capture the findings in a written emergency plan that is accessible without working IT - for example printed out with the most important contact numbers.

The most effective time for all of this is before the incident. A rehearsed escalation chain, tested backups, and continuous monitoring shorten the critical first hours from days to hours. This preparation is exactly what separates companies that resume work within a day from those that stand still for weeks.