Designing Tabletop Injects and the MSEL
Write tabletop injects that force real decisions: inject anatomy, types, branching, realism artifacts, pacing, and a Master Scenario Events List you can reuse.
An inject is any piece of information you introduce into a tabletop to move the scenario forward: an alert, a phone call, an email from a supplier, a news headline, a message from the regulator. Injects are the engine of the exercise. Good ones force the group to make a decision someone will really face; weak ones produce nodding and a slide change.
This guide covers inject anatomy, the main inject types, how to sequence them in a Master Scenario Events List (MSEL), and how to calibrate difficulty. It assumes you already have objectives; if not, start with the planning guide.
Start from objectives, work backwards
Write each objective at the top of a page. Under it, list the decisions and behaviours that would demonstrate it. Then ask: what information would make the group face that decision? That information is your inject.
| Objective | Decision to force | Inject that forces it |
|---|---|---|
| Declare severity within 30 min | Is this a Sev-1? Who says so? | Service desk reports three sites cannot open shared drives |
| Agree who authorises isolating the hypervisors | Take production offline or not | IT ops asks for approval to disconnect the virtualisation network |
| Confirm external statement approval chain | Who drafts, approves and sends | A journalist emails asking for comment within the hour |
| Test notification decision-making | Notify now or investigate further | Threat actor posts sample files that include customer data |
If an objective does not generate at least one inject, either write one or drop the objective.
Anatomy of an inject
Every inject in the MSEL should carry the same fields. This makes the exercise easier to run and to evaluate.
- ID: a short reference, such as
INJ-04, used in notes and the report. - Exercise time: when it is delivered, as
T+hh:mmfrom the start of the scenario. - From: the simulated source (SOC analyst, CFO's assistant, regulator, attacker).
- To: which player role receives it first. Delivering to one role and watching how it spreads is itself a test.
- Mode: how it arrives: verbal, handout, slide, email, phone call played by the controller, mock ticket.
- Content: the text or artifact players see.
- Expected actions: what a well-prepared team would discuss or decide. Used by the facilitator and evaluators, never shown to players.
- Objective: which objective(s) it supports.
- Facilitator notes: probing questions, likely pitfalls, what to do if the group gets stuck.
- Optional: whether it can be skipped for time.
A reusable inject template
- id: INJ-04
time: "T+01:10"
module: "Containment"
from: "IT Operations lead (via incident bridge)"
to: "Incident commander"
mode: "verbal + handout"
content: >
"We can stop the spread by disconnecting the virtualisation management
network, but every VM on that cluster goes down, including order
processing and the warehouse system. I need a go/no-go in 15 minutes."
artifacts:
- "handout-04-cluster-diagram.pdf"
expected_actions:
- "Identify who has authority to approve a production-wide outage"
- "Weigh containment benefit against business impact"
- "Record the decision, time and approver"
- "Inform the business owner and communications before systems drop"
objectives: [OBJ-2]
probes:
- "Who can approve this at 11 pm on a Friday?"
- "What evidence would you lose if you shut down vs disconnect?"
optional: false
Types of injects
A well-balanced exercise mixes several types.
| Type | Purpose | Example |
|---|---|---|
| Information | Advances the story; adds facts | EDR shows the same encryption binary on 40 hosts |
| Escalation | Raises stakes or scope | The attacker's leak site lists your company with a countdown |
| Decision point | Forces an explicit choice with trade-offs | Approve shutting down the ERP to contain spread? |
| Stakeholder pressure | Tests communications under pressure | A major customer's CISO calls asking if their data is affected |
| Constraint | Removes a resource players rely on | Email and chat are down; the IR lead is unreachable |
| Curveball | Tests adaptability; used sparingly | The backup server was also encrypted |
| Clarifying | Answers a question players asked, in character | The insurer confirms coverage requires using a panel firm |
Constraint injects are among the most revealing. Many plans quietly assume email, the corporate chat and the document management system all keep working during a cyber incident. Take one away and see what happens; it is a direct test of your out-of-band communications.
Building the MSEL
The MSEL is the master timeline of the exercise. Facilitators run from it; evaluators score against it. A compact version for a 2.5-hour ransomware exercise:
| ID | Time | Module | From → To | Inject summary | Objective | Optional |
|---|---|---|---|---|---|---|
| INJ-01 | T+00:00 | Detection | SOC → IR lead | EDR alert: mass file renames on a file server | OBJ-1 | No |
| INJ-02 | T+00:20 | Detection | Service desk → IT ops | Users at three sites cannot open shared drives | OBJ-1 | No |
| INJ-03 | T+00:45 | Escalation | IT ops → IR lead | Hypervisor cluster unreachable; ransom note found | OBJ-1, OBJ-2 | No |
| INJ-04 | T+01:10 | Containment | IT ops → Incident commander | Request to disconnect the virtualisation network | OBJ-2 | No |
| INJ-05 | T+02:30 | Containment | Controller (insurer) → Legal | Insurer requires panel IR firm; claim number needed | OBJ-3 | Yes |
| INJ-06 | T+06:00 | Escalation | Threat intel → IR lead | Company listed on leak site; sample files include HR data | OBJ-3, OBJ-4 | No |
| INJ-07 | T+08:00 | Communications | Journalist → Comms | Request for comment within one hour | OBJ-3 | No |
| INJ-08 | T+20:00 | Recovery | IT ops → CIO | Offline backups intact but full restore estimated at 5 days | OBJ-4 | No |
| INJ-09 | T+26:00 | Recovery | Controller (attacker) → CEO | Ransom demand reduced if paid within 24 hours | OBJ-4 | Yes |
The full scenario for this example is in the ransomware tabletop scenario.
Making injects realistic
Realism keeps experienced players engaged and prevents "this could never happen" objections.
- Use your own names: your system names, your business services, your sites, your roles. Generic scenarios produce generic answers.
- Show artifacts, not narration. A mock alert with a hostname and a timestamp prompts players to ask the right questions. A narrator saying "you detect ransomware" skips the detection decision entirely.
- Keep artifacts harmless and clearly fictional. Use reserved domains such as
example.com, documentation IP ranges such as192.0.2.0/24and obviously fake file hashes. Mark handouts "EXERCISE — NOT A REAL INCIDENT". - Include ambiguity. Real alerts are incomplete. An inject that could be a false positive tests triage.
- Match time to reality. If forensic imaging of 40 hosts would take a day, don't give players results ten minutes later in exercise time.
A simple, harmless alert artifact:
=== EXERCISE — NOT A REAL INCIDENT ===
EDR ALERT Severity: High Status: New
Time: 2026-10-15 22:47 UTC
Host: FS-02 (file server, Lyon site)
Rule: Rapid file modification with extension change
Details: 1,240 files renamed to *.locked in 90 seconds
Process: C:\ProgramData\svcupd.exe (unsigned)
Parent: services.exe
User: SYSTEM
Related: Similar activity on FS-03 (2 min ago)
Branching and contingent injects
Players will not always follow the path you expect. Plan for it.
- Contingent injects are delivered only if players take (or fail to take) an action. Example: if players have not engaged legal by T+02:00, the controller plays outside counsel calling to ask whether privilege has been established.
- Branch points offer two versions of the next inject depending on a decision. If players isolate the cluster, INJ-05a describes the business outage; if not, INJ-05b describes further encryption.
- Reset injects bring a derailed group back onto the main line: "Regardless of earlier choices, it is now Saturday 09:00 and the following is true…"
Keep branching shallow. Two levels is plenty for a tabletop; beyond that the facilitator loses track and the evaluation becomes inconsistent.
Calibrating difficulty
Tune difficulty to the maturity of the team and the objectives.
| Lever | Easier | Harder |
|---|---|---|
| Information | Clear, confirmed facts | Partial, conflicting reports |
| Timing | Generous gaps between injects | Overlapping injects, simultaneous demands |
| Resources | Everyone available, tools working | Key person unreachable, email down |
| Scope | One site, one system | Multiple sites, cloud and on-premises |
| External pressure | None | Media, regulator, customers, attacker contact |
| Decision stakes | Reversible choices | Irreversible, high-cost trade-offs |
A first exercise for a team should feel challenging but winnable. If the group is overwhelmed by inject three, they learn only that incidents are stressful, which they already knew.
Pacing the MSEL
- Budget 10 to 20 minutes per main inject, including discussion.
- Put the most important decision injects early in each module, before time pressure builds.
- Mark two or three injects optional so the facilitator can adjust on the day.
- Do not sacrifice the communications and recovery modules. They are often where organisations are weakest and they are the first to be cut when earlier modules overrun.
Dry-run checklist
Run through the MSEL with the planning team a week or two before the exercise:
- Does each objective have at least one inject that forces a decision?
- Could a player answer each inject with "we'd follow the plan"? If so, add a complication.
- Is each artifact readable in under a minute?
- Is exercise time consistent and realistic?
- Can the exercise finish on time with optional injects removed?
- Does the controller have a script for every simulated party?
- Is the hotwash protected in the agenda?
Related
Frequently asked questions
How many injects should a tabletop exercise have?
For a two- to three-hour exercise, seven to ten main injects is a good range, plus two or three optional injects the facilitator can use or skip depending on time. Each inject needs roughly ten to twenty minutes of discussion to be useful.
What is the difference between an inject and a MSEL?
An inject is a single piece of information introduced into the exercise, such as an alert, an email or a phone call. The Master Scenario Events List (MSEL) is the ordered list of all injects with their timing, delivery method, recipients, expected player actions and the objective each one supports.
Should injects tell players what happened or show them evidence?
Show evidence where you can. A mocked-up EDR alert, a ransom note or a journalist's email makes players interpret and decide, which is closer to reality than a narrator explaining the situation. Keep artifacts clearly fictional and harmless.