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.

NIS2 requirements: the second regime to know about

Data protection law is not the only European regime a business gets asked about. The NIS2 directive sets baseline cybersecurity and incident-reporting obligations for organisations in a defined list of sectors, and it is the source of most of the security questions that now arrive attached to contracts. The two regimes cover different ground: data protection law governs personal data and what people can ask you to do with it, while the NIS2 requirements govern the security and resilience of network and information systems, whether or not personal data is involved. A single incident can engage both, on separate clocks, to separate authorities.

The directive applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet above ten million euros. That size rule puts most small businesses outside its direct scope, and the honest answer for a ten-person company is usually that the directive does not regulate it. What the size rule does not do is keep the requirements away, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and the way that expectation shows up in the world is as a questionnaire in your inbox.

The measures the directive names are a reasonable checklist for any business, which is why they are worth knowing even when they do not apply to you directly. They cover risk analysis and written security policies, incident handling, business continuity and backups, supply chain security, secure development and vulnerability handling, basic cyber hygiene and training including for management, encryption and access control policies, and multi-factor authentication. Reporting is staged and fast for the organisations it covers: an early warning within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within one month.

Because the directive is national law in each member state rather than a single rulebook, the details of scope, thresholds and reporting differ by country. For a fuller explanation of the instrument itself, see our guide to what the NIS2 directive is, and for the supplier side of the supply chain obligation, our walkthrough of vendor risk assessment. The reporting clocks that run alongside data protection deadlines are covered in data breach notification requirements.

Frequently asked questions

Does NIS2 apply to a small business?

NIS2 generally applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet total above ten million euros. Most smaller businesses fall outside its direct scope, unless a member state has specifically designated them or they sit in one of the size-independent categories such as DNS service providers or trust service providers. Being outside scope does not stop the directive reaching you through customers who are inside it.

What is the difference between GDPR and NIS2?

GDPR governs personal data: what you may collect, why you may hold it, and what rights people have over it. NIS2 governs the security and resilience of network and information systems in specific sectors, whether or not personal data is involved. One incident can engage both regimes at once, on separate reporting clocks and to separate authorities.

How long do you have to report a data breach?

Under the European model, a personal data breach is reported to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, and affected individuals are told without undue delay where the risk to them is high. Organisations in scope of NIS2 carry a separate obligation: an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within one month.

Does a small business need a data protection officer?

Under GDPR a data protection officer is required where the organisation is a public authority, where its core activities involve regular and systematic monitoring of people on a large scale, or where its core activities involve large-scale processing of special category or criminal offence data. Most small businesses meet none of those tests and are not required to appoint one, though naming someone internally as the contact for privacy questions is worth doing regardless.

What should a small business do when a client's security questionnaire asks about NIS2?

Answer what you actually do rather than what you think the client wants to hear. The questions usually cover written security policies, incident handling and how fast you would notify them, multi-factor authentication, access control when staff join and leave, backup and recovery arrangements, and which of your own subprocessors touch their data. Gaps are common, and disclosing one with a date for closing it lands far better than an answer that does not survive the follow-up question.

Do these rules reach a business based outside the EU?

They can. GDPR reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour, and other regions have their own regimes with their own triggers. NIS2 obligations follow the sectors and the member states that transpose it, but its supply chain expectations travel through contracts, which is how they reach suppliers anywhere in the world.

Related reading