Hit by ransomware: what to do now, from assessing the damage to restarting the business

Key takeaways

• Containment means disconnecting, not deleting. Take systems off the network but rebuild nothing while the picture is unclear — otherwise you lose the evidence.
• Communicate outside the affected environment. If the attackers are still in the network, they are reading along.
• Establish first which backup state is demonstrably clean. Everything else follows from that.
• Emergency operation and recovery are two separate jobs and need two separate teams.
• Restore in dependency order, not in order of which department shouts loudest.
• Reporting duties run in parallel: where personal data is affected, a 72-hour deadline towards the supervisory authority applies.
• The ransom question is a legal and commercial decision — never one made spontaneously in the middle of the night.

The first hours: contain without destroying evidence

The first reflex is usually right and the second one dangerous. Right is to disconnect affected systems immediately so the encryption cannot spread further. Dangerous is to start cleaning up straight afterwards: rebuilding systems, formatting drives or deleting logs destroys exactly the information you will need over the coming days — to understand how the attackers got in, how long they were there, and whether they still are.

Disconnecting also means disconnecting properly: backup systems, cloud connections and site-to-site links included. While it is unclear which accounts were taken over, every connected system is a possible next target — and that explicitly includes the backups.

Just as important and often overlooked: move communication out of the affected environment. If attackers still have access, they read the emails and chats in which you coordinate your response. A separate channel — personal devices, a freshly set-up service, the telephone if need be — is not excessive caution at this stage.

• Take affected systems off the network but leave them powered on where that helps forensics
• Disconnect backup systems and cloud connections as well
• Rebuild nothing, format nothing, delete no logs
• Switch to a communication channel outside the affected environment
• Keep a written record from the first minute: who established and did what, and when

Step 1: Establish the damage

Before anything is restored, it has to be clear what is actually affected. This assessment is often cut short because everyone wants to get running again — and it comes back later, when an overlooked system reinfects the freshly cleaned environment.

Four questions matter: which systems are encrypted, which merely affected, and which untouched? Which accounts were taken over, particularly those with far-reaching rights? Since when have the attackers been in the network — that point in time determines which backup states can still be trusted? And was data exfiltrated before the encryption?

The last question tends to be pushed aside but decides everything that follows. An outflow of personal data triggers reporting duties and cannot be undone by any restore. Indications come from unusual outbound data volumes in the firewall logs — one more reason not to delete those logs.

• Inventory: encrypted, affected, untouched — per system, not per department
• Identify compromised accounts, especially administrator and service accounts
• Narrow down the time of initial intrusion, not the time of encryption
• Check whether data was exfiltrated, and which
• Establish whether personal data is affected — that starts the 72-hour clock

Step 2: Check the recovery options

This is where the preparation shows its worth. The guiding question is not whether backups exist but which state is demonstrably clean — that is, predates the initial intrusion and was itself unreachable while the attackers held administrator rights.

Check the states in this order: first copies held offline or immutable, then off-site backups, then anything that was reachable from the production network. The last is frequently unusable in a real incident because it was encrypted or deleted along with everything else. Note too that a backup dated after the initial intrusion can contain the attackers' tooling. Restoring it means restoring their access with it.

Every usable state comes with two numbers: how old it is — how much work has to be redone — and how long it takes to restore. Only those two numbers turn a backup into an option you can decide about.

• Which state safely predates the initial intrusion?
• Was that state technically unreachable during the attack?
• How much data loss does it mean, measured in working days?
• How long does restoring it realistically take — measured, not estimated?
• Are directory services, certificates and licences included in that state?

Step 3: Emergency operation — what has to keep running

Recovery almost always takes longer than the business can stand still. So a second task runs in parallel: keeping operations going in makeshift form while IT is rebuilt. Having the same people do both at once is the most common organisational mistake in this situation.

The starting point is a sober prioritisation: which processes have to run over the next few days so the company can still deliver, still pay, and still meet its deadlines? Usually fewer survive that test than were initially claimed — goods in and out, order intake, payroll on its due date, production in progress.

Those few processes need workarounds, and they are allowed to be inelegant: paper lists, isolated standalone PCs, a separate mailbox with an external provider, orders taken by phone. What matters is only that everything created during emergency operation is captured so it can be posted later. Otherwise the problem simply moves into the period after the restart.

Communication is part of emergency operation too. Customers, suppliers and staff will notice the outage regardless. Early, factual information about what works and what does not costs less trust than days of silence.

Step 4: Plan the restart

Restore in dependency order, not in order of which department shouts loudest. Without network, directory services and name resolution nothing else starts meaningfully; without the database no ERP; without ERP no order processing. Writing that chain down once, before the first server is touched, saves more time than any speed-up in an individual step.

