Your backups have never been tested. Here's what that actually means.

Ask a business owner whether they have backups and the answer is almost always yes. Ask when those backups were last restored (fully, under a clock, with someone confirming the systems actually worked) and the answer is almost always never. That gap is the difference between a hypothesis and evidence.

A hypothesis is a claim nobody has tested. “Our backups are fine” is a hypothesis. So is “we could be back up in a day.” Evidence is a timestamped restore: clock start, clock stop, systems verified working. Until you have the second thing, you only have the first.

Why the nightly success email proves nothing

Backup software reports success when it copies data. It does not report whether that data can be turned back into a running business. Those are two different questions. The copy can succeed every night for three years while the restore, the only operation that ever mattered, fails the first time anyone attempts it. In the backup audits we run, the restore has usually never been attempted at all.

There is a reason for that. Restores feel disruptive to test, nobody asks for the result, and the success email feels like an answer. Then the proposed HIPAA Security Rule update arrived, and cyber insurers started asking for restore test results at renewal. “When did you last test?” now comes with consequences attached.

The five failures we find most often

None of these are exotic. They show up in most small-business environments we audit, usually in combination. Each one has a known fix.

• 1. Backups on the same network they protect. Ransomware that reaches your server reaches your backup share in the same pass. Modern crews hunt for backups first and destroy them before touching production. The answer: an offsite copy on separate credentials, at minimum.
• 2. No immutability.If an administrator can delete a backup, an attacker holding that administrator’s password can too. The answer: object-locked storage in compliance mode. Once written, the backup cannot be altered or deleted by anyone until retention expires. Not you, not your IT provider, not the attacker.
• 3. Untested restores. A restore that has never been run is a hypothesis. The answer: a scheduled drill with a stopwatch and a written result.
• 4. No restore order. When everything is down, what comes back first: payments, scheduling, email, the file server? Most businesses have never ranked their own systems, so the ranking gets decided at 2 AM by whoever is awake. The answer: a one-page critical systems map with a target restore time per tier, written in advance.
• 5. Single-admin deletion. One person can empty the vault alone. Or one stolen password. Or one social-engineered help desk call. The answer: quorum control, where destructive operations require two or three named executives to approve through separate channels.

The 30-minute self-audit

You do not need a consultant to find out where you stand. Six questions. Write the answers down, with dates.

1. Where do the backups physically live? If the answer includes “on the server” or “on the same network,” that is finding number one.
2. Could one person delete them? Count your IT provider as one person.
3. When was a full restore last tested? A date, or the word “never.”
4. How long did that restore take? A number, or “unknown.”
5. Is the restore order written down anywhere your leadership can find it?
6. Who confirms the backups completed: a human who checks, or software that emails?

Score it simply: every “not sure” counts the same as a no, because in an incident it behaves the same as a no.

What to do with bad answers

If the audit went badly, the fix is not a bigger backup product. The fix is a tested restore: immutable storage, a written restore order, and a quarterly drill that turns the open questions into measured answers. Our published example artifact came in at 5h 42m against a 12-hour target. Your number will be different. The point is to have one.