Why rehearse if you already have a plan
A plan on paper is tested only by carrying it out. The very first rehearsal reveals the usual things: contacts are out of date; nobody can isolate the network segment because the admin is on holiday; the backup takes a full day to restore, not four hours; and management spends half an hour arguing about who has the authority to stop shipments. Each such finding costs nothing in an exercise. In a real attack it costs hours of downtime, at a price you already know how to calculate.
Format: tabletop simulation
A tabletop exercise is a facilitated game. The facilitator gives inputs, the team makes decisions in real time, and no live systems are touched. It is safe, cheap and sufficient: 80% of the findings come from decisions and communications, not from technology. The technical layer, restoring a test environment from a real backup, is added as a second stage for the IT team.
The “72 hours” scenario, phase by phase
- Hours 0-2 (30 minutes of game time). Morning: files will not open, and a ransom demand is on the screens. Who notices it, whom do they call, who has the authority to disconnect the network? We test the activation triggers.
- Hours 2-8. The scale is clear: ERP and email are down. The crisis team is assembled. Decisions: whether to pay the ransom (the legal position), and what to tell employees and customers. The spokesperson writes the actual text against the clock.
- Days 1-2. Recovery: the order in which systems are restored, based on the cost of downtime, and workaround processes, such as how to take orders without ERP. We check whether the manual procedures exist in practice or only on paper.
- Day 3. Return to work, notifications (customers and the regulator: for financial organisations this is mandatory), and a debrief on what needs fine-tuning.
Roles and observers
The players are the people who will act for real: the CEO or COO (decisions), IT, finance, communications, legal and HR. The facilitator gives inputs and complications (“a journalist is already calling”, “the backup turned out to be encrypted”). An observer with a stopwatch records the time of each decision, and this is where the metrics come from.
What we measure
- Time to activate the crisis team and time to the first message to employees.
- Actual time to restore a critical system from a backup (technical stage).
- The share of critical processes where the workaround mode worked.
- The number of decisions for which no responsible person or authority could be found.
These figures go into the continuity dashboard and turn “we are ready” from an opinion into a measured fact. They also give the underwriter and the board of directors what they want to see.
After the exercise: report and decisions
The result of one day is a short report: measured times, the top 10 findings, each with an owner and a deadline, and management decisions on disputed points (ransom policy, the crisis team's limits of authority). After 3-6 months, the exercise is run again: the comparison of times shows your progress. We run these rehearsals as a fixed-price service: a scenario tailored to your business, facilitation, measurements and a report for the management board.
An exercise like this is part of the ransomware readiness check, together with a test of restoring from backups and a loss calculation in roubles.
Frequently asked questions
How long does it take? The tabletop part takes 3-4 hours in one block. The technical recovery stage is a separate day for the IT team. Preparing the scenario takes a week.
Will it scare the team? Quite the opposite: the most common feedback is relief. What frightens people is the unknown, and a rehearsed attack is no longer unknown.
How often should you run them? Twice a year: one cyber scenario and one non-cyber scenario (an accident or loss of a supplier; see the types of exercises).
Is your team ready for the first hour of a crisis?
You test a plan by running a scenario. Reading it is not enough. The assessment shows the gaps, and the corporate format works through them with your team on your own processes.