How to Run a Social-Engineering Tabletop Exercise

Most security teams have rehearsed a ransomware outage. Far fewer have rehearsed the phone call that starts one. Technical tabletop exercises — server down, backups encrypted, who calls legal — are a fixture of incident response programs. But with the Verizon DBIR attributing 62% of breaches to the human element, the scenarios most likely to hit first are conversations, not exploits: a cloned voice asking finance for an urgent transfer, a fake IT help desk talking an employee through an MFA reset, a supplier email quietly changing bank details.

Those scenarios have a property that makes them perfect tabletop material: they are decided in minutes, by a handful of people, under social pressure — and almost never by the security team. Arup's $25.6 million loss was authorized by a finance employee on a video call. Uber's 2022 breach hinged on one contractor approving one push notification. A tabletop exercise is the cheapest way to find out, before an attacker does, what your people would actually do in that moment. This guide covers how to build and run one: the scenarios worth rehearsing, who belongs in the room, and how to convert an afternoon of discussion into controls that hold.

Why the human layer needs its own rehearsal

A tabletop exercise, in NIST SP 800-84's definition, is a discussion-based session where personnel talk through their roles in an emergency scenario — no live systems, no simulated traffic, just structured conversation with a facilitator driving events forward. The format is standard practice for outages and ransomware. Applying it to social engineering is rarer, and the gap matters for three reasons.

First, the decisions that determine the outcome of a social engineering attack are distributed far outside the security team. Whether a pretexting call succeeds is decided by an accounts-payable clerk, an executive assistant, or a help-desk agent — people who have almost never been asked "what exactly would you do?" in a structured way. Second, the highest-impact scenarios cannot be safely simulated live. You can and should run phishing simulations at scale, but you cannot realistically fake a $2 million wire request against your own finance team every quarter. A tabletop lets you rehearse precisely the scenarios that are too hot to touch. Third, the cost of being unrehearsed is well documented: the average breach reached $4.99 million in IBM's 2026 Cost of a Data Breach report, and the FBI's IC3 logged $20.9 billion in reported cybercrime losses in 2025, with business email compromise — a pure social engineering play — accounting for roughly $3 billion of it.

A phishing simulation tests whether one person clicks. A tabletop exercise tests whether your organization can say "no" to a convincing voice with authority — and whether anyone knows what to do in the ten minutes after someone says "yes."

Five scenarios worth rehearsing

The best scenarios are adaptations of documented incidents, because nobody in the room can dismiss them as hypothetical. Each row below is grounded in a real, public case.

Scenario	Opening inject	Who must be in the room	The question it tests
Deepfake executive on a video call	"The CFO" appears on a group call and requests a confidential transfer — as in the Arup case	Finance, treasury, executive team	Can any employee refuse a request that looks and sounds like leadership?
MFA bombing plus fake IT call	An employee's phone floods with push prompts, then "IT support" calls to "fix" it	Help desk, IT admins, any employee rep	Does anyone recognize MFA fatigue as an active intrusion, and what happens after a prompt is approved?
Help-desk impersonation	A caller with convincing personal details asks the service desk to reset credentials and MFA, the technique in CISA's Scattered Spider advisory	Help desk, identity/IAM owner	What does the desk require before touching an account — and does urgency override it?
Vendor banking change	A known supplier emails updated bank details two days before a scheduled payment	Accounts payable, procurement, finance lead	Is there an out-of-band verification path for invoice fraud, and does anyone actually use it?
CEO urgency message	A new "CEO" number texts an assistant requesting urgent gift-card purchases or a same-day payment	Executive assistants, finance, comms	Does CEO fraud have a rehearsed refusal script, and is refusing visibly safe?

Resist the temptation to run all five at once. One scenario, explored deeply with escalating complications, produces more findings than a highlight reel.

Running the exercise, step by step

You do not need consultants or a platform to start. CISA's Tabletop Exercise Packages are free, adaptable templates covering phishing, insider threat, and industry-specific scenarios; NIST SP 800-84 provides the program structure. What follows is a practical distillation for the social engineering case.

1. Pick one scenario and one objective

Choose the scenario that maps to your scariest plausible loss — for most organizations that is payment fraud or credential compromise. Write a single-sentence objective, such as: "Determine whether a fraudulent urgent payment request would be caught before funds move." The objective decides who you invite and what "success" means.

2. Script the injects

An inject is a new piece of information the facilitator drops into the discussion: the first email, the follow-up call, the escalating pressure. Script five to eight of them in a timeline, each designed to force a decision. Good injects remove easy outs — when a participant says "I'd verify with the CFO," the next inject is: "The CFO is boarding a flight and unreachable for four hours. The deadline is in two." Borrow pressure tactics from real cases: the Ferrari attempt collapsed only because an executive improvised a security question the impostor could not answer.

3. Assemble the right room

Eight to twelve people: the employees who would actually face the scenario, their managers, one security lead, and — for payment scenarios — someone who can speak for finance controls. Assign a facilitator who runs the timeline and a scribe who records every decision, hesitation, and "I don't know whose job that is." Keep observers to a minimum; a room full of spectators kills honesty.

4. Facilitate for decisions, not narration

The facilitator's job is to keep asking one question: "What do you do, right now, with what you know?" Push past generalities. If the answer is "I'd escalate," ask to whom, on what channel, and what that person does at 6 p.m. on a Friday. Rule number one, stated at the start: this is a no-blame room. The exercise is testing the process, and every gap found here is a gap an attacker will not get to use.

5. Capture gaps while they are fresh

The scribe's notes become a findings list in three categories: missing controls (no out-of-band verification path for payment changes), missing knowledge (nobody knew that an unexpected MFA prompt means the password is already compromised), and missing authority (the assistant did not feel safe refusing "the CEO"). Close the session by reading the list back and assigning an owner and a date to each item.

6. Fix, then re-test

An exercise that produces a report and no changes is theater. Convert findings into concrete controls — a callback procedure, a help-desk verification standard, number matching on MFA — and schedule a re-run of the same scenario in about six months. The second run is the real measurement: it tells you whether the fixes survived contact with day-to-day operations.

Wiring tabletops into a human risk program

A tabletop exercise is a point-in-time deep dive; its value multiplies when the findings feed a continuous program rather than a binder. The scenarios that surface in the room should shape what you test at scale — if the exercise revealed confusion about voice-based requests, the next quarter's simulation program should include vishing and callback lures, and the deepfake playbook from our deepfake voice attacks guide belongs in the follow-up training. Repeated exercise findings are also a signal worth quantifying: departments that consistently struggle in scenarios are measurably higher-risk, and that belongs in your human risk score alongside simulation and behavior data.

Start small: one scenario, ninety minutes, the right ten people, and a findings list with owners. The organizations that handled real social engineering attacks well — Ferrari's improvised challenge question, the LastPass employee who reported a deepfake call instead of engaging — succeeded because someone in the moment knew a refusal was expected and safe. That knowledge is exactly what a tabletop builds.