Your Backups Are Answering the Wrong Question

A manufacturing firm near Derby called us last spring after a ransomware scare. Their IT lead was almost cheerful on the phone. "We're fine," he said. "Backups ran overnight, we've restored everything, we lost about four hours of work." He wanted us to confirm the all-clear so he could close the ticket.

We couldn't. Because by the time we'd looked at their firewall logs and the attacker's own leak site, it was obvious the gang hadn't really wanted to encrypt anything. They'd copied roughly 40GB of data — HR records, customer contracts, a folder of scanned passports from a recruitment drive — out of the network over the course of a week. The encryption was almost an afterthought, a noisy flourish at the end to get attention. The real product had already left the building.

Those backups restored the files perfectly. They did nothing at all about the fact that the firm now had personal data sitting on a criminal server, a 72-hour clock ticking under UK GDPR, and customers who were about to read about it online.

The assumption that's quietly gone stale

For the best part of a decade, "do we have good backups?" was the right question to ask about ransomware. The threat model was simple: attackers got in, encrypted your files, and demanded money to hand back the key. If you could restore from clean backups, you could tell them to get lost. Backups were the counter-move, and a lot of sensible money went into making them faster, more frequent and harder to tamper with.

That work wasn't wasted. Immutable, offsite, tested backups are still essential, and if you haven't got them you have a different and more urgent problem. But the question they answer — "can I get my data back?" — is increasingly not the question the attacker is asking.

The economics have shifted. Encryption is slow, loud and, frankly, a hassle for the criminals. It trips alarms. It requires them to maintain decryption infrastructure. And against a target with decent backups, it simply doesn't pay. Theft, by contrast, is quiet, quick and doesn't care how good your restore process is. Once the data is copied, the leverage exists whether you pay or not.

So a growing share of attacks have dropped the encryption entirely. The industry calls it exfiltration-only or "encryptionless" extortion. The playbook is: get in, find the sensitive stuff, copy it out, then email you a sample and a deadline. Pay us, or your data goes on the leak site and your customers get a nice note explaining what happened.

Why restore can't save you here

Here's the uncomfortable part. Every defence built around "we can restore" assumes the damage is the loss of access to your data. Exfiltration flips that. The damage is that someone else now has your data. You restoring your own copy changes nothing about theirs.

Walk through what a stolen dataset actually triggers.

A legal obligation. If the data includes personal information — and it almost always does — you may have a notifiable breach. Under UK GDPR you have 72 hours from becoming aware of it to tell the ICO, unless you can show the breach is unlikely to result in risk to people. A copied database of customer details is not "unlikely to result in risk". That clock starts whether your backups are pristine or not.

A duty to tell affected people. Where the risk to individuals is high, you have to inform them directly. That's the letter or email that lands on your customers' doormats. No backup undoes it.

Reputational fallout. Leak sites are public. Journalists monitor them. So do your competitors and your biggest customers' procurement teams. "We restored from backup" is a reassuring line internally and a meaningless one externally.

Ongoing exposure. Stolen credentials get reused. Stolen contracts inform the next attack. Stolen personal data gets sold. The harm has a long tail that a restore point can't shorten.

The Derby firm's four-hour data loss was genuinely trivial. The passport scans were not. They ended up notifying the ICO, writing to 300-odd individuals, and fielding some very awkward questions from a large customer whose pricing was in one of the leaked contracts. None of that was on the IT lead's radar, because his mental model stopped at "files are back".

Reframing the question

If backups answer "can I recover?", the two questions that actually matter against modern ransomware are:

1. Would we even know if data left the building?
2. If it did, are we ready to disclose it properly and fast?

Most SMEs we meet are weak on both, and they're weak precisely because they've spent their security budget being strong on recovery.

Detecting exfiltration

You can't notify what you never noticed, and plenty of these attacks are discovered only when the ransom email arrives — or worse, when the data appears online. The goal is to spot the theft while it's happening, or at least establish afterwards exactly what went.

In practical terms for a smaller business, that means a few things:

• Egress visibility. Know what normal outbound traffic looks like so you can spot the abnormal. A workstation suddenly pushing gigabytes to an unfamiliar cloud storage service at 2am is a signal — if anyone is watching for it. This is a core reason managed detection and response (MDR) has become worth the money for firms that can't staff a 24/7 security desk.

• Logging you can actually use. When you need to establish scope for the ICO, "we think they might have got into the file server" is a disaster. Detailed access logs let you say with confidence what was and wasn't touched, which directly affects whether a breach is notifiable and how.

• Data you can account for. You can't protect, or assess the loss of, data you didn't know you had. Knowing where personal and sensitive data actually lives — not where policy says it should live — is the difference between a targeted response and a panicked guess.

• Controls on bulk access. Alerts when someone pulls down an entire folder or queries a whole customer table. Legitimate users rarely do that; attackers always do.

Disclosure readiness

The 72-hour clock is unforgiving, and it starts at the worst possible moment — when everyone's already firefighting. The organisations that come through this well are the ones that decided how they'd respond before it happened.

That's an incident response plan that treats data theft as a first-class scenario, not a footnote. It names who makes the notification decision, who drafts ICO and customer communications, and which legal adviser gets the call. It includes a holding statement you can adapt rather than write from scratch at midnight. And it's been walked through at least once, so the first time people run it isn't for real.

Where this leaves your backups

Not redundant — just correctly scoped. Backups remain your answer to accidental deletion, hardware failure, and the ransomware crews still bothering to encrypt. Keep them immutable, keep them offsite, and keep testing restores, because an untested backup is a hope, not a control.

But stop letting them answer a question they were never built for. "We have good backups so we're safe" was a reasonable thing to believe in 2019. In 2026 it's a sentence that ends just before the part that costs you.

If you're not sure whether you'd detect data leaving your network, or what you'd do in the 72 hours after you found out, that's the gap worth closing this year. We're happy to help you find it before someone else does.