Ransomware Attack: Immediate Response, Communication, and Recovery

When suddenly nothing works anymore

The screen displays a message no IT manager ever wants to see: "Your files have been encrypted. Pay 5 Bitcoin within 72 hours or your data will be published." Accounting reports that no files can be opened. The ERP system is unresponsive. Phone calls from departments are piling up.

Ransomware attacks are among the most destructive cyberattacks an organization can experience. They encrypt data, paralyze business processes, and put those affected under massive time pressure. At the same time, attackers increasingly threaten to publish stolen data, adding a data protection dimension to an already critical situation.

The good news: how well an organization survives a ransomware attack depends less on whether it gets hit than on how it responds. And this response can be prepared, trained, and largely automated. The bad news: anyone who only starts thinking about the right steps during the actual emergency loses valuable time and makes avoidable mistakes.

This article walks you through the entire process: from the first minutes after discovery through communication with all stakeholders to recovery and forensic analysis. It is based on recommendations from the BSI and BKA and is structured so you can directly incorporate the content into your incident response plan.

The first 30 minutes: immediate response

The first minutes after discovering a ransomware infection are the most critical. In this phase, the course is set: does the encryption continue to spread or is it contained? Are forensic evidence preserved or accidentally destroyed? Does panic ensue or is action taken in a structured manner?

Step 1: Disconnect affected systems from the network

The very first measure is network disconnection of the affected systems. Pull the network cable, disable WiFi, disconnect VPN connections. The goal is simple: stop the attacker's lateral movement and prevent the encryption from spreading to additional systems, network drives, and backup storage.

An important rule applies: disconnect the network, but do not shut down the systems. The volatile memory (RAM) often contains information valuable for forensic analysis — such as the encryption key still in working memory, or traces of the malware that would be lost after a reboot. An affected computer that is disconnected from the network but still running is far more valuable to forensic analysts than one that has been shut down.

If you operate a segmented network, disconnect the affected segments selectively. If not, a complete network disconnect is often the safer option, even if it means that nothing works in the short term. A controlled interruption is better than uncontrolled spread.

Step 2: Secure evidence

Before anyone starts cleaning up or restoring systems, evidence must be secured. In a crisis, this may sound like a luxury you cannot afford, but it is the opposite: without evidence preservation, you can neither identify the root cause nor determine the scope of compromise, and you have nothing in hand should criminal prosecution follow.

Specifically, this means:

• Screenshots of the ransomware message (ransom demand, Bitcoin address, attacker contact details)
• RAM dumps of affected systems where possible (tools like FTK Imager or WinPmem)
• Log files from affected systems and network infrastructure (firewall logs, AD logs, email logs)
• Timestamps — document: when was the attack noticed? When was what disconnected? Who decided what?
• Encrypted files — secure them, do not delete them. Decryption tools exist for some ransomware variants, but they need the encrypted files as input

Evidence preservation does not need to be perfect. Proceed systematically and document what you do — that is sufficient as a foundation.

Step 3: Activate the crisis team

Ransomware is not purely an IT problem. It affects business operations, communications, data protection, and possibly contractual obligations toward customers. Therefore, handling it does not belong solely in the hands of the IT department but in those of a crisis team.

The crisis team should be defined in advance and documented in the emergency plan. Typical members:

• IT management or ISO: Technical coordination, damage assessment
• Executive management: Decision-making authority for far-reaching measures (e.g., complete shutdown, engaging external service providers)
• Data protection officer: Assessment of whether personal data is affected, coordination of reporting obligations
• Communications/PR: Managing internal and external communication
• Legal department or external counsel: Legal assessment, reporting obligations, insurance matters
• External incident response provider: If internal forensic expertise is insufficient

Convene the crisis team, brief them on the situation, and distribute tasks. From this moment on, every decision should be documented: who, what, when, why. This documentation is important not only for later analysis but also for communication with authorities and insurers.

What you should NOT do in the first 30 minutes

Equally important as the right measures is avoiding certain mistakes:

Do not pay the ransom. This is the official recommendation from the BSI, BKA, and virtually all security authorities worldwide. Payment finances criminal structures, there is no guarantee you will receive a functioning decryption key, and you signal that you are willing to pay — making you an attractive target for future attacks. In exceptional cases — for instance, when lives are at stake or the business's existence is threatened — the decision may differ. But this decision is made by executive management after careful deliberation, not by the IT department under the stress of the first hour.

Do not negotiate on your own. If executive management considers negotiation, leave it to specialized incident response firms experienced in communicating with ransomware groups.