Second principle: rebuild clean rather than clean up. A system that was compromised is reinstalled and the data restored from a verified state — not the other way round. That applies particularly to directory services, which in a successful attack were regularly under the attackers' full control.

Before systems are reconnected, access has to be renewed: reset passwords, enable multi-factor authentication, remove unnecessary accounts, close or secure remote access. And the gap the attack came through must be closed — otherwise the incident repeats, which happens more often in practice than it should.

Plan an observation phase as well. The first weeks after the restart are when it becomes clear whether everything really was removed. Heightened attention to logins, outbound traffic and newly created accounts belongs to normal operation during that period.

• Write down the dependency chain before touching the first server
• Reinstall compromised systems rather than cleaning them
• Renew all credentials and enable multi-factor authentication
• Close the entry point before systems go back on the network
• Have restored data checked by the business, not only technically
• Plan an observation phase of several weeks

The ransom question

This decision is often made at night under pressure, and that is exactly what it should not be. The German Federal Office for Information Security and law enforcement advise against paying, and the reasons are practical: payment guarantees neither a working decryption key nor the deletion of exfiltrated data, it funds the next wave of attacks, and it marks the company as willing to pay — repeat attacks are documented.

On top of that come legal risks that must be clarified before any consideration: payments to sanctioned individuals or groups are not permitted, and depending on the circumstances further criminal and regulatory questions arise. This is not a topic for the IT department but for legal counsel and the management board.

If the question is nevertheless seriously on the table — typically because no usable backup state exists, or because publication of sensitive data is being threatened — then it belongs in an ordered framework: management, legal counsel, the cyber insurer where applicable, and law enforcement are involved. In Germany, businesses can turn to the Central Cybercrime Contact Points of the state criminal police offices, which advise confidentially. Contact with the attackers themselves belongs with specialised providers, not with your own staff — insurers usually make that a condition anyway.

Whatever the outcome: even those who pay have to rebuild afterwards. A decryption tool restores files, but it removes neither the attackers' access nor the root cause. The work in step 4 arises either way.

Reporting duties and who to involve

Deadlines run in parallel with the technical work and do not wait for the restart. Where personal data is affected, the incident must generally be reported to the competent data protection supervisory authority within 72 hours of becoming aware of it. Where there is a high risk to the individuals concerned, notifying them is added. The clock starts with knowledge of the incident, not with the completion of the investigation — an initial report with a provisional picture is explicitly foreseen.

Independently of that, filing a criminal complaint is sensible and is regularly expected by insurers. Operators of critical infrastructure and companies covered by the extended network and information security rules have additional and sometimes shorter reporting duties. Which of these apply to your company should be settled in advance rather than researched during the incident.

The list of parties also includes the data protection officer, the cyber insurer — many policies require immediate notification and the use of named providers — and, depending on the contracts, customers whose data may be affected. The specific legal assessment belongs in expert hands in every case.

• Data protection authority: generally within 72 hours where personal data is affected
• Notify affected individuals where there is a high risk to them
• File a criminal complaint and contact the Central Cybercrime Contact Point
• Involve the cyber insurer immediately — mind deadlines and mandated providers
• Have the data protection officer and legal counsel involved from the outset

Frequently asked questions

Should we switch off the affected machines?

Disconnect from the network yes, power off only with care. Memory can hold information that is valuable for the investigation and is lost on shutdown. If encryption is visibly still running, however, stopping the damage takes priority. When in doubt: pull the network cable or disable Wi-Fi, leave the device powered on, and bring in expert support.

Can we simply restore the backup and carry on?

Only if two conditions hold: the state predates the initial intrusion, and the entry point is closed. Restoring a backup created after the break-in brings the attackers' tooling back with it. And if the original gap is not closed, the incident repeats — often within weeks.

How long does recovery realistically take?

That depends almost entirely on whether a clean backup state exists and whether the restart has ever been rehearsed. Companies with offline backups and a documented procedure talk in days. Companies assembling both for the first time during the incident talk in weeks — and in some cases about systems that never fully come back.

Do we really have to report the incident if nothing was exfiltrated?

The duty to report is not tied to exfiltration alone. The loss of availability of personal data — which is exactly what encryption causes — can also constitute a reportable breach. Whether a report is required depends on assessing the risk in the specific case; make that assessment with your data protection officer or legal counsel rather than on your own.

Should we communicate with the attackers?

Not on your own initiative. Any contact has legal and insurance consequences and shapes the situation that follows. If communication happens, it goes through specialised providers and is coordinated with management, legal counsel, the insurer and law enforcement. Spontaneous replies from inside the company regularly worsen the position.