How Does Disaster Recovery Planning Work for a Small Business?

This entry was posted in Disaster Recovery on by .

Disaster recovery planning for a small business is four decisions and one habit. The decisions are how long you can be down (your recovery time objective), how much data you can afford to lose (your recovery point objective), which systems have to come back first, and who is allowed to declare a disaster. The habit is testing a restore on a schedule, because an untested backup is a hope rather than a plan.

In Los Angeles the disaster is rarely exotic. It is a ransomware event, a failed server, a burst pipe on the floor above, a wildfire evacuation zone that includes your office, or a power event during a heat wave. The plan that handles a ransomware event handles most of the others too, which is why it is worth building one rather than one per scenario.

Start with the two numbers

Recovery time objective (RTO) is how long a system can be unavailable before the impact becomes unacceptable. Recovery point objective (RPO) is how much data you can afford to lose, measured backwards from the moment of failure. If your backup runs nightly at 11 p.m. and the server fails at 4 p.m., you have lost a day of work, so your RPO is 24 hours whether or not you chose it.

Set both per system rather than for the business as a whole. A practice management system and the marketing file share do not deserve the same investment, and pretending they do is how disaster recovery budgets get rejected. Write the numbers down, because they are what turns a technology conversation into a business decision: every improvement in RTO or RPO has a price, and the owner gets to choose.

Classify your systems

Three tiers is enough for most small businesses.

  • Tier 1, revenue or safety critical. The systems where an hour of downtime is visible to customers or regulators. Typically the line-of-business application, email, and whatever holds client or patient records.
  • Tier 2, operationally important. Painful within a day: file shares, accounting, phones, internal collaboration.
  • Tier 3, everything else. Recoverable within a week without lasting damage.

The classification is what drives the restore order during a real event, and having it decided in advance is the difference between a recovery and an argument.

Backups: the 3-2-1 rule, plus immutability

The old rule still holds: three copies of your data, on two different media, with one copy offsite. Ransomware added a fourth requirement, which is that at least one copy must be immutable, meaning it cannot be altered or deleted within its retention window even by an administrator account.

That last property is the one that decides ransomware outcomes. Modern ransomware operators look for the backup console first and delete what they find, using credentials they have already stolen. A backup that a compromised administrator can delete is not protection against the threat you are most likely to face.

What to verify about your own backups today:

  • What is included, and specifically whether Microsoft 365 or Google Workspace data is included. Both providers replicate your data for availability; neither is a backup against deletion, corruption, or a malicious insider.
  • How often each system is backed up, compared against the RPO you wrote down.
  • Where the offsite copy lives and who can delete it.
  • Whether at least one copy is immutable, and for how long.
  • Who holds the encryption key, and whether you could restore without your IT provider.
  • The date of the last successful test restore.

Write the plan as a document someone can follow at 3 a.m.

A disaster recovery plan that only makes sense to the person who wrote it fails in exactly the circumstances it was written for. Keep it short and operational.

  • Declaration. Who decides this is a disaster, who they call, and what authority that gives them.
  • Contacts. Staff, IT provider, insurer, bank, landlord, key vendors, and legal counsel, with mobile numbers, stored somewhere reachable when the network is down.
  • Restore order. The tier list, as a sequence.
  • Step-by-step restore procedures for each Tier 1 system, written to be followed rather than interpreted.
  • Alternate work arrangements. Where people work if the office is unreachable, and what they need to do it.
  • Communication templates. What you tell staff, what you tell clients, and who signs it off.
  • A printed copy, or one on a device that does not depend on the systems being recovered.

Test it, and be specific about what you tested

Testing is where plans stop being paperwork. Three levels, escalating in cost and value:

  1. Restore test, monthly. Pull one file and one full system from backup and confirm both open. This catches silent backup failures, which are the most common and the most damaging.
  2. Tabletop exercise, twice a year. Sit the leadership team down with a scenario and walk the plan. Ninety minutes. It finds the gaps in decision-making rather than the gaps in technology, and those are usually the bigger ones.
  3. Full failover test, annually. Bring a Tier 1 system up in the recovery environment and measure how long it actually took against the RTO you wrote down. The measured number is almost always longer than the estimate, which is the point of measuring it.

