What Is a BCDR Policy, Runbook and Tabletop Program?
What Is a BCDR Policy, Runbook and Tabletop Program?
A BCDR policy states what your organization commits to recovering and how quickly. The runbook is the step-by-step procedure for actually doing it. The tabletop exercise programme is how you find out whether either of them works before a real incident does the testing for you.
At DAG Tech, all three are delivered together as a CxO™ Virtual CTO deliverable, because separately they fail predictably: a policy with no runbook is an aspiration, a runbook nobody has rehearsed is fiction, and exercises without a policy have nothing to test against.
Why BCDR Plans Fail When Used
Almost every organization we assess has something. The gap is between having it and being able to use it:
- Recovery objectives were never agreed with the business. IT set an RTO nobody in operations has seen, and it does not match what the business actually needs.
- The runbook assumes normal conditions. It references a system that is down, credentials in a vault that is unreachable, or a person who is unavailable.
- Backups were monitored, not tested. Green dashboards for two years, and the first real restore attempt is the first restore attempt.
- Nobody knows who declares a disaster. Hours are lost deciding whether this counts as one.
- It was never exercised. The plan is technically accurate and operationally untried, and it is written for people who are calm.
How DAG Tech Builds a BCDR Program
1. Business Impact Analysis
Objective: Let the business, not IT, set the recovery targets.
- Identify critical business processes and the systems each depends on.
- Quantify the cost of downtime per process, per hour, so targets can be justified.
- Agree recovery time objectives and recovery point objectives with process owners.
- Map interdependencies — a four-hour target for one system is meaningless if it depends on another with a two-day target.
This is where most of the value sits. An RTO agreed with the person accountable for the process is a commitment; one set by IT alone is a guess.
2. Write the Policy
Objective: State the commitments, the authority and the obligations.
- Scope: which scenarios are covered — outage, ransomware, site loss, supplier failure, key-person absence.
- Agreed RTO and RPO per system, traceable to the impact analysis.
- Roles: who declares an incident, who leads recovery, who communicates externally.
- Escalation and notification obligations, including regulatory and client contractual timelines.
- Testing commitments and review cadence, so the policy obliges its own maintenance.
3. Build the Runbook
Objective: Produce a document usable by a stressed person at 3am.
The runbook is written in the order actions are performed, not in the order systems appear on a diagram. It assumes degraded conditions: primary systems unavailable, the usual people unreachable, and the network you normally rely on down. Credentials and contact details are referenced from a location that survives the scenario, which is the detail most runbooks get wrong. Every procedure names the role performing it and the verification step that confirms it worked.
4. Run Tabletop Exercises
Objective: Find the gaps in a conference room rather than during an incident.
- Scenario-driven walkthroughs with the people who would actually respond, including leadership.
- Injected complications mid-exercise — the person who owns the step is on leave, the secondary site is also affected.
- Decision points tested explicitly: who declares, who authorizes spend, who talks to clients.
- Every gap recorded as a numbered finding with an owner and a due date.
- Technical restore testing alongside the discussion, because a restore nobody has performed is not a capability.
What the Deliverable Actually Looks Like
The programme produces three linked artefacts and an operating cadence. The pack runs in eight sections.
Sections 1–3: Scope, approach and business impact analysis
What is covered and which disruption scenarios are in scope, the standards applied, then the impact analysis with criticality, RTO and RPO agreed per system and signed by process owners.
Sections 4–6: The policy, the runbook and the exercise programme
The three artefacts themselves. Every system in the policy carries the same fields:
- System and business process supported — what stops if it stops.
- Criticality tier — and the downtime cost behind the rating.
- Agreed RTO and RPO — with the process owner who signed them.
- Recovery method — failover, restore, rebuild or manual workaround.
- Dependencies — what must be recovered first.
- Runbook reference — the numbered procedure that recovers it.
- Last tested date and result — the field that separates a plan from a capability.
The runbook then carries numbered procedures in execution order, each with the role responsible, the prerequisites, the steps, the verification test and the expected duration. The exercise programme defines scenarios, cadence, participants and how each run is scored.
Sections 7–8: Findings and the review schedule
What testing broke, written as numbered remediation items with owners and dates, then sign-off and the review schedule for each artefact. BCDR documents decay faster than almost anything else in IT, so the review cadence is part of the deliverable rather than an intention.
Where the BCDR Program Fits
The BCDR policy, runbook and tabletop exercise programme are CxO™ Virtual CTO deliverables that depend on the technology assessment for an accurate system inventory and on the digital foundation plan for the backup and recovery standards underneath them. They are supported operationally by our managed cybersecurity practice, since ransomware is now the scenario most likely to invoke them.
The question is never whether you have a BCDR plan. It is when you last watched someone try to use it.
Contact DAG Tech today to scope a BCDR policy, runbook and tabletop exercise programme.
Related reading: NYDFS Cybersecurity Regulations · SEC Cybersecurity Compliance · Build a Compliance Readiness Plan
