A security incident tabletop asks whether the response team knows its procedures. A cyber resilience exercise asks a wider question: when a cyber event takes a critical service down, does the organization keep operating, make good decisions and recover within the limits it has set?
The people who answer that question are not all in security. Operations, legal, communications, finance, procurement and the executive sponsor all make calls in the first hours. If they have never made those calls together, the first time will be the real event.
This playbook walks through seven steps. It draws on NIST SP 800-84, which covers designing, conducting and evaluating test, training and exercise events, and on the exercise packages CISA publishes.
Step 1. Pick one question and one service
Exercises that try to test everything test nothing. Choose a single business service and write the question as a statement the exercise can prove or disprove. For example:
-
Can we continue taking customer orders by manual means for 24 hours if the order platform is unavailable?
-
Who decides whether to restore from an older backup, and how fast can they decide?
-
Can the executive team and legal agree a customer notification position within the time our contracts allow?
The question becomes the scoring criterion in Step 6.
Step 2. Choose the format
| Format | What it tests | Effort | Use it when |
|---|---|---|---|
| Discussion-based tabletop | Decisions, roles, escalation, communication | Low. A facilitated conversation around a scenario. | You need to find gaps in decision rights and coordination. |
| Functional exercise | Real tasks under simulated conditions: activating the out-of-band channel, retrieving runbooks, drafting statements | Medium. Participants use real tools and documents. | Decisions are mostly settled and you need to know whether people can execute. |
| Technical recovery test | Whether systems can actually be restored | High. Needs engineering time and an isolated environment. | You want evidence about recovery capability. See Playbook: Testing Ransomware Recovery. |
Most organizations should start with a discussion-based exercise, then move to functional work once the main decision gaps are closed.
Step 3. Put the right people in the room
A room made up only of security staff is the most common design flaw. Each role below has a decision the exercise should force.
| Role | Decision the exercise should force |
|---|---|
| Business service owner | What can be done manually, what must wait, and what loss is acceptable. |
| IT and infrastructure | Which services are restored first and in what order. |
| Security and incident response | Containment choices and what is known about scope. |
| Legal and privacy | Notification obligations, evidence handling, regulator contact. |
| Communications | Who speaks, what is said, and when. |
| Finance | Payment workarounds and the controls that keep them safe. |
| Procurement and vendor management | Which suppliers to call and what the contracts require. |
| HR | Staff communication, and cover if the disruption outlasts a shift. |
| Executive sponsor | Approvals, risk acceptance, external statements. |
Add two non-participants: a scribe who records decisions and times, and an observer who watches for gaps. Name a facilitator who does not have a stake in the outcome.
Step 4. Build the scenario and injects
Start from the question, then design events that force the decision. The scenario below is hypothetical and composite, written to illustrate the structure. It is not drawn from a specific incident. It reflects the pattern in current threat reporting, where ransomware operators go after identity services and backup infrastructure.
| Scenario time | Inject | Decision it forces | Capture |
|---|---|---|---|
| Start | Finance reports the payment system is slow. Security sees a spike in failed authentications. | Who declares an incident, and on what criteria? | Time to declaration. Who was involved. |
| 30 min | Corporate email and directory-based logins stop working. | Move to out-of-band channels. Who approves emergency access? | Whether the channel and contact list worked. |
| 90 min | A message from the attacker claims data has been stolen and includes a sample. | Engage counsel. Which notification clocks start? What goes in a holding statement? | Who owned the clock. Whether the claim was treated as unverified. |
| 150 min | The backup console is unreachable. The last known clean restore point is unclear. | Which services restore first? How is a clean point chosen? What data loss is acceptable? | Whether the business or IT made the call. |
| 4 hours | A major customer asks whether its data is affected. | What can be said, who says it, and what do the contract terms require? | Response time. Consistency with the legal position. |
| 6 hours | Operations asks to bypass system approvals to keep orders moving. Someone requests an urgent change to supplier payment details. | Which manual workarounds are allowed? How are payment changes verified? | Whether fraud controls survived the workaround. |
| 8 hours | A journalist and a regulator both call. | Who answers? Is the statement consistent with earlier decisions? | Whether messages stayed aligned. |
Scenario time can be compressed. A day of events can fit into a three-hour session as long as the facilitator keeps the sequence and the pressure.
Step 5. Run it
-
Start with degraded conditions. Declare corporate email and chat unavailable from the first minute.
-
Use real documents. Participants open the actual call tree, runbook and contract. If a document cannot be found or is out of date, that is a finding.
-
Do not rescue. If the team goes wrong, let it. The cost of a wrong turn is lowest here.
-
Answer from capability, not hope. When someone asks whether a restore is possible, answer from what the documented capability shows, not what they wish it were.
-
Make decisions explicit. Each decision is stated, attributed and written down with the time.
-
Keep one objective per inject. Too many threads obscure what you are testing.
Observers record time to decision, who decided, what information was used, and which assumptions went untested.
Step 6. Score against the question
Score only what the exercise was designed to test. Use three ratings: met, partly met, not met. Back each rating with an observation.
| Question | Evidence to look for |
|---|---|
| Were decision rights clear? | The same person was named as decision-maker by participants, and acted without delay. |
| Did the out-of-band channel work? | Participants joined, contact lists were current, records were kept outside corporate systems. |
| Were recovery priorities agreed with the business? | Service owners, not only IT, chose the restore order and accepted data-loss limits. |
| Did someone own each notification clock? | A named person tracked each obligation and the time it began. |
| Did manual workarounds exist for critical processes? | Documented fallback procedures were found and used, with controls intact. |
| Were external contacts reachable? | Retainer, insurer and key vendors were contacted using details already on file. |
Step 7. Turn findings into change
Each finding gets an owner, a fix and a date for retesting. Avoid a list of lessons learned with no owners attached. CISA’s tabletop packages include an after action report template that can serve as a starting structure.
Retest by running the same inject again once the fix is in place. If a decision that took 40 minutes the first time takes ten the second, you have evidence of improvement. If nothing changes, the fix did not work or the owner was not accountable.
Why exercises fail
-
Only security staff attend, so business decisions go untested.
-
The scenario is scripted so tightly that the team can never fail.
-
Too many objectives, so nothing is measured properly.
-
Findings go into a report and no one owns them.
-
The same scenario runs every time, so teams rehearse the exercise instead of building capability.
-
The exercise tests whether documents exist, not whether people can use them.
Next step
Pick one service, write the question, and book a three-hour discussion-based session with the full list of roles above.
Sources
-
NIST. SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities. csrc.nist.gov/pubs/sp/800/84/final
-
CISA. CISA Tabletop Exercise Packages — scenario templates including ransomware, role guidance and an after action report template. cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages
-
NIST. SP 800-184, Guide for Cybersecurity Event Recovery — recovery playbooks, realistic test scenarios and improvement. csrc.nist.gov/pubs/sp/800/184/final
-
Google Cloud / Mandiant. M-Trends, latest annual report — ransomware operators targeting identity and backup infrastructure. cloud.google.com/blog/topics/threat-intelligence
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionDetect, Respond & RecoverSpot attacks early and get back to business fast.See how we work →Related service
Resilience Testing
Use this to test resilience under realistic disruption.