A disaster recovery plan sets out which systems come back, and in what order, after an outage. Learn how to use RPO and RTO according to your business's real needs.
A power or internet outage, a hardware failure, an accidental deletion, a cyber incident or physical damage can bring day-to-day work to a halt without warning. A disaster recovery plan is the working arrangement that sets out in advance which system comes back first, where data is restored from and who makes the decisions. The aim is not to predict the disaster, but to act in an orderly way when things are uncertain.
Understand the business impact
Start the plan with business processes, not a list of technology. Write down which applications order-taking, production, sales, accounting, customer service or the field team depend on. For each process, discuss who would be affected by an outage, how people could work in the meantime and which system needs to come back first.
Business owners, department managers and IT staff should take part in this assessment together. The technical team knows how the systems work; the business units know what a stoppage really means. Reconciling different priorities into a single list is what makes the plan usable.
What are RPO and RTO?
RPO (Recovery Point Objective) expresses the maximum acceptable data loss as a period of time: it shows how recent the data you return to after recovery needs to be. For example, if a system is only backed up overnight, changes made during the day may be lost; the RPO this arrangement can meet is roughly 24 hours. That does not mean every system must be backed up at the same frequency; frequency should be decided by how critical the data is.
RTO (Recovery Time Objective) sets the maximum time within which a system must be usable again once an outage has begun. It should fall within the longest outage the business can tolerate without unacceptable harm. RTO is a target and a decision-making tool; it is not a promise that comes automatically with a product you buy. Shorter RPO and RTO targets generally require more preparation, additional infrastructure and higher cost.
RPO and RTO values should not be set by the technical team alone. They are management decisions about how much data loss and downtime the business can withstand; the technical team's role is to show what infrastructure and cost it takes to meet them.
Key components of the plan
System and dependency inventory
List servers, cloud applications, file storage, network devices, email, internet connectivity and authentication services. Add which services each application depends on to run. If the sales application needs the internet, user accounts, a database and file storage, all of these belong in the recovery order; otherwise you may face surprises such as "we brought the application back, but nobody can log in". A short sequence you can glance at during an incident is more useful than a complex diagram.
Backup and restore design
Document which data is backed up, how often, where to and under whose responsibility. Keeping backups on a system separate from the primary one, restricting access to them and testing restores regularly are core parts of the plan; the 3-2-1 rule is a good starting point for distributing copies. It should also be clear who receives an alert when a backup fails.
Communication and chain of command
Who will inform staff, customers, service providers and management during an incident? Keep up-to-date contact details for the technical lead, application owners, the manager who makes decisions, internet and cloud service providers, and external support. This list, and the plan itself, must be reachable even when systems are down; alongside a secure digital copy, keep an offline or printed one. Separate people can be made responsible for technical response, business priorities and external communication.
Alternative ways of working
Write down how work will continue until the critical system is back. Temporary measures such as manual records, taking orders by phone, limited access or working from another location differ from business to business. Also decide when these measures kick in and how records kept in the meantime will later be entered into the system.
Build the plan step by step
Start with a few of the most critical processes. For each, record the system owner, the RPO and RTO, the backup source, the person responsible for recovery and the verification step. Details such as the network, internet access, user accounts or licence access can delay recovery, so add them to the dependencies as well.
Don't leave recovery steps in purely technical language. Make it clear who starts the process, who approves it and who tells the business unit that things are "ready". Next to each step, note where the required access information or document can be found; but never put passwords or access keys in the plan file.
The plan needs management approval and a link to the budget. If reaching the target time requires extra backup storage, a secondary internet connection or a support agreement, decision-makers need to know; otherwise a gap opens up between what the plan says and the resources actually provided.
Testing and improvement
An untested plan is an assumption. As a first step, walk through an outage scenario together as a team in a tabletop exercise. Then try a real restore of selected data or a selected system.
Not every test requires shutting down the whole system. Narrow exercises, such as recovering a user account, restoring a sample folder from backup or calling through the contact list, also yield valuable information. For each exercise, note the time taken, the obstacles encountered and the next improvement step; these records show whether your RPO and RTO targets are realistic.
A failed test is also a valuable result, because it brings problems to light before a real incident. Update the plan after every significant change, such as a new application, a new location, a change of service provider or a change in roles.
Verification after recovery
Switching a system back on is not the end of recovery. Together with the business unit, confirm that the application is running with the correct data, that users have the access they need and that the core tasks can be carried out. In a partial recovery, keep visible which operations have been postponed. After a cyber incident, before you start restoring, make sure the attacker's access has been shut off and that the backup you use dates from a point unaffected by the incident.
The decision to return to normal operations and remove temporary workarounds should be made by the responsible person. Once the incident is closed, hold a short review: which steps worked well, and which caused delays? These notes strengthen the next exercise and the decisions made in a real incident.
Checklist
- Have critical business processes and the systems supporting them been identified?
- Have RPO and RTO been agreed with the business units for each critical process?
- Are system dependencies and the recovery order written down?
- Are the location, owner and restore testing of backups clearly defined?
- Can the plan and contact list be reached even when systems are down?
- Is there a defined alternative way of working during an outage?
- Has the plan been tested with a tabletop exercise or a real restore?
- Is the plan updated when systems or roles change?