Continuity & recovery

Purpose: what the Continuity & recovery section is for, the terms it uses (BIA, RTO/RPO, MTPD), and how it fits together with the policies, recovery register, and tabletop exercises you may already use elsewhere in CMDash.

This section's pages (/continuity, /continuity/bia, /continuity/plans, /continuity/recovery, /continuity/dependencies) read from the content documented here — the Business Continuity Plan, Disaster Recovery Plan, and Backup Policy templates, and the tabletop scenarios. Exact tier gating and role restrictions for each page can change; check the page itself, not this guide, for the current answer on either.

What it is

Continuity & recovery is CMDash's home for business continuity and disaster recovery planning — distinct from, and linked to, the Security Program and Tabletop Exercises you may already use. It has four parts:

Business impact analysis (BIA). The exercise that identifies your organization's critical business processes, how long each can tolerate being disrupted (its Maximum Tolerable Period of Disruption, or MTPD), and what each process depends on. The BIA drives everything else in this section — plan priorities and recovery-tier assignments both trace back to it.
Continuity plans. The Business Continuity Plan (the operational plan for keeping business processes running through a disruption) and the Disaster Recovery Plan (the technical plan for restoring systems and data), each available as a policy template you can adopt and customize from Compliance → Policies, or read about below.
Recovery objectives (RTO/RPO). The Recovery Time Objective and Recovery Point Objective committed for each system, tracked against your asset register and recovery-test history, so a committed target and an actually-tested result live next to each other instead of drifting apart silently.
Dependencies. The upstream and downstream dependencies (systems, vendors, personnel, facilities) a critical process or system relies on — the detail a BIA surfaces and a recovery plan has to account for.

When to use it

Start with the BIA before you write or adopt either plan — a continuity plan built without a BIA is a guess at what matters, not a plan. Adopt the Business Continuity Plan and Disaster Recovery Plan templates once the BIA gives you real priorities to plug into them, and the Backup Policy alongside the Disaster Recovery Plan since its 3-2-1/immutability/restore- testing requirements are what make the Disaster Recovery Plan's RPO commitments real rather than aspirational. Check Recovery objectives whenever you need to know whether a system's actual, tested recovery time meets what was promised — not just whether a backup job reported success. Run a tabletop exercise (see below) to rehearse the plans before a real disruption forces you to improvise.

Key terms

Business Impact Analysis (BIA). Identifies critical business processes, their MTPD, and their dependencies. See the glossary entry for the full definition.
Recovery Time Objective (RTO). The target elapsed time between a disruption and restoring a service. See the glossary entry.
Recovery Point Objective (RPO). The maximum acceptable data loss, measured as the age of the last recoverable data. See the glossary entry.
Maximum Tolerable Period of Disruption (MTPD). The longest a process can be disrupted before the impact becomes unacceptable to the organization — the number the BIA exists to establish per process. See the glossary entry.

The policy templates

Four templates in the policy library cover business continuity and disaster recovery:

Business Continuity and Disaster Recovery Policy — the program-level policy: objectives, the recovery-tier table, roles, and review cadence. Start here; it links to the three plans below under its own "Related plans" section.
Business Continuity Plan — the operational BCP: BIA-driven priorities, activation criteria, roles, communications, and the path back to normal operations.
Disaster Recovery Plan — the technical DRP: recovery strategy per system tier, RTO/RPO validation against the recovery register, DR runbook structure, and testing cadence.
Backup Policy — the 3-2-1 rule, immutability, restore testing, and retention that the Disaster Recovery Plan's recovery strategies and RPO commitments depend on.

Adopt any of them from Compliance → Policies → New from template; each pre-links to the compliance-framework controls it maps to (NIST 800-53, ISO/IEC 27001, SOC 2, CMMC/NIST 800-171, and NIST CSF 2.0 — see each template for its exact mappings).

Tabletop exercises for continuity

Three scenarios in the tabletop-exercise library exercise this section's plans specifically, alongside the existing security-incident scenarios (Ransomware, Business Email Compromise, Insider Threat, Cloud Breach):

Data Centre Outage — an extended loss of a primary facility, exercising Disaster Recovery Plan failover and RTO/RPO validation.
Cloud Region Outage — a provider-wide availability event with no security incident involved, exercising the Disaster Recovery Plan's activation trigger and single-vendor concentration risk.
Key Person Unavailability — the sudden, extended loss of a sole holder of critical operational knowledge or access, exercising the Business Continuity Plan's role and succession assumptions.

Schedule any of them from Security → Tabletop Exercises, the same way you would schedule the four existing scenarios.

Incidents & Exercises — the tabletop-exercise mechanism these three new scenarios run on, and how a declared security incident hands off to business continuity.
Policies & Attestations — adopting and customizing a policy template, including the four covered above.

This page is the product manual, published from the repository at docs/user/continuity.md. Customers read the same text inside CMDash under Help. Last updated October 9, 2026.