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:

Post‑Incident Review (PIR) Example
Tabletop Exercise Scenario ← this article
Facilitator’s Script
Participant Handout
After‑Action Report (AAR)

How I Run a Tabletop Exercise

Whenever I run a tabletop exercise, the first thing I do is set the tone for the room. I tell everyone that this is not a test and it’s not about catching anyone out. It’s a safe space to walk through our policies, procedures, and decision‑making as a team. The goal is to explore how we work, not judge how anyone performs.

From there, I already have a few people in mind I plan to direct questions to, and I make a point of involving those who might not naturally speak up. It’s never about putting someone on the spot, it’s about making sure every voice is included, because the quietest people often hold the most valuable insights.

I keep the exercise clearly presented and easy to follow. Participants don’t see the scenario or questions beforehand, so I introduce each inject properly and display it on the meeting room screen during that phase of the exercise. That way, everyone can read it at their own pace and revisit the question as they think through their answer. I’ve used printed handouts in the past, but the big screen usually works best for keeping everyone aligned and focused.

As the facilitator, my job is simple: ask the questions, guide the conversation, and help the team move forward if they get stuck. The other essential role is the scribe, because the notes they capture become the foundation for the Tabletop After Action Report (AAR). That document summarises how the exercise went, what gaps were identified, and what improvements are recommended. A tabletop is not just an exercise, it’s an opportunity to uplift our policies, technologies, procedures, and the way we operate as a team.

This tabletop pairs with the identity compromise explored in my Post‑Incident Review (PIR) article. If you want the full narrative context, read that first.

With that framing in place, the following scenario walks teams through a real‑world identity compromise.

Tabletop Exercise Scenario

This tabletop simulates an identity compromise involving MFA fatigue, malicious OAuth persistence, and delayed SOC response due to business‑hour coverage. It is designed to test:

identity threat detection
SOC workflows
escalation and communication
governance and training gaps
alignment with NIST CSF 2.0
long‑term improvement capability

Participants & Roles

Facilitator – runs the scenario, guides discussion, keeps the room psychologically safe.
SOC Analyst – validates alerts, gathers evidence, triggers escalation.
Incident Manager – coordinates containment, ensures communication flow.
ICT Manager – makes operational decisions about account lockdown and access restoration.
ELT Representative – receives impact updates, approves major decisions.
Legal / Privacy – advises on regulatory triggers and data exposure.
HR / Comms – supports user communication and internal messaging.

Scenario Overview

At 06:12, a staff member receives repeated MFA push notifications. Half‑awake, they accidentally approve one. The attacker logs into Microsoft 365, registers a malicious OAuth application, creates inbox rules to hide alerts, and accesses OneDrive files.

The SOC operates 8am – 5pm. Automation detects the OAuth anomaly at 06:45, but no analyst sees it until 08:00. Containment occurs at 08:12.

During the Hot Wash, it’s discovered that the user reused their password across multiple services, and that password was present in a known third‑party breach.

The exercise is delivered in five stages, each with injects, facilitator questions, expected themes, and CSF mappings, plus commentary on what typically trips teams up.

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

Inject: The user receives repeated MFA prompts early in the morning. They approve one. No SOC staff are on shift.

Facilitator Commentary: This moment exposes two weaknesses at once: user awareness and after‑hours detection. Most teams underestimate how quickly MFA fatigue can escalate, and many assume “the SOC will catch it” even when the SOC isn’t operating.

Facilitator Questions:

What indicators should the organisation rely on to detect MFA fatigue outside SOC hours?
What should the user have done when receiving unexpected MFA prompts?
How should the organisation educate staff to recognise identity‑based attacks?
What automated controls could have prevented the attacker from authenticating?
How should this early activity be logged and escalated once the SOC begins at 08:00?

Expected Themes: Number‑matching MFA, user awareness, after‑hours alerting, Conditional Access, Identity Protection.

CSF 2.0 Mappings: PR.AA – Identity & Access Control PR.AT – Awareness & Training DE.AE – Anomalies & Events GV.OC – Oversight & Culture

Part 2: Attacker Activity & OAuth Persistence (06:14–06:22)

Inject: The attacker registers a malicious OAuth app, grants Mail/Files permissions, creates inbox rules, and accesses OneDrive.

Facilitator Commentary: OAuth persistence is one of the most misunderstood identity attack paths. Teams often focus on the login and completely miss the silent foothold created by malicious app consent.

Facilitator Questions:

