Tabletop Exercise Injects: Build an MSEL That Tests Decisions

TL;DR

• What it is: A Master Scenario Events List (MSEL) is the controller’s run sheet for exercise events, injects, expected actions, timing, and evaluation notes.
• Requirement status: An MSEL is not generally a regulatory requirement for a bank or fintech. It is an optional exercise-design technique; separate continuity or resilience testing obligations may still apply.
• How to use it: Build each inject backward from an objective, a decision, an expected action, and the evidence an evaluator should observe.
• What to record: Adapt the useful fields proportionately, including decision ownership, actual delivery time, evidence, and conditional branch logic.

A tabletop can feel productive and still test almost nothing.

The room is full. Leaders talk through the scenario. Someone takes notes. The session ends with broad agreement that communication should improve. The final record shows who attended—but not who decided, what authority they used, whether the plan worked, or what evidence supports the conclusion.

The missing control is often the Master Scenario Events List, or MSEL: the controller’s timeline connecting exercise events to expected actions and objectives. For a tabletop, a lightweight MSEL turns a sequence of discussion prompts into a controlled test of decisions.

This guide focuses on that artifact. For facilitator roles, probing questions, and hot-wash technique, use the companion guide on tabletop exercise facilitation. Use the 90-minute tabletop template for an end-to-end agenda, or the tabletop scenario library when you need a disruption to adapt.

What Is an MSEL?

Plain-English answer: An MSEL is a chronological control sheet showing the events and injects that will enter exercise play, who delivers and receives them, the participant action expected, the objective being tested, and controller or evaluator notes. Think of it as the controller’s run sheet, not a participant checklist.

Requirement status: An MSEL is not generally required by regulation for banks or fintechs. FEMA HSEEP and NIST SP 800-84 are guidance, while the FFIEC Business Continuity Management booklet is examination guidance that expressly says it does not impose requirements. An institution may still have applicable exercise or testing obligations from law, supervision, contracts, or internal policy, but those obligations do not automatically require this specific artifact.

FEMA’s 2020 Homeland Security Exercise and Evaluation Program doctrine defines an MSEL as a chronological timeline of expected actions and scripted events injected by controllers to prompt player activity and help meet exercise objectives. FEMA lists three MSEL event types:

1. Inject: information introduced by control staff to build the exercise environment and drive play.
2. Contingency inject: information used when a key expected action did not occur, giving participants another opportunity to address the objective.
3. Expected action: an anticipated participant action during the exercise.

HSEEP formally describes the detailed MSEL and MSEL planning meeting in the context of operations-based exercises. A discussion-based tabletop does not automatically need the same machinery. Adapting a lightweight MSEL for a tabletop is a practical RiskTemplates interpretation, not a claim that FEMA or the FFIEC requires every tabletop to use one.

If you are still deciding which exercise method fits the capability being tested, start with the broader business continuity testing guide. The rest of this article assumes you have already chosen a tabletop and now need to control its injects.

Keep the tabletop MSEL proportionate. It is a controller and evaluation tool, not a second business continuity plan.

Start With the Decision, Not the Disaster

A weak design process starts with a dramatic scenario and asks, “What complications could happen next?” That tends to produce entertaining injects with no evaluation logic.

A stronger process works backward:

Use each inject to trigger a decision tied to an objective, then define the evidence the evaluator will capture.

If you cannot complete all three of these statements, the inject is not ready:

• “This inject tests whether participants can decide _____.”
• “The plan, procedure, or authority relevant to that decision is _____.”
• “The evaluator will know what happened by observing or collecting _____.”

The Minimum Viable MSEL Fields

HSEEP says each operations-based MSEL entry should include an event number, scenario time, event type, inject mode, sender, recipient, message, expected participant response, exercise objective, and notes. In its functional-exercise section, NIST SP 800-84 separately describes the MSEL, message injects, and a message-inject tracking form. Together, those artifacts cover event sequencing, expected actions, objectives, delivery channels, scheduled and actual injection times, and injector comments.

For a financial-services tabletop, use those as the baseline and add fields that make the record easier to challenge later:

“Expected action” does not mean the controller should force participants toward a predetermined answer. It means the design team has identified behavior it expects to observe based on current plans, authority, and exercise objectives. A different action may reveal that the plan is wrong, the scenario exposed a valid alternative, or the participants misunderstood their authority.

A Worked MSEL for a Payment-Processing Outage

The following example is hypothetical. It illustrates structure, not a prescribed response or regulatory notification timetable.

Exercise objectives:

• OBJ-1: Classify the outage, establish decision authority, and activate the appropriate continuity governance.
• OBJ-2: Prioritize customer-impact controls and constrained workarounds.
• OBJ-3: Approve accurate external communications while material facts remain uncertain.
• OBJ-4: Decide on recovery conditions, reconciliation, validation, and return-to-normal criteria.

The table below is a page-friendly reader view. In the working spreadsheet, keep scenario time and actual delivery time as separate fields.

The working control sheet should preserve the full schema. In a workbook, use the fields below as columns. On this page, the same hypothetical INJ-01 record is shown vertically so every field remains readable.

The MSEL controls the test without prescribing the participants’ answer. It makes decisions, authority, dependencies, and evidence visible to controllers and evaluators.

How to Write Tabletop Exercise Injects That Force Decisions

