Tabletop Exercise Templates for the CISO — Five Scenarios Worth Running in 2026

Published May 19, 2026 · By AxVeil Resilience · 16 min read

The best incident response programmes treat tabletops like fire drills: structured, frequent, independently facilitated, and ruthlessly post-mortemed. The worst use them as a one-page item in an ISO 27001 evidence binder. This article gives you five scenarios you can run with your leadership team this quarter — each with a facilitator script, a set of injects designed to surface the decisions you actually need to make, and a hot-wash template that produces real action items. The five are picked because they cover the regulatory drivers Indian, EU, and US-headquartered organisations have to answer to in 2026, and because they exercise different muscles (technical, legal, communications, executive). Pair them with quarterly VAPTand annual red team engagements for a complete validation programme.

Tabletop format — the universal frame

Every scenario in this post uses the same structure. Build one template, reuse it forever.

• Orientation (15 min). Facilitator states the rules: this is a drill, no judgement, no "gotchas", decisions made here are notional and reversible.
• Scenario opening (5 min). Read a one-paragraph situation summary out loud. Confirm everyone understands the starting state.
• Inject cycles (90-120 min). Facilitator releases injects on a clock. Each inject is a new fact (a ticket, an email, a regulator phone call) that forces a decision.
• Decision capture (continuous). Scribe records every decision, the owner, and the time-to-decide.
• Hot-wash (20 min). Anonymous +1/-1 round, then open discussion: what worked, what did not, what surprised us, what we will change.
• Report (within 5 days). Action items with owners and due dates. Trackable in the same backlog you use for everything else.

Scenario 1 — Ransomware in the BFSI back office

Opening

It is 14:00 on a Tuesday. The SOC pages the IR lead: 47 file-server endpoints across two data centres have raised LockBit-style signatures within four minutes. EDR confirms active encryption on at least 8 hosts. AD telemetry from the prior 36 hours shows the svc-backup service account was used from an unusual workstation. The CFO is on a flight; the CEO is on holiday but reachable.

Injects

1. T+15m: SOC reports lateral movement to two domain controllers. Containment now requires a domain-wide credential reset.
2. T+30m: a tester from your own red team rotation is on site this week. Are they in or out of the response?
3. T+45m: an unknown Telegram channel posts redacted samples of customer KYC documents claiming to be from your environment.
4. T+60m: CERT-In's six-hour clock is now four hours away. Who files? With what?
5. T+90m: ransom demand arrives via Onion email - USD 3.4M in BTC, 72-hour deadline.
6. T+105m: Operations head reports core banking platform performance degrading; they suspect spread to a second segment.

Decisions to surface

• When (and who) declares a major incident vs continuing as P1 ticket?
• Containment vs evidence preservation - do we re-image immediately or snapshot first?
• Who decides to engage the cyber-insurance breach coach vs incident response retainer first?
• What do we tell customers, and when - holding statement, full disclosure, regulator-first?
• Ransom posture - do we negotiate, decline, or stall? Who has the authority?
• How is the CERT-In six-hour clock met? See our CERT-In six-hour rule guide.
• RBI / SEBI / IRDAI parallel notifications - who owns each, do we have the templates?

Scenario 2 — Supply-chain compromise via a build dependency

Opening

Engineering leadership receives an automated SCA alert at 03:00 IST: a Tier-1 dependency in your primary backend service has shipped a malicious release tagged 4.7.2, published 18 hours ago. The postinstall script exfiltrates environment variables to an attacker-controlled domain. Your CI pipeline pulled this release for the 11pm production deploy. Production has been running on the compromised version for four hours.

Injects

1. T+15m: forensic trace shows the package successfully fetched but the network egress was blocked by a default-deny SG. Did it actually exfiltrate?
2. T+30m: a second service in a different account pulled the same package - it has wider egress.
3. T+45m: the package maintainer is unreachable; the registry has not yet pulled the release.
4. T+60m: a journalist from a tech publication emails the press address asking about reports of a supply-chain incident across the ecosystem.
5. T+90m: customer success reports two enterprise customers asking whether you are affected, having seen the GitHub advisory.
6. T+120m: secrets stored in the affected service include rotating AWS access keys, a Stripe key, and a SendGrid token.

Decisions to surface

• Forensic confidence - do we treat as confirmed exfil or as suspected exfil with different response thresholds?
• Rotation policy - what is the order of secret rotation, who has the runbook, and how do we validate every consumer has picked up the new secret?
• Communications - proactive blog post or reactive only on customer ask?
• Vendor management - do we ban the package, the maintainer, or both? How do we even enforce that?
• Lessons - what would have caught this in CI? Pair with our supply chain attacks 2026 guide.

Scenario 3 — Insider threat with privileged access

Opening

HR informs the CISO that a senior engineer with production AWS access has tendered resignation, citing a competitor. The engineer is on a 60-day notice and currently has root-level access to the production data warehouse. Over the past three weeks, audit logs show a 4x increase in their data exports from the warehouse. The exports were all permitted by their role.

Injects

