Implementing Business Continuity & Disaster Recovery

Foundation's Annex A survey covered business continuity (5.29-5.30) as a concept. This lesson is about actually building the two related but distinct plans behind it, and setting concrete, defensible recovery targets rather than vague aspirations.

BCP vs. DRP: related, not identical

• Business Continuity Plan (BCP) — how the entire business keeps functioning during a disruption, not just IT systems. Covers alternate work locations, communication trees, manual workarounds for critical processes, and critical supplier contacts.
• Disaster Recovery Plan (DRP) — specifically how IT systems and data get restored after a disruption. A subset of business continuity, focused on technical recovery: failover procedures, backup restoration (this roadmap, lesson 6), and infrastructure rebuild steps.

A DRP alone doesn't make an organization resilient if, say, no one has a plan for how customer support keeps operating with no access to the ticketing system for two days — that's a BCP gap a purely technical DRP would never catch.

RTO and RPO: setting targets, not guessing

Two metrics anchor continuity planning for each critical system or process:

• RTO (Recovery Time Objective) — the maximum acceptable time a system/process can be down before the impact becomes unacceptable.
• RPO (Recovery Point Objective) — the maximum acceptable amount of data loss, measured in time (e.g., "up to 4 hours of data loss is acceptable").

RPO directly drives backup frequency: if a system's RPO is 4 hours, backups must run at least every 4 hours — a nightly backup (24-hour RPO) does not satisfy a 4-hour RPO target, no matter how reliable that nightly job is. This is a common Implementer-level gap: a stated RPO that the actual backup schedule mathematically cannot achieve.

A simplified Business Impact Analysis (BIA)

A BIA identifies which processes are actually critical and sets their RTO/RPO — it's the risk-assessment-equivalent step for continuity planning, and shouldn't be skipped in favor of guessing:

For each critical business process:
1. What's the financial/operational/reputational impact per hour of downtime?
2. At what point does the impact become severe/unacceptable? → informs RTO
3. How much data could be lost/redone if the last backup point is used? → informs RPO
4. What dependencies does this process have (systems, people, suppliers)?

Not every process needs the same rigor — a BIA should prioritize genuinely critical processes (payment processing, customer-facing production systems) over lower-impact ones (an internal wiki), mirroring the risk-tiering principle from earlier lessons in this roadmap.

Choosing the right test type

Like the incident plan from the previous lesson, an untested BCP/DRP is an unverified assumption. Different test types trade off cost against realism:

A sensible program uses tabletop exercises frequently (e.g., annually) and reserves full functional tests for less frequent intervals or for the most critical systems specifically — full tests are valuable precisely because they catch things tabletop discussion alone cannot (e.g., a failover script that was never actually run and has a real bug), but their cost and disruption mean they can't realistically be the only or most frequent test type for every system.