What is a disaster recovery plan?
A disaster recovery plan (DRP) documents how an organization brings its technology back after a disruptive event: a data center fire, a storage failure, a regional power outage or a ransomware attack. It covers which systems are restored, in what order, where, by whom and how fast. It is part of the broader business continuity effort. The business continuity plan (BCP) keeps critical functions running, often with manual workarounds, while the DRP restores the systems those functions depend on.
Recovery targets drive the plan
Every critical system in the DRP carries two targets taken from the business impact analysis (BIA):
- Recovery time objective (RTO): how quickly the system must be working again after a disruption.
- Recovery point objective (RPO): the most data loss the business can accept, measured in time. An RPO of 15 minutes means the restored copy can be no more than 15 minutes old.
| Tier | Example systems | RTO | RPO |
|---|---|---|---|
| 1 | Payments, order processing | 4 hours | 15 minutes |
| 2 | Email, ERP reporting | 24 hours | 4 hours |
| 3 | Intranet, training portal | 72 hours | 24 hours |
The targets have to be achievable. A 15-minute RPO cannot be met with nightly backups, and a 4-hour RTO fails if the restore takes 12. A good plan records such gaps so leadership can fund a fix or formally accept the risk.
What a disaster recovery plan contains
- Activation criteria and the person authorized to declare a disaster
- Recovery team roles with primary and alternate contacts, plus vendor and carrier support numbers
- The recovery site, whether a hot, warm or cold site or cloud-based recovery, with access and contract details
- Where backups are kept, how to reach them, and how to retrieve encryption keys and administrator credentials
- The restore order, with references to detailed runbooks for each technical step
- Validation steps, failback to the primary site and stand-down criteria
Recovery happens in dependency order
Applications cannot start without the services beneath them, so a DRP restores in layers: network connectivity and firewalls, then DNS, DHCP and time synchronization, then identity services such as Active Directory, then databases and storage, then application servers, and finally user-facing front ends. Recovery is not finished when the servers boot; business owners confirm that applications work and the data is correct.
A cyberattack adds steps that a fire does not need. Systems are restored into a clean, isolated environment, restored data is scanned, credentials are reset, and the attacker's entry point is closed before anything reconnects. Restoring before incident responders have contained the attacker can simply hand them fresh systems to encrypt.
Testing the plan
Tabletop exercises test decisions and contact lists without touching production. Simulations carry out the steps in a test environment. Parallel processing runs the recovery systems alongside production and compares results. Failover tests move a real workload to the secondary site, and a full interruption test shuts the primary down completely. The usual rule is to choose the least disruptive test that still proves what needs proving.
Disaster recovery plan on the CompTIA Security+ exam
The DRP appears in SY0-801 objective 5.1 as a governance document and in objective 3.4, which covers resilience and recovery: recovery sites, backups, testing and recovery metrics. A scenario about restoring servers and data at a recovery site in a set order, failing systems over or meeting an RTO points at the disaster recovery plan. A scenario about keeping staff working with paper forms or an alternate office points at the business continuity plan instead, and containing an intruder points at the incident response plan. If the question asks what sets the recovery targets, the answer is the business impact analysis. Remember that the DRP is a subset of continuity planning, not a substitute for it.