1. T+15m: a quick audit shows the exports include customer email addresses and pricing terms - the categories competitors would value.
2. T+30m: the engineer's laptop shows unusual personal-Dropbox upload activity in the last week.
3. T+45m: legal asks - what is our position on retaining and analysing the personal device contents?
4. T+60m: HR asks - can we put them on garden leave today without tipping them off?
5. T+90m: the engineer's manager argues they are essential to a customer commitment ending in two weeks.
6. T+120m: a tip from an internal channel suggests the engineer has been contracting with the competitor for six weeks.

Decisions to surface

• Trust calibration - when do we stop treating elevated activity as "normal for their role"?
• Forensic ethics - what consents, jurisdictions, and policies cover device review?
• Legal posture - civil action, criminal complaint, both, neither?
• HR coordination - garden leave vs PIP vs immediate termination, who decides?
• Customer impact - if data left, who do we tell, how, and when? DPDP Act 2023 triggers apply.

Scenario 4 — Regulator-driven personal data breach

Opening

At 10:00 IST, the Data Protection Board sends an email asking your DPO to clarify a third-party report that 1.8 million customer records from your platform were observed on a leak site. Your internal monitoring did not flag anything in the past 30 days. Your last pentest was four months ago and was clean.

Injects

1. T+15m: a sample of 100 records from the leak site matches your schema and includes records of users who signed up in the last 14 days.
2. T+30m: the leak site claims the data was taken via "an exposed admin endpoint". You cannot immediately confirm or deny.
3. T+45m: a journalist publishes a story citing the leak. Your customer-success Slack channel is on fire.
4. T+60m: legal asks - 72-hour clock on the DPB notification starts when?
5. T+90m: your CEO asks for a status update they can send to the board.
6. T+120m: a customer threatens to pull contract worth INR 4 crore unless they get written assurance within 24 hours.

Decisions to surface

• Notification cadence - DPB (within 72h under DPDP Act), CERT-In (within 6h if you have the relevant trigger), affected customers, public statement.
• Investigation depth - do we hire an external forensic firm immediately or attempt internal first?
• Pentest scope review - what did the last engagement cover, what did it miss? See scoping a pentest.
• Customer language - the difference between "we have no evidence of a breach" and "we are investigating reports of a breach" under cross-examination later.
• Board reporting - what is the standing template, who fills it, who signs it?

Scenario 5 — Cloud account takeover via OIDC misuse

Opening

GuardDuty raises an alert: an IAM role normally assumed by GitHub Actions has been assumed from an IP in a country your CI does not deploy from. The assumed-role session has been active for 38 minutes. CloudTrail shows the session enumerating IAM, KMS keys, and S3 buckets - listing only, no destructive action yet.

Injects

1. T+15m: investigation reveals the OIDC trust policy on the role accepts repo:* from the GitHub OIDC provider - any public fork could trigger it.
2. T+30m: the session has now successfully read three production S3 buckets but no objects have been deleted.
3. T+45m: the role's policy includes kms:Decrypt on the data warehouse KMS key.
4. T+60m: the SOC asks - should we kill the session or watch and learn?
5. T+90m: a public Reddit thread mentions someone discovering an "abandoned" OIDC role from your org.
6. T+120m: legal asks - is this a reportable incident under CERT-In Annexure I?

Decisions to surface

• Containment vs intel - revoke the session immediately or maintain visibility for attribution?
• Trust policy hardening - how fast can every OIDC role in the estate be scoped to specific repos/branches?
• Disclosure threshold - read-only enumeration with no confirmed data access still qualifies under most regulators as an "unauthorised access".
• Public statement - silence is often misread; what is your default position on infosec-Twitter discovery?
• Programme follow-through - see our cloud misconfiguration Top 10 for the underlying control gap.

Hot-wash template

# Tabletop Hot-Wash - <Scenario name> - <Date>

Attendees: <list>
Facilitator: <name>
Scribe: <name>

## Decisions made during exercise
| Time | Decision | Owner | Confidence (H/M/L) |
|------|----------|-------|--------------------|

## Decisions deferred or stuck
| Time | Decision | Blocker | Owner to unblock |
|------|----------|---------|------------------|

## Surprises (policy / runbook gaps surfaced)
- ...

## Action items
| # | Item | Owner | Due | Tracker |
|---|------|-------|-----|---------|

## Metrics
- Decision latency (avg): __ minutes
- Decisions deferred:    __ / __
- Surprise count:         __

## Next tabletop scenario: <pick from rotation>
## Next tabletop date:     <YYYY-MM-DD>

Tying tabletops into the broader programme

Tabletops are most valuable when their outputs flow into the rest of the security programme. Three integration points worth wiring in:

• Action items live in the same backlog as engineering tickets. The CISO reviews open items weekly until closed.
• Surprises feed your NIST CSF 2.0 Profile as gap candidates - if a runbook did not answer a question, the relevant subcategory is below the target maturity.
• Detection gaps surface as Sigma / KQL / SPL queries to write or tune. Pair with the annual red team report's detection matrix.

For sector-specific scenario libraries, our BFSIand healthcare practices maintain extended scenario packs that cover regulator-specific drills (RBI cyber stress test, IRDAI breach simulation, HIPAA business-associate exercise).

FAQ

Further reading

• CERT-In Six-Hour Rule
• Red Team Engagement vs Pentest
• Supply Chain Attacks 2026
• Glossary: Tabletop Exercise