Ask most companies whether they have a disaster recovery plan and the answer is usually yes. Ask when they last tested it against a real scenario, and the room goes quiet. A recovery plan you have never tested is not a plan. It is a guess written down, and disruptions have a way of exposing guesses at the worst possible moment.
Business continuity that actually works rests on two things: knowing exactly what you are committing to, and proving you can deliver it before you need to.
Start with two numbers
Every meaningful continuity conversation begins with two objectives, defined per system rather than for the company as a whole:
- RTO (Recovery Time Objective) -- how long a system can be down before the impact becomes unacceptable.
- RPO (Recovery Point Objective) -- how much data you can afford to lose, measured in time.
These are business decisions, not technical ones. The order-taking system might need an RTO of minutes and near-zero RPO, while an internal reporting tool can tolerate a day. Setting these honestly forces a useful conversation: faster recovery and less data loss cost more, so you are deciding where that investment is worth it.
Without an RTO/RPO matrix, every system implicitly gets the same priority, which means none of them are actually prioritized.
A backup is not a recovery
The most common and dangerous assumption is that backups equal recoverability. They do not. Backups fail silently. Restores take far longer than expected. The one system nobody backed up turns out to be the one everything depends on.
Recoverability is only proven by restoring -- ideally on a schedule, into a clean environment, with someone timing it against the RTO you committed to. Until you have done that, your backups are a hypothesis.
This is why backup validation is a distinct activity in our Reliability, Operations and BCDR work, separate from simply running backups. A backup that has never been restored is a liability dressed as a safeguard.
Write the runbook, then rehearse it
When a real incident hits, people do not rise to the occasion. They fall back on their preparation. That preparation has two parts:
Runbooks -- step-by-step recovery procedures specific enough that someone who is not the original architect can follow them under pressure. If recovery depends on one person's memory, that person is a single point of failure.
Tabletop exercises -- walking the team through a realistic scenario before it happens. Tabletops reliably surface the gaps you cannot see on paper: the credential nobody can find, the dependency nobody mapped, the vendor whose support hours do not match your RTO.
The pattern we see again and again: the first tabletop exercise is humbling, and that is exactly why it is valuable. Better to find the gap in a conference room than at 3 a.m. during an outage.
Make recovery a habit, not an event
Resilience decays. Systems change, dependencies shift, and a plan that was accurate last year quietly goes stale. The organizations that recover well treat continuity as an ongoing cadence rather than a binder produced once for an auditor:
- Review RTO/RPO as systems and business priorities change.
- Validate backups on a regular schedule, not just after an incident.
- Run tabletop exercises and recovery tests at least annually.
- Update runbooks whenever the architecture changes.
That cadence is what turns a document into a capability. It is also what gives executives a defensible, evidence-backed answer when the board asks whether the business can survive disruption.
What good looks like
A continuity program that works is not exotic. It is an RTO/RPO matrix grounded in business impact, runbooks anyone on the team can follow, validated backups, tested recovery, and a regular tabletop cadence. The components are well understood. What is rare is the discipline to test them before they are needed.
If your recovery plan has never met a real scenario, you do not yet know whether it works -- and that is the one thing you cannot afford to learn during an outage. A resilience assessment can pressure-test your RTO/RPO assumptions, validate your backups, and turn a plan you hope works into one you have proven.