First Steps After a Ransomware Attack: A UK Business Playbook

A ransomware note has appeared on a screen. Files have been renamed with a strange extension. Backups are showing as failed. Someone's just realised what they're looking at.

The first four hours decide whether this is a near miss or a notifiable, recoverable, or business-ending incident. This guide walks through exactly what a UK business should do — and what it should not do — in those first hours, written from the perspective of a senior engineer who has worked active ransomware incidents across legal, healthcare, dental, and pharma environments.

If this is happening to you right now, call 01923 372471 immediately — a senior engineer will be on a call and responding quickly. Containment in the first hour saves orders of magnitude more cost than recovery in the first day.

What this guide assumes

You are an IT manager, operations director, owner, or partner at a UK business. You have just discovered (or been told about) one of the following:

• A ransom note on user screens, in shared folders, or as a desktop wallpaper
• Files renamed with extensions like .lockbit, .akira, .babuk, .lukky, .encrypted, or random strings
• Servers offline with strange behaviour, logs missing, or services stopped
• A user reporting "all my files have weird names and won't open"
• Your backup vendor flagging that backup jobs have been deleted or repositories purged
• An anonymous email demanding payment in cryptocurrency

Any one of these is enough. Treat it as confirmed until proven otherwise.

Step 1: Stop and think (first 5 minutes)

The single most damaging early move is the panic move — pulling power on every server, deleting suspicious files, "trying to clean it up" with antivirus, or rebooting to "see if it goes away".

Three things are true at this moment:

1. The attacker has been on your network for days to weeks before encrypting. The encryption is the last phase of the attack, not the first. Anything they wanted to steal, they have.
2. Volatile evidence lives in RAM, network connections, and running processes. A reboot destroys it. A wipe destroys all of it.
3. The decisions you make in the next 60 minutes will be examined later — by your insurer, by the ICO, possibly by the NCSC, and almost certainly by your own board. Slow, deliberate moves now save you weeks later.

So: take a breath. Get a notebook (paper, not a laptop file — the laptop may be compromised). Write down the time. Write down what you saw and where. From here, every action is logged with a timestamp.

Step 2: Contain — disconnect, don't power off (first 30 minutes)

The goal is to stop the attacker reaching anything they haven't reached yet, while preserving evidence on what they have already touched.

Do this:

• Disconnect network cables from servers and any clearly-compromised endpoints. Or pull them from the switch — same effect, faster if you know your patch panel.
• Disable Wi-Fi at the AP/controller level for the affected segment.
• Block egress at the firewall — outbound to all but a small list of known-good destinations. The attacker's command-and-control will keep beaconing; cutting C2 limits further damage.
• Suspend or disable the domain admin and global admin accounts the attacker may already control. Reset passwords for break-glass accounts only, on out-of-band devices.
• Disconnect cloud sync. OneDrive, SharePoint, Google Drive, Dropbox — if encryption is hitting endpoints, the cloud copies are being overwritten in real time. Pause sync at the tenant level (Set-SPOTenantSyncClientRestriction for OneDrive, equivalent for others) or block the client from the firewall.
• Disable cloud backup retention settings that auto-purge old versions, if you can do it without authenticating from a compromised machine.

Do not:

• Do not power off servers. Powering off a Windows server destroys the contents of RAM, kills any running attacker processes that an investigator could fingerprint, and risks corrupting partially-encrypted files mid-write.
• Do not delete suspicious files or "clean" them with AV. Antivirus running a remediation pass after the fact destroys forensic evidence, often without removing persistence mechanisms.
• Do not run malware scans or "tools" you find online for ransomware decryption. The vast majority are scams, and even the legitimate ones (e.g. NoMoreRansom.org) should only be run after evidence is preserved.

Step 3: Preserve evidence (within first hour)

While containment is happening, in parallel:

• Image the affected systems before any cleanup. A bit-for-bit disk image (forensic image) preserves the file system as it stood at the moment of discovery. Free tools: FTK Imager. If you have an MSP or insurance provider with a forensic partner, this is their job — call them.
• Capture memory from any system still powered on (DumpIt.exe from Magnet Forensics, or winpmem). Memory contains the encryption keys for some ransomware families and active C2 connections that don't appear in disk artefacts.
• Export firewall and switch logs to a secure location — the attacker may have rotated logs out by the time you look on day three.
• Export your Microsoft 365 unified audit log for the last 90 days immediately. Microsoft retains these for 90 days by default (longer with E5 / Audit Premium); you want a copy in your hands before the clock or the attacker shortens that window.

# From a clean device, with an unaffected admin account:
Connect-ExchangeOnline
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -ResultSize 5000 |
    Export-Csv -Path "M365-AuditLog-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

• Note the ransom note text exactly. Take photos with a phone. The text often identifies the ransomware family, which informs everything downstream — known TTPs, known data exfiltration patterns, known decryptor availability.
• Check NoMoreRansom.org's Crypto Sheriff with a copy of an encrypted file (do this from a clean system). If a free decryptor exists for the family, you have a path forward that doesn't involve paying.

