The reality of ransomware for UK SMEs

Ransomware isn't a large-enterprise problem that occasionally touches small businesses. It's an SME problem. Roughly 88% of ransomware attacks now target small businesses – organisations with fewer resources, less mature security infrastructure and, critically, less capacity to absorb weeks of operational disruption.

The economics are straightforward from an attacker's perspective. SMEs are more likely to pay because they're less likely to have clean backups or a tested recovery process. They're also less likely to have cyber insurance that covers everything – or legal teams that can push back on ransom demands intelligently. That makes them easier targets with a reasonable probability of a payout.

The £300,000 average recovery figure isn't just the ransom itself. It includes lost revenue during downtime, IT recovery costs, regulatory fines if personal data was exposed, legal fees, crisis communications and the longer-term reputational damage that follows a public incident. Many SMEs find the costs distributed across all of these categories in ways they didn't anticipate – and weren't insured for.

The businesses that recover fastest aren't necessarily the ones with the most sophisticated security. They're the ones with a clear, tested plan that doesn't rely on anyone improvising under pressure.

The first hour: what to actually do

The opening hour of a ransomware incident is the one that shapes everything that follows. The decisions made – or not made – in that window determine how far the attack spreads, how much forensic evidence survives and how quickly recovery can begin.

The first action is isolation, not shutdown. When staff notice ransomware – encrypted files, ransom notes appearing, systems behaving erratically – the instinct is often to power down the affected machine immediately. Resist it. Powering down destroys volatile memory (RAM) that may contain encryption keys, process information and attacker artefacts that forensic investigators can use. Instead, disconnect the machine from the network: physically unplug the ethernet cable, disable Wi-Fi, remove it from the domain. Contain the spread without destroying evidence.

Then identify scope. Is this one machine or multiple? Are servers affected? Has the attacker reached your backup environment? Answering these questions quickly – before taking further action – determines whether you're dealing with a contained incident or a full estate compromise. The response is different in each case.

Notify your IT provider or MSP immediately. If you don't have one, your cyber insurer should be the next call – before you contact law enforcement, before you communicate externally, and certainly before you consider paying anything. Insurers often have incident response partners they expect to be engaged before any other action is taken. Calling them late can affect your coverage.

Preserve logs. Firewall logs, authentication logs, email gateway logs – these tell the story of how the attacker got in and what they accessed. Many businesses delete or overwrite logs during the cleanup phase and lose information that would have identified the root cause and helped them avoid re-infection.

Who needs to be in the room

One of the most reliable predictors of a poor incident response is the absence of defined roles. When an attack hits and no one knows who makes which decisions, the result is delay, contradiction and conflicting communication – none of which helps recovery.

Four roles need to be defined before an attack happens:

These four roles don't need four different people – in a small business they may overlap. What matters is that every role is assigned in advance and that everyone knows who holds each one.

The backup question: where most SMEs find out they have a problem

The most expensive moment in a ransomware incident is discovering your backups don't work. Not that they don't exist – most businesses have some form of backup – but that they can't be restored, or that they've been encrypted alongside everything else.

The 3-2-1 rule is the baseline: three copies of your data, on two different media types, with one stored offsite. It's a sound principle, but it has a critical gap in a ransomware context: if your backup target is accessible from the same network as your production systems, ransomware can reach it. Many businesses that thought they had offsite backups discover that "offsite" meant a cloud sync service – Dropbox, OneDrive, Google Drive – that had already replicated the encrypted files before anyone noticed the attack.

Cloud sync is not a backup. It replicates whatever is in your production environment, including ransomware. The moment encryption begins, the sync process faithfully copies encrypted files to the cloud, overwriting your clean versions.

What you need instead is immutable backups – backups that cannot be modified, overwritten or deleted for a defined retention period, even by an administrator. Modern backup platforms support this natively. An attacker who compromises your systems and your backup admin credentials still can't touch an immutable backup target.

