A disaster can expose gaps in a recovery plan at exactly the wrong moment. The problem may be technical, organisational, or a mixture of both. Planning cannot prevent every disruption, but it can give people a workable response. This guide explains what a disaster recovery and business continuity plan should cover, without the big-business language that can make small and mid-sized businesses assume the subject is out of their league.
Why disaster recovery is a survival question, not an IT checkbox
A major disruption can leave a small business unable to serve customers or access essential records. The threat is not limited to floods and fires: ransomware, prolonged power failures, cloud outages and human mistakes can also interrupt work. A deleted database, a failed migration or a stolen laptop belongs in the planning conversation alongside damage to the premises.
Rather than judging resilience by the size of the IT budget, start with a few unsettling questions: what are we willing to lose, how urgently do we need to recover it, and who is accountable for taking the necessary measures? The answers give the recovery team something concrete to work towards when normal operations are interrupted.
Business continuity and disaster recovery aren’t the same thing
Using these terms interchangeably can leave gaps in a plan right at the start.
Business continuity management is the broader picture. It outlines how your people, suppliers, facilities, and processes will function during a disruption – where staff will work if the office is out of bounds, how customers will be served if the phones aren’t working, which suppliers can take over if your primary one is unable to deliver. Disaster recovery is the technical part of that plan. It specifically details the recovery of IT systems, applications, and data after a disruption.
You can have a good DR plan and a bad BC plan, and vice versa. A company may be able to recover its servers in four hours, but have no solution for staff who have lost premises to work in. Both plans should exist, and both should reference each other. Your incident response plan is what activates both – it’s the tripwire, not the recovery itself.
RTO and RPO: the numbers that decide everything else
There are two targets to agree: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Use RTO to set the intended time to restore a system. Use RPO to set the acceptable age of the data recovered. Both need a business explanation. A day without a system may sound manageable until you work through the orders, invoices and customer requests that depend on it. Set the targets with the people doing that work, rather than choosing a convenient number for the IT team alone.
For example, a one-hour RPO calls for a recovery method that can bring back data no more than an hour old. Check that the backup schedule and completed recovery points actually support that target. Reaching for yesterday’s backup could mean losing later customers, invoices and orders, even if the backup itself restores without errors.
These targets help you choose backup frequency, recovery infrastructure and the amount of manual work the team can tolerate during an outage. They do not choose a design for you: cost, site risks and system dependencies still matter. A four-hour RTO for an accounting system is a different planning example from a fifteen-minute RTO for a live e-commerce website. Setting the targets honestly, system by system, turns recovery from a vague ambition into something you can budget for and test.
Start with a business impact analysis, not a tool
It is tempting to rush out to buy backup software or a DRaaS subscription before doing the spadework of working out what needs to be protected in the first place.
A business impact analysis means sorting your systems by the consequences of losing them, whether operational (‘we cannot process orders’) or financial (‘we cannot invoice customers’). Do not assume payroll, email or the internal wiki belongs at the top of the list. Ask each team what stops, what can wait, and which temporary workarounds are realistic.
Once you’ve done that, a risk assessment is nothing fancier than sorting the things that could stop those systems being available, which might include ‘half the town’s on fire’ or ‘Dave was our guy for that and he’s taken another job.’ Businesses that need help with this kind of planning often turn to a specialist provider for it support in Essex rather than trying to figure it all out alone.
Only after that work is it time to go shopping. A limited budget calls for clear priorities, not the same recovery setup for every application. Decide where continuous availability matters and where a planned interruption is tolerable. A supplier can explain its products, but it should not be your sole source of advice on what the business actually needs.
The 3-2-1 rule, updated for ransomware
A good, solid baseline backup strategy has been the 3-2-1 rule for a long time now: three copies of your data, on two different media types, with one stored offsite. That’s still a perfectly good minimum.
Connected backups can be vulnerable during a ransomware incident, so the basic copy count should not be the end of the discussion. Consider a separate offline or immutable copy and check how its access controls work. The extended 3-2-1-1-0 approach adds an isolated or protected copy and an emphasis on error-free recovery checks. Treat that as a planning aid, not a promise that any particular product is immune to attack. Test a restore and confirm that the recovered information is usable before relying on the arrangement.
Choosing your recovery model: on-prem, hybrid, or cloud
There are three main shapes a DR setup can take, and each has its trade-offs.
On-premises DR means owning secondary hardware or a site that you control directly. That gives you responsibility for its configuration, maintenance and capacity as well as its recovery performance. Cloud-based recovery, including services described as DRaaS, can avoid the need to maintain your own second physical site. Check the provider’s actual recovery arrangement, ongoing charges and connectivity requirements. Neither approach proves that recovery will be fast: the test is whether it can restore your systems within the targets you agreed.
Hybrid setups split the middle ground – with your most critical systems replicated near to home for speed, and less urgent systems held in the cloud for cost. Latency, cost, and recovery speed are all pulling against each other no matter which model you decide to go with. The actual technology is easy to purchase. It’s configuring it correctly, and keeping that configuration valid as your systems change, that’s the real work.
The human side: roles, drills, and testing
A recovery plan that only exists on paper is close to useless, because outages don’t wait for someone to figure out who’s in charge.
Every plan needs a named recovery coordinator, a clear escalation route, and a documented set of steps that don’t rely on one person’s memory. Staff need to know who calls whom, in what order, and what to do if that person is unreachable. This gets tested through tabletop exercises and fire drills – scheduled simulations where the team walks through a fake outage and finds the gaps before a real one exposes them.
Set a testing schedule around the importance of the systems and how often they change. Quarterly exercises may be a useful starting proposal, but the business should agree what is appropriate. Staff changes, upgrades and new access arrangements can all invalidate old instructions. Revisit those instructions after changes instead of waiting for the next scheduled exercise.
Where plans usually break down
The same errors are repeated in businesses of all types and sizes.
For instance, backups on the same network as the original systems may be exposed to the same compromise. Archives that are never checked can hide unusable files until someone needs them. Replication alone leaves questions about failback, communication and the people needed to recover. Ask whoever owns your compliance obligations which retention and recovery requirements apply, and build those into the review schedule rather than assuming a single annual check covers everything.
These are useful failure scenarios to test against your own plan, rather than reasons to assume that a completed setup will look after itself.
Closing the gap when you don’t have the expertise in-house
If your business has no dedicated resilience team, decide which work existing staff can own and where outside help would be useful. Building a new team is not the only option, but neither is handing the whole problem to a supplier without agreeing responsibilities.
A specialist IT provider may be worth considering when your team needs help turning recovery priorities into a technical plan. Ask what planning, monitoring and recovery testing a proposed service actually includes, who responds during an incident, and what remains your responsibility. Do not infer those services from a provider’s name or a general support description. The business still owns its impact analysis, priorities and budget decisions. Outside help is useful when it fills a defined skills or capacity gap and leaves everyone clear about their part in recovery.
Keep the plan alive
A disaster recovery plan is not a one-time thing. Version it, date it, and take a fresh look every time something new or different happens in the business – a new application, a new office, a contractor who has access to some of your more sensitive systems, an acquisition with technology you’ve never come across before.
Schedule a regular review of the business impact analysis, and revisit it after significant changes. Update RTOs and RPOs when the importance of a system changes. Treat a failed recovery test as a chance to fix a gap while normal operations are still available. The useful question is not how expensive the setup looks, but whether the plan still fits the business and whether the team can put it into practice.
Comments are closed.