A recovery tabletop that tests business decisions

A recovery tabletop should show whether people can decide what to restore, who can authorise the work and how the business will operate while systems are unavailable. It does not demonstrate that a backup can be restored or that a recovery-time target has been achieved. Plan separate technical tests for those claims.

This guide addresses US and Canadian business teams using an internal discussion exercise. It is not an incident-response runbook or a determination of reporting duties. Regulated, safety-critical and personal-data scenarios need the relevant specialists and applicable legal requirements.

The Canadian Cyber Centre recommends identifying recovery priorities and testing plans, including in a test environment to avoid business interruption. NIST’s small-business guidance connects recovery responsibilities with lessons learned after an incident. These are useful foundations; the agenda below is an original suggested exercise design. 1 2

Choose one business service and define success before the meeting. Ask participants to identify real evidence and authority rather than simply agreeing that a plan exists. Separate planned recovery objectives from observed technical performance. Assign follow-up tests to gaps that discussion cannot resolve.

Select a service whose interruption matters, such as order acceptance or payroll preparation. Write down the minimum useful service, priority users, data needed, dependencies, provider contacts and business owner. Include identity access, network connectivity and any external interface needed to use the restored application.

Record the organisation’s approved recovery time objective and recovery point objective. RTO concerns the planned time and service level for recovery; RPO concerns tolerable data loss. State the clock convention and the data reference point used in your own plan, so exercise participants do not compare incompatible measures. The Cyber Centre explains these objectives alongside maximum tolerable downtime. 1

If objectives are missing, make that a finding. Do not invent ambitious targets during the exercise and then report that the business has a tested capability. Obtain business input on consequences and have competent technical staff assess what can be supported.

Invite the service owner, technical recovery lead, communications representative, relevant provider liaison and an observer. Include legal, privacy or safety specialists where the scenario warrants them. A facilitator should control the fictional events; an observer should record decisions and evidence requests. Label all materials as an exercise.

Use a sequence that forces a decision. Begin with an unavailable service. Then reveal that the primary contact cannot be reached. Later provide an uncertain backup time and a customer request for an update. Ask who has authority, what information is needed and what happens if that information remains unavailable.

Do not send simulated alerts to real customers or initiate a production failover as part of this discussion. If a technical demonstration is required, approve its scope, environment, safety limits and rollback arrangements separately. The Canadian ransomware playbook includes exercising participant roles as part of preparation; it is not a licence to experiment on operational systems. 3

Assume a distributor has a Canadian order desk and a US fulfilment provider. For this example only, its chosen RTO is four hours and its RPO is thirty minutes. At 09:00 UTC the order application becomes unavailable; the scenario supplies a last confirmed usable backup timestamp of 07:45 UTC. All figures and events are invented.

The supplied backup timestamp is seventy-five minutes before the stated outage, exceeding the illustrative thirty-minute objective. Participants should identify the gap and ask whether later usable data exists. They should not declare the RPO met because backups are normally scheduled every fifteen minutes.

At the next stage, assume the application can be restored but access credentials for the fulfilment connection are unavailable. The discussion should establish who can resolve that dependency, what restricted manual process is permitted and who can communicate uncertainty to customers. A functioning application alone does not settle the business-service question.

This scenario measures the quality of decisions and the availability of supporting information. It supplies no evidence of actual restore duration, backup integrity or transaction completeness.

For each decision, capture the scenario time, decision-maker, information used, assumption, chosen action and unresolved dependency. Mark evidence as available and inspected, claimed but not shown, or absent. Use the actual names of controlled records in the internal exercise log; avoid circulating sensitive credentials or system details.

Distinguish an exercise observation from a proven technical weakness. If a participant cannot locate a restore report, the observation is missing accessible evidence. Establish whether testing was absent or whether the record could not be found before writing a stronger conclusion.

Useful measures include decisions lacking an authorised owner, recovery dependencies missing from the plan and critical claims that require testing. A fast discussion or high attendance percentage is not evidence that the service can recover.

Fictional tabletop output for the scenario above. No restore or contact test has occurred. The discussion yields the following bounded findings:

The scenario gap is 75 − 30 = 45 minutes beyond the illustrative data-loss objective. That identifies a decision problem in the supplied facts. It does not prove a real organisation lost 75 minutes of data, nor that every backup fails.

The controller assigns the evidence requests to named roles and leaves the relevant findings open. A missing report should initially be logged as evidence unavailable during the exercise; further investigation can establish whether testing was absent or the record was simply inaccessible.

Report exercise completion separately from recovery readiness. Attendance, prompt answers and an agreed action list can support useful learning, but none supplies the technical measurements or verified service results deliberately outside this tabletop's scope.

Give each gap an owner, due date, acceptance evidence and reviewer. A missing contact might be resolved through an authorised contact check. A question about backup usability needs an appropriately controlled restore test. A disputed service priority needs a business decision, not a technical screenshot.

For a later restore test, agree the environment, representative data, integrity checks and user acceptance needed to judge the result. Capture actual timings and limitations. Follow our corrective-action guide when defining closure evidence and checking that the fix works. Corrective actions need evidence of effectiveness before closure

Does completing a tabletop prove our RTO? No. It tests planning and decisions. Claims about achieved recovery need relevant observed technical and business-service evidence.

How often should we exercise? Select a frequency based on consequences, obligations and changes. Revisit the plan after significant system, supplier or organisational changes; this guide sets no universal interval.

Can we use one global notification deadline? Do not assume so. Ask the appropriate specialists to map affected jurisdictions, contracts, data and reporting duties before building a notification decision into the plan.

1 Canadian Cyber Centre developing your IT recovery plan — ITSAP.40.004; live guidance checked 1 October 2026.

2 NIST Cybersecurity Framework 2.0 Small Business Quick Start Guide — NIST SP 1300; February 2024; voluntary framework implementation guidance.

3 Canadian Cyber Centre ransomware playbook — ITSM.00.099; live guidance checked 1 October 2026.

Explore the Risk & Excellence topic page for related guidance.

Prepared with AI-assisted research and drafting. The implementation method and hypothetical example are editorial guidance, not reported client results. QSE Advisory is part of the QSE Advisory brand family.

General information and suggested management controls. Obtain competent technical and jurisdiction-specific review before consequential use.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.