Testing matters as much as the backup itself. Many businesses run a backup process for months or years without ever restoring from it. A backup you've never tested is a backup you don't actually have – you have a process that creates files you hope are restorable. Run a full restore test at least quarterly. Document how long it takes to restore critical systems, because that figure is what you'll be quoting to your business decision-maker during an active incident.

Communication during an incident

Communication is one of the most mismanaged aspects of ransomware incidents, and the mistakes compound quickly.

Internally, staff need to know what's happening, what they should and shouldn't do (particularly around affected systems) and who to direct questions to. A brief, factual message from a senior figure – "we're dealing with a security incident, the IT team is working on it, we'll update you at [time]" – is far better than silence, which generates speculation and unofficial channels.

Externally, the timing and content of client and supplier communication depends on what data has been affected. If you don't yet know whether personal data has been compromised, don't communicate as if it has – but don't communicate as if it definitely hasn't either. Your legal contact should guide this.

Under GDPR, if a personal data breach is likely to result in a risk to individuals, you must notify the ICO within 72 hours of becoming aware of it. That clock starts when you have reasonable grounds to believe a breach has occurred – not when you've confirmed every detail. Missing the 72-hour window is itself a regulatory failure, separate from the breach. Your incident response plan should have the ICO notification process documented, with the relevant contact details and a draft notification template, so that filing the report doesn't require starting from scratch during an active incident.

Recovery phases: why rushing to restore leads to re-infection

Recovery from ransomware follows four phases: containment, eradication, restoration and lessons learned. Each phase must complete before the next begins. Skipping eradication – because there's pressure to get systems back up quickly – is the most common reason businesses get hit a second time.

Containment is what happens in the first hours: isolating affected systems, stopping the spread and preserving evidence. You're limiting damage, not fixing it.

Eradication is identifying and removing the attacker's presence from your environment. This means finding the initial access vector (a phishing email? an exposed RDP port? a compromised credential?), identifying every system the attacker touched, removing malware and backdoors, and closing the vulnerability that let them in. This cannot be skipped. Restoring from backup onto a system that still contains attacker tooling means restoring into a compromised environment.

Restoration is rebuilding systems from clean backups or images, validating that systems are operating correctly and bringing services back online in a controlled sequence – typically critical systems first, then secondary systems, with monitoring in place throughout.

Lessons learned is a structured review, conducted within days or weeks of the incident, covering what happened, what the plan got right, what it got wrong and what changes are needed. This is the step that prevents a second incident – and it's the step most businesses skip because by then the pressure is off and there are other priorities.

What your incident response plan document should actually contain

Most incident response plans fail not because they're wrong but because they're unusable. A 40-page document that lives in a SharePoint folder, last reviewed two years ago, is not a plan – it's a liability. If the systems that host it are encrypted, it's not even accessible.

A useful incident response plan is a single page that a non-technical member of staff can follow under pressure. It should contain:

Keep a printed copy of this document somewhere accessible offline. If your entire environment is encrypted, the plan that only exists on your network is useless.

Cyber insurance: what it covers and what it typically doesn't

Cyber insurance has become an essential component of ransomware preparedness, but it's widely misunderstood. Policies vary significantly, and many businesses discover the gaps after an incident rather than before.

A good cyber policy typically covers incident response costs (including forensic investigation), legal fees, regulatory fines under GDPR, business interruption losses, crisis communications support and – where legally permissible – ransom payments. What it often excludes: incidents that resulted from controls the business said it had in place but didn't (this is where disclosure matters), losses from attacks that predate the policy, systems that were end-of-life or unpatched, and social engineering attacks if they're not explicitly listed.

Call your insurer early – in the first hour if possible. Most cyber policies have specific requirements about who must be engaged and in what sequence before certain costs are covered. Hiring your own forensics firm before calling your insurer, for example, may mean those costs aren't reimbursed. Your insurer wants to manage the response: let them.

Review your policy annually and specifically test it against your current environment. If you've grown significantly, taken on new systems or started handling more sensitive data, your coverage may no longer reflect your actual risk.

Don't wait for an incident to find out your plan has gaps. Route B helps businesses put practical incident response plans in place – and the managed IT foundations that make recovery faster.

Get in Touch