"What will we do when a breach happens?": Preparing for incidents in advance using video games as an example

When creating a cyber-resilient infrastructure, much attention is paid to security checks: pentests, Red/Purple Teaming, Bug Bounty programs, and cyber exercises. Assessments often boil down to a binary question: "Hacked / Not hacked?" However, even if a hack has not yet occurred, this does not mean that the business is resilient to attacks, as the question remains: "What will we do when we get hacked?"

When most systems are down, the scale of the disaster is unclear, and the media is already publishing insider information, many act reactively and blindly, relying only on experience and intuition. At the same time, actions after an incident can and should be tested in advance. While there is already a systematic approach to testing resilience to hacking, the situation with checks for the ability to stay afloat after a successful attack is more complex — there is no unified methodology. Recommendations are scattered across various standards, which I have studied and compiled into a table. Use it if you want to check not the security but specifically the response capability to a large-scale incident and recovery afterwards.

*For convenience, the terms "testing," "learning," and "checking" are used as synonyms in the text.

To make it easier to work with the table, I will describe the formats and levels of testing using video games as an example.

So, here is what we have by format:

• Theoretical, discussion-based testing — discussions of plans and potential actions without a specific incident scenario. We gathered, clarified roles, discussed who does what, how long it will take, identified shortcomings in the plan, or recorded the discussion in a new plan.
  This is the "training mode," where we are told that W means to move forward, and holding Shift means we will run. We ran around an empty room and changed some control settings if we realized that something was not satisfactory.

• Tabletop testing with a scenario — enriched theoretical testing with an incident scenario aimed at comprehensive analysis of plans and responses to the incident.
  
  Imagine playing on the easiest difficulty level just to get acquainted with the storyline. We completed the game, know where the key bosses and forks are, but did not touch the side quests and defeated enemies with one hit. We anticipate what awaits us on hard mode and without saves (in the event of an incident), but we have not experienced those feelings.

• Modeling — practical testing of a response or recovery scenario, such as relocating employees to backup work locations or restoring a small segment of infrastructure in response to ransomware with the involvement of the cybersecurity team.
  
  Here we go through a complete run for a certain faction or one of the endings. We looked at the quests, and the difficulty was higher. In general, the game is completed, and the mechanics are learned; the next part of the series with the same mechanics will not pose difficulties.

• Full-scale testing — modeling involving the entire company.
  
  100% achievement unlocked. We know all the details and checked every chest. But a lot of time was spent.

• Functional or special checks — we check not the end-to-end process, but only a small part within its framework.
  
  An arena, an endless quest, or a "grinding" area where you can improve a specific skill of the main character. It may not be very interesting, but we need to drop by periodically.

It is also worth mentioning the conditional three levels of plans and their checks, taking game genres as an analogy:

• Strategic, defining key vectors in response and recovery. Usually, the main participants are top management.
  
  Interactive movie style games are best suited for understanding this level. Complex decisions and difficult choices are what a player does in interactive cinema or top management does in response to a crisis. And yes, 4x strategies are more similar to the usual activities of senior management, but we are talking about a crisis situation!

• Tactical, coordinating main tasks and turning the given vectors into specific tasks. Responsibility for it lies with the heads of IT, cybersecurity, PR, as well as with experts who have extensive knowledge and understanding of the full picture.
  
  This is classic Real Time Strategy, managing resources at the moment of the incident, assigning tasks, and leading the rescue team Azeroth infrastructure. And don't forget to reward the best with more gold based on the results!

• Operational, performing specific tasks—from implementing the DR plan to publishing the status of the incident in the Telegram channel.
  
  Good old shooters, where skill decides everything—this is about the operational level. And if the infrastructure is large and complex, plans are not prepared, and there is an abundance of legacy, then good old shooters turn into soulslike games.

Now let's overlay the level onto the format and gain an understanding of what and how we can test. Yes, ideally, you should conduct full-scale testing everywhere, but how much time and resources do you have to go through each game 100%?

Alright, now we can relax a bit: below we will discuss what international and domestic standards offer and how to choose a testing format based on the purpose and management level, and in conclusion, I will provide my version of an optimal approach to comprehensive response and recovery testing.

Foreign Practices and Standards

Of course, we should start with the classics: ISO 22301 and the entire series of business continuity standards are designed to increase the resilience of companies during various disasters and emergencies. A large-scale incident involving encryption or destruction of infrastructure also fits this description.

A separate standard in the family is ISO 22398:2013 Guidelines for exercises (created in 2013 and reaffirmed unchanged in 2022) — introduces a key division of exercises into two types: Discussion-based (theoretical discussions, such as tabletop crisis response testing) and Trials (practical tests with real actions, such as team evacuation to a backup site). The former are suitable for practicing strategic decisions and can be conducted even in the absence of detailed plans. The latter are effective at tactical and operational levels: they model a situation close to real life, allow checking the completeness of instructions, and measure response and recovery times.

This classification is not a choice of "either-or," but a basis for planning multi-level checks. It helps to systematically approach testing different aspects of response and recovery, combining theoretical development with practical checks where it is critical.

