The Exercise That Passed Too Easily
Crestline Credit Union has run the same annual tabletop for four years. The scenario is a core banking outage; the facilitator reads injects from a script; participants confirm they would call the numbers in the contact list. Attendance is consistently above 90 percent and post-exercise surveys rate the session highly. This year a new resilience officer observes the exercise and notes three things: no one opened the actual recovery plan, the contact list was read aloud but no call was placed, and the stated recovery time of six hours was accepted without anyone checking whether the backup site could actually achieve it. She also learns that the exercise has never involved the call center, which handles customer inquiries during outages, and that the last live failover test was five years ago.
1. Diagnose why this exercise program is not producing assurance, referring to specific observations.
Read the worked answer
The program is measuring comfort, not capability. Each observation points to a different defect.
Nobody opening the plan means the exercise is testing memory and general competence rather than the usability of the document. A plan that has never been used under exercise conditions is untested; the exercise should have forced participants to navigate it, including the awkward parts like finding the current version and the correct appendix.
Reading the contact list without placing calls is the most serious gap. Contact data decays silently. An exercise that recites numbers proves the list exists, not that it works. A single round of test calls would have revealed stale numbers, changed roles, and unanswered after-hours lines - the exact failures that consume the first hour of a real incident.
Accepting the six-hour recovery time without verification means the exercise validated an assumption rather than a capability. Combined with a five-year-old failover test, the organization has no current evidence that the target is achievable. The number in the plan and the number the technology can deliver may have diverged years ago.
Excluding the call center is a scope error. During a core outage the call center is where the customer experience of the incident actually happens, and it has its own dependencies, scripts, and staffing decisions. An exercise that omits the highest-volume customer-facing function cannot claim to have tested the response.
High attendance and positive surveys are consistent with all of these defects. Satisfaction measures how the session felt, not what it proved.
2. Redesign the exercise program for the next two years. Be specific about what changes and why.
Read the worked answer
Build a progressive program that moves from discussion to demonstration to live disruption, with each step justified by what it proves.
Year one, first half: keep a tabletop but change its rules. Participants must use the actual plan and contact list, place real test calls to a sample of contacts, and document every point where the plan was unclear or wrong. Include the call center and at least one business line that has never participated. Capture findings as corrective actions with owners and dates.
Year one, second half: run a functional exercise on a single recovery component - for example, fail over one non-critical application to the backup site and time it. This produces the first current evidence about whether recovery targets are realistic. If the measured time exceeds six hours, the plan's target must be revised or the capability improved, and that decision belongs to the business owner.
Year two: conduct a live failover test of the core banking platform in a controlled window, with the call center operating its outage scripts and customer communications drafted but not sent. This is the only test that validates the six-hour claim end to end.
Throughout, change the reporting. Track corrective actions closed, recovery times measured versus targeted, and contact-list accuracy, rather than attendance and satisfaction. Report those to executive management and the board risk committee.
The sequencing matters: jumping straight to a live core failover without first fixing the plan and contact data would generate noise rather than learning. Each phase should close the gaps the previous phase exposed.