IncidentKitBuild Your Exercise

Tabletop Exercise Inject Examples

An 'inject' is a new piece of information introduced mid-exercise to move the scenario forward. Here's what separates a good one from a weak one, with examples.

What makes an inject good

A strong inject does three things: it introduces genuinely new information (not just more detail on something already known), it forces a decision or a change in plan, and it has a clear teaching point — you should be able to say in one sentence what you want the team to practice or discover.

A weak inject is either pure technical trivia with no decision attached, or so vague that the group doesn't know what to actually do with it.

Example: Ransomware

Weak: "The malware uses AES-256 encryption."

Strong: "IT reports backups may also be affected — it's unclear yet. Finance needs system access in two days to run payroll."

Teaching point: forces a business-continuity decision under real uncertainty, and surfaces whether the team has a manual fallback for time-critical functions.

Example: Business Email Compromise

Weak: "The attacker used a spoofed email address."

Strong: "A call to the CEO's known cell number goes to voicemail. A reply email pushes back on the delay, adding pressure."

Teaching point: tests whether verification procedures hold up under social pressure and urgency, which is exactly how these attacks succeed in real life.

Example: Vendor Breach

Weak: "The vendor was hacked."

Strong: "Two days pass with no further detail from the vendor. Some staff want to suspend their access as a precaution; others worry about business disruption."

Teaching point: forces a decision under incomplete information and clarifies who actually has authority to make that call.

Example: Lost or Stolen Device

Weak: "The laptop was not encrypted."

Strong: "IT checks records and isn't fully certain whether full-disk encryption was enabled on this device — inventory records are incomplete."

Teaching point: surfaces an asset-management gap through the story, rather than as an abstract audit finding — usually a more memorable way to make the point.

A simple structure for writing your own

  1. Start with the decision you want the team to face.
  2. Write the smallest piece of new information that would force that decision.
  3. Add one detail that creates realistic ambiguity — you rarely have complete information in real incidents.
  4. Write two to four discussion questions and two to four expected actions to guide facilitation.

Want this done for you, tailored to your organization?

Build Your Exercise