What detections should exist for OAuth app registration and consent events?
Should standard users be allowed to self‑consent to OAuth applications?
What alerts should fire when inbox rules are created or modified?
How would the team determine what data was accessed or exfiltrated?
What immediate containment steps should be taken once this activity is discovered?

Expected Themes: OAuth governance, inbox rule monitoring, identity protection, data access logs, token revocation.

CSF 2.0 Mappings: PR.AA – Identity & Access Governance DE.CM – Continuous Monitoring RS.MI – Mitigation ID.AM – Asset/Data Visibility

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

Inject: Automation generates an OAuth anomaly alert at 06:45. SOC shift begins at 08:00. Analyst escalates and locks the account by 08:12.

Facilitator Commentary: This is where operational maturity shows. Teams with strong shift‑start workflows handle this cleanly. Teams without them drown in queued alerts.

Facilitator Questions:

How should automation be tuned to ensure high‑risk alerts are prioritised?
What is the expected SOC workflow when starting a shift with queued alerts?
What information must be validated before locking the account?
How should the SOC communicate the escalation to ICT Management?
What evidence must be preserved immediately for later forensic review?

Expected Themes: Alert prioritisation, shift handover, evidence preservation, communication flow, SOC maturity.

CSF 2.0 Mappings: DE.CM – Continuous Monitoring RS.AN – Analysis RS.CO – Communications RS.MI – Mitigation

Part 4: Escalation, ELT Notification & Business Impact (08:12–09:30)

Inject: Containment is complete. User contacted at 09:10. ELT notified at 09:30. Initial scoping shows limited access.

Facilitator Commentary: Leadership communication is where most teams get nervous. The challenge isn’t the technical detail, it’s communicating uncertainty without sounding uncertain.

Facilitator Questions:

What criteria determine whether ELT must be notified?
How should the SOC communicate uncertainty to leadership?
What business units must be informed during identity‑based incidents?
How should the organisation assess whether regulatory reporting is required?
What information must be included in the initial ELT briefing?

Expected Themes: Impact assessment, leadership communication, privacy/legal considerations, business continuity.

CSF 2.0 Mappings: RS.CO – Communications GV.RM – Risk Management Strategy RC.CO – Recovery Communications

Part 5: Hot Wash & Continuous Improvement (Next Business Day)

Inject: Hot Wash reveals password reuse and breached‑password exposure.

Facilitator Commentary: This is the moment where the exercise becomes real. Teams often discover that the root cause wasn’t the attacker, it was governance.

Facilitator Questions:

How should password reuse and external breach exposure be handled in the RCA (Root Cause Analysis)?
What governance controls should prevent password reuse across services?
How should the organisation implement breached‑password detection?
What training updates are required to address MFA fatigue and password hygiene?
What long‑term improvements should be added to the remediation register?

Expected Themes: Identity governance, training uplift, policy updates, remediation register, continuous improvement.

CSF 2.0 Mappings: ID.IM – Improvement PR.AA – Identity & Access Governance PR.AT – Role‑Based Training

Tabletop Maturity Scoring Rubric

Level	Indicators
Beginner	Team relies on guesswork; unclear roles; inconsistent answers; no reference to IRP or CSF.
Intermediate	Team understands workflow; identifies major actions; some gaps in communication or evidence handling.
Mature	Team follows IRP; answers align with CSF; clear escalation paths; strong containment logic.
Advanced	Team demonstrates proactive thinking; references governance, automation, and long‑term improvements; answers show architectural awareness.

Running This Exercise

A typical run takes 60–90 minutes:

Parts 1–3: 45 minutes
Part 4: 15 minutes
Part 5: 10 minutes
Hot Wash: 10–20 minutes

Debrief Format

After the final inject, the facilitator should ask:

What worked well
What slowed us down
What decisions were unclear
What governance gaps did we uncover
What improvements go into the remediation register

Outputs

This exercise should produce:

Updated IRP sections
Updated identity playbook steps
Updated training requirements
Updated governance controls
A CSF‑mapped remediation list

These outputs feed directly into your After Action Report (AAR).

Conclusion

A tabletop exercise isn’t about testing people, it’s about revealing how your organisation thinks, communicates, and responds under pressure. Identity compromises are fast, subtle, and unforgiving, but the conversations that matter most only happen when the room feels safe enough for people to speak honestly. That psychological safety you establish at the start is what makes those insights possible. When run well, a tabletop becomes one of the most powerful improvement tools in your entire security program.