Guidance
Hit by ransomware? What to do, and what not to
The first few hours shape everything that follows — how much you recover, what you can prove afterwards, and whether you meet the notification deadlines that have already started running. Most of the expensive mistakes are made quickly and with good intentions.
If this is happening right now
- 1Disconnect affected machines from the network — pull the cable, disable Wi-Fi. Do not power them off yet (see step 1).
- 2Stop using the compromised network to talk about it. Phones, personal accounts, a different network.
- 3Tell one person to own the timeline and write down what happened and when, starting now.
- 4Call your cyber insurer or incident-response retainer before you change anything else. Many policies require it, and they have done this before.
Contain, without destroying what you need later
Isolation and shutdown are not the same thing, and the difference matters.
Disconnect from the network rather than powering off
Encryption is usually finished long before anyone notices. Powering off throws away the contents of memory — encryption keys are sometimes recoverable there, and so is most of the evidence about how they got in. Isolating stops spread and keeps that.
Power off only when encryption is visibly still running and you cannot isolate
This is the one case where the trade goes the other way. It is a judgement call under pressure; NCSC and CISA both accept it, and both prefer isolation where it is possible.
Isolate backups immediately, before anything else touches them
Modern intrusions target backups first and encrypt or delete them deliberately, precisely so this decision is not available to you. Disconnect them even if they look fine.
Disable remote access at the perimeter — VPN, RDP, management interfaces
Assume the route in is still open and still being used. Closing it is not remediation, but it buys the hours you need.
Preserve logs before anything rotates them out
Firewall, VPN, authentication, EDR. Default retention is often days, and the useful window is usually longer than that.
What not to do
Each of these is common, understandable, and expensive.
Do not wipe and rebuild before anyone has looked
It destroys the only record of how they got in. Rebuild onto the same unpatched weakness and you will be doing this again — reinfection within weeks is ordinary, not unlucky.
Do not restore from backup until you know the intruder is out
Restoring into a network somebody still controls gets the restored systems encrypted too, and burns the backup in the process. Establish access is closed first.
Do not discuss it over the compromised network
Email, chat and file shares should be assumed readable. Negotiating or planning where they can watch has cost organisations a great deal of leverage.
Do not pay in the first few hours
It is not a decision to take while frightened and under-informed. Nothing about it gets harder by waiting a day, and section 05 covers what it does and does not buy.
Do not contact the group yourself
Anything you say sets expectations and reveals what you know. If it comes to that, it is a job for people who do it regularly, alongside your legal advisers.
Do not try to break in to their infrastructure
It is illegal in most jurisdictions regardless of provocation, and it will not help.
Do not announce a scope you have not established
A statement that says less than it later turns out to be true is far more damaging than one that says little. Say what you know and when you will say more.
Do not assume nothing was taken because nothing was encrypted
Exfiltration frequently happens days or weeks before anything locks, and some groups now steal without encrypting at all. Encryption is the ransom note, not the whole event.
The first day
Once the bleeding has stopped, the questions become scope and obligation.
Establish what was taken, not just what was locked
Outbound volume in firewall and proxy logs is usually the first honest signal. If a group names you on a leak site, treat exfiltration as established regardless of what they show.
Reset credentials from the top down, after containment
Domain administrators, service accounts, anything cached on a compromised machine. Doing this before you have closed the route in simply tells them to move.
Identify the strain and check whether a free decryptor exists
A minority of families have recoverable flaws or seized keys. The No More Ransom project publishes free decryptors and costs nothing to check.
Work out which clocks are already running
Notification deadlines start from awareness, not from resolution. See section 04.
Keep one written timeline, in one place, off the affected network
Insurers, regulators and lawyers will all ask for the same sequence of events. Reconstructing it three weeks later from memory is miserable and unconvincing.
Who to tell, and how long you have
These obligations are jurisdictional and sector-specific. This is orientation, not legal advice — confirm your own position with your advisers.
| Who | When | Note |
|---|---|---|
| Your cyber insurer | Immediately | Policies commonly require notification before you engage anyone or change systems. Acting first can affect cover. |
| Data protection regulator | 72 hours under UK/EU GDPR | From becoming aware, where personal data is affected. Partial notification on time beats a complete one late. |
| National cyber authority | As early as practical | NCSC in the UK, CISA and the FBI's IC3 in the US, your national CERT elsewhere. Reporting is generally free and does not oblige you to act on their advice. |
| Law enforcement | Early | Action Fraud in the UK, the FBI in the US. Relevant to sanctions questions if payment is ever discussed. |
| Affected people | Without undue delay, where there is high risk | Regulator-dependent and often the hardest judgement. Take advice before, not after. |
| Customers, suppliers, staff | Deliberately | Contracts often carry their own notification clauses that are shorter than the regulatory ones. Check them. |
The ransom question, honestly
Nobody sensible will tell you it is simple. What follows is what is known, not what is comfortable.
Paying does not reliably get your data back
Decryptors are supplied more often than not, but they are frequently slow, partial, or corrupt files on the way through. Budget for recovery either way.
Paying for deletion buys a promise, and nothing else
There is no way to verify a copy was destroyed. Groups have re-extorted the same organisation, and data has surfaced after payment. You are buying a criminal's word.
Payment can itself be unlawful
Sending funds to a sanctioned entity is an offence in the US and UK regardless of duress, and some groups are sanctioned. This is why law enforcement and legal advice come before any payment discussion.
If it is being considered, get specialist help first
Insurer, legal counsel, and a negotiation firm. Sanctions screening, tax treatment and disclosure all have to be handled, and a first message sent by an amateur is not retrievable.
Decide the recovery plan independently of the payment question
The organisations that come out of this best are the ones that could have recovered anyway. Keep the two tracks separate.
Recovering
The goal is not to be running again. It is to be running again without them.
Rebuild clean rather than disinfecting
Cleaning a compromised machine leaves you trusting that you found everything. On anything that mattered, rebuild from a known-good image.
Close the route in before restoring anything
Patch it, or take it off the internet. Restoring behind an open door is the single most common way this happens twice.
Restore in stages and watch what comes back up
Dormant access frequently reappears with the restore. Bring systems back in order of importance, monitoring as you go.
Rotate every secret that touched an affected system
Service accounts, API keys, certificates, anything in a script or a config file. Assume everything cached on those machines is known.
Turn on multi-factor authentication for remote access before reopening it
Exposed remote access without MFA is among the most common ways in. Reopening without it invites the same route.
Afterwards
The window where an organisation will actually fund the fix is short. Use it.
Write the review while it is still uncomfortable
Six weeks later the detail is gone and the urgency with it.
Test a restore, on a schedule, and record the time it took
An untested backup is a hypothesis. The number that matters is how long a full restore actually takes, measured rather than estimated.
Reduce what is reachable from the internet
Most intrusions begin at an exposed service, a stolen credential, or a phishing message. The first of those is the one you can measure from outside.
Watch for your name appearing on a leak site
Publication often follows the intrusion by weeks. Knowing before a journalist calls is worth the monitoring.
This is general guidance, not advice about your situation
It follows public guidance from CISA, the UK NCSC and NIST, and it is no substitute for an incident-response firm, your insurer, or a lawyer who knows your obligations. If you are in the middle of something, call them rather than finish reading this.
Sentinel Surface addresses one line in section 07 — what is reachable from outside, and whether a group has named you. It does not detect compromise, and nothing here is a service we will contact you about.