A staff member calls. Files will not open. There is a note demanding payment. What you do in the next sixty minutes decides whether this is an inconvenience or a company-ending event.
First: do not reboot, and do not pay
Rebooting can trigger encryption routines that were waiting for a restart, and it destroys the memory-resident evidence you need to find out how they got in. Paying is not a fix — it funds the next attack and there is no guarantee of a working decryption key.
The sequence
- Disconnect the network, not the power. Pull the network cable or disable Wi-Fi on affected machines. This stops the spread without losing memory.
- Tell people to stop working and not to plug anything in. Include remote staff. A laptop that reconnects can reinfect a cleaned network.
- Identify the blast radius. Which shared drives, which servers, which accounts? Write it down with timestamps.
- Preserve the evidence. Do not wipe anything yet. Logs, ransom notes, and affected file listings matter later — for insurers, regulators and for understanding the entry point.
- Check your backups are actually intact. This is the step that determines your outcome. Verify they were not connected when the attack hit.
- Notify. Insurer, legal counsel, and — if personal data is involved — the relevant privacy authority. Do this early; deadlines are strict.
- Rebuild rather than clean. Restore from a known-good backup onto clean systems, then change every credential.
The mistake that ends companies
Backups that are online and reachable from the network get encrypted too. An attacker with domain administrator rights will find your backup server. This is the single most common reason a business cannot recover.
A backup that the attacker can reach is not a backup. It is a second copy of the problem.
The fix is a 3-2-1 arrangement with at least one copy that is offline or immutable — physically disconnected, or written to storage that cannot be altered or deleted for a fixed retention period.
| Copy | Where | Survives ransomware? |
|---|---|---|
| 1 | Local server or NAS | Only if unplugged during the attack |
| 2 | Cloud or second site | Only if credentials are not domain-linked |
| 3 | Offline or immutable | Yes — this is the one that saves you |
Test the restore, not the backup
A backup job that reports “success” proves the file was written. It does not prove the file can be restored. The only meaningful test is restoring to a clean machine and opening the data.
Do this quarterly. Choose a random file, a folder, and a whole system. Time it. If you cannot restore a single folder on a calm Tuesday, you will not restore an entire company during an incident.
Afterwards, answer one question
How did they get in? Almost always it is one of a short list:
- A password reused from another breached site, with no multi-factor authentication.
- An unpatched internet-facing device — VPN, firewall, mail gateway.
- A staff member who opened an attachment or approved a fake login prompt.
- A remote-access tool left open with weak credentials.
Fix that specific door. Buying more tools without fixing the entry point just means paying for the same lesson twice.
Want your backups and recovery tested before you need them? Talk to a specialist.