Test your backups before an attacker does

Somewhere in your business, backups are running. Probably every night. Nobody looks at them, because nobody needs to, because they are running. If you were asked whether the business could recover from losing its data, you would say yes, and you would be in good company.

That confidence is the problem. Veeam's 2026 resilience research, surveying more than 900 senior IT and risk leaders, found that 90% of organisations were confident they could recover from an incident. Among those actually hit by ransomware, fewer than one in three got all their data back. The average victim recovered 72% of what was affected. Between "we have backups" and "we got everything back" sits a gap that only shows itself on the worst day.

A backup you have never restored from is a hope, not a control. The good news is that turning the hope into a control costs an afternoon, and this filing is the walkthrough.

Why backups fail when they are finally needed

Attackers go for the backups first. Ransomware crews know the backup server is what stands between them and a payment, so encrypting or deleting backups is a standard early step, not an afterthought. The National Cyber Security Centre (NCSC) says this plainly in its ransomware guidance: attackers target connected backup devices to make recovery harder. A backup that sits on the same network, always connected, with the same admin passwords, tends to die alongside the systems it was supposed to save.

The backup was quietly incomplete. The job that has been reporting success for two years may be backing up a folder everyone stopped using in 2024, while the line-of-business database moved somewhere new. Success means the job ran, not that it covered what matters now.

The restore is slower than the business can bear. Getting 400 gigabytes back from a cloud backup over an office broadband line can take days. That is survivable if you knew and planned for it, and a crisis of its own if you find out live.

Nobody has done it before. A restore performed for the first time during an incident, by a stressed person, on unfamiliar screens, goes about as well as you would expect. Sophos's 2026 ransomware report puts the fix the same way we would: backups should be tested regularly, stored offline or in immutable formats, and wired into a response plan you can execute under pressure.

There is genuine progress in those Sophos numbers, incidentally: 66% of victims whose data was encrypted recovered it from backups this year, up from 54% the year before. Backups work. Tested backups work when it counts.

What a restore test actually looks like

You do not need a disaster simulation. You need three exercises, sized for a small business, on a calendar.

Monthly: restore one thing. Pick a file or folder somebody actually uses, restore yesterday's version to a different location, and open it. Ten minutes. This catches the silent failures: the job that stopped, the folder that moved, the corrupted archive. Rotate what you pick so you cover each system that matters across a few months.

Quarterly: restore something whole. A full mailbox, the accounts system, one complete machine. Restore it somewhere safe rather than over the live copy, check it opens and the recent data is present, and time it. That number, hours or days, is the one to write down: it is what "we would restore from backup" actually means for you.

Once: walk the whole path. List what the business could not run without, per function rather than per server: take orders, do the work, invoice, pay people. Check each one is inside a backup job, work out who would do the restoring if your IT person were on holiday, and confirm you could reach the backup credentials if your password manager were among the casualties. If you have worked through minimum viable operations from the NCSC's recovery guidance, this is the same list.

Two checks to fold in as you go. Keep at least one copy offline or otherwise disconnected: the NCSC's offline backups rule exists because the popular 3-2-1 rule (three copies, two devices, one offsite) can be satisfied entirely by connected copies, and connected copies are what ransomware reaches. And when you do restore after a real incident, scan before you reconnect: restoring the attacker's foothold along with your files is a well-worn way to have a second bad month.

What to do this quarter

• Put the monthly ten-minute restore in someone's calendar, named, recurring. Unowned tests do not happen.
• Run the quarterly full restore once, and write down how long it took next to your continuity plan.
• Confirm one backup copy is offline or immutable, meaning a copy that malware on your network cannot reach or rewrite.
• Ask whoever runs your backups, in-house or provider, one question in writing: when did we last successfully restore, and what did we restore? A confident answer with a date is what good looks like.

How Steelwise can help

Checking that your backups cover what the business actually depends on, and proving a restore works before you need it, is a short, well-defined piece of security advisory work. Get in touch if you would like it done properly.

Further reading

• NCSC: Ransomware-resistant backups
• NCSC: Backing up your data (small organisations guide)
• NCSC: Mitigating malware and ransomware attacks

← All filings