Disaster recovery plan: how to build it for mid-size and large

A disaster recovery plan is the set of processes, objectives and responsibilities that allow an organisation to restore its critical systems after a disruption, whether caused by a cyberattack, an infrastructure failure, human error or an external event. For mid-size and large companies, where an hour of systems down translates into concrete losses and reputational risk, it is not a compliance document: it is the difference between an orderly recovery and a prolonged crisis. This guide explains how to build one step by step, starting with the two metrics that govern every other decision.

What is a disaster recovery plan and why does it matter?

The disaster recovery plan defines, in advance, how normal operations are restored after a disruption. It does not seek to prevent the incident but to contain its impact: how long each system can be down and how much data it is acceptable to lose. It differs from the broader business continuity plan in that it concentrates on the technical recovery of systems, data and services. Without a documented and tested plan, recovery depends on improvisation at the worst possible moment.

The real cost of downtime

To justify investment in recovery, it helps to put numbers on what is being avoided. Every hour of systems down carries a cost combining lost revenue, halted productivity, contractual penalties and wear on customer relationships. In a mid-size or large company, that hourly cost is usually far higher than the contingency infrastructure that prevents it. On top of that comes reputational damage, harder to quantify but real: the trust eroded in a prolonged outage can take years to rebuild. Estimating the cost of downtime for critical systems is often the argument that turns the recovery plan from a good intention into a budgeted priority.

RTO and RPO: the two metrics that govern the plan

The entire design of a recovery plan turns on two objectives that must be set for each system. Defining them precisely, rather than as a single policy for the whole company, is what makes the plan realistic.

RTO (Recovery Time Objective)

The RTO is the maximum acceptable time a process can remain down after a disruption. It answers the question of how long it can take to get back to operating. A critical transactional system may demand an RTO of minutes, while an internal analytics platform tolerates hours. The shorter the RTO, the greater the investment in redundancy and automation it requires.

RPO (Recovery Point Objective)

The RPO is the maximum amount of data, measured in time, that the organisation can afford to lose. It answers how far back into the past it is acceptable to go. An RPO of five minutes implies near-continuous replication; one of twenty-four hours is covered by daily backups. Adjusting the RPO per system avoids paying for real-time replication where it is not justified.

How to build the plan step by step

With the metrics clear, the plan is built in five ordered stages. Each one feeds the next.

Business impact analysis

The starting point is the business impact analysis (BIA), which identifies critical processes and estimates what the company loses for each hour each of them is down. This exercise prioritises resources: not all systems merit the same investment in recovery, and the BIA makes explicit which ones are genuinely vital.

Risk and dependency assessment

The next step is to map likely threats and, above all, the real dependencies between systems. An application may look self-contained and in fact depend on a database, an identity service and a connectivity link. Recovering in the wrong order lengthens the outage, so dependencies must be documented. This map also reveals single points of failure, components whose collapse drags many others down, which are usually the first candidates to reinforce with redundancy. Without this exercise, a plan can look complete on paper and fail in practice because of a dependency nobody had mapped.

Setting objectives by application tier

Each application is classified into a criticality tier, and each tier is assigned specific RTO and RPO objectives. This segmentation is current best practice: it replaces blanket policies with granular targets that balance cost and protection.

Indicative reference values; each organisation adjusts its objectives according to its impact analysis. 

Runbooks and assigned roles

The objectives translate into runbooks: documented procedures describing, step by step, how to recover each system. Each runbook assigns owners with backup contacts, so that execution does not depend on a single person. In an emergency, the clarity of these documents is worth more than any technology.

Periodic testing

An untested plan is a hypothesis. The recommendation is to run full simulations at least once a year and tabletop exercises every quarter, as well as reviewing the plan after significant infrastructure changes or real incidents. Testing reveals mistaken assumptions before a disaster does.

Communication plan during the incident

Technical recovery does not happen in a vacuum. While the teams restore systems, the organisation needs to coordinate who informs the board, customers, suppliers and, where applicable, regulators. A plan that defines these channels and messages in advance avoids silence or improvisation in the middle of a crisis, two factors that tend to amplify reputational damage. Including communication as part of the recovery plan, with owners and templates ready, turns a chaotic response into an orderly one that preserves trust.

Disaster recovery and business continuity are not the same thing

The two terms are often used interchangeably, but they cover different and complementary scopes. The business continuity plan is the broad framework: it defines how the organisation keeps operating during a crisis, covering people, processes, communication and suppliers. The disaster recovery plan is the technical component of that framework, focused on restoring systems, data and services. One without the other leaves gaps: a continuity plan without technical recovery cannot keep its promises, and a recovery plan without continuity restores the systems but does not organise the company around them. Designing them in an articulated way, with clear responsibilities at both levels, is what distinguishes a prepared company from one that merely has backups.