Do not hastily reformat. The impulse is understandable but fatal: you destroy forensic evidence and cannot trace how the attacker entered the network. As long as the root cause is unknown, there is a risk of re-compromise through the same path.

Do not communicate through compromised channels. If the attacker has access to the email system, use alternative channels: mobile phones, encrypted messengers, in-person conversations.

Communication plan: who learns what and when

Communication during a ransomware incident is at least as important as the technical response. Poor communication creates uncertainty, rumors, and loss of trust. Good communication creates clarity and enables coordinated action.

Level 1: Internal crisis team (immediately)

The crisis team is informed first and receives all available facts: what is affected? Since when? What measures have already been taken? This communication is factual and complete. The goal is to establish a common situational picture.

Level 2: Executive management (within the first hour)

Executive management must be informed promptly because they have decision-making authority for far-reaching measures. Prepare a brief briefing: what happened? What is the current status? What does the crisis team recommend? What decisions are pending? Avoid technical jargon and focus on the business impact.

Level 3: Employees (within the first hours)

Inform employees promptly and honestly. They notice anyway that something is wrong when systems are not working. Open communication prevents rumors and provides clear guidance: which systems must no longer be used? How does work continue in the interim? Whom can they contact with questions?

A proven formulation: "We have identified an IT security incident and are working to resolve it urgently. Please do not use network drives until further notice and do not log into [affected systems]. We will keep you regularly informed of progress."

Level 4: Authorities (within the statutory deadlines)

Reporting obligations are clearly defined and non-negotiable. More detail follows shortly.

Level 5: Customers and partners (once the scope is known)

When customer data is affected or delivery capability is impaired, customers and partners must be informed. Do not wait until you have all the details. An early, honest communication noting that the investigation is still underway is better than silence that may be interpreted as a cover-up.

Level 6: Public (only if necessary)

Not every ransomware incident needs to be publicly communicated. But if the incident becomes public — because customers are affected or the attackers publish data — you need a prepared statement. Have the communication written by someone with PR experience, not the IT department.

Reporting obligations: NIS2 and GDPR

Ransomware attacks trigger statutory reporting obligations in most cases. The deadlines are tight and begin from the moment the incident is recognized — not from the moment the investigation is complete. It is therefore critical to have the reporting processes prepared and not to look up which form to submit where only during an actual emergency.

NIS2 reporting obligation to the BSI

If your organization falls under the NIS2 directive, you are obligated to report significant security incidents to the BSI. A ransomware attack typically meets the threshold of a significant incident, particularly when business operations are impaired.

The NIS2 reporting deadlines are staggered:

• Early warning within 24 hours: An initial notification with basic information, even if the full scope is not yet known. The goal is to enable the BSI to warn other potentially affected organizations.
• Incident notification within 72 hours: A more detailed notification with an initial assessment of the incident, its severity, and the countermeasures taken.
• Final report within one month: A complete report with root cause analysis, impact assessment, and measures taken.

Prepare the notification as soon as the crisis team is assembled. Tools like ISMS Lite generate the BSI initial notification directly from the captured incident data, so you do not start from scratch within the 24-hour deadline. Do not wait until you have all details. The early warning may and should be incomplete. An early, supplementable notification is better than a late, complete one.

DSGVO (GDPR) reporting obligation to the data protection authority

When personal data is affected by the ransomware attack — meaning encrypted, stolen, or published — a data breach within the meaning of the GDPR has occurred. The reporting obligation to the competent data protection authority applies within 72 hours of becoming aware of the breach.

The notification must contain:

• Nature of the breach (encryption, exfiltration, publication)
• Categories and approximate number of affected individuals
• Contact details of the data protection officer
• Likely consequences of the breach
• Measures taken and planned

Additionally, notification of affected individuals may be required when there is a high risk to their rights and freedoms. With ransomware involving data exfiltration, this is regularly the case.

Criminal complaint to the BKA or police

Filing a criminal complaint is not mandatory but is expressly recommended by the BSI and BKA. The Central Contact Point for Cybercrime (ZAC) of your federal state is the right contact. The complaint has several advantages: it enables cooperation with law enforcement, can help identify the attackers, and is often a prerequisite for cyber insurance benefits.

Notifying the cyber insurer

If you have a cyber insurance policy, notify the insurer immediately. Most policies have tight notification deadlines and obligate you to take (or refrain from) certain measures. In particular, a ransom payment without coordination with the insurer can lead to loss of insurance coverage.

Recovery from backups

After the immediate response is complete, communication is underway, and reporting obligations have been met, the actual recovery begins. The goal: bring business-critical systems back online as quickly as possible without letting the attacker back into the network.