Details on readiness checks and testing of plans are also addressed in ISO 22313:2020 Guidance on the use of ISO 22301. The standard expands the classification set in 2013 and also relies on two levels of checks:

• Theoretical, discussion-based (Discussion): checks from joint discussions of the plan to table-top tests based on a developed scenario lasting several hours.

• Simulated (Simulation): larger-scale exercises involving multiple teams, with a complex branched scenario closely resembling a real incident.

In practice, the complexity of conducting such checks hinges on the budget. Moreover, there is no guarantee that full-scale simulation, which requires significantly more resources, will yield proportionally better results compared to discussion or tabletop, especially if systematic tests have not been conducted before. Investments in the quality of the scenario and preparation of participants often pay off faster than large-scale exercises without a foundation.

Another basis is ISO/IEC 27031:2025 Cybersecurity – Information and communication technology readiness for business continuity (revised in 2026). The standard is more focused on testing the readiness of technical infrastructure for recovery and divides testing into three blocks:

• Theoretical review of plans (Desktop process review) — discuss the recovery plan, check that the performers understand the instructions and the actions required of them.

• Recovery simulation — run a test recovery of an infrastructure component, system, or service.

• Digital resilience — conduct a full check of the IT infrastructure, for example, switching from the primary data center to the secondary data center.

Such checks are well-suited for testing DR plans but do not cover the entire response process, including communications, interaction with the media, and decision-making.

Another ISO standard dedicated to crisis management is ISO 22361:2022 Crisis management – Guidelines. For checking crisis response, it suggests using the already familiar ISO 22313 and ISO 22398. I would recommend that everyone planning exercises with top management read this standard to understand the possible phases of crisis management and moderate testing by asking the right questions.

From other recommendations and practices not related to ISO, the following can be highlighted:

1. NIST SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities covers a broader range of checks than ISO/IEC 27031, although it also emphasizes DR planning. Its classification of tests is characterized by versatility:

• Tabletop — theoretical discussions, both with and without a scenario.

• Functional — practical checks of specific functions within IT infrastructure recovery or communications, for example, switching to a backup provider.

• Tests — verification of components: from load testing of individual systems to full-scale exercises.

The standard covers operational and tactical levels with a focus on IT. Despite its publication date, which dates back to 2006, it remains a fundamental document in this area. Current NIST guidelines (SP 800-61 Rev. 3, SP 800-184) refer to 800-84 as a foundation when considering issues of exercises and testing.

2. Good Practice Guidelines 7.0 from the Business Continuity Institute introduces perhaps the most serious classification of exercises and tests:

• Discussion-based — theoretical discussions without a script.

• Scenario — tabletop testing based on a pre-developed scenario.

• Simulation — practical training of response elements with limited impact on infrastructure.

• Live — large-scale exercises in the style of "pull the switch and see what happens."

• Test — specific checks, from fire evacuation to backup testing.

This gradation is useful for mature organizations with established exercise practices. For companies that are just building a systematic approach to testing response and recovery, excessive detail can be an obstacle — it is better to first master the basic formats.

Domestic Standards and Recommendations

In Russian practice, systematic testing of the end-to-end response and recovery process is rare, as are theoretical classifications of such checks. Most often, in the context of cyber resilience, command-staff exercises (CSE) are mentioned. The term is borrowed from the civil defense/EMERCOM system and described in the methodological recommendations for the preparation and conduct of command-staff exercises in organizations by the EMERCOM of Russia. At a high level, they distinguish three types of training: practical (site-specific), theoretical (staff), and mixed (command-staff, tactical-special).

In practice, CSE is often used as a collective marketing term — from Purple Team to management training. It is most logically understood as tabletop testing based on a scenario, sometimes with elements of practice. This interpretation aligns with foreign analogs.

There is also in the domestic market GOST R 59711-2022 Management of Computer Incidents. Organization of Activities for Managing Computer Incidents. The document also introduces a classification of training for testing incident response:

• discussion (discussions);

• team training;

• practical exercises;

• mixed (using all three forms).

However, unlike foreign standards, the document does not detail each format. Moreover, the classification mixes criteria (formats, methods, and participants), causing most checks to formally fall into the "mixed" category, which reduces the practical utility of such classification. In the vast array of domestic standards, I was unable to find anything relevant — reader contributions are welcome in the comments!

What to do with this information?

Continuity management and crisis management standards, especially in the context of cybersecurity incidents, do not offer us a universal way of testing or a magic check for everything at once. In practice, companies often focus on protection "before the incident": even after a successful Red Team exercise, they rarely model response actions at the top management level, PR, and the whole organization. Instead of comprehensive response testing, they conduct spot functional checks. As experience shows, this affects the response speed during a real incident: instead of well-rehearsed procedures, the company spends critically important time discussing decisions that could have been made in advance.

In my opinion, an optimal addition to security checks is tabletop testing with a scenario based on the successes of attackers, followed by specific hypothesis testing for recovery voiced during the tabletop. This sequence answers the main question: how cyber resilient is the company? After all, even with a successful attack, it will have both a well-developed action plan and confirmed technical capability to recover.