Recovery strategies, from the simplest to the most robust

Defining objectives and runbooks leads to a practical question: how ready does the contingency infrastructure need to be. There are four reference strategies, ordered from lowest to highest cost and complexity, and each application is assigned to the one matching its criticality. Not every workload needs the most robust option, and paying for it where it is not justified is as common a mistake as falling short on vital systems.

Backup and restore

This is the simplest and most economical strategy. It consists of backing up systems and restoring them from that copy when an incident occurs. It offers the longest recovery time and allows for some data loss depending on backup frequency, so it is reserved for non-critical systems or for data that tolerates wide recovery windows.

Pilot light

In this strategy the essential components of the contingency environment are kept switched on at a secondary site, while compute capacity stays off until needed. On activation, the rest of the infrastructure is powered up. It reduces recovery time compared with restoring from backup, at moderate cost, because only the bare minimum is paid for permanently.

Warm standby

Here a scaled-down but fully functional copy of the production environment runs in another location. It can serve traffic at a lower level immediately and then scale to take on the full load. Being always active, it offers a lower recovery time than pilot light, in exchange for a higher cost of keeping the environment running.

Multi-site active-active

This is the most robust strategy and also the most expensive. Two or more locations serve requests simultaneously, and recovery amounts to redirecting traffic away from the affected site. It offers the lowest possible RTO and RPO objectives, close to zero, and is justified for the most critical systems, where every minute of downtime carries a high cost.

Common mistakes when building a recovery plan

Several mistakes recur and weaken plans that looked solid on paper. The first is not testing the plan: a procedure never executed in a simulation usually fails when it truly matters. The second is applying blanket objectives across the whole organisation, which leads to over-protecting secondary systems and falling short on critical ones. The third is ignoring dependencies between systems, which causes recoveries in the wrong order. The fourth is forgetting connectivity: without reliable links between the primary and contingency sites, replication and recovery do not work as planned. And the fifth is treating the plan as a static document, when it should be updated with every significant infrastructure change.

DRaaS: when it makes sense to delegate recovery

Building and operating an entire recovery infrastructure at your own secondary site is costly and complex. That is why many companies opt for disaster recovery as a service (DRaaS), where a third party provides and operates the contingency environment under agreed RTO and RPO objectives. The global DRaaS market reflects that trend: it is estimated at some US$16 billion in 2025, with sustained double-digit growth. At Liberty Networks we offer continuity and managed infrastructure solutions that allow these objectives to be met without duplicating investment in data centres of your own.

How to keep the plan current over time

A recovery plan is not finished the day it is documented. Infrastructure changes, applications are added, workloads migrate to the cloud and providers come on board, and each of those changes can invalidate the plan's assumptions. It is therefore worth reviewing it after every significant modification and, as a minimum, on a fixed annual cadence. The results of each simulation should translate into concrete adjustments, not be filed away. It also helps to designate an owner of the plan, with the authority to require that infrastructure changes consider their impact on recovery. A living plan that evolves with the organisation is the only guarantee that it will work when the time comes to use it.

Continuity as a business decision

A recovery plan does not protect servers: it protects revenue, customers and reputation. The underlying decision is not technical but commercial, and consists of defining how much disruption and how much data loss the organisation can tolerate, and then investing accordingly. That design also rests on reliable connectivity that allows replication and recovery between locations, so it is worth assessing alongside the business connectivity strategy. A well-built and tested plan turns a potentially catastrophic event into a manageable incident.

Sources

• TechTarget, RPO vs. RTO: Key Differences Explained: https://www.techtarget.com/searchstorage/feature/What-is-the-difference-between-RPO-and-RTO-from-a-backup-perspective
• Microsoft Learn, Business Continuity, High Availability and Disaster Recovery: https://learn.microsoft.com/en-us/azure/reliability/concept-business-continuity-high-availability-disaster-recovery
• InterVision, RPO, RTO and DRaaS: Disaster Recovery Explained: https://intervision.com/blog-rpo-rto-draas-disaster-recovery-explained/
• MarketsandMarkets, Disaster Recovery as a Service (DRaaS) Market: https://www.marketsandmarkets.com/Market-Reports/recovery-as-a-service-market-962.html
• AWS, Disaster Recovery of Workloads on AWS: Recovery Options in the Cloud: https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html