Most organizations of meaningful size have a business continuity plan. It may have been written to satisfy an auditor, an insurer, a board request, or a grant condition. It is usually well formatted. It often sits in a shared folder that would be unreachable during the very outage it is meant to address.
The problem with an untested plan is not that it is wrong. It is that nobody knows whether it is wrong. Contact lists go stale, systems change, staff turn over, and vendors are replaced. Assumptions that were reasonable when the plan was written quietly stop being true. The only reliable way to find out is to exercise the plan under realistic conditions, with the people who would actually have to carry it out.
Start with a business impact analysis
A continuity plan should be built on a clear understanding of what the organization cannot afford to lose, and for how long. That understanding comes from a business impact analysis, often abbreviated BIA.
A BIA is a structured conversation with each part of the organization. For every significant function, it asks a consistent set of questions:
- What does this function deliver, and to whom?
- What happens after one hour without it? One day? One week?
- Which systems, data, people, facilities, and vendors does it depend on?
- Are there legal, regulatory, contractual, or safety consequences to an interruption?
- What manual workarounds exist, and how long can they be sustained?
The output is a ranked view of business functions by criticality, with their dependencies mapped. This matters because technology recovery priorities should follow business priorities, not the other way around. When a BIA is skipped, recovery order tends to default to whatever the IT team happens to understand best, which may not be what the organization needs first.
RTO and RPO in plain English
Two measures sit at the center of most recovery planning. They sound technical, but the underlying questions are business questions.
Recovery Time Objective (RTO) is how long a function or system can be unavailable before the impact becomes unacceptable. It answers the question: how quickly do we need this back?
Recovery Point Objective (RPO) is how much data the organization can afford to lose, measured in time. If a system is restored from a backup taken four hours before the failure, four hours of work may need to be recreated or may be gone. It answers the question: how far back can we afford to go?
Shorter RTOs and RPOs are always possible, but they cost more. They require more redundant infrastructure, more frequent replication, and more operational discipline. The purpose of setting these targets deliberately is to spend where it matters and accept reasonable delay where it does not.
A common approach is to group systems into tiers. The table below is an illustrative example only. Appropriate targets depend on each organization's operations, obligations, and risk tolerance.
| Tier (example) | Typical functions | Example RTO | Example RPO |
|---|---|---|---|
| Tier 1: Critical | Safety systems, core clinical or broadcast operations, identity and authentication | Under 4 hours | Under 15 minutes |
| Tier 2: Essential | Finance and payroll, student or client information systems, primary email | Within 24 hours | Within 4 hours |
| Tier 3: Important | Internal collaboration, reporting, departmental applications | Within 72 hours | Within 24 hours |
| Tier 4: Deferrable | Archives, development environments, non-essential tools | Within 1 to 2 weeks | Within 1 week |
Once targets exist, they can be compared against what the current environment can actually achieve. That comparison is often the most useful single page in a continuity program, because it shows leadership exactly where expectations and capability diverge.
How to run an executive tabletop exercise
A tabletop exercise is a facilitated, discussion-based walkthrough of a realistic disruption. Nothing is actually shut down. Instead, leaders and key staff talk through what they would know, decide, and do as a scenario unfolds. It is the most efficient way to test a plan's assumptions without operational risk.
Choose a plausible scenario
The scenario should be credible for the organization and uncomfortable enough to be instructive. Ransomware affecting core systems, a prolonged outage at a primary site, the loss of a key cloud or managed service provider, or a regional weather event are all common choices. The scenario should unfold in stages, with new information introduced as the exercise progresses.
Invite the right participants
An executive tabletop should include the people who would make decisions in a real event: the chief executive or a delegate, operations, finance, communications, legal or compliance, human resources, and technology leadership. Where relevant, include facilities and the leads of critical business functions. Keep the group small enough for genuine discussion.
Facilitate, do not lecture
A neutral facilitator presents each stage of the scenario and asks direct questions. Who is in charge right now? How do we reach staff if email is down? Who decides whether to notify customers, regulators, or insurers? What do we tell the media? When do we invoke manual procedures? The facilitator's role is to surface assumptions and gaps, not to evaluate individuals.
Capture observations and assign owners
A designated note-taker should record decisions, points of confusion, and missing information in real time. Shortly after the exercise, those observations should be consolidated into an after-action report with specific improvement items, each with an owner and a target date.
Gaps a tabletop commonly exposes
The value of an exercise lies in what it reveals. Certain gaps appear across industries with notable consistency.
Unclear decision authority. Participants frequently discover that nobody is sure who has authority to declare an incident, approve emergency spending, or authorize public communication.
Communication dependencies. Call trees and notification plans often assume that email, collaboration tools, or phone systems will be available. In many realistic scenarios, they will not be.
Unverified recovery capability. Leaders may assume a system can be restored within a day, only to learn that the backup has never been fully restored or that restoration depends on a single person.
Inaccessible documentation. The plan itself may be stored on systems affected by the scenario. Printed or offline copies are frequently missing or outdated.
Vendor assumptions. Organizations often assume a provider will respond in a particular way or timeframe, without having confirmed what the contract actually requires.
Regulatory and contractual notification obligations. Participants may be uncertain about which notifications are required, to whom, and within what timeframe, particularly in regulated sectors such as healthcare and education.
Staff wellbeing and fatigue. Plans rarely address how a small team sustains recovery work over several days, including shift coverage and decision-making under stress.
None of these findings reflect poorly on the people involved. They are precisely what an exercise is designed to uncover, in a setting where the cost of discovery is a few hours of discussion rather than a live incident.
Make testing routine
A single exercise improves a plan. A regular testing cadence keeps it reliable. A reasonable pattern for many organizations is an executive tabletop at least annually, supplemented by technical recovery tests of critical systems and periodic updates to contact lists and dependencies whenever significant changes occur. Each cycle should begin by confirming that improvement items from the previous exercise were completed.
From document to capability
A business continuity plan is a statement of intent. Testing turns it into an organizational capability that leadership can rely on when it matters. The investment is modest, and the alternative is discovering the plan's weaknesses at the worst possible time.
To gauge where your organization stands, begin with our readiness assessment. If you would like support facilitating a business impact analysis or an executive tabletop exercise, schedule a consultation.