Infrastructure · Infrastructure Resilience · 02
Disaster recovery planning
Disaster recovery planning defines how the organization’s technology is restored after a major failure or attack: which systems come back first, from what, where, by whom and within what time, and how the recovery is run when the people who built the systems may not be available. It is needed when recovery depends on a few individuals’ knowledge, when recovery time has never been tested against the business’s expectations, when ransomware readiness requires rebuilding from trusted sources, or when a regulator, customer or insurer requires a documented and tested plan. Planning produces a system inventory with recovery priorities and dependencies, recovery procedures for each tier, the recovery environment and tooling design, and the test schedule that turns the plan into evidence.
Scope
What the review covers.
- System inventory with recovery tiers, objectives and dependencies
- Recovery strategies: backup restore, replication, failover, rebuild
- Recovery environment design, including isolated recovery for ransomware scenarios
- Procedures per system and per tier, written for responders under stress
- Roles, communications and decision authority during recovery
- Testing schedule and maintenance
Deliverables
What you receive.
| Deliverable | Form |
|---|---|
| Recovery inventory | Systems, tiers, objectives, dependencies |
| Disaster recovery plan | Procedures, roles, communications, decisions |
| Recovery environment design | Where and how systems are restored |
| Test schedule | From component restores to full drills |
Prerequisites
What we need from you.
- The application and infrastructure inventory and its owners
- Recovery objectives from the business impact analysis, or support deriving them
- Access to backup, replication and infrastructure platforms
Related
Where this sits.
By David Selakovic · Published 2026-10-16 · Revised 2026-10-16 · Reviewed every 180 days
Questions
Asked before engaging.
What if our objectives are unachievable with current backups?
The plan says so, with the options and costs to close the gap. An honest plan is more useful than an optimistic one.
Does the plan assume the attacker is still inside?
Ransomware scenarios require it. The recovery environment design includes isolated rebuild for that case.
How often is the plan tested?
Component tests regularly, a full drill at least annually. See Recovery testing and Backup recovery drills.