Tabletop Exercises and Testing

To meet the tabletop exercises and testing requirement, you must run regular incident response tabletop exercises and simulations that prove your plan works, your people know their roles, and gaps get tracked through remediation. Treat this as an operational control: define a testing schedule, run scenario-based exercises with the right stakeholders (including key third parties), document outcomes, and update the plan. ¹

Key takeaways:

• Tabletop exercises must test both the incident response plan and team readiness, not just “talk through” a policy. ¹
• Evidence matters: you need agendas, scenarios, attendance, decisions made, issues found, and remediation tracking. ¹
• Operationalize with repeatable playbooks, a scenario library, and a closed-loop corrective action process tied to your risk register. ¹

“Tabletop exercises and testing” is a requirement because most incident response plans fail at the seams: unclear decision rights, missing contact paths, weak third-party coordination, and confusion about what must be reported and when. HICP Practice 8.3 expects you to run tabletop exercises and incident response simulations regularly to verify plan effectiveness and team readiness, then fix what you find. ¹

For a Compliance Officer, CCO, or GRC lead, the practical question is not “do we have an incident response plan?” It’s “can we prove we can execute it under stress, across business units, with Legal/Privacy, IT/Security, clinical operations, and critical third parties in the loop?” This page translates HICP’s requirement into an execution-ready program: who must participate, how to scope scenarios, what artifacts auditors ask for, and how to drive remediation so each exercise measurably improves readiness. ¹

If you need to stand this up quickly, the fastest path is a repeatable exercise template, a small scenario library tailored to your environment, and a corrective action workflow that assigns owners, due dates, and evidence of closure. Daydream can help you centralize scenarios, runbooks, attendance, findings, and remediation proof so tabletop testing is auditable rather than tribal knowledge.

Regulatory text

Requirement (HICP Practice 8.3): “Conduct regular tabletop exercises and incident response simulations to test plan effectiveness and team readiness.” ¹

Operator interpretation: You must do more than maintain an incident response document. You need a recurring testing program that:

• Exercises realistic incident scenarios against your actual plan and playbooks
• Validates that people can execute their roles (including decision-making and escalation)
• Identifies gaps and drives corrective actions to closure
  ¹

Plain-English interpretation of the requirement

A tabletop exercise is a structured, scenario-driven discussion where participants walk through what they would do during an incident. A simulation adds realism by testing workflows (for example, simulated alerts, mock communications, or timed decision points). HICP’s expectation is that you regularly run these to confirm the plan works in practice and your team is ready. ¹

From a compliance perspective, the control objective is defensible readiness:

• You can show that your incident response plan is executable.
• You can show that key roles understand responsibilities.
• You can show that you improve after each test.
  ¹

Who it applies to (entity and operational context)

HICP Practice 8.3 is applicable to:

• Healthcare organizations (providers, payers, and related healthcare entities)
• Health IT vendors that handle healthcare data, integrate with healthcare systems, or support clinical/business operations
  ¹

Operationally, you should treat it as in-scope anywhere an incident would create material risk across:

• Patient care operations and downtime procedures
• Protected health information and regulated data handling
• Billing, claims, and revenue cycle continuity
• Integration dependencies (EHR, imaging, labs, identity providers)
• Critical third parties (managed service providers, hosting/cloud, EHR vendors, call centers, payment processors)

If a third party plays a role in detection, containment, recovery, forensics, notification support, or core service delivery, your scenarios must account for them. Otherwise you are “testing a fantasy org chart,” not your operating reality.

What you actually need to do (step-by-step)

1) Define scope and ownership

Set a named owner for the tabletop program (often Security, with GRC coordinating evidence). Define which incident response plan(s) are in scope: enterprise IR, privacy incident response, ransomware playbook, downtime/BCP coordination, and third-party incident intake.

Practical decision: Decide whether you will run exercises as:

• A single enterprise series with multiple scenarios, or
• Separate tracks (privacy, cybersecurity, operational downtime) that share a common corrective action process

2) Build a scenario library tied to your real risks

