“We’re backed up” is the most dangerous sentence in your business.

Ask almost any leadership team whether they're protected against data loss and you'll hear the same four words: "We're backed up."

It's the most dangerous sentence in the small and mid-sized business vocabulary, because it's an assertion standing in for evidence. And in recovery, the gap between assertion and evidence is the whole story.

Job success is not restorability

A backup report full of green checkmarks tells you that a job ran. It does not tell you that you can get your business back. Those are different facts, and conflating them is the most common false comfort in IT.

The only test that matters is a restore: at the file level, at the system level, and at the business-process level. Can people actually work again, and how long does it take?

Five questions to ask this week

You don't need to be technical to ask these. You need to insist on answers that come with evidence.

• When did we last restore something, and was it recorded? File-level restores should be tested at least quarterly. Full system recovery should be tested at least annually.
• Can ransomware reach our backups? At least one copy should be immutable or offline, unalterable with production credentials. Attackers go after backups first.
• Are our backups protected by separate credentials? If one compromised admin account can delete production and backups, you have one copy, not two.
• What about our cloud data? Email, files, CRM, and finance systems in the cloud are frequently assumed to be protected by the vendor. Often they aren't, at least not in the way you'd need. Either back them up or make an informed, written decision not to.
• Does recovery depend on one person? If the only person who knows how to restore is on vacation, recovery takes as long as their flight home.

Recovery objectives are business decisions

Recovery time and acceptable data loss are not IT settings. They're executive decisions with price tags attached.

The most useful exercise is short: list the eight to fifteen processes that matter most (serve customers, collect money, pay people, meet obligations), and for each one ask how long it can be down before serious harm and how much data you can afford to lose. Then tier them: hours matter, days matter, a week is survivable.

Everything can't be top tier. The cost of recovery makes that trade-off real, and it's a trade-off leadership should make and sign, not one that gets made by default in a server room.

Say it plainly

Unverified recovery is the largest single unpriced risk on most small and mid-sized balance sheets. It doesn't appear in the financials until the day it becomes the only number that matters.

The fix is not expensive or complicated. It's a scheduled restore test, a separated copy, and a signed set of recovery targets. The hard part is replacing four comfortable words with evidence. Start this week: ask for the date of your last successful restore.