Guide

Business Continuity and Disaster Recovery: The Basics

The difference between business continuity and disaster recovery, what a BCDR plan for a small business should contain, and how to build one without a dedicated IT department.

By SecureBusinessHub Editorial, International cybersecurity desk — · 5 min read

Business continuity and disaster recovery, usually shortened to BCDR, are the plans that answer a question most small businesses only think about after something has already gone wrong: if a major system, your office, or your main tool goes down, how does the business keep running while it gets fixed? The two terms get used interchangeably, but they cover different ground. This guide explains the difference, what a BCDR plan for a small business should actually contain, and how to build one without a dedicated IT department.

This plan is the wider umbrella that a specific ransomware recovery falls under; if that is the scenario you are planning for right now, our ransomware survival guide walks through the recovery steps directly. A BCDR plan covers that scenario and every other kind of major disruption: a fire, a long internet or power outage, a key supplier going down, or the loss of your office space.

Business continuity versus disaster recovery

Disaster recovery is about getting your systems and data back: restoring servers, recovering files from backup, and getting technology working again after it fails. Business continuity is broader. It is about keeping the business functioning, in some form, while that recovery happens: where staff work if the office is unusable, how you keep serving customers with limited systems, and what gets prioritized when you cannot do everything at once.

A small business usually needs both, and they overlap in practice more than the definitions suggest. Disaster recovery gets your email server back online. Business continuity is the plan for how staff kept working, from home or on phones, in the hours before that happened. Treating them as one combined plan, which is the usual small-business approach, is simpler than maintaining two separate documents and works just as well.

What a BCDR plan should contain

A usable plan does not need to cover every conceivable disaster in detail. It needs to identify what actually matters to keep running, how quickly you need it back, and the concrete steps to get there.

  • Critical functions: the small number of things your business cannot operate without, such as taking orders, communicating with customers, or processing payments.
  • Recovery targets: how quickly each critical function needs to be back, and how much data loss is acceptable, covered in more detail below.
  • Fallback arrangements: where people work and what tools they use if the normal office or systems are unavailable.
  • Communication plan: how you tell staff, customers, and suppliers what is happening, and who is responsible for sending those updates.
  • Recovery steps: the concrete sequence for restoring systems, informed by your 3-2-1 backup strategy and your incident response plan.

Setting realistic recovery targets

Two terms do a lot of work in disaster recovery planning, and both are simpler than they sound. Recovery Time Objective, or RTO, is how long you can tolerate a system being down before the impact becomes serious. Recovery Point Objective, or RPO, is how much data you can afford to lose, measured in time: if your last backup was six hours old when things went wrong, your RPO for that system is six hours.

Set these per system rather than as one number for the whole business. Email might need an RTO of a few hours, since a day without it stalls most work. An internal reporting tool might tolerate a full day down with no real damage. Setting an honest RTO for each system, rather than declaring everything critical, is what turns a BCDR plan from a wish list into something you can actually deliver on with the budget you have.

The plan in practice

Consider a six-person consultancy that rents a small office. A burst pipe floods the office overnight, and staff arrive the next morning to a room full of damaged furniture and no usable internet connection. Their BCDR plan already answers the immediate question: everyone works from home for the time being, using the cloud-based tools they already use day to day, so client work barely pauses. The plan also names who calls the landlord and the insurer, so that job does not fall to whoever happens to notice the flood first.

Because their file storage and email both run in the cloud rather than on a server in that office, the flood does not touch their data at all: the RTO for those systems is effectively zero, since nothing needs restoring. The only real recovery task is physical: getting a usable office back, which the plan treats as a facilities problem with its own timeline, separate from the technology that kept working the whole time.

Keeping it current

A BCDR plan ages the moment your tools, office, or team change, so review it at least once a year and immediately after any significant change: a new office, a new core system, or a supplier you now depend on that did not exist when the plan was written. Test it the same way you would test a backup: walk through a scenario with your team and see whether the plan's assumptions still hold. A plan that names a fallback office you no longer have access to, or a staff member who left two years ago as the emergency contact, will not help you when you actually need it.

Where this fits

This plan sits above the specific recovery steps in our ransomware survival guide and depends on a working 3-2-1 backup strategy to give it something to recover from. If you would rather adapt a structured document than build one from scratch, our editable policy template pack includes a business continuity and disaster recovery plan written for small businesses, ready to fill in with your own critical functions and recovery targets.