Step 4: Notify — UK regulatory and reporting obligations (within first 4 hours)

UK businesses have specific obligations after a cyber incident. Get these started early — the deadlines are real and the penalties for missing them are substantial.

ICO (Information Commissioner's Office) — 72 hours

If personal data has been compromised — accessed, exfiltrated, or made unavailable — you have 72 hours from awareness to notify the ICO under UK GDPR Article 33. The clock starts when you become aware, not when you've finished investigating. You report what you know, and update as the investigation progresses.

Report at: ico.org.uk/for-organisations/report-a-breach — phone: 0303 123 1113.

What constitutes "personal data made unavailable": ransomware encryption qualifies. If patient records, employee data, customer details, or any other personal data is encrypted and you cannot access it, that is a notifiable breach even if no exfiltration occurred.

NCSC (National Cyber Security Centre) — voluntary but recommended

Report to NCSC via ncsc.gov.uk/section/about-this-website/contact-us or their incident reporting form. NCSC reports are voluntary and confidential — they do not enforce regulation. They do provide:

• Threat intelligence on the specific ransomware family
• Connections to incident response specialists
• Anonymised data that helps the wider UK ecosystem
• A formal record that supports later insurance and regulatory claims

If you are critical national infrastructure, regulated under NIS2, or fit OES/RDSP definitions, NCSC reporting may be mandatory.

Action Fraud — for the criminal report

actionfraud.police.uk — 0300 123 2040. This is your formal report to UK law enforcement. It generates a crime reference number, which insurers and other parties will require.

Sector-specific regulators

• CQC (health/social care) — if patient care is affected
• FCA (financial services) — within 24–72 hours depending on incident category
• Ofcom (telecoms) — if applicable
• Solicitors Regulation Authority (legal) — promptly
• MHRA (medical devices/pharma) — if patient-facing systems or medical devices affected

Cyber insurance

If you have a policy: call the breach hotline first, before engaging external IR. Most policies require pre-approval of incident response providers, forensic firms, and legal counsel. Engaging your own without approval can void coverage. The hotline number is on the policy document — find it now if you don't have it to hand.

Step 5: Investigate scope (hours 4–24)

Now you start to map what actually happened. From a clean, isolated system using a trusted admin account:

• Identify patient zero — the first compromised endpoint. Check Windows Security event logs (4624, 4625, 4672), PowerShell logs, Sysmon if you have it.
• Identify the dwell time — when did the attacker first land. Common entry vectors: phishing email with macro, exposed RDP, exposed VPN appliance with known CVE, supply chain via an MSP, valid credentials from infostealer logs.
• Identify what was exfiltrated. Check firewall egress logs for unusual destinations, large outbound transfers, connections to cloud storage providers (mega.nz, anonfiles, common attacker-favoured services). Modern ransomware groups exfiltrate before encrypting and use the data as additional leverage ("pay or we publish").
• Identify what was encrypted. Walk file shares, server volumes, backups, cloud sync targets. Build a list — this becomes the basis of your recovery scope and your ICO notification.
• Identify persistence. Compromised service accounts, scheduled tasks, registry run keys, new local admin accounts, golden tickets, modified GPO. The attacker assumes you'll restore from backup; their persistence is designed to survive that.

This is the work that determines whether your eventual restore is clean or just resets the clock to the next incident.

Step 6: Decide on recovery strategy

There are three paths, in order of preference:

Path A: Restore from clean backups

If you have backups that are:

• Offline or immutable (tape, immutable cloud object storage, S3 Object Lock, Datto immutable, Veeam hardened repository)
• Older than the dwell time (not infected themselves)
• Verified as bootable / restorable (you tested them, recently)

— then restore is the path. Rebuild domain controllers from clean ISO, restore data from immutable backup, force password reset on every account in the domain (including service accounts and computer accounts), rotate all secrets, rebuild trust boundaries.

This is the answer most UK SMBs think they have and very often do not, because the attacker's first move on landing is to find and destroy backups. If your backup repository was reachable from a compromised admin account, assume it is also compromised.

Path B: Decrypt with a free or commercial decryptor

For some ransomware families, free decryptors exist (NoMoreRansom.org). For others, the operator's master keys have leaked (LockBit 3.0 builder leaked in 2022, several variants of Conti, etc.). This path is family-dependent — your incident response team will identify the family from the note, file extensions, and on-disk artefacts.

Path C: Negotiate with the attacker

This is the last resort. Considerations:

• It is not illegal in the UK to pay a ransom, but it may be illegal under sanctions regulations if the attacker group is on the OFSI sanctions list (e.g. Conti, certain LockBit affiliates linked to sanctioned entities). Check before paying.
• Insurance often covers payment but requires their nominated negotiator and prior approval.
• Decryption tools provided by attackers are frequently buggy, slow, or only partially restore data. Plan to use them as a "last copy of files" source while you rebuild infrastructure from clean.
• Paying funds the next attack — and signals to that group and others that you pay.

What NOT to do

• Don't communicate about the incident on potentially-compromised channels. Email, Teams, Slack — assume these are read by the attacker. Move to phones, encrypted messengers (Signal), or in-person.
• Don't rebuild on the same domain as the compromised one without rotating Krbtgt twice. Compromised Kerberos golden tickets persist across password resets unless krbtgt is reset twice (with replication between resets). Tools: Microsoft's New-KrbtgtKeys.ps1.
• Don't restore endpoints onto the network before infrastructure is clean. Reinfection within hours is common.
• Don't make public statements until you understand what's happened. Wrong statements early — "no data has been exfiltrated" before you've checked — are far worse than acknowledging "we are investigating an IT incident".
• Don't fire the user who clicked the phish. The phish reached them because controls didn't catch it. Punishing the user makes the next user hide their click — which is the worst possible outcome.

Recovery and prevention

Once contained and recovering, your post-incident roadmap will include:

• MFA on everything — every admin account, every external login, every M365 user. Conditional Access policies blocking legacy auth.
• Endpoint Detection and Response (EDR) — proper EDR, not just AV. Microsoft Defender for Endpoint, SentinelOne, CrowdStrike, Sophos Intercept X.
• Immutable backups — your existing backup, plus an immutable copy that cannot be deleted from any machine on the network. Datto SIRIS with Cloud Backup, Veeam with hardened Linux repository, S3 Object Lock.
• Privileged Access Management — separate accounts for admin work, JIT/JEA, no permanent global admins.
• Network segmentation — flat networks let ransomware spread. Servers, clients, IoT, OT each in separated VLANs with firewall rules between.
• Patching cadence — internet-facing services patched within 14 days. The ones the attacker came in through.
• Incident response plan — a written, tested plan. The first time you read it should not be during an incident.

When to call us

For ransomware specifically, call us if:

• You have an active or suspected ransomware incident in progress.
• You're not sure whether what you're seeing is ransomware or something else (sometimes a ransom note is real and the encryption is fake — sometimes the reverse).
• You need help executing the first-hour containment without making things worse.
• Your backups have been deleted or look suspect.
• Your MSP is unavailable, has been the entry vector, or is not equipped for incident response.

Engineerdirect.co.uk handles cyber incidents in line with NCSC guidance and can be on-site across London and the South East within two hours.

Call 01923 372471 — 24/7 emergency line. Senior engineer answers directly.

FAQ

Should I pay the ransom? Last resort, with cyber insurance approval and sanctions screening first. Payment is legal in the UK provided the recipient is not on the OFSI sanctions list, but it funds further attacks, marks you as a payer, and decryptors are often unreliable. Restore from immutable backup first if at all possible.

Do I have to tell the ICO? If personal data has been compromised — encrypted (rendering it unavailable), accessed, or exfiltrated — yes, within 72 hours of awareness under UK GDPR Article 33. The bar for "personal data" is low: names with email addresses qualify. Report at ico.org.uk/for-organisations/report-a-breach.

Will my cyber insurance cover this? Probably yes, if you have an active policy and follow their procedures — call their breach hotline before engaging any external party. Common reasons coverage is denied: pre-existing unpatched vulnerability, MFA not enabled where the policy required it, engagement of unapproved IR providers.

Can the police catch them? Realistically, no — most ransomware operators are based in jurisdictions where UK law enforcement has no reach. Action Fraud reporting still matters because it generates a crime reference for insurance and regulatory purposes, contributes to the wider intelligence picture, and is required for any sanctions screening.

My backup vendor said the backups are "immutable" — is that enough? Only if "immutable" means immutable from any account on your network — including a compromised domain admin and a compromised backup admin. Many vendors call backups "immutable" when they are merely "retention-protected", which a compromised admin can disable. Verify with your vendor: can a domain admin or backup admin shorten retention, delete, or modify backups? If yes, those backups are at risk.

How long does ransomware recovery take? Highly variable. A well-prepared business with immutable offline backups, a tested IR plan, and segmented infrastructure: 3–7 days to operational. A typical SMB without those: 2–6 weeks. A poorly-prepared business: months, often with permanent data loss.

Should I tell customers and staff? Yes — but only after legal and PR review, and only what you know to be true. UK GDPR Article 34 may require you to notify affected data subjects directly if there is a high risk to their rights and freedoms. Customers will find out anyway; controlled, honest communication is far better than the alternative.

If an attack is unfolding right now, our emergency cyber incident response can take over containment, evidence preservation and recovery — the first hours decide the outcome.

This guide is one of a series of disaster-recovery references for IT managers and operations directors. If a ransomware incident is in progress: 01923 372471 — 24/7.

References

UK reporting obligations and recovery resources referenced in this guide:

• ICO — Report a personal data breach
• NCSC — Mitigating malware and ransomware attacks
• Action Fraud — Report fraud and cybercrime
• No More Ransom — Free decryption tools