Most small and mid-sized businesses we meet already have a backup. Very few have a disaster recovery plan. The difference sounds like wordplay until the morning the office opens and nothing works — and the backup you have been paying for turns out to cover files, not the business.
A backup protects data. Disaster recovery is about continuing to operate: answering the phone, invoicing customers, shipping orders, seeing patients, running payroll on time. Those are different problems, and the second one usually decides whether a bad week stays a bad week or becomes a lost year.
A Backup Is Not a Disaster Recovery Plan
Backup software is sold as insurance, so it feels like the job is done once the nightly job turns green. But a backup only answers one narrow question: can we get the data back? A recovery plan answers the questions that actually keep you in business.
- Where do we work tomorrow? If the office has no power or no network, which staff can work remotely, and what do they need to get in?
- Who is doing what? Not the IT person alone — who calls the bank, the landlord, and the customers?
- What runs first? If you can bring back only three systems today, which three?
- How do we reach people? If email is down and the phones run over the internet, your contact list is not where you think it is.
A backup is one component of the answer. The plan is the whole answer, and it lives in a document real people can follow at 7 a.m. while stressed.
RTO and RPO, in Plain Business Language
Two terms do most of the work in recovery planning, and neither needs a technical background. Recovery time objective (RTO) is how long you can tolerate being down. Recovery point objective (RPO) is how much data you can tolerate losing, measured in time: if your last good copy is from 11 p.m. and the failure hits at 3 p.m., your real RPO is 16 hours, and everything typed in that window is gone. Tolerances differ wildly by system, which is exactly why they belong in writing.
- Email down for an hour is annoying. Down for two days, it starts costing you deals and makes you look unreliable.
- The order or job-tracking system down for a day is not survivable for some businesses — you cannot quote, schedule, or bill.
- An hour of lost invoices means someone re-types them. A day of lost patient notes is a different category of problem, and HIPAA expects a contingency plan that covers it.
- Payroll data lost the week payroll runs turns into a very human crisis, quickly.
You do not need the same tolerance everywhere. You need to know which systems justify paying for fast recovery and which can wait.
The Threats You Actually Need to Plan For
Recovery planning goes wrong when people plan only for the cinematic events and ignore the ordinary ones. Most of what actually takes a business offline is not a disaster in the movie sense. It is Tuesday.
- Ransomware. The most common serious event for small businesses, and attackers hunt for your backups first.
- Hardware failure. A server, firewall, or switch that has quietly run for seven years will eventually stop.
- Fire, water, and power. A burst pipe above the server closet, a prolonged outage, a building closed for a week.
- Accidental deletion. Someone moves the wrong folder, or a sync tool faithfully replicates the mistake everywhere in seconds.
- A key person unavailable. The one person who knows how the phone system is configured is on vacation, has resigned, or is in the hospital.
- A cloud provider outage. Cloud services go down too. "It's in the cloud" is a hosting decision, not a recovery plan.
- A vendor going out of business. A niche application whose vendor disappears can leave you with data you can read and no way to run the business on it.
What Belongs in the Plan
A useful plan is short enough that someone will actually read it and specific enough to follow under pressure. These pieces earn their place.
- A systems inventory ranked by criticality — every application, server, and service you depend on, who owns it, where the data lives, and the recovery order.
- Roles, with a named backup for each. "IT will handle it" is not a role. Name who declares a disaster, who handles communications, and who coordinates vendors — and name a second person for each, because the first may be unreachable.
- A contact tree that does not live only in email. Staff mobiles, key vendors, the landlord, your bank, your insurance agent, your IT provider. Keep it reachable from a phone on cellular data, plus a printed copy offsite.
- An alternate work location or remote-work fallback. Which roles can work from home, what equipment they need, and how they get into systems with the office network gone.
- Supplier and vendor contacts, with account numbers. Your ISP, hardware vendor, software vendors, and the escalation path for each. Rebuilding without those numbers takes far longer than it should.
- A communication plan. Who sends the message, through which channel, and roughly what it says. A short holding message drafted in advance beats an improvised one written in hour four.
- Compliance obligations. HIPAA, PCI DSS, and CMMC requirements do not pause during an outage, and your recovery steps should be written to satisfy them rather than work against them. Our compliance services team builds plans with that framing.
The Test That Turns a Document Into a Plan
Here is the uncomfortable part: an untested backup is a hope, not a plan. Plenty of businesses discover mid-incident that the backup job has been failing silently for months, that the encryption key belongs to someone who left, or that a restore takes three times longer than anyone assumed.
- Start small. Restore a single critical file or mailbox and confirm it opens with current data.
- Move to a full system. Recover a server or core application into a test environment and confirm it actually runs, not just that files copied.
- Walk through a scenario. Hand two people the plan and a fictional outage, and see whether they can follow it without calling whoever wrote it.
- Write down what happened. Record how long each step took and compare it against the RTO you claimed. If the restore took nine hours and the target was four, the plan or the infrastructure is wrong — either way, you know before it matters.
Do this at least twice a year and keep the notes. They are the most valuable page in the document, because they show exactly where it breaks.
Ransomware Changes the Question You Need to Ask
Traditional recovery assumes data is lost. Ransomware assumes the attacker is already inside your network, logged in with real credentials, and specifically looking for backups.
So the question is not only "do we have backups?" but "are our backups reachable from a compromised account?" If a domain administrator account can delete or encrypt the backup repository, you effectively have no backups — just a second copy of the problem. Immutable and offline copies exist to break that chain, so a copy survives even when the credentials do not. We cover the copy design in our post on the 3-2-1 backup rule; read that one for the mechanics. This post is about the layer above it — what your business does in the first hour, and who does it. Hardening the backup path itself is core work in our cybersecurity services.
Keeping the Plan Current
A recovery plan decays quietly. It describes last year's systems, lists a vendor you no longer use, and names a coordinator whose title changed in the spring. Nobody notices until they need it.
Two triggers keep you ahead of that. Review after any major system change — a new server, a move to cloud email, a new line-of-business application, a change of ISP — because those changes usually invalidate a step somewhere. And review at least annually, on a calendar date, even if nothing obvious changed. Re-verify the contacts at the same time: call the numbers, confirm the escalation paths, check that the people named still work there.
If reviewing the plan is the task that keeps sliding down the list, hand it to someone whose job it is. Our managed IT services team maintains recovery documentation as part of ongoing support, so it is updated when the environment changes rather than once a year in a panic. For businesses running a mix of on-premises and cloud systems, cloud services and infrastructure is where the resilience design usually lives.
Not sure your plan would survive contact with reality? Contact Virtue Technology Solutions for a no-pressure review of your recovery readiness.