Security Incident Response Simulation: How to Run Tabletop Exercises That Actually Prepare Your Team

Your organisation has an incident response plan. It's a 47-page PDF that was last updated eighteen months ago. It references team members who've since left, escalation paths to phone numbers that no longer work, and a Slack channel that was archived during a reorganisation. On paper, you're prepared. In reality, you're one critical CVE away from discovering that your plan is fiction.

Security incident response simulations — commonly called tabletop exercises — are the only reliable way to discover this before an actual attacker does. They're not optional nice-to-haves. Under DORA (Article 26), financial entities must conduct regular threat-led penetration testing and ICT incident response exercises. Under NIS2 (Article 21), essential and important entities must test their incident handling procedures. Under the CRA, manufacturers must have vulnerability handling processes that demonstrably work.

This article covers how to design simulations that surface real gaps, how to facilitate them without turning them into compliance theatre, and five ready-to-use scenarios calibrated for regulated enterprises running Kubernetes-based AI infrastructure.

Why Plans Fail Without Practice

Incident response plans fail for predictable reasons. Simulations exist to find these reasons before a real breach does:

• Communication breakdown: The plan says "notify the CISO." But what if the CISO is on holiday? What if the backup contact doesn't know they're the backup? What if the notification channel (email) is the system that's been compromised?
• Tooling assumptions: The plan assumes you can query your SBOM database. But the SBOM database runs on the same Kubernetes cluster that's under attack. Do you have offline copies?
• Decision paralysis: The plan says "assess impact and escalate if necessary." Who decides what's "necessary"? What's the threshold? At 2 AM with incomplete information, people freeze without clear criteria
• Regulatory gaps: The plan doesn't mention ENISA notification. Or it mentions ENISA but nobody knows the portal URL, the credentials, or the required data format. The 24-hour clock runs regardless
• Skill atrophy: The engineer who built the forensics toolkit left six months ago. Nobody else knows how to pull container logs from a compromised node without alerting the attacker

Anatomy of an Effective Tabletop Exercise

Format

A tabletop exercise is a structured, discussion-based simulation. No keyboards, no live systems, no actual exploitation. Participants sit around a table (or a video call) and talk through their response to a fictional scenario, making decisions in real time as new information is revealed.

• Duration: 2–4 hours (shorter exercises miss complexity; longer ones lose focus)
• Participants: 8–15 people from security, engineering, platform, legal, communications, and executive leadership
• Facilitator: An experienced facilitator who drives the scenario, injects new information, challenges assumptions, and prevents the exercise from devolving into a theoretical debate
• Observers: 1–2 people who take notes, track decisions, and document gaps without participating

Structure

1. Scene setting (15 min): Brief the participants on the scenario premise, ground rules, and objectives. Remind everyone: the goal is to find gaps, not to prove the plan works
2. Initial detection (30 min): Present the first alert. Who receives it? What do they do? Who do they call? What tools do they use?
3. Escalation (30 min): Inject new information that raises the severity. The breach is worse than initially thought. Test escalation paths, leadership notification, and decision-making under pressure
4. Response and containment (45 min): The team works through containment, remediation, and communication decisions. Inject complications: a critical team member is unreachable, the backup system has a different vulnerability, the media calls
5. Regulatory notification (30 min): Test the CRA/DORA/NIS2 notification process. Who drafts the notification? Who approves it? Where does it get submitted? What's the legal review process under time pressure?
6. Debrief (30 min): Honest discussion of what worked, what failed, and what needs to change. This is the most valuable part — protect the time

Ground Rules

• No blame: Exercises surface systemic gaps, not individual failures. If someone doesn't know who to call, that's a documentation problem, not a competence problem
• Stay in role: Participants respond as they would in a real incident — with the information they actually have, not with omniscient knowledge
• Time pressure is real: The facilitator enforces time boxes. If the team takes 45 minutes to decide whether to notify ENISA, that's a finding
• Document everything: Every decision, every hesitation, every "I'm not sure who handles that" is a data point

Five Ready-to-Use Scenarios

Each scenario is designed for a regulated enterprise running Kubernetes-based infrastructure. Adapt the details to your environment.

Scenario 1: Critical CVE in a Transitive Dependency

Premise: A CVSS 9.8 vulnerability is published in a widely-used serialisation library. Your SBOM scan reveals it's a transitive dependency in your customer-facing API service — pulled in by a logging framework that depends on it. Exploitation is confirmed in the wild within 4 hours of disclosure.

Injects:

• The patched version of the logging framework introduces a breaking API change
• Your staging environment uses a different version than production (SBOM mismatch)
• A customer contacts support asking if they're affected before your team has finished assessment
• The security team discovers the same library is also used in your internal CI/CD pipeline

Tests: SBOM query speed, CRA 24h notification, customer communication under uncertainty, transitive dependency upgrade workflow

Scenario 2: Supply Chain Compromise via CI/CD Plugin

Premise: A popular GitHub Actions marketplace action that your pipelines use for container image scanning has been compromised. The malicious version exfiltrates environment variables — including registry credentials and deploy tokens — to an external server. You've been running the compromised version for 11 days before detection.

Injects:

• The exfiltrated registry credentials have push access to your production container registry
• Three container images were pushed to the registry during the compromise window that don't match your build records
• One of those images is already deployed to a customer-facing namespace
• The attacker has also obtained your Helm chart signing key