Before recovery: verify backup integrity

The most common mistake during ransomware recovery is assuming the backups are clean. Professional attackers specifically target backup systems — either by encrypting the backups themselves or by embedding backdoors that reactivate after recovery.

Before restoring a backup, clarify the following questions:

• When did the compromise begin? Most attackers move undetected in the network for weeks or months before triggering encryption. The average dwell time is 10 to 21 days but can extend to several months. Backups created within this timeframe may be compromised.
• Are the backup systems themselves affected? Check whether the attacker had access to the backup infrastructure. Offline backups and air-gapped backups are invaluable in this situation.
• Are there immutable backups? Backup solutions with WORM storage (Write Once, Read Many) provide additional protection since data cannot be altered after writing.

When in doubt, restore the backup into an isolated environment and scan it for malware before transferring it to the production environment.

Prioritizing the recovery

Not all systems need to be restored simultaneously. Create a prioritized list based on the business impact analysis:

Priority 1: Infrastructure foundations Active Directory, DNS, DHCP, authentication systems. Without these, nothing else works. Ensure the AD database was not compromised — specifically that no new admin accounts were created or group policies manipulated.

Priority 2: Business-critical systems ERP, email, customer database, financial systems. The systems without which the organization cannot generate revenue.

Priority 3: Important systems File servers, intranet, project management tools. Systems that enable daily work but can be temporarily replaced by workarounds.

Priority 4: All remaining systems Secondary applications, test systems, non-critical services.

Secure recovery environment

Do not restore systems into the same network where the attack occurred as long as the root cause has not been identified and remediated. Build a clean recovery environment, ideally in a separate network segment, and migrate the systems to the production environment only after the entry point has been closed.

During recovery, change all credentials: administrator passwords, service accounts, API keys, certificates. Assume that the attacker had access to all credentials that were stored or used on the compromised systems.

Data recovery as a last resort

If no clean backups are available, there are still two options: first, recover data from the encrypted files. For some ransomware variants, free decryption tools exist, for example through the "No More Ransom" initiative (nomoreransom.org). Second, engage data recovery firms specializing in recovering encrypted data. Both options offer no guaranteed success but are worth trying before writing off data as permanently lost.

Forensic analysis: understanding the attack

In parallel with recovery or directly afterward, a forensic analysis must be conducted. The goal is threefold: first, identify the attack path so the entry point can be closed. Second, determine the scope of compromise to know which data is affected. Third, secure evidence for potential criminal prosecution.

Typical entry points for ransomware

The forensic analysis initially focuses on the most likely attack vectors:

Phishing emails: An employee clicked a link or opened an attachment that loaded the initial malware. Check email logs for suspicious messages in the period before the attack.

Exposed remote access: RDP servers, VPN access, or other remote access services reachable via the internet that were compromised through weak or stolen credentials. Check authentication logs for unusual access.

Unpatched vulnerabilities: Known security flaws in VPN gateways, web servers, or other exposed systems for which no patch was applied. Compare the patch status of your systems with vulnerabilities known at the time of the attack.

Compromised supply chain or stolen credentials: Malware via legitimate software updates or credentials obtained through data leaks or social engineering.

Scope of compromise

The forensic analysis must clarify:

• Which systems were affected — only the encrypted ones or others as well?
• Did the attacker have access to Active Directory or other central systems?
• Was data exfiltrated (copied and stolen) or only encrypted?
• Which accounts were compromised?
• How long was the attacker active in the network?

This information is relevant not only for technical remediation but also for notifications to authorities and affected individuals.

External forensic support

If you do not have internal forensic expertise, engage an external incident response provider. The costs are significant, but the alternative — recovering without root cause analysis and potentially having the attacker back in the network — is more expensive. Many cyber insurance policies cover the costs of external forensics. Clarify this early with the insurer.

Lessons learned: learning from the incident

After the acute incident has been managed, systems are restored, and normal operations resume, the perhaps most important phase begins: structured post-incident review. Every ransomware attack contains valuable information about where the weaknesses lay and how the organization can better protect itself.

The lessons-learned workshop

Plan a workshop with all persons involved in the incident. Conduct it promptly — ideally within two weeks of completing the recovery — while memories are still fresh. The workshop is not about assigning blame but about factual analysis.

Guiding questions for the workshop:

• How was the attack discovered? Through technical systems (SIEM, EDR) or by an employee? Could it have been discovered earlier?
• How quickly was the response? Were the immediate measures taken promptly and correctly? Where were there delays?
• Did the emergency plan work? Was it complete? Current? Was it followed? Where were there gaps?
• Did communication work? Were the right people informed in time? Were there communication problems?
• Were the backups sufficient? Were they complete, current, and clean? How long did recovery take?
• What measures could have prevented the attack? What was missing in terms of prevention?

Deriving an action plan

From the workshop findings, derive concrete measures. Prioritize these measures, assign responsibilities, and set a timeline. Typical measures after a ransomware incident:

• Introduce or improve network segmentation
• Multi-factor authentication for all remote access and admin accounts
• Revise backup strategy (offline backups, immutable storage, regular restore tests)
• Accelerate patch management
• Strengthen email security (SPF, DKIM, DMARC, sandboxing)
• Introduce or configure EDR/XDR solution
• Employee training on phishing and social engineering
• Update incident response plan
• Introduce regular incident response exercises

Updating the emergency plan

The incident response plan used during the incident must be updated after the lessons-learned workshop. Every identified gap, every process that did not work, every outdated contact list is corrected. The updated plan is then communicated to the crisis team and tested again in the next quarter.

Prevention: so the next attack fails

Ransomware prevention is not a single product or a single measure. It is a combination of technical, organizational, and human protection layers that together reduce the probability and impact of a successful attack.

Technical protective measures

Backup strategy following the 3-2-1-1 rule: Three copies of data, on two different media, one copy offsite, one copy offline or immutable. The last "1" is the lesson from the ransomware waves of recent years: a backup the attacker cannot reach is the last line of defense.

Network segmentation: Separate critical systems, admin networks, and production environments from each other so an attacker cannot move freely through the network after the initial compromise.

Patch management: Keep all systems up to date, especially exposed services like VPN gateways and email servers. Many ransomware attacks exploit known vulnerabilities for which patches have long been available.

Endpoint Detection and Response (EDR): Modern endpoint protection detects suspicious behavior like mass encryption in real time and can stop an attack in its early stages.

Email security: SPF, DKIM, DMARC, and an email gateway with sandbox analysis form the first line of defense against phishing emails with ransomware payloads.

Privileged access management: Separate admin accounts, least privilege principle, and MFA for all privileged access prevent a single compromised account from leading to total damage.

Organizational protective measures

Incident response plan: Create a plan that describes immediate measures, communication, escalation paths, and recovery. Test it regularly in tabletop exercises.

Business continuity plan: Define how the organization can continue operating during a total IT outage — which processes can run manually and how long the organization can hold out.

Cyber insurance: Review your policy carefully and ensure ransomware is explicitly covered. Many policies cover forensics costs, business interruption, and legal advice.

Human protective measures

Security awareness training: Regular training on phishing and social engineering as a continuous program with phishing simulations and a culture where reporting is actively encouraged.

Establishing reporting processes: The reporting path must be simple, low-barrier, and free of consequences. Every reported suspicious email is an early warning signal that can stop an attack in its early stages.

Checklist: ransomware emergency plan at a glance

To close, a compact checklist you can use as the basis for your own emergency plan:

First 30 minutes:

• Disconnect affected systems from the network (do not shut down)
• Secure evidence (screenshots, RAM dumps, logs)
• Activate the crisis team
• Use alternative communication channels
• Do not pay ransom, do not negotiate on your own

First 24 hours:

• Send NIS2 early warning to the BSI (if applicable)
• Brief executive management
• Inform employees
• Contact cyber insurer
• File criminal complaint with ZAC
• Assess scope of compromise

72 hours:

• GDPR notification to data protection authority (if personal data is affected)
• NIS2 incident notification to BSI
• Start forensic analysis or engage external forensics
• Verify backup integrity
• Determine recovery order

First week:

• Restore critical systems
• Change all credentials
• Identify and close entry point
• Inform affected customers and partners
• Manage customer and supplier communication

Within one month:

• NIS2 final report to BSI
• Conduct lessons-learned workshop
• Derive and prioritize action plan
• Update emergency plan
• Implement security measures

When it happens, a prepared and tested emergency plan makes the difference between a controlled crisis and an existentially threatening catastrophe. Prepare while you have the calm to do so.

Further reading

• Sicherheitsvorfälle erkennen und melden: Der richtige Prozess
• NIS2-Erstmeldung ans BSI: So gelingt die fristgerechte Meldung
• Backup-Strategie und Restore-Tests: Deine letzte Verteidigungslinie
• Incident-Response-Plan erstellen: Vom leeren Dokument zum funktionierenden Prozess
• Phishing Detection and Reporting: A Practical Guide for Employees and IT