Record the date and the result of every test. When your insurer, your largest client, or a regulator asks whether you test your recovery capability, the answer they want is a date, not an assurance.

The small business disaster recovery checklist

  • RTO and RPO written down for each Tier 1 and Tier 2 system, agreed by the owner.
  • System tier list, with a restore sequence.
  • Backups covering every Tier 1 and Tier 2 system, including cloud email and files.
  • At least one immutable copy and at least one offsite copy.
  • Encryption key custody documented, and held by the business.
  • Monthly restore test, with dated results.
  • Annual full failover test of at least one Tier 1 system.
  • Written plan with declaration authority, contacts, restore order, and procedures.
  • Offline copy of the plan and the contact list.
  • Alternate work arrangements documented, and tried once.
  • Cyber insurance policy read, with the notification window known in advance.
  • Plan reviewed annually and after any material change.

Related reading

Schedule a free consultation today to learn more about how Be Structured can safeguard your business from costly disruptions and security threats.

Frequently Asked Questions About Disaster Recovery Planning

What is the difference between disaster recovery and business continuity?

Disaster recovery is about restoring technology: systems, data, and access. Business continuity is about keeping the business operating while that restoration happens, which includes where staff work, how you serve customers manually, who talks to clients, and how you pay people. Disaster recovery is a subset of business continuity, and a small business usually builds the recovery plan first because it is the part with a technical answer.

What are RTO and RPO?

Recovery time objective is how long a system can be down before the impact becomes unacceptable. Recovery point objective is how much data you can afford to lose, measured backwards from the moment of failure. If backups run nightly and a server fails at 4 p.m., you have lost a day of work, so your effective RPO is 24 hours whether you chose it or not. Set both per system rather than for the business as a whole, because improving either one costs money and the owner should decide where to spend it.

How often should we test our backups?

Restore something monthly, run a tabletop exercise twice a year, and do a full failover test of at least one critical system annually. The monthly restore catches silent backup failures, which are common and usually go unnoticed until the day they matter. The annual failover test is the only way to learn what your recovery time actually is, as opposed to what your provider estimated it would be. Record the date and result of every test.

Do we need to back up Microsoft 365 or Google Workspace?

Yes. Both providers replicate your data across their infrastructure so it survives their hardware failures, and neither protects you from your own deletions, a ransomware encryption event that syncs, a departing employee wiping a mailbox, or retention policies expiring content you needed. Third-party backup for cloud email and files is inexpensive and is the gap we find most often when we take over an environment.

What is an immutable backup and why does it matter?

An immutable backup cannot be altered or deleted within its retention window, even by an administrator account. It matters because modern ransomware operators go looking for the backup console before they encrypt anything, using credentials they have already stolen, and they delete what they can reach. A backup a compromised administrator can delete is not protection against the threat most likely to hit you. At least one immutable copy should be part of every small business backup design.

How much does disaster recovery cost for a small business?

It scales with the recovery time you want. Nightly backup with a next-day restore is inexpensive and covers most Tier 2 and Tier 3 systems. Hour-scale recovery for a critical system requires replication or a standby environment and costs meaningfully more. This is why writing down the RTO per system first matters: it turns the question from how much disaster recovery costs into how much a specific hour of downtime is worth, which the owner can answer.

Who should be able to declare a disaster?

Name one person and one alternate, and give them the authority in writing before anything happens. The failure we see during real events is not a technical one, it is an hour lost to deciding whether the situation counts and who is allowed to spend money on it. Put the name, the alternate, and the decision criteria at the top of the plan.

How long does it take to build a disaster recovery plan?

Two to four weeks for a small business, with most of the elapsed time going to decisions rather than to work. Setting recovery objectives and classifying systems takes a workshop and some follow-up. Backup configuration changes take days. Writing the plan takes a few days. The first full failover test should follow within 90 days, because until you have tested it you have a document rather than a capability.

About Chad Lauterbach

Founder & CTO at Be Structured Technology Group, Inc., a Los Angeles-based provider of Managed IT Services for small businesses. I desire to help small businesses better utilize technology by assisting in high-level planning to make sure that new systems will benefit them both operationally and financially. I am careful to implement and support systems using industry best practices. I am a CMMC Registered Practitioner Advanced (RPA) with the Cyber AB.