“Business continuity” and “disaster recovery” get used interchangeably so often that many people assume they’re synonyms. They’re not — and the difference matters when you’re deciding what to buy, what to plan for, and what to test.

The shortest honest version:

Disaster recovery answers: how do we get our systems and data back? Business continuity answers: how does the business keep operating while that happens — and no matter what else happens?

Disaster recovery: the IT half

Disaster recovery (DR) is the technical discipline of restoring IT after something breaks it — ransomware, a dead server, fire, flood, a botched update, an honest mistake with a delete key. A DR plan covers what gets backed up and how often, where backups live and how they’re protected, in what order systems get restored, who does the work, and how long it takes.

Two numbers sit at the heart of every DR decision:

  • RPO — recovery point objective. How much data can we afford to lose? Nightly backups mean up to a day of lost work; if that’s unacceptable for some system, it needs more frequent protection.
  • RTO — recovery time objective. How long can we afford to be down? If the honest answer for your core systems is “hours, not days,” restoring a server from cloud storage alone won’t cut it — you need local copies, or a BCDR appliance/cloud service that can run a virtual copy of your server while the real one is rebuilt.

Different systems deserve different numbers. Your order-processing database might warrant an RPO of one hour and an RTO of four; the archive of 2019 marketing files can take a week. Tiering this way keeps costs proportionate.

Business continuity: the whole-business half

Business continuity (BC) zooms out from servers to operations. Its core question: for each critical business function, how do we keep it running — in some form — through a disruption? That includes IT failures, but also scenarios where the technology is fine and something else isn’t:

  • The office is inaccessible (fire next door, a burst pipe, a winter storm — or, for us in the Northwest, a wildfire-smoke week or an ice storm that closes roads)
  • The internet or power is out for days
  • A key vendor or supplier goes down
  • Several essential people are unavailable at once
  • The phones are fine but the phone staff aren’t

A BC plan identifies your critical functions (taking orders, paying people, serving clients, answering phones), what each depends on (systems, people, vendors, facilities), and the workaround for each dependency: Where does everyone work if the office is closed? How do calls get answered — can the main number forward to cell phones? Who can cover for whom? What’s the manual fallback if a system is down for two days? Who communicates what to clients and staff, and how, if email itself is the casualty?

DR is a subset of BC: recovery of systems is one of the things continuity depends on. But a business with perfect backups and no continuity plan can still find itself with recovered servers and no way to operate; a business with a continuity mindset can often keep serving clients even while IT is mid-restore.

Why small businesses skip this — and why that’s backwards

Continuity planning sounds like an enterprise exercise: binders, committees, consultants. But small businesses are more fragile than enterprises, not less — thinner margins, less redundancy, more knowledge in single heads, and extended downtime is existential rather than embarrassing.

The fix is scale, not omission. A genuinely useful small-business BCDR plan can be a handful of pages.

A starter plan you can build in an afternoon

  1. List your critical functions. The five to ten things that must keep happening for the business to be a business.
  2. Map dependencies. For each: which systems, which people, which vendors, which location?
  3. Set RTO/RPO per system. Business decision first, technology second. Be honest about the cost of a day of downtime.
  4. Check your backups against those numbers. This is where most plans reveal a gap — often that current backups can’t meet the recovery times leadership assumed. (The 3-2-1 rule is the baseline.)
  5. Write the workarounds. One short paragraph per scenario: office inaccessible, internet down, key system down, key person out.
  6. Build the contact tree. Staff, IT provider, insurer, key vendors, key clients — printed and stored somewhere that isn’t only a server or a desk drawer in the office you can’t enter.
  7. Assign decision-makers. Who declares a disaster? Who talks to clients? Who’s the backup for each?
  8. Test something once a year. A restore test, a work-from-home day, a tabletop walkthrough of “it’s Monday and the server room flooded.” Plans that are never rehearsed fail in the details — the number nobody had, the password nobody could reach, the step everyone assumed someone else owned.

The bottom line

Disaster recovery gets your systems back; business continuity keeps the business alive in the meantime. You need both, sized to your reality — and for most small businesses that’s a short, tested document plus backups that genuinely meet your recovery numbers, not a binder on a shelf. If you can’t currently say what your RTO and RPO are, that’s the best possible starting question to bring to whoever manages your IT. And if you want to see this thinking stress-tested against the region’s biggest what-if, the Cascadia question is the honest version of that exercise.