Tests: Blast radius assessment, secret rotation speed, container image integrity verification, customer notification for on-premise deployments, ENISA reporting

Scenario 3: Ransomware Targeting Kubernetes Persistent Volumes

Premise: A pod running a compromised container image escalates privileges via a known container runtime vulnerability. It encrypts data on multiple PersistentVolumeClaims across namespaces, including ML model storage and training datasets. A ransom note appears in every affected namespace.

Injects:

• The backup system uses the same storage class — backups may also be encrypted
• The compromised container image passed your vulnerability scanner because the exploit targets the runtime, not the image contents
• Two of the encrypted PVCs contain data subject to GDPR data protection requirements
• Your cyber insurance provider wants a forensic analysis before authorising any recovery expenditure

Tests: Backup isolation verification, container runtime patching process, GDPR breach notification (72h), insurance claim workflow, decision-making on ransom payment

Scenario 4: AI Model Poisoning via Compromised Training Data

Premise: Your ML team discovers that a training dataset sourced from an external provider contained manipulated samples. Models trained on this dataset — now serving inference in production — produce subtly incorrect outputs for specific input patterns. The compromised model has been in production for 3 weeks.

Injects:

• The model serves financial risk scoring for a banking customer (DORA-regulated)
• Retraining the model takes 72 hours on your current GPU allocation
• Rolling back to the previous model version means losing 3 weeks of legitimate model improvements
• The external data provider is also a supplier to two of your competitors — potential coordinated attack

Tests: AI-specific incident response, model rollback procedures, data provenance verification, customer notification for compromised outputs, EU AI Act implications

Scenario 5: Insider Threat — Privileged Access Abuse

Premise: Your SIEM flags anomalous kubectl activity from a platform engineer's account: bulk secret reads across multiple namespaces, unusual API server queries, and data exfiltration to an external S3 bucket. The activity spans the last 5 days. The engineer has cluster-admin privileges.

Injects:

• The secrets include database credentials, API keys for third-party services, and TLS private keys
• The engineer also has access to your SBOM database, vulnerability scanner results, and incident response documentation
• HR confirms the engineer submitted their resignation last week (not yet public)
• Legal advises that revoking access without documented cause could trigger wrongful termination claims in the relevant jurisdiction

Tests: Insider threat detection and response, legal coordination under time pressure, secret rotation at scale, RBAC audit, damage assessment when the attacker knows your playbook

Measuring What Matters

After each exercise, score your response against concrete metrics:

• Time to detect: How long from scenario injection to team awareness? Target: under 15 minutes for critical scenarios
• Time to assess: How long from detection to confirmed impact assessment? Target: under 2 hours
• Time to contain: How long from assessment to containment action? Target: under 4 hours
• Regulatory notification: Did the team meet the 24h/72h CRA timelines? Did they know the process?
• Communication clarity: Were customer notifications accurate, timely, and appropriately scoped?
• Decision quality: Were decisions made with available information, or did the team wait for certainty that never comes?
• Role clarity: Did everyone know their role? Were there gaps or overlaps?

Track these metrics across exercises. Improvement over time is the goal — not perfection on the first attempt.

From Exercise to Improvement

The exercise is worthless without follow-through. After each simulation:

1. Document all findings in a structured report: gap, severity, owner, remediation deadline
2. Update the incident response plan within 2 weeks — not "eventually"
3. Fix the tooling gaps — if the team couldn't query SBOMs fast enough, that's an engineering ticket, not a process note
4. Update contact lists and escalation paths — every exercise reveals at least one stale contact
5. Schedule the next exercise — quarterly for high-risk organisations, semi-annually minimum. Exercises lose value if they're annual events

Regulatory Compliance Alignment

Tabletop exercises directly satisfy requirements across multiple regulatory frameworks:

• DORA Article 26: Threat-led penetration testing and ICT response/recovery testing for financial entities
• NIS2 Article 21: Incident handling testing and crisis management exercises for essential/important entities
• CRA Annex I: Demonstration that vulnerability handling processes are effective and tested
• ISO 27001 A.5.24: Information security incident management planning and preparation
• SOC2 CC7.4: The entity responds to identified security incidents by executing defined response activities

Keep exercise records, findings reports, and improvement tracking as audit evidence. Regulators don't just want to see a plan — they want to see proof you've tested it.

What Open Empower Delivers

We design and facilitate incident response simulations for regulated enterprises running cloud-native infrastructure:

• Custom scenario design: Scenarios calibrated to your actual tech stack, regulatory obligations, and threat landscape
• Professional facilitation: Experienced facilitators who challenge assumptions and surface real gaps
• Kubernetes-specific scenarios: Container escape, supply chain compromise, PVC encryption, API server abuse — scenarios that reflect real cloud-native threats
• AI/ML incident scenarios: Model poisoning, training data compromise, inference manipulation — the threats your AI teams need to rehearse
• Regulatory mapping: Exercise findings mapped to DORA, NIS2, CRA, and ISO 27001 requirements
• Improvement tracking: Structured follow-up to ensure findings become fixes, not just findings

Your incident response plan is a hypothesis. Tabletop exercises are the experiments that test it. Book a call to design your first simulation.