Anatomy of a ransomware exercise: 90 minutes of manufacturing crisis

Plenty is written about tabletop exercises; very little shows what actually happens inside one. So this article opens the door: a walk through the Verdus scenario “Production-line ransomware” from the inside: phase by phase, with the injects, the decision points, and what ends up in the debrief.

The setup: a fictional plant, a very real dilemma

The scenario’s starting position: a phishing foothold in corporate IT escalates into a domain-wide ransomware deployment that reaches the plant network. Production control systems go dark, orders back up, and the attacker threatens to publish stolen design files. The dilemma is set from minute one: every hour of standstill costs money, and so does every premature cut between IT and OT. Nobody gets to avoid both.

Six roles sit at the table, each with a different view of the same situation:

• Crisis team lead: owns cadence, the decision log and escalations; keeps the room on decisions instead of diagnosis.
• IT / SOC lead: containment options, forensic preservation, and the honest answer to whether it is still spreading.
• OT / plant operations: safe-shutdown and manual-operation options; speaks for what the line can actually still do.
• Communications: holding statements for customers, suppliers and press; one story across every channel.
• Legal / data protection: ransom legality, contract penalties, notification duties and evidence discipline.
• Executive sponsor: the ransom stance, spending authority and the final call when functions disagree.

Technically, the exercise runs in the browser, on two seats: a facilitator drives injects, pacing and curveballs from the controller seat, while the team works a realistic console (inbox, calls, news, chat). Behind it sits a library of 65+ injects across more than 20 categories. The full manufacturing scenario is laid out for roughly three hours; for executive sessions a facilitator runs the same dramaturgy compressed into 90 minutes, because pacing is a directing tool in the inject queue.

Phase 1 · Detection and alarm: the situation takes shape

The opening is deliberately undramatic. First inject (exercise content): the EDR flags mass file encryption spreading toward the OT DMZ. No countdown, no ransom note, just an alert that can be read correctly or incorrectly. The first measurable decisions fall right here: who declares an incident? Who convenes the crisis team, and how long until it is actually able to work? Teams that give these minutes away spend the rest of the exercise chasing the situation.

Phase 2 · Containment: the IT/OT question

Then the line stops. A shift supervisor calls (exercise content, delivered as a phone inject) asking whether to shut down safely. That puts the hardest question of the scenario on the table: do you disconnect the OT network on suspicion alone, and who even has the authority to stop production for what may be days? In parallel, the crisis team needs an honest answer on backup status: “it should work” is not one. One of the documented exercise objectives: an IT/OT decision within 30 minutes of the first inject, with production, safety and delivery impact weighed on the record.

Phase 3 · Escalation peak: customer, countdown, ransom

Now the direction tightens. A key customer demands a delivery guarantee within the hour: what do you promise while the blast radius is still unknown? Shortly after, the attacker posts a countdown on their leak site. At the latest here, the ransom question arrives in its most uncomfortable form: backups unverified, pressure rising. At what point does paying become a board-level option, and who says the word first? The exercise does not force a particular answer. It forces a decision, with its reasoning, captured in the log.

Phase 4 · Reporting and communications: the early warning takes shape

While the ransom question is still open, regulation knocks: a dedicated reporting-chain inject. The team must decide whether the incident is notifiable and get the 24-hour early warning to the competent authority drafted before the exercise ends, one of the scenario’s fixed objectives. In parallel, the customer line and the press line have to match: what sales tells the key account and what communications prepares must not contradict each other. And somewhere in between, someone has to decide who briefs the works council and the shift teams.

Hot wash and debrief: what gets measured

The final minutes belong to the hot wash: the facilitator mirrors the situation against the timestamped decision log. Because every decision is captured with a timestamp, an owner and a rationale, this is not a memory round: it is a comparison with data. The debrief package then scores the run across eight competencies and maps the findings to NIST CSF, ISO 27001, MITRE ATT&CK, DORA and NIS2. Concretely, it answers questions such as:

• How long did the IT/OT decision take, and who took it, on what basis?
• Would the 24-hour early warning have reached the authority in time?
• Did customer and press communications hold one line across every channel?
• Which gaps surfaced, and which measure follows from each of them?

A vague sense that it went okay becomes a defensible timeline with findings and an action list, usable as exercise evidence towards supervisors, auditors and your own board.

Why is 90 minutes enough? Because an exercise does not need the length of a real crisis: it needs its density. What matters is not how long the team sits in the room, but that it takes the five or six decisions nobody will be able to look up when it happens for real. Everything else (format, depth, sector) is a matter of direction.