How to Build a Business Disaster Recovery Plan

A server failure at 8.30am, a ransomware alert during term time, or a flooded comms room can stop an organisation far faster than most people expect. A business disaster recovery plan gives your team a clear, tested route back to safe operations – rather than relying on hurried decisions, incomplete backups and the one person who knows how everything works.

For UK businesses, schools and charities, recovery planning is not just an IT exercise. It is about protecting payroll, teaching, customer service, safeguarding information, reputation and the ability for people to do their jobs. The right plan creates peace of mind because it turns an uncertain event into a managed response.

What a disaster recovery plan should do

Disaster recovery, often shortened to DR, covers the restoration of technology, systems and data after a serious disruption. That disruption could be cyber crime, hardware failure, a power outage, fire, flood, failed update, supplier issue or human error. Business continuity is the wider discipline: how the organisation continues its essential work while services are unavailable.

The distinction matters. A backup is a copy of data. It is not automatically a recovery plan. If your files are backed up but nobody has confirmed where the backup is held, how long restoration takes, whether it is protected from ransomware, or which systems must come back first, you have a useful safety measure but not a dependable recovery capability.

A practical plan answers several uncomfortable questions before an incident forces them. Who declares an incident? How do staff communicate if email is unavailable? Can users work from another location or securely from home? Which applications are essential on day one, and which can wait? Who speaks to parents, customers, insurers, regulators or suppliers?

Start with the services your organisation cannot lose

Every organisation has a different definition of critical. An accountancy firm may prioritise practice management, document access and secure client communications. A school may need safeguarding systems, MIS access, telephony and network connectivity. A manufacturer may need line-of-business systems, stock control and site connectivity before anything else.

Begin by mapping your key services, not simply your hardware. Record what each service does, who depends on it, where its data is stored, its technical owner and its supplier. Include cloud platforms such as Microsoft 365, on-premises servers, internet connections, phone systems, finance software, backups and specialist applications.

Then agree two recovery measures with senior stakeholders. The recovery time objective, or RTO, is how long a system can be unavailable before the impact becomes unacceptable. The recovery point objective, or RPO, is how much data loss is tolerable. An RPO of four hours means you need to be able to restore data no more than four hours old.

These targets need to be realistic. Recovering every platform within minutes is expensive and may not be necessary. On the other hand, accepting a two-day recovery window for payroll, safeguarding or client records may create more risk than the apparent saving is worth. The right balance depends on operational impact, legal obligations and budget.

Make dependencies visible

Systems rarely fail in isolation. Your cloud application might rely on identity services, multi-factor authentication, internet connectivity and staff devices. A restored server is of little use if users cannot connect to it, licences cannot be activated or the phone system is still down.

Document those dependencies in the order they must be restored. This prevents a common recovery problem: technical teams working hard on individual systems while the organisation remains unable to operate.

Build recovery around people, process and technology

A recovery plan should be usable by someone under pressure, including people who do not work in IT every day. Keep the opening section concise: incident contacts, decision-makers, communication methods and immediate actions. Store it in more than one secure place, including an accessible offline copy.

Assign named roles, with deputies. A typical response needs an incident lead, technical recovery lead, communications owner and business representatives who can make priority decisions. For a smaller organisation, one person may hold more than one role, but there should never be a single point of failure.

Your documented procedures should cover the essentials:

• how an incident is identified, assessed and escalated;
• who can authorise a shutdown, failover or supplier engagement;
• how staff, customers, parents or other stakeholders will be kept informed;
• how to restore priority services and validate that they are safe to use; and
• how evidence, costs and decisions will be recorded for insurers, regulators and post-incident review.

For cyber incidents, include a clear rule: do not reconnect affected devices or restore data until the cause has been investigated and contained. Restoring too quickly can reintroduce malware, allow an attacker back in or overwrite evidence needed to understand what happened.

Design backups for recovery, not reassurance

Backups are only valuable if they can be restored when you need them. A sensible approach uses separate, protected copies rather than a single backup destination connected permanently to the same environment it is meant to protect.

The widely used 3–2‑1 principle is a useful starting point: keep three copies of important data, on two different types of storage, with one copy held off site. For greater resilience against ransomware, consider an immutable copy that cannot be changed or deleted for a defined period. Cloud services also need their own protection strategy. Microsoft 365 provides availability of the platform, but that does not necessarily mean it meets your requirements for recovering deleted, corrupted or maliciously encrypted data.

Your plan should state retention periods, backup frequency, encryption arrangements, account ownership and restoration responsibilities. It should also address access control. If a compromised administrator account can delete backups, the backup design has a serious weakness.

Test the business disaster recovery plan properly

A plan that has not been tested is a set of assumptions. Testing reveals missing credentials, undocumented dependencies, outdated phone numbers, unrealistic recovery times and gaps between technical recovery and operational readiness.

Start with a tabletop exercise. Bring together the people who would respond and talk through a realistic scenario, such as a ransomware attack affecting file access or a fire making the office inaccessible. Ask what happens in the first 30 minutes, first four hours and first working day. This is an efficient way to clarify ownership and communication without disrupting services.

Then carry out technical tests. Restore selected files, virtual machines or systems into a controlled environment and measure the actual outcome against your RTO and RPO. Test whether users can access the recovered service securely and whether data is complete. A successful restoration is not enough if the application cannot function or staff cannot log in.

Test frequency should reflect risk and change. Organisations with sensitive data, complex infrastructure or tight recovery requirements may need regular, scheduled validation. At a minimum, review the plan after a major systems change, office move, migration, cyber incident or change in key personnel.

Common gaps that create avoidable downtime

The most damaging weaknesses are often ordinary rather than dramatic. Supplier contacts sit in a former employee’s inbox. The plan refers to a server retired two years ago. Critical cloud accounts are tied to one administrator. Remote working was never tested at full scale. Or senior leaders assume the IT team can recover systems without deciding what takes priority.

There is also a tendency to treat cyber security and disaster recovery as separate projects. They are closely connected. Multi-factor authentication, least-privilege access, endpoint protection, patching, network segmentation and monitored backups all reduce the chance that a disruption becomes a full operational crisis. Recovery planning is stronger when it sits alongside an ongoing cyber security programme rather than being reviewed only at renewal time.

For organisations without an in-house specialist, an experienced managed service partner can provide independent challenge as well as technical delivery. Breathe Technology works with organisations to assess recovery risk, improve backup and security controls, and create recovery arrangements that suit the way their teams actually work.

Keep the plan alive

A good disaster recovery plan is short enough to use, detailed enough to guide action and regularly updated to reflect real change. It should be understood by leadership, IT and operational teams alike, because every one of them has a role in getting the organisation back on its feet.

The goal is not to predict every possible failure. It is to make sure that, when something goes wrong, your people know what matters most, who is responsible and how to recover with confidence.