How to Run an Incident Response Tabletop Exercise?

Incident response tabletop exercise with cybersecurity team reviewing a simulated security incident

An incident response tabletop exercise walks your team through a real attack scenario, out loud, in a room, without anything actually going wrong.

The point isn’t to test whether your written plan exists. It’s to find out whether the plan actually works once real people have to use it under pressure and that gap between “we have a plan” and “we’re actually ready” is usually bigger than anyone expects going in. 

Related Topic: What Is a System Security Plan? | Everything You Should Know

What a Tabletop Exercise Actually Is?

An incident response tabletop exercise walks your team through a real attack scenario, out loud, in a room, without anything actually going wrong. The point isn’t to test whether your written plan exists. Simulate realistic incidents to test how teams respond under pressure, uncover weaknesses, and measure the gap between planning and actual readiness.

A tabletop exercise isn’t a fire drill, and it isn’t a technical penetration test. Nobody’s system actually gets touched. Instead, a facilitator walks the team through a specific scenario, step by step, asking real questions as it unfolds: who gets notified first, who actually has the authority to make a call, what happens if the person who’s supposed to handle step three is out sick that day. 

Tabletop exercises test real response capabilities, uncover access issues, clarify decision ownership, and reveal gaps that written incident response plans often miss.

Related Topic: What Is a POA&M? Complete Guide for Defense Contractors

The Real Story: What One Exercise Actually Found 

One manufacturer working through CMMC Level 2 ran a full tabletop exercise covering a ransomware scenario, and it surfaced problems nobody had flagged in months of otherwise solid compliance work. 

The Access Gap Nobody Noticed Until the Scenario Ran 

Partway through the exercise, walking through what would actually happen if ransomware hit, the team realized a specific administrator no longer had direct owner-level access to their own VPN portal. Nobody had done anything wrong. Access had just drifted over time, the way it does in any growing environment, and nobody had a reason to check it until a scenario forced the question: if this happened right now, could you actually get in and shut it down. The answer, in that moment, was no. 

The Question Nobody Had a Clean Answer To 

The same exercise surfaced a second gap that looked small on paper and would have been a real problem in an actual incident: nobody was fully certain who owned the decision to implement a specific firewall rule change during a live event. Everyone assumed someone else had it covered. That’s exactly the kind of ambiguity a written incident response plan can say is resolved, right up until a real scenario asks the room directly and gets a pause instead of an answer. 

Not Every Scenario Needs the Same Playbook 

Test multiple incident scenarios because ransomware, stolen devices, insider leaks, and phishing attacks require different responses and reveal unique security gaps. Test phishing, data exfiltration, and access scenarios separately because each incident requires different response steps, priorities, notifications, and responsible stakeholders. 

Testing different incident scenarios helps teams uncover outdated playbooks, identify missing procedures, verify vendor changes, and address overlooked response gaps early.

Coordination Extends Past Your Own Team 

A real incident doesn’t stay contained to internal IT and security staff, and a tabletop exercise that stops at “notify the internal team” misses a real part of the picture. Depending on the scenario, coordination may need to extend to law enforcement, cyber insurance providers, legal counsel, and any external parties affected by the incident. Preserve evidence before remediation by completing forensic imaging before wiping devices, resetting systems, or prioritizing efforts to restore normal business operations.

None of this is exotic. It’s the kind of detail that’s easy to leave out of a written plan because it doesn’t come up until someone actually walks through what a real event would require, end to end, rather than stopping at the point where the technical fix begins. 

Related Topic: FCI vs. CUI: What Every Defense Subcontractor Needs to Know

Why “We Have a Plan” Isn’t the Same as “We’re Ready” 

Neither of those gaps showed up because the underlying incident response plan was poorly written. They showed up because a plan is a static document, and an environment isn’t static. People change roles. Access changes. Responsibilities shift between the IT team and the MSP without either side fully realizing the other assumed they had it. A tabletop exercise is the only reliable way to catch that drift before it costs you time during an actual incident, because it forces the specific question instead of accepting a general assumption that someone, somewhere, has it handled. 

