A tabletop exercise is a facilitated, discussion-based simulation where your team talks through how it would respond to a security incident — a ransomware outbreak, a data breach, a compromised vendor — without touching a single production system. It is not a live red-team drill; nobody hacks anything. A facilitator narrates a scenario, injects new developments, and the team decides who does what, in what order, and how fast. Most Indian SMBs have a written incident response (IR) plan sitting in a shared drive. Almost none have tested it. A tabletop exercise is how you find out, in a low-stakes two-hour session, whether that plan actually works before a real attacker forces the answer.
Why a Written IR Plan Isn't Enough
An IR plan is a document. A tabletop exercise is proof. Plans read well on paper — clear escalation paths, named owners, tidy communication trees — but they are written by one or two people during a calm afternoon, and they are rarely stress-tested against how a real incident actually unfolds: at 11 PM, on a Friday, with the on-call engineer on leave and the CEO traveling.
The gap between "we have a plan" and "we know the plan works" is exactly where incidents turn into disasters. CERT-In's guidelines and advisories emphasise that organisations must have not just a documented plan but rehearsed procedures, because untested plans routinely fail on basic execution — someone doesn't know who to call, a contact number is two years stale, nobody remembers who is authorised to take a server offline. NIST's Computer Security Incident Handling Guide, SP 800-61 makes the same point structurally: it lists incident response testing and rehearsal as a distinct, recurring activity separate from writing the plan itself, precisely because the two are not the same exercise.
What a Tabletop Exercise Actually Looks Like
A tabletop is structured, time-boxed, and low-drama by design. The core elements:
- A realistic scenario. Pick something plausible for your business — a ransomware note on the finance server, customer PII appearing on a paste site, a SaaS vendor emailing to say they were breached and your data may be exposed. Generic "hacker attacks company" scenarios don't surface real gaps; specific ones do.
- A facilitator. One person (often the CISO, IT lead, or an external consultant) runs the session, reads out scenario "injects" — new facts that arrive every 10-15 minutes — and keeps the discussion moving without solving problems for the team.
- Participants in their real roles. IT/security lead, a business owner or founder, legal/compliance, HR (if data involves employees), a comms/PR contact, and any relevant vendor or MSP contact. The point is to test the actual people who'd be in the room, not a hypothetical org chart.
- Decision points. At each inject, the team has to decide: Do we isolate this system? Do we notify affected users? Do we call our CERT-In empanelled forensics partner? Who signs off on a public statement? Do we need to file a report with CERT-In within the mandated timeline?
- A debrief. After the scenario ends, the facilitator runs a structured after-action review: what worked, what stalled, what nobody knew, what the plan should say that it currently doesn't.
Choosing a Realistic Scenario
The scenario is the single most important design choice. It should be specific to your business, plausible given your actual stack and vendors, and hard enough to force real decisions rather than obvious ones. Three scenarios that work well for most Indian SMBs:
- Ransomware on a core system. Files on a shared drive or a critical application server are encrypted. Backups may or may not be intact. This tests containment authority, backup verification, and the decision to pay or not pay (and who has legal authority to even discuss that).
- Customer data breach. A researcher, a journalist, or a dark-web monitoring alert flags that customer records — PII, financial data, or credentials — are exposed. This tests your DPDP Act breach-notification workflow, your customer comms plan, and whether you know which regulator or authority to inform and by when.
- Vendor or supply-chain compromise. A payment gateway, cloud host, or SaaS tool you depend on discloses that it was breached and your data might be affected. This tests your vendor risk visibility — do you even know which vendors hold what data — and your ability to respond to something outside your own infrastructure.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanCommon Gaps Tabletop Exercises Reveal
Across facilitated sessions, the same handful of gaps surface again and again — and they are almost never gaps in technical capability. They are gaps in coordination.
| Gap category | What it looks like in the room | Why it matters |
|---|---|---|
| Unclear ownership | Two people think they're the incident commander; nobody actually is | Decisions stall while people defer to each other |
| Missing or stale contact lists | The forensics partner's number was for someone who left two years ago | Hours lost re-discovering who to call |
| Legal/PR not looped in | Legal only hears about the incident after a public statement is drafted | Regulatory and reputational risk compounds |
| No DPDP breach-notification owner | Nobody knows the timeline or the authority to notify | Statutory exposure under the DPDP Act |
| Vendor contacts unknown | Nobody has the vendor's security escalation contact, only a sales rep | Delays containment on third-party systems |
| No decision authority for downtime | Nobody is empowered to take a revenue system offline without CEO sign-off, and the CEO is unreachable | Containment is delayed at the worst moment |
How to Run Your First Tabletop Exercise
You don't need a big budget or an external firm to run a useful first session. A practical path for a small Indian team:
- Block two hours, not a full day. A focused two-hour session with a clear scenario beats a rambling all-day workshop that people mentally check out of after 90 minutes.
- Write three or four injects in advance. Draft the opening scenario plus 3-4 escalating developments the facilitator will introduce at intervals. Keep each inject to a few sentences.
- Invite the real responders, not just IT. Include a business decision-maker, someone who can speak to legal/DPDP obligations, and whoever owns external communications — even if that's the founder wearing multiple hats.
- Assign a note-taker who isn't the facilitator. Someone needs to capture gaps in real time; the facilitator is too busy running the scenario.
- Run the debrief as a checklist, not a conversation. Go through: Did we know who was in charge? Did we have working contact numbers? Did we know our notification deadlines? Did legal get looped in before or after key decisions? Write every "no" down as an action item with an owner and a date.
- Update the plan and re-test. A tabletop that doesn't result in a revised IR plan was a discussion, not an exercise. Fix the gaps, then schedule the next tabletop for a different scenario.
Where Automated Testing Fits In
Tabletop exercises test people and process. They work best alongside — not instead of — technical testing of the systems those people will be defending. Running a free VAPT scan gives you a current picture of exploitable vulnerabilities across your external assets, which makes your tabletop scenarios more realistic: instead of a generic "ransomware hits a server," you can build the scenario around an actual exposed service or outdated component your last scan flagged. If your tabletop reveals gaps around personal-data breach notification specifically, pair it with a review of your obligations at /dpdp-compliance. For more on building the IR plan itself before you test it, see the Bachao.AI blog.
Gap Distribution From Facilitated Sessions
The chart below reflects the relative frequency of the gap categories most commonly logged during facilitated incident-response tabletop debriefs, based on the categories described above.
Building a Cadence, Not a One-Off
A single tabletop exercise is useful. A recurring cadence is what actually builds resilience. Aim for at least two sessions a year, rotating scenarios, and run an extra one whenever something material changes — a new critical vendor, a new data type you now handle, a reorg that changes who owns what. Each session should be shorter than the last as gaps close, and each debrief should feed directly back into the written plan so the document and the rehearsed reality stay in sync. Dhisattva AI Pvt Ltd, the company behind Bachao.AI, works with Indian SMBs to combine this kind of process testing with technical vulnerability visibility, so the scenarios you rehearse reflect the risks your actual infrastructure carries.