Whoever knows the script is not practising

Most emergency exercises run like this: everyone sits in the room, the exercise lead hands out the scenario as a PDF, it is read together, discussed, and at the end the minutes say the plan works. That is not a bad event. BSI Standard 200-4 calls it a plan review, in quotation marks a "desk test", and expressly recommends it.

But it is not a staff exercise. And for the reactive BCMS the standard requires in section 13.1 that staff exercises and alerting exercises be carried out regularly. Must, not should.

The difference is the script

A staff exercise begins with an initial situation, not with the whole scenario. The team assesses the situation, declares the emergency, and then the injects come: the second report, the call from the press, the ransom note, the failure of the fallback site. The exercise lead holds an exercise script with the intended course for that, and the standard says in 13.6.2 expressly that the lead may decide at any time "that an inject is played earlier, later or not at all, if this has a positive effect on the course of the exercise".

That sentence is the core. It only works if the team does not know the script. Whoever knows the ransom note arrives at T+40 waits for it. Whoever does not has to decide whether to wake up management now.

The time that is to be measured

At the same point the standard wants a number: the time from the initial situation to declaring the emergency. It is "an essential component of the crisis organisation’s response time", alongside detection and alerting time, and is to be measured and compared with the response time from the business impact analysis. An exercise where the lead glances at the wall clock and recalculates the injects in their head delivers that number imprecisely at best.

What became of that in the product

The emergency management module in isidaten runs exercises with a script of injects, each with a time T+n minutes. "Start exercise" sets T+0 and writes the log entry. From then on an exercise clock runs against server time: per inject "due in", "due now" or "overdue since", the next inject with its own countdown and release button. Release stays with the exercise lead. The clock says when the script intends it; whether the inject comes is decided by the person.

The team gets its own participant page, without sign-in, by link or QR code. It shows the exercise clock and the released injects, with attachments: a README_RECOVER.txt as the ransom note sits directly on the page, a screenshot inline, a PDF for download. Before release the attachment endpoint answers 404, not "not yet".

What the participant page never shows

Three things are deliberately missing from the participant page, and building it showed that the third is the easiest to forget.

First, the expected reaction per inject. It belongs to the exercise lead and the observers, whom the standard obliges to neutrality in 13.6.2. Second, assessment and observations. Third, the scenario itself. In the first version it sat on the page as a heading, so participants would know what it was about. That is exactly what gives the situation away in advance. The team is supposed to establish it from the injects; that is the situation assessment the standard describes as the first step. The scenario is now removed from page and feed.

Dry run and handover

Whoever prepares an exercise plays it through once. Afterwards all injects are released and the clock stands at T+90. "Reset" puts the clock back to zero and reopens all injects; log and results are deleted only by ticking a box, and the reset itself is recorded in the log. A proven script can be exported as JSON and imported elsewhere either as a script only or completely as an archive.

The question to ask

When did your crisis team last assess a situation whose course it had not read beforehand? And how long did it take to declare the emergency?

If the first answer is "at the plan review", the second number has not been measured.

Sources

BSI Standard 200-4 Business Continuity Management (German), chapter 13 exercising and testing: 13.1 (obligation to run staff and alerting exercises in the reactive BCMS), table 34 (exercise types), 13.6.2 (conducting a staff exercise). Regulation (EU) 2022/2554 (DORA), Article 11(6): yearly testing of ICT business continuity plans. Section 30(2) no. 3 BSIG: business continuity and crisis management.