How to Run a Cybersecurity Tabletop Exercise: Facilitator Script with Discussion Prompts

A cybersecurity team sits around a conference table while a facilitator leads a tabletop exercise. The screen behind them displays the Tayven Cyber Security logo and the words “Tabletop Exercise: Cyber Security Team.”

Series Introduction

This article is part of my Incident Response series, where I use the same fictional identity compromise across every piece to keep the entire workflow aligned. The goal is to show how a single incident can be documented, analysed, simulated, and improved, exactly the way a real organisation would handle it. The series covers how to report an incident, how to run a tabletop exercise, how to facilitate it, what supporting documents to provide, and how to write the After‑Action Report that turns discussion into measurable improvement.

Articles in the series:

FACILITATOR SCRIPT


Facilitator Introduction

A good tabletop lives or dies on facilitation. A script doesn’t remove spontaneity, it creates psychological safety. It gives the facilitator a structure to fall back on, keeps the room aligned, and ensures the exercise stays focused on process rather than personalities. This script is written so that even a first‑time facilitator can run the scenario confidently while still leaving space for natural discussion and team dynamics.


FACILITATOR SCRIPT (With Discussion Prompts)

Opening (2 minutes)

“Welcome everyone. Today’s tabletop simulates an identity compromise involving MFA fatigue and OAuth persistence. This is a learning exercise, not a test. There are no wrong answers. We’re here to explore decision‑making, communication, and alignment with our IRP.”


Inject 0 – Framing (1 minute)

“This scenario is fictional but based on real attacker behaviour. Timestamps are compressed. Focus on process, clarity, and communication.”


PART 1 – Initial Suspicious Activity (06:12–06:14)

Inject: User receives repeated MFA prompts and approves one.

Ask the room:

  • How would we detect MFA fatigue outside SOC hours
  • What should the user have done
  • How do we train staff to recognise identity attacks
  • What controls could have prevented authentication
  • How is this logged and escalated at 08:00

Listen for: Number matching, Conditional Access, user awareness gaps, after‑hours alerting, Identity Protection signals.

Facilitator guidance: If the room focuses only on the user mistake, steer them back to systemic controls and training.

If the room goes quiet: “Think about what signals Microsoft 365 or Identity Protection would generate here.”


PART 2 – OAuth Persistence (06:14–06:22)

Inject: Attacker registers OAuth app, grants permissions, creates inbox rules.

Ask:

  • What detections should exist for OAuth events
  • Should users self‑consent to apps
  • What alerts should fire for inbox rules
  • How do we determine data access
  • What containment steps follow

Listen for: OAuth governance, app consent restrictions, inbox rule monitoring, token revocation, data access logs.

Facilitator guidance: Highlight that OAuth persistence is often missed because teams focus on the login, not the silent foothold created by malicious app consent.

If the room goes quiet: “Consider what normal OAuth behaviour looks like, what would stand out as unusual.”


PART 3 – Automated Alerting & SOC Response (06:45–08:12)

Inject: Alert fires at 06:45; SOC sees it at 08:00; containment at 08:12.

Ask:

  • How should automation prioritise high‑risk alerts
  • What is the shift‑start workflow
  • What must be validated before locking the account
  • How is escalation communicated
  • What evidence must be preserved

Listen for: Alert severity tuning, shift handover, evidence preservation, communication flow.

Facilitator guidance: Reinforce that escalation confidence is a skill, analysts must balance validation with urgency.

If the room goes quiet: “What’s the first thing a SOC analyst must confirm before taking action?”


PART 4 – Escalation & Business Impact (08:12–09:30)

Inject: ELT notified at 09:30; limited access confirmed.

Ask:

  • What triggers ELT notification
  • How do we communicate uncertainty
  • Who else must be informed
  • How do we assess regulatory reporting
  • What goes into the ELT briefing

Listen for: Impact thresholds, privacy/legal involvement, business continuity, clear leadership communication.

Facilitator guidance: Encourage the team to think about what leadership needs, clarity, confidence levels, and business impact, not technical depth.

If the room goes quiet: “Think about what leadership needs to know, not the technical details.”


PART 5 – Hot Wash & Improvement (Next Business Day)

Inject: Password reuse + breached password discovered.

Ask:

  • How does this factor into RCA (Root Cause Analysis)
  • What governance controls prevent reuse
  • How do we implement breached‑password detection
  • What training updates are required
  • What goes into the remediation register

Listen for: ID.IM improvements, password governance, training uplift, policy updates.

Facilitator guidance: Bring the room back to governance, this is about systemic controls, not user blame.

If the room goes quiet: “What does this tell us about our governance rather than just the user?”


Closing (2 minutes)

“Thank you, everyone. These conversations only work when people are willing to be honest about uncertainty, assumptions, and gaps, and today had all of that. Our next step is to consolidate findings into the remediation register and update the IRP and identity playbook accordingly. The goal isn’t perfection; it’s improvement, and this session gives us exactly what we need to move forward.”


3. VISUAL TIMELINE DIAGRAM

Use this timeline to keep the room oriented as the scenario progresses.

                 Identity Compromise Timeline
───────────────────────────────────────────────────────────────

06:12 ──▶ MFA fatigue attack begins
          • User receives repeated MFA prompts
          • User accidentally approves one

06:14 ──▶ Attacker gains access
          • Registers malicious OAuth app
          • Grants Mail/Files permissions
          • Creates inbox rules to hide alerts
          • Accesses OneDrive files

06:45 ──▶ Automated alert fires (OAuth anomaly)
          • SOC not yet on shift

08:00 ──▶ SOC shift begins
          • Analyst reviews queued alert

08:05 ──▶ Analyst escalates to Incident Manager

08:12 ──▶ Containment actions
          • Account locked
          • OAuth tokens revoked
          • Inbox rules removed

09:10 ──▶ User contacted

09:30 ──▶ ELT notified
          • Initial scoping: limited access window

Next Business Day ──▶ Hot Wash
          • Password reuse discovered
          • Password found in third‑party breach
          • Governance and training gaps identified

───────────────────────────────────────────────────────────────

Continue Reading

This is part of an ongoing series. If you want the full picture, the rest of the articles are worth your time.

How to Create a Participant Handout for a Cybersecurity Tabletop Exercise

How to Write an After Action Report (AAR) for Cyber Tabletop Exercises

How to Run a Cybersecurity Tabletop Exercise: A Complete Example Scenario and Facilitation Guide

How to Write a Post-Incident Review (PIR) Report (With Real-World Example)

How to Build an Incident Response Plan: A Complete NIST CSF 2.0 Example

How to Write a Modern Incident Response Plan (IRP) Using NIST CSF 2.0

The Evolution of Incident Response: Updating the Classic NIST IRP to the 2026 Framework

How to Build a Vulnerability Management Program

How to Build a Cyber Aware Workplace Culture

Leave a Comment

Your email address will not be published. Required fields are marked *