The cost of skipping this step is measurable, not just theoretical. IBM research shows tested incident response capabilities significantly reduce breach costs, delivering greater savings than simply maintaining a written response plan.. A plan nobody has actually walked through under pressure isn’t earning that benefit. 

Tabletop exercises test phishing and data exfiltration scenarios while helping teams identify additional stakeholders who should participate in real incident responses.

Related Topic: Why Passing CMMC Starts With Finding the Gaps First?

How Often Is Often Enough? 

A different shop we worked with had a written incident response plan that looked complete on paper. Their last tabletop exercise had happened fourteen months earlier. Fourteen months is enough time for staff to change, for access to drift, for a vendor relationship to shift, for half the assumptions baked into that plan to no longer match reality. Nobody had done anything wrong by letting it slide. It’s just what happens to any process that isn’t deliberately kept current. 

An annual cadence is a reasonable floor, not a ceiling. If your environment changes meaningfully new staff in security-relevant roles, a new MSP relationship, new systems entering scope that’s a real trigger to run the exercise again sooner, not wait for the calendar to catch up. 

Who Actually Needs to Be in the Room 

This isn’t purely an IT exercise, and treating it like one is a common way to make it less useful than it should be. Choose participants who handle technical response, communications, and vendor coordination, ensuring the exercise includes everyone responsible during a real incident.

Business continuity matters here too. A real incident affects IT, finances, operations, and backups, so tabletop exercises must test business continuity alongside technical response procedures.

Tabletop exercises test recovery plans, uncover security gaps, identify vulnerabilities, strengthen business resilience, and help organizations meet CMMC incident response requirements.

What to Do With the Findings Afterward 

The exercise itself isn’t the deliverable. What actually matters is what happens with the gaps it surfaces. That means documenting exactly what came up  the access issue, the ownership ambiguity, whatever else got exposed assigning a real owner to each one, and treating it the same way any other open Plan of Action and Milestones item gets tracked, with an actual completion date rather than a vague intention to get to it. An exercise that surfaces real gaps and then doesn’t produce a documented follow-up plan has done half the job. 

Related Topic: CMMC Enclave vs. Enterprise: Which Compliance Model Works Best?

What To Do With This?

If your incident response plan hasn’t actually been tested with a real scenario recently, that’s worth fixing before an assessor asks about it, or worse, before a real incident does. 

Schedule a free consultation with our CMMC-certified team to talk through what a real tabletop exercise would look like for your environment. If you’re already working through CMMC compliance services with us, this is exactly the kind of gap worth catching in an exercise rather than during a real incident. A CMMC gap assessment is also a good way to confirm whether your incident response plan is one of the areas actually holding up under scrutiny. 

Related Topic: What Is a Passing CMMC Score and How Is It Calculated?

FAQ 

How often should tabletop exercises be performed?

Run tabletop exercises annually and after major changes involving staff, systems, vendors, security responsibilities, or incident response processes.

How do you run a tabletop exercise?

A facilitator presents a realistic incident scenario, asks response questions, tests decisions, evaluates responsibilities, and identifies gaps requiring improvement.

Who should be involved in a tabletop exercise?

Include IT teams, security staff, leadership, communications personnel, MSP representatives, and vendors who would actively support a real incident response.

Our Blog

How to Run an Incident Response Tabletop Exercise?

How to Run an Incident Response Tabletop Exercise?

An incident response tabletop exercise walks your team through a real attack scenario, out loud,…

Why GCC High Migration Costs Vary and How to Budget Smarter

Why GCC High Migration Costs Vary and How to Budget Smarter

Not every employee at your shop needs a GCC High license. The real question…

What Is a System Security Plan? | Everything You Should Know

What Is a System Security Plan? | Everything You Should Know

A system security plan often shortened to SSP  is a formal document that provides…