Create a small library of scenarios you can rotate. Keep each scenario mapped to:

• A triggering event (what happened)
• Systems and data affected
• Likely decision points (shut down systems, isolate network segments, invoke downtime)
• Required notifications (internal and external)
• Third-party dependencies and handoffs

Starter scenarios (healthcare-relevant):

• Ransomware impacting clinical systems with patient care downtime
• Third-party compromise that affects your environment (for example, MSP tooling abuse)
• Email compromise and suspected data exfiltration involving PHI
• Cloud storage exposure with misconfiguration and external access concerns

3) Select participants and assign roles before the session

Invite the people who would actually act in the first hours of an incident:

• Security operations / incident commander
• IT infrastructure and identity
• Legal, Privacy, and Compliance
• Communications/PR
• Clinical operations leadership (for provider environments)
• HR (if insider actions are plausible in the scenario)
• Key third parties (or at minimum, validate their engagement paths and SLAs)

Make roles explicit: incident commander, scribe, comms lead, privacy lead, executive decision-maker, third-party liaison.

4) Prepare an exercise packet (so it runs like an audit-proof control)

Use a consistent template:

• Objective and success criteria (what “ready” means for this scenario)
• Scenario narrative
• Assumptions and constraints (for example, “EHR unavailable,” “email down,” “threat actor contacted PR inbox”)
• Injects: timed prompts that force decisions (for example, “media calls,” “law enforcement inquiry,” “patient safety issue reported”)
• Reference materials: current IR plan, call tree, decision matrix, third-party contacts, downtime procedures

5) Run the tabletop with real decision points

Facilitate tightly. Your job is to surface gaps, not to “win” the scenario.

• Start with the first alert and ask, “Who sees this first and how?”
• Force escalation: “Who gets paged? Who has authority to declare an incident?”
• Walk through containment: “What can we isolate safely without harming patient care?”
• Cover communications: “What do we tell staff? Patients? Partners? Regulators?”
• Bring third parties in: “Who opens the case? What information must we provide? What’s the escalation path if they’re unresponsive?”

A common hangup: teams describe actions without naming owners or channels. Stop and capture: owner name/role, system/tool used, and time sensitivity.

6) Document findings as corrective actions, not meeting notes

Your output is a punch list with owners and evidence requirements. For each gap, capture:

• Finding statement (what failed or was unclear)
• Risk implication (what could go wrong in a real incident)
• Corrective action (what will change)
• Owner, priority, and target completion criteria
• Evidence to close (updated runbook, revised call tree, screenshots, training record)

Tie high-risk items into your risk register and governance cadence so they do not die in a spreadsheet.

7) Update plans, playbooks, and training based on results

HICP’s purpose is plan effectiveness and readiness. If your IR plan remains unchanged after repeated exercises, auditors will question whether the program is real. ¹

Operational updates typically include:

• Revised escalation thresholds and incident declaration criteria
• Updated contact lists and third-party escalation paths
• Clearer decision authority (who can approve isolation, downtime, public statements)
• Stronger intake triage for suspected privacy incidents

8) Retest the changed areas

After major updates (new EHR module, identity platform change, M&A, new MSP), rerun a scenario that stresses those dependencies. The goal is continuous readiness, not “annual theater.” ¹

Required evidence and artifacts to retain

Keep artifacts in a centralized, access-controlled location. A solid evidence set includes:

• Tabletop/exercise schedule and scope statement
• Scenario documents and injects (version-controlled)
• Attendance records (names, roles, business units, third parties present)
• Facilitation guide and agenda
• Scribe notes that capture decisions, escalations, and gaps
• After-action report (AAR) with findings and corrective actions
• Corrective action tracker with owners and closure evidence
• Updated IR plan/runbooks/call tree versions reflecting improvements
• Management review sign-off for high-impact findings

Daydream is useful here because it can keep scenario templates, AARs, and corrective action evidence in one workflow so you can answer audits without scraping inboxes and chat logs.

Common exam/audit questions and hangups

Expect questions like:

• “Show the last tabletop exercise. Who attended and what scenario was used?”
• “What gaps were identified, and how do you prove remediation was completed?”
• “How do you decide which scenarios to test?”
• “How do third parties participate, and what happens if a critical third party is unavailable?”
• “How do you validate the incident response plan is current and executable?”

Common hangups auditors flag:

• Exercises that omit Legal/Privacy and Communications
• No proof of corrective action closure
• Scenarios that are generic and do not match your architecture or dependencies
• Contact lists and escalation paths that are stale

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in practice	Fix
Treating the tabletop as training only	Training without gap remediation does not demonstrate plan effectiveness	Require an AAR and corrective action tickets for every exercise
Not testing third-party handoffs	Most real incidents involve external dependencies	Include at least one third-party-driven scenario and validate escalation paths
No decision authority defined	The group “agrees” in the room but can’t act during a real incident	Build a decision matrix (who can isolate, who can declare, who can notify)
Storing artifacts in email threads	Evidence becomes incomplete and hard to retrieve	Centralize in a GRC system or a dedicated repository with versioning
Scenarios too easy	Teams “pass” but nothing improves	Add injects that create tradeoffs: downtime vs containment, speed vs accuracy

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Operational risk is still clear: if you cannot execute incident response under stress, you increase the chance of prolonged downtime, uncontrolled data exposure, missed notification obligations, and inconsistent communications. Tabletop exercises reduce those failure modes by forcing decisions and improving coordination before an actual event. ¹

A practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign program owner and define scope (which plans/playbooks are tested).
• Build a tabletop template: agenda, scenario format, inject format, AAR format, corrective action format.
• Identify core participants and back-ups; validate contact details and escalation paths.
• Draft two scenarios that match your top operational risks and key third-party dependencies.

By 60 days (run, document, remediate)

• Run the first tabletop with scribe and facilitator roles assigned.
• Publish the AAR within a tight internal turnaround window and open corrective actions with named owners.
• Update the IR plan/runbooks and call tree based on findings.
• Decide how you will track corrective actions to closure (ticketing system, GRC workflow, or Daydream).

By 90 days (prove repeatability and readiness)

• Run a second tabletop using a different scenario and include at least one third-party coordination decision.
• Verify closure evidence for the first exercise’s corrective actions and record management review.
• Add tabletop outcomes into governance: risk committee reporting, KPIs (qualitative if needed), and policy exceptions where gaps cannot be fixed quickly.
• Finalize a forward schedule so “regular” is demonstrable. ¹

Frequently Asked Questions

What counts as “regular” tabletop exercises under HICP Practice 8.3?

HICP Practice 8.3 requires that you conduct them regularly but does not define a fixed cadence. Set a documented schedule based on your risk profile and major change events, then follow it consistently. ¹

Do we need simulations, or are discussion-based tabletops enough?

The requirement calls for tabletop exercises and incident response simulations, so you should include at least some simulation elements. If you start with discussion-based sessions, add injects, timed decision points, and workflow testing to demonstrate readiness. ¹

Which teams must attend for the exercise to be credible?

Include the teams that make decisions and execute actions: Security/IT, Legal, Privacy/Compliance, and Communications, plus operational leaders relevant to the scenario. If third parties are critical to containment or recovery, include them or formally test the handoff and escalation path. ¹

What artifacts do auditors usually ask for first?

They typically start with the most recent scenario packet, attendance, and the after-action report. The deciding factor is proof that gaps were tracked to closure with evidence, not just identified. ¹

How do we handle sensitive details in tabletop documentation?

Keep scenario realism while restricting sensitive technical indicators, credentials, and investigative details. Store artifacts in an access-controlled repository and document decisions and process gaps without exposing exploit paths or defensive weaknesses.

How can Daydream help operationalize tabletop exercises and testing?

Daydream can centralize scenario templates, evidence collection, AARs, and corrective action tracking so each exercise produces audit-ready artifacts. It also helps you show a clean chain from exercise findings to plan updates and remediation closure.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices