What is a master scenario events list (MSEL)?
A master scenario events list, or MSEL, is the timed script for an exercise: a chronological list of the events (injects) the exercise team will introduce and the actions players are expected to take in response. FEMA’s HSEEP doctrine describes it as a document or system that is a chronological timeline of expected actions and scripted events, injected into play by controllers to prompt player activity.
What it means in practice
Each row usually holds an event number, a scheduled time or trigger, the inject itself, who delivers it and how (a phone call from the help desk, an email, a screenshot, a news clip), the response expected, and the exercise objective it tests. The last two columns do the work. They tie every inject to something the exercise is trying to learn, so the session doesn’t drift.
Players never see the MSEL. The facilitator, the controllers and the trusted agents do.
One point of vocabulary. HSEEP lists the MSEL among the documents for operations-based exercises (drills, functional and full-scale exercises). For discussion-based exercises such as tabletops, it lists a situation manual and a facilitator guide instead. CISA’s cybersecurity tabletop packages likewise organize play into modules with discussion questions. Many cyber tabletop facilitators keep a simple run sheet that does the same job.
Where it shows up in an incident
A MSEL doesn’t appear in a real incident. Its real-world counterpart is the incident timeline: the running record of what happened, when, and what was decided (see decision log). A MSEL is that timeline written in advance.
It is owned by the lead planner and the facilitator, drafted with the planning team and checked by the trusted agents for realism. Common mistakes:
- Events that arrive in a tidy order with plenty of time between them. Real incidents deliver conflicting information while earlier problems are still open.
- No contingency injects. HSEEP’s planning guidance mentions contingency injects to prompt player action if needed, such as a message that fires only if players haven’t yet called their insurer.
- Reading the next row aloud even when the group has gone somewhere more useful.
- Injects that test nothing. If a row has no objective beside it, cut it.
In a tabletop exercise
Two sample rows for a ransomware scenario at a 120-person company:
Event 5, T+40 minutes. Delivered by the facilitator, in the role of the help desk, by phone: “Six people in accounts payable can’t open files on the shared drive. One says a file now has an odd extension and a text file has appeared on the desktop.” Expected action: someone declares an incident and names an incident commander, and the group makes a first containment decision. Objective 1: activate the incident response plan.
Event 9, T+95 minutes. Contingency inject, used only if no one has called the insurer. Delivered as an email from the broker: “In this scenario, the policy asks for notice before an outside forensic firm is hired. Has anyone called?” Expected action: the group identifies who holds the policy and who makes the call. Objective 3: notify the insurer before engaging vendors.
For planning help, see how to test an incident response plan.
Sources
Want to see how your team would handle this for real? Here is how a facilitated tabletop works.