Loading...
Scenario Design
Creating Effective Tabletop Exercise Scenarios
The art and science of designing tabletop scenarios that challenge teams, reveal gaps, and build real capabilities.
16 min read
For Facilitators & Security Leaders
Why Scenario Design Matters
A great scenario can transform a routine compliance exercise into a transformative learning experience. Poor scenarios result in: teams checking out mentally, unrealistic discussions, or missing critical gaps. The scenario is 70% of exercise success. Great facilitation can't save a bad scenario.
4-6
Injects per scenario
70%
Scenario importance
5-7
Decision points
60-90m
Ideal duration
The Goldilocks Principle
Effective scenarios must be challenging but not overwhelming. The balance determines whether your team learns or shuts down:
Too Easy
Team coasts, no real decisions
- • Everyone agrees immediately
- • No debate or discussion
- • Completed in 30 minutes
- • No gaps identified
Just Right
Team challenged, productive struggle
- • Healthy debate on decisions
- • Some uncertainty (good!)
- • Engagement throughout
- • Specific gaps identified
Too Hard
Team overwhelmed, gives up
- • Analysis paralysis
- • Frustration and disengagement
- • Too many unknowns
- • Unrealistic complexity
Scenario Design Principles
5 principles that separate great scenarios from mediocre ones
1
Realistic but Achievable
Based on actual threat actor TTPs, but scoped to what your team can reasonably handle in 2-3 hours
DO
- • Research real attacks in your industry
- • Use MITRE ATT&CK framework for authenticity
- • Adapt complexity to team maturity
- • Include realistic indicators and artifacts
DON'T
- • Create Hollywood-style cyber attacks
- • Include 15 attack vectors simultaneously
- • Require knowledge of obscure tools
- • Make timing unrealistic (instant propagation)
2
Aligned with Actual Threats
Test against the threats your organization actually faces, not just "interesting" scenarios
DO
- • Review threat intelligence for your sector
- • Consider your attack surface (cloud, OT, etc.)
- • Align with recent risk assessments
- • Focus on high-likelihood scenarios
DON'T
- • Default to generic "advanced persistent threat"
- • Ignore your specific environment
- • Copy scenarios from other organizations
- • Test threats that don't apply to you
3
Tests Specific Objectives
Every scenario should have clear learning objectives - what specific capabilities are you validating?
DO
- • Define 3-5 specific objectives before scenario design
- • Example: "Test backup restoration decision process"
- • Ensure injects drive toward objectives
- • Measure whether objectives were achieved
DON'T
- • Create generic "test our IR plan" objectives
- • Add complexity that doesn't serve objectives
- • Lose focus during scenario progression
- • Skip the "why are we doing this?" conversation
4
Has Meaningful Decision Points
Great scenarios force teams to make difficult decisions with imperfect information
DO
- • Build in 5-7 major decision points
- • Create trade-offs (speed vs. thoroughness)
- • Include ambiguous information
- • Force prioritization decisions
DON'T
- • Make the "right answer" obvious
- • Provide all information up front
- • Remove time pressure artificially
- • Allow endless analysis without decisions
5
Progressive Complexity
Start simple, add complications. Let teams build confidence before introducing major pivots
DO
- • Initial inject is straightforward
- • Layer in complexity based on team responses
- • Save major twists for after initial response
- • Build to a crescendo, then debrief
DON'T
- • Dump all information in first inject
- • Introduce chaos without foundation
- • Make every inject a surprise twist
- • Skip the simple-to-complex progression
Scenario Structure: The 5-Layer Model
Every effective scenario follows this proven structure
1
Layer 1: Initial Inject
The discovery or alert that starts the exercise
- Realistic detection method (alert, user report, etc.)
- Timestamp and context
- Initial indicators only (not full picture)
- Enough info to start triage
Example Inject
"6:47 AM: SOC analyst sees EDR alert: Suspicious process execution on FINANCE-WKS-042. Process: powershell.exe launching encoded commands. User: jsmith@company.com. Status: Still executing."
2
Layer 2: Context Provision
Background information teams need to make decisions
- Affected system details
- User/account information
- Network topology relevant to incident
- Tools and data available for investigation
Example Inject
"The affected workstation is in the Finance department. User jsmith is a Senior Accountant with access to financial systems and customer data. The system has EDR but logs are only retained 30 days."
3
Layer 3: Complication Layers
Pivots that increase difficulty based on team actions
- Consequences of decisions made
- New information that changes situation
- "Gotchas" that test assumptions
- Time pressure or constraints
Example Inject
"As you isolate FINANCE-WKS-042, you see 12 more finance workstations showing similar behavior. Your backup systems are also showing suspicious access patterns. The CFO needs to send investor reports today."
4
Layer 4: Decision Points
Explicit questions that require team decisions
- Clear decision with multiple options
- Trade-offs to consider
- Stakeholders to consult
- Time constraints
Example Inject
"Do you: A) Isolate all finance systems immediately (blocks business), B) Isolate selectively (risk of spread), or C) Monitor while investigating (gather intel, risk of escalation)?"
5
Layer 5: Consequences
Outcomes based on team decisions (not punitive, but realistic)
- Logical results of actions taken
- New information revealed
- Next phase of incident
- Opportunities to adjust approach
Example Inject
"You chose selective isolation. Good: You contained 3 systems quickly. Bad: 2 additional systems were compromised in the meantime. The attacker is now attempting to access backup servers."
Inject Writing Techniques
How to craft realistic, engaging injects
Use Actual Log Formats
Why: Realism drives engagement and tests tool familiarity
Instead of "A suspicious process ran", use actual EDR alert format with fields, timestamps, hashes
💡 Tip: Screenshot real alerts (redacted) and include them
Include Realistic Details
Why: Specific details make scenario feel real
Name systems like "PROD-DB-03" not "Database Server". Use real software versions, actual IP ranges, specific usernames
💡 Tip: Mirror your actual environment naming conventions
Avoid Giving Away Answers
Why: Teams should deduce, not be told
Bad: "This is a ransomware attack". Good: "Multiple files renamed with .encrypted extension, ransom note observed"
💡 Tip: Provide indicators, let teams draw conclusions
Build Progressive Complexity
Why: Gradual escalation allows for learning
Start with single affected system, reveal lateral movement over time, don't dump 50 compromised hosts in inject 1
💡 Tip: Each inject should add 1-2 new complications
Create Time Pressure
Why: Forces prioritization and realistic stress
Include business deadlines, regulatory timelines, ransom countdowns, or spreading threats
💡 Tip: Use countdown timers or facilitator reminders
Introduce Ambiguity
Why: Real incidents are messy and uncertain
Conflicting information, incomplete logs, uncertainty about scope, unclear attribution
💡 Tip: Teams should ask "we need more information"
Example Scenarios by Objective
Tailor scenarios to what you want to test
1
Testing Detection Capabilities
Credential theft via phishing with gradual escalation
Tests if SIEM rules detect suspicious auth patterns, lateral movement
Key Injects:
- Phishing email reported by user
- Suspicious logins from unusual locations
- Multiple failed login attempts
- Successful access to privileged account
Discussion Questions:
- How would we detect this?
- What logs would show this activity?
- Do we have visibility into X?
2
Testing Escalation Procedures
Minor incident that escalates to major breach
Tests when and how teams escalate to leadership
Key Injects:
- Single compromised workstation (low severity)
- Evidence of data access (medium severity)
- Exfiltration confirmed (high severity)
- Media inquiry received (crisis level)
Discussion Questions:
- At what point do we notify CISO?
- When do we involve legal?
- Who approves external communications?
3
Testing Cross-Team Coordination
DDoS attack affecting customer-facing systems
Requires IT, security, communications, customer support coordination
Key Injects:
- Website loading slowly, customer complaints
- Confirmed DDoS, source unclear
- Customers posting on social media
- Ransom demand received
Discussion Questions:
- Who handles customer communication?
- How do IT and security coordinate?
- What's our public statement?
4
Testing Executive Decision-Making
Ransomware with backup failure
Forces C-suite to make difficult business decisions
Key Injects:
- Critical systems encrypted
- Backups also compromised
- Recovery estimated at 4-6 weeks
- Ransom demand: $3M, 48-hour deadline
Discussion Questions:
- Do we pay the ransom?
- How do we communicate to customers?
- What's our survival window?
Common Scenario Pitfalls
Mistakes that kill exercise effectiveness
Too easy: Team solves in 20 minutes
Fix: Add complications, time pressure, ambiguous information
Too hard: 10 attack vectors at once
Fix: Focus on 1-2 primary threats, build gradually
Too scripted: No room for team decisions
Fix: Build branching paths based on team choices
Unrealistic: Hollywood cyber attack
Fix: Research real TTPs, use MITRE ATT&CK
No decision points: Just an info dump
Fix: Force explicit choices with trade-offs
Gives away answers: "This is ransomware"
Fix: Provide indicators, let team deduce
Missing context: Team can't make decisions
Fix: Provide org details, available tools, constraints
No consequences: Decisions don't matter
Fix: Show realistic outcomes of each choice
Skip the Scenario Design Work
Breakpoint provides 50+ pre-built, field-tested scenarios designed by incident response experts. Each scenario includes progressive injects, decision trees, and facilitator guides. Focus on your team, not scenario design.
Related Articles
How to Conduct Tabletop Exercises
Complete facilitation guide for running effective tabletop exercises
Read more →
Ransomware Scenario Example
Detailed ransomware exercise guide with timeline and decision points
Read more →
Why Run Tabletop Exercises Quarterly
Learn why quarterly training is more effective than annual exercises
Read more →