Disaster Recovery Planning
Know how long you can be down, and prove you can come back before the day you must.
Disaster recovery planning answers one question before it matters: if this system, this site or this region is gone tomorrow, how long until the business works again, and how much recent work is lost? Most companies cannot answer it, and the answer decides whether a ransomware attack, a hurricane, a fire or a failed cloud region is a bad week or the end of the company.
It is for any company whose work stops when its systems do: a New York law firm that holds privileged files, a Los Angeles marketing agency on cloud tools, a Connecticut investment firm under examiner scrutiny, a Chicago manufacturer whose plant needs its ERP, a Texas distributor with a warehouse that ships every day. The details differ and the method is the same.
At a glance
A disaster recovery plan designed around your business: which systems matter most, how long each can be down, how much data each can lose, and a tested way back. It connects to our Apocalypse IT Package for offline continuity.
The problem
Most companies have backups and call it a plan. A plan answers different questions: who decides, what comes back first, where it runs, how people are told and how long it takes. Ransomware, a hurricane, a fire, a failed cloud region or a vendor outage all end the same way for a company with an untested plan: days of guessing. We design the answer in advance and test it until the timings are measured, not hoped for.
A backup is not a plan. A plan names who decides, what returns first, where it runs, how people are told and how long each step takes, and it has been tested. The failures we see are ordinary: backups in the same building as the servers, restores nobody has timed, a single cloud region, no list of the accounts and licenses needed to rebuild, and a contact list that lives on the server that is down.
Ransomware changed the rules. Attackers look for the backups first, so a copy the attacker can reach is not a recovery option. Immutable and offline copies, and a clean room to restore into, are now part of the baseline. Our articles "Backups That Actually Restore" and "Ransomware Readiness and Incident Response" cover the principles in plain language.
Packages
Business impact analysis
We interview the people who run each process and rank every system by what an hour of downtime costs the business, what depends on it and what the law or a contract requires.
Recovery design
A recovery time objective (RTO) and recovery point objective (RPO) for every system, grouped into tiers, with the architecture that meets them: replication, immutable or offline backups, an alternate site or cloud region.
Runbooks and communications plan
Step-by-step recovery runbooks written for the person on shift at 3 a.m., plus who calls whom: staff, clients, insurer, counsel, regulators and vendors.
Failover and recovery testing
Tabletop exercises for decisions and live failover tests for systems, each timed and written up, so the plan's numbers come from tests.
Offline continuity
For long outages of any cause, our Apocalypse IT Package keeps core work running on site with the internet down.
Review cadence
A scheduled review after every significant change and at least once a year, so the plan matches the environment you run today.
What we deliver
- A business impact analysis ranking every system and process
- RTO and RPO per system, grouped into recovery tiers
- A recovery architecture: backup design with immutable and offline copies, replication, and an alternate site or cloud region
- Recovery runbooks for each tier, kept current
- A communications plan with contact trees for staff, clients, insurer, counsel and regulators
- Tabletop exercise reports and live failover test results with measured timings
- A ransomware recovery path: clean-room restore and verification before systems return
- A review calendar and a record of every change to the plan
- Evidence your insurer, client or examiner can read
We start with a business impact analysis. For every system and process we record who depends on it, what an hour of downtime costs, what a contract or regulation requires and what has to come back before anything else. The result is a ranked list that leadership signs off, not a technical inventory.
Next comes the recovery design. Each system gets a recovery time objective (RTO, how long it can be down) and a recovery point objective (RPO, how much data it can lose), and the systems are grouped into tiers. A tier-one system may need continuous replication to a second region or site. A tier-three system may need only a nightly immutable copy. Matching the design to the tier is how a plan stays affordable. The diagram on this page shows the relationship between RPO, RTO and the cost of each tier.
The architecture uses the copies and places that fit the tier. Backups follow the 3-2-1 rule with at least one immutable or offline copy that ransomware cannot alter. Critical systems run from an alternate site or a second cloud region, whether in a colocation cage, a private room or a cloud landing zone on AWS, Google Cloud, Microsoft Azure or Oracle Cloud. Our article "Hurricane-Proofing IT by Moving to the Cloud" is a worked example of moving out of a risk zone, and "Proving what you sent" shows how immutable email archives keep records unalterable.
The plan is only useful if people can follow it under stress. We write runbooks for each tier in the order of the recovery, with the commands, accounts and vendor contacts in them, and a communications plan that says who calls staff, clients, the insurer, counsel and regulators, and what each message says. A copy of both lives off the systems they describe, on paper where it makes sense.
Then we test. Tabletop exercises walk leadership through a scenario to test decisions and communication. Live failover tests move real systems to the alternate site or region and back, with the timings recorded and compared with the objectives. Every gap becomes a fix and a retest. The failover diagram on this page shows what a clean switchover looks like.
The Apocalypse IT Package is the offline layer of the plan. When an outage outlasts the cloud, whether from a regional disaster, a provider failure or an attack on a vendor, an on-premises kit with a local reference library, scanning, a private AI desk and local chat keeps core work running. Disaster recovery planning decides which of your processes need it and how it connects to your recovery tiers. See the Apocalypse IT Package for the details, and "Can the Internet Be Switched Off in the US?" for the reasoning.
The plan ends with a review cadence. It is reviewed after every significant change, such as a new system, a new site or a changed provider, and at least once a year, and the test schedule is part of it. The result is a plan that matches the environment you run today, with documentation current on the day we hand it over and every day after.
Backup tiers: data lost versus time to recover
Recovery point objective (RPO) is how much recent data a restore loses; recovery time objective (RTO) is how long the restore takes. Faster tiers sit close to the production system and share its fate; slower tiers survive ransomware and site loss. The scale is logarithmic. Illustrative figures.
Failover in under a second
ISP A fails at 300 ms. BFD (RFC 5880) with a 50 ms interval and multiplier 3 declares the session down 150 ms later, BGP withdraws the routes, and the forwarding table repoints to ISP B. Traffic is back at full rate in well under a second; without BFD the router would wait for the 90 s BGP hold timer. Illustrative figures.
An office that keeps working with the internet cut
A small on-premises server holds the law library, reads scanned mail, drafts correspondence with a local language model and runs chat. Scanner, printers and staff PCs sit on the same LAN behind a UPS, so a cut WAN cable changes nothing inside the office.
A Google Cloud landing zone built for a hurricane coast
Two regions outside the storm zone, a Shared VPC hub in each, guardrails set once at the organization, and two Partner Interconnect links through different carriers into different metro locations, with an HA VPN as the last resort. Staff reach apps through identity-aware access, not a VPN.
Our process
- 1
Analyze
A business impact analysis: what each system does, who depends on it and what downtime costs.
- 2
Design
RTO and RPO per system, tiers, backups that cannot be altered, and an alternate site or cloud region for what must keep running.
- 3
Document
Runbooks, a communications plan and an inventory of accounts, licenses and vendors needed to rebuild.
- 4
Test
Tabletop exercises and live failover tests, timed, with every gap written down and fixed.
- 5
Review
A review cadence tied to change, so the plan does not age out of date.
A plan that has never been tested is a guess. We would rather find a missing credential or a slow restore in a rehearsal than in a crisis, so the process ends in tests and the tests end in fixes. Evidence of those tests also supports what insurers, clients and examiners increasingly ask for: a documented plan with dates and timings.
Frequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWho needs disaster recovery planning?
Any company whose work stops when its systems do: law and accounting firms, investment firms, manufacturers, distributors, medical practices, agencies and growing companies of 10 to 500 people. If you could not say within an hour how long a full outage would last, you need a plan.
What are RTO and RPO?
The recovery time objective (RTO) is how long a system can be down before the business is hurt. The recovery point objective (RPO) is how much recent data you can afford to lose. Each system gets its own pair, and the pair decides what the recovery costs to build.
Is a backup the same as a disaster recovery plan?
No. A backup is a copy of data. A plan decides what returns first, where it runs, who does what and how long it takes, and it is tested. Our article on backups that restore covers the 3-2-1 rule, immutable copies and restore tests.
How do you handle ransomware?
The plan includes a ransomware path: immutable or offline copies the attacker cannot reach, a clean-room restore, verification before systems rejoin the network and a communications plan. Our ransomware readiness article turns the CISA #StopRansomware guide into a checklist.
How often do you test the plan?
We run tabletop exercises for decisions and live failover tests for systems, on a schedule agreed during scoping and after any major change. Every test produces measured timings and a list of fixes.
How does this relate to the Apocalypse IT Package?
The Apocalypse IT Package is the offline layer: an on-premises kit that keeps research, mail handling and staff chat running when the internet is down. Disaster Recovery Planning decides which work needs it and ties it to your recovery tiers.
Who is disaster recovery planning for?
Any organization that would lose money, clients or regulatory standing if its systems were down for a day or a week: law firms, investment firms, manufacturers, agencies, clinics and distributors, in any state. It matters most when you depend on one office, one server room, one cloud region or one person who knows how everything fits together.
What are RTO and RPO, and how do you set them?
RTO is the recovery time objective: how long a system can be down before the business is hurt. RPO is the recovery point objective: how much recent data you can afford to lose. We set both with you system by system, from a business impact review, because an email platform, a trading system and a file share rarely need the same answer. The targets drive the design and are written down.
How do you design a disaster recovery plan?
We start with an inventory of your systems, their dependencies and the people who run them, then rank them by business impact. We design the recovery path for each tier: backups, a second site or cloud region, network and identity failover, and a clear order of restoration. The result is a written plan with owners, contact lists and step-by-step runbooks, not a binder that sits on a shelf.
How do you test the plan?
A plan is only real once it has been run. We schedule restore tests that are timed against your RTO and RPO, tabletop exercises where your team walks through a scenario, and, where the business can support it, a live failover to the recovery site. Each test ends with a written list of what failed and what changed. Scope and timing are agreed during scoping.
What if the internet, power or the cloud is unavailable?
Then the plan has to work offline. Our Apocalypse IT Package covers continuity without internet access: an offline reference library, local procedures, alternate communications and a way to keep core work going for an extended outage. It is designed for the common causes, such as storms, fiber cuts, provider failures and ransomware at a vendor, and it ties into your disaster recovery runbooks.
How often is the plan reviewed, and what is it not?
We review it at least once a year and after any major change, such as a new office, a cloud migration, a new core application or a staff change in a key role. Disaster recovery planning is not a guarantee that nothing will go wrong, a replacement for good backups and security, or legal or insurance advice. It is a tested, documented way to get back to work, and your management decides the targets.