A useful inject changes what participants know or constrains what they can do. It should not merely add color to the story.

Weak inject

The provider continues working on the outage.

Nothing must be decided. Participants can acknowledge the update and wait.

Stronger inject

The provider offers two options: restore sooner using a checkpoint that requires transaction reconciliation, or wait for a later restoration with a more complete dataset. The provider needs an authorized decision within 20 minutes.

Now the team must identify authority, compare customer and operational impacts, establish control conditions, and document a decision.

A strong inject usually contains four elements:

1. A material change or uncertainty. New information makes the current plan incomplete.
2. A decision owner or escalation problem. Someone must decide, approve, or elevate.
3. A consequence. Delay or action changes customer, financial, legal, operational, or recovery exposure.
4. Observable output. The team produces a decision, communication, record, or control response.

Avoid turning injects into trivia questions. “What does section 4.2 of the plan say?” tests recall. “The named approver is unavailable; who can authorize the workaround, and what supports that authority?” tests whether governance works.

Use Branch Logic Without Rescuing Participants

A controller should not deliver every row simply because it appears in the spreadsheet. Mark each event with a disposition rule:

• Deliver: the event is required to test the objective.
• Hold: participant discussion is still producing relevant decisions or evidence.
• Skip: participants already addressed the intended decision through another route.
• Contingency: deliver only if an expected action did not occur or a decision remains unresolved.
• Replace: use an alternate inject when participants take a valid path that changes the scenario.

FEMA describes a contingency inject as an additional opportunity to meet an objective when an expected action does not occur. That does not mean controllers should repeatedly hint until participants reach a passing answer. One clarifying prompt may test whether the problem was incomplete information. Repeated coaching hides a capability gap.

Record both the planned and actual delivery time. If a ten-minute decision consumes forty minutes, that variance may be more informative than the eventual answer.

Evaluate Evidence, Not Airtime

Attendance, confidence, and discussion quality can provide context. They are not substitutes for performance evidence.

HSEEP’s evaluation method emphasizes observing decisions, actions, information sharing, and outcomes, then comparing actual performance with exercise objectives. It also calls for a fact-based record rather than assumptions about what participants would have done.

For each priority decision, identify evidence before the exercise:

• incident classification or activation record;
• decision log with time, owner, rationale, and approval;
• plan, procedure, or authority cited;
• impact assessment or dependency map used;
• draft customer, partner, board, or regulator communication;
• workaround instructions and approval conditions;
• reconciliation, validation, or recovery checklist;
• assigned issue owner and due date.

A tabletop may simulate these artifacts rather than complete production records. The evaluator should still record whether participants could identify the artifact, its owner, required inputs, and approval path.

After the session, connect MSEL event IDs to findings in the after-action report. That creates a traceable chain:

objective → inject → decision → evidence → finding → corrective action

Quality-Control the MSEL Before Exercise Day

Run a controller dry run and challenge every row:

• Does the inject map to a named objective?
• Does it require a decision, action, or artifact?
• Is the simulated sender credible, and is the intended recipient the role that would actually receive it?
• Does the team have enough information to decide without making the answer obvious?
• Is the expected action observable?
• Is the evidence specific enough for an evaluator to capture?
• Does another inject test the same decision?
• Is the contingency logic defined?
• Could the inject accidentally introduce an unsupported legal deadline, contractual term, or system capability?
• Does the sequence leave enough room for participants to work the problem?

There is no universal correct number of injects. In its guidance for functional exercises, NIST SP 800-84 says the number of message injects should vary with exercise duration and keep participants occupied without overwhelming them. For a tabletop, treat that as an adapted pacing heuristic, not a NIST tabletop requirement. Remove an inject if it duplicates a decision. Add one only if an important objective otherwise has no test.

Where Regulatory and Supervisory Sources Fit

Practitioners should separate three different concepts:

1. A regulatory requirement is imposed by an applicable law, rule, order, or other binding authority.
2. Supervisory or examination guidance describes how an agency approaches sound practice or examination; it is not automatically a binding requirement.
3. A best practice is an optional technique adopted because it improves control or evidence quality. A lightweight tabletop MSEL falls in this category unless another obligation, contract, or internal policy specifically requires it.

Any actual exercise or testing requirement depends on the institution’s charter, regulator, size, risk profile, contracts, internal policy, and the systems or services in scope. Confirm those obligations separately. An MSEL can improve the test record, but using one does not by itself prove regulatory compliance or program sufficiency.

So What?

If your last tabletop record is a scenario deck, an attendance sheet, and a list of general observations, build the next exercise backward from decisions.

As a practical starting point for a focused session, choose three to five priority decisions. Define the evidence each should produce. Write only the injects needed to create those decisions. Add conditional branches. Track what was delivered, what participants did, and where the evidence lives.

The result is a tabletop record that shows more than activity: it shows what the team decided, what authority it used, and what evidence supports the evaluation.

Need a facilitator-ready starting point? The Business Continuity & Disaster Recovery (BCP/DR) Kit includes a 23-page Tabletop Exercise Kit with scenario cards and a findings template, plus BIA, dependency-mapping, test-log, action-tracking, and board-reporting materials. Tailor the scenarios, injects, evaluation criteria, and evidence to your organization and applicable requirements.