Business Continuity Planning: The Test That Separates Real Plans From Binders on a Shelf

A business continuity plan is one of those things that feels complete the moment you finish writing it.

You document your critical systems. You list your recovery steps. You identify your vendors and contact numbers. You put the binder on the shelf, check the box, and get back to running your business.

Then something actually happens.

THE PROBLEM WITH PLANS THAT LIVE IN BINDERS

I've been in this industry for over 20 years. I've walked into businesses — good businesses, well-managed businesses, businesses that did everything right by conventional wisdom — and found disaster recovery plans that described infrastructure that was replaced three years ago. Recovery procedures that referenced a vendor who went out of business. Contact information for an IT provider that no longer exists.

A plan that hasn't been tested isn't a safety net. It's a document that gives you false confidence until the moment you need it — at which point you discover it doesn't reflect reality.

Business continuity planning failures don't look like "we had no plan." They look like: we had a plan, we followed the plan, and the plan was wrong.

THE TWO NUMBERS THAT ACTUALLY MATTER

Before you can build or evaluate a business continuity plan, you need to define two things:

Recovery Time Objective (RTO): How long can your business be down before the impact becomes unacceptable? For a Las Vegas law firm, that might be four hours. For a medical practice, it might be two. For a 24-hour hospitality operation, it might be 30 minutes. Your RTO defines how fast your recovery must be.

Recovery Point Objective (RPO): How much data can you afford to lose? If your backups run nightly at midnight and a ransomware attack encrypts everything at 5 PM, you've lost 17 hours of transactions. If that's acceptable, a nightly backup meets your RPO. If it's not — if losing a day of invoices would be catastrophic — you need more frequent backups.

Most Las Vegas businesses have never explicitly defined these numbers. They have backups, but they don't know how long recovery would actually take. They have a recovery plan, but they don't know if it would meet their RTO. The plan lives in the binder because defining RTO and RPO would force them to test it.

LAS VEGAS-SPECIFIC RISKS

Business continuity planning in the Las Vegas valley needs to account for threats that aren't as prominent in other markets.

Heat: Las Vegas summers push ambient temperatures above 110°F. If air conditioning fails in a server room or IT closet — even briefly — equipment can fail within minutes. We've seen business-critical servers taken out by a failed HVAC unit on a July afternoon.

Power: NV Energy delivers reliable service, but Las Vegas's peak summer demand creates grid stress. Power fluctuations and brief outages happen. UPS systems protect against brief interruptions, but extended outages require generator capability or cloud redundancy.

Flash flooding: Southern Nevada experiences flash flooding that can be rapid and severe. Businesses near washes or in low-lying areas are at real risk. We've seen offices flood with 30 minutes of warning.

Ransomware: This is the most common business continuity event we respond to. A ransomware attack doesn't just encrypt your files — it may destroy your backups, disable your monitoring, and compromise your recovery environment. A continuity plan that assumes your backups are intact when ransomware hits needs to be revisited.

WHAT A REAL BUSINESS CONTINUITY PLAN INCLUDES

A plan that will actually work when you need it covers more than data backup. It defines:

Critical systems and dependencies — which systems absolutely must be restored first, and what other systems depend on them. Restoring your file server before your domain controller is online helps nobody.

Recovery procedures — step-by-step, written for a technician who has never touched your environment before. Not "restore from backup" but the specific commands, credentials, and validation steps needed to bring each system back online.

Communication plan — who contacts whom, through what channels, when a continuity event occurs. If your email is down, how does your team communicate? If your office is physically inaccessible, where do employees go?

Vendor contacts and SLAs — every critical vendor, their emergency contact, and the response time you're entitled to under your agreement.

Recovery validation — the specific tests you run to confirm systems are actually working before you declare recovery complete. "It booted up" is not recovery validation.

Alternative work locations — where does your team work if your office is inaccessible? Remote work capacity, VPN access, and cloud-based applications need to be pre-configured, not figured out during an incident.

THE TEST IS THE PLAN

Every business continuity plan should be tested at least annually. There are three levels of testing, each more rigorous than the last:

Tabletop exercise: Your team walks through a simulated scenario — ransomware attack, office fire, extended power outage — and discusses what they would actually do. You're not executing procedures, just talking through them. This catches logical gaps and communication problems.

Functional test: You actually execute recovery procedures in a controlled environment. Restore from backup to a test system. Verify applications start. Confirm data integrity. This catches procedure problems that don't show up in discussion.

Full failover test: Simulate a complete failure of your primary environment and operate from recovery systems. This is the hardest test to schedule — it requires taking systems offline in a controlled way — but it's the only test that reveals whether your RTO is actually achievable.

Most Las Vegas businesses should be doing tabletop exercises twice a year and functional tests annually at minimum.

WHAT TO DO THIS WEEK

If you have a business continuity plan that hasn't been updated or tested in the past 12 months, here are three things you can do right now:

1. Open the plan and check the infrastructure. Does it accurately describe your current systems? Are the contact numbers still current? Is the backup solution it references still in place?

2. Attempt a test restore. Pick a non-critical file server or a secondary system and try to restore it from your most recent backup. Time it. Does it meet your RTO?

3. Define your RTO and RPO if you haven't. Ask yourself honestly: how long can we be down? How much data can we lose? Then verify that your current backup and recovery capabilities can actually meet those numbers.

If any of those steps reveals a gap — and they almost certainly will — that's valuable information. The goal isn't a perfect plan. It's a plan that's been tested and is continuously improved.

702MSP helps Las Vegas businesses build, test, and maintain business continuity plans that work under real-world conditions — including the specific threats and environment of Southern Nevada. If you want to know how your current plan holds up, call us at (702) 333-2001 or visit 702msp.com.