What is an inject in a tabletop exercise?
An inject is a piece of new information the facilitator or control team introduces during an exercise to move the scenario forward and prompt players to decide or act: an alert from the monitoring tool, a call from a reporter, a message from the attacker. It has nothing to do with SQL injection or other code attacks. FEMA’s HSEEP doctrine defines an inject as a master scenario events list event introduced to a player by the control staff, representing non-playing entities.
What it means in practice
A well-built inject has six parts: who is speaking (the source), how it arrives (email, phone call, screenshot, news clip), what it says, when it lands or what triggers it, the action it is meant to prompt, and the objective it tests. Without the last two it’s just a plot twist.
Most are scripted and timed. Some are conditional: they fire only if players haven’t done something yet, like calling counsel. In a tabletop they are often delivered as slides, printed cards or the facilitator speaking in character. CISA’s tabletop packages group them into modules with discussion questions, and its facilitator guidance describes facilitators presenting situation updates and moderating the discussion.
The best injects give a little detail and leave the interpretation to the players. “Unusual outbound traffic from a file server” is more realistic than “data is being stolen.”
Where it shows up in an incident
There are no injects in a real incident. Information just arrives: an alert, a vendor’s phone call, a ransom note, a customer’s email, a regulator’s letter. Good injects copy that pattern, including its mess. Facts come in partial, in the wrong order, from people who are not sure.
They are written by the planning team and delivered by the facilitator or controllers. Trusted agents review them for realism. Common mistakes:
- Too many, too fast. Players need time to finish one decision before the next arrives.
- Too technical for the room. An executive team needs injects about money, customers, legal duties and public statements, not packet captures.
- Injects that hand over the answer, like a message reading “this is a ransomware attack.”
- Injects that test only IT. The business, legal, privacy and communications sides need their own.
- No tie to an objective, and no contingency version for a group that skips ahead.
In a tabletop exercise
Two sample injects for a 120-person company.
Inject A, 2:10 p.m., from the help desk by phone. “Several people in accounts payable can’t open files on the shared drive. One says a document was renamed with a strange extension, and a text file with instructions has appeared on the desktop.” Facilitator prompts: who declares an incident, who is named to lead it, and what gets isolated first? Objective: activate the incident response plan.
Inject B, 4:45 p.m., email from a local business reporter to the communications lead. “We hear you’ve had a cyber attack. Can you comment before 5 p.m.?” Facilitator prompts: who approves a statement, what does the holding statement say, and who tells employees and key customers first? Objective: communications ownership.
Injects work best when they come from your own plan and systems. For the planning side, 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.