Most business owners assume their backups work. Most of them are wrong, or at least wrong about the details that matter — how recent the backups actually are, whether they’d survive the same incident that took down the primary system, and whether anyone has ever actually tried restoring from one. You don’t need a multi-week project to find out where you stand. A few focused hours will tell you almost everything you need to know.
Step 1: Find Out What’s Actually Being Backed Up
Pull up whatever backup system your company uses and get a straight answer to a simple question: what, specifically, is included? It’s common to discover that a backup system covers the obvious file server but misses a critical application database, a cloud-based tool nobody thought to include, or configuration settings that would take days to rebuild from scratch even if the data itself is safe. List every system your business genuinely can’t operate without, then cross-check it against what’s actually being captured.
Step 2: Check the Frequency Against Your Tolerance for Loss
A daily backup sounds reasonable until you calculate what a full day of lost work actually means for your business — every order, email, and document created since the last backup, gone. For some businesses, daily is fine. For others, especially anything transaction-heavy, it’s a real gap. Compare your actual backup frequency against how much data loss your business could genuinely absorb, and be honest about the answer.
Step 3: Confirm Backups Are Isolated From Your Primary Network
This is the step that catches the most companies off guard. If your backups are sitting on the same network as everything else, a ransomware attack that encrypts your primary systems can encrypt your backups right along with them — turning what should be a recovery option into just another casualty. Backups need genuine isolation: a separate system, offline storage, or a cloud backup provider with its own independent access controls, not just a different folder on the same server.
Step 4: Actually Restore Something
This is the step almost everyone skips, and it’s the one that matters most. A backup that’s never been test-restored is a backup you’re simply hoping works. Pick a non-critical file or system and actually run a full restore. You’re checking two things: whether the restore process works technically, and whether anyone on your team actually knows how to execute it without scrambling to figure it out for the first time during a real emergency.
Step 5: Time the Restore
Note how long the test restore actually took. Then compare that number honestly against how long your business can tolerate being down. A backup that technically works but takes three days to fully restore isn’t much comfort if your business can’t survive three days of downtime. This is often the single most revealing number in the entire audit.
Step 6: Review Who Has Access and Who Would Know What to Do
Check who currently has the credentials and knowledge to execute a restore, and consider what happens if that person is unavailable during an actual emergency. Backup access that lives entirely in one person’s head is a real vulnerability, even if the technical backup itself is solid.
What to Do With What You Find
If this audit surfaces gaps — and for a lot of companies, it will — the fix doesn’t have to be an overnight overhaul. Prioritize the systems you genuinely can’t operate without, close the isolation gap first since that’s the one most likely to turn a bad day into a catastrophic one, and build a recurring test-restore into your calendar rather than treating this as a one-time exercise. Firms like Cortavo that specialize in disaster recovery planning often note that the businesses who fare best after a real incident are simply the ones who ran this exact audit, and acted on it, long before they needed to.
