Example of an IT Crisis Scenario
A widespread outage of the information system does not become a crisis simply because a server is down. It becomes a crisis when critical operations can no longer be carried out within acceptable timeframes, decisions must be made under conditions of uncertainty, and stakeholders expect a coordinated response. This example of an IT crisis scenario illustrates how to coordinate technical response, business continuity, communication, and governance.
The scenario below is not a script to be applied mechanically. It serves as a working basis for a crisis exercise, the development of an incident response plan, or the review of a business continuity plan. Each organization must adapt it to its business impact analysis, its technological dependencies, its regulatory obligations, and its level of maturity.
Example of an IT crisis scenario: a ransomware attack
A B2B services company operates an order-processing platform, a customer portal, and several interconnected financial applications. One Monday morning, the security operations center detected unusual login activity on a privileged account. A few minutes later, several file servers became inaccessible. Ransom notes appeared on workstations in several departments.
The initial investigation indicates that ransomware encrypted part of the network, including servers hosting shared data and an application used to process orders. Recent backups are available, but their integrity has not yet been confirmed. The customer portal remains accessible, but the data displayed is no longer synchronized with the internal management system.
The challenge isn’t just about encryption. The organization must quickly answer several questions: Has the spread been stopped? Has any data been exfiltrated? Which activities should continue in a degraded mode? What level of information should be shared with customers, employees, authorities, and partners? The IT crisis then becomes a matter of operational resilience.
Trigger: Classify the incident without waiting for absolute certainty
The first mistake is to wait for the complete forensic analysis before activating the crisis management process. At this stage, uncertainty is to be expected. The trigger must be based on predefined criteria: unavailability of a critical service beyond its maximum allowable downtime, suspicion of widespread compromise, risk of a data breach, or a significant impact on the ability to serve customers.
In our scenario, the IS Security Manager alerts the Crisis Management Manager and the Business Continuity Plan (BCP) Manager. A small crisis response team is convened, comprising at a minimum the relevant department head, IT, cybersecurity, business continuity, the affected business units, communications, and legal. Depending on the situation, human resources, data protection, procurement, or security may also be called upon.
The initial status report must clearly distinguish between established facts, assumptions, and decisions to be made. This approach prevents incomplete technical information from being interpreted as facts by management or disclosed prematurely to outside parties.
The First Decisions: Contain, Maintain, Document
The technical priority is containment. The IT team isolates compromised segments, deactivates suspicious accounts, blocks non-essential remote access, and, if necessary, suspends certain data flows between environments. These measures may further degrade service in the short term. This is a common trade-off: preserving system integrity and preventing the spread of the breach may take precedence over maintaining immediate availability.
At the same time, business units are activating their planned business continuity procedures. Order processing can be switched to manual mode or to a backup system, with specific rules for deferred data entry and reconciliation. Customer service receives consistent instructions: acknowledge the incident without speculating on its cause, log priority requests, and do not promise any unconfirmed recovery times.
Every action must be time-stamped and recorded. This crisis log is useful for managing the response, reconstructing the timeline, justifying decisions, and preparing a debriefing. It also facilitates coordination when teams take turns over several days.
A crisis management team is not just an expanded technical meeting
The crisis response team oversees decisions that span multiple areas: prioritizing which services to restore, making decisions regarding fallback modes, approving messages, keeping senior management informed, and mobilizing service providers. Technical experts continue to lead the investigation and remediation efforts, but their analyses must be translated into operational impacts and management decisions.
A schedule for status updates is established from the outset. It may be every thirty minutes at first, then become less frequent as the situation stabilizes. Each update must result in explicit decisions, a designated person in charge, and a deadline. Without this rigor, the crisis will become bogged down in a succession of technical assessments without a shared path to recovery.
Assess the business and regulatory impacts
After the initial lockdown, the organization must assess the impact on critical operations. The analysis is not limited to the number of affected servers; it also covers disrupted processes, contractual obligations, unavailable data, financial risks, notification requirements, and potential reputational impacts.
In this example, order fulfillment is halted, invoicing is delayed, and the sales teams no longer have a reliable view of inventory. The PCA manager compares these impacts with the recovery time objectives defined in the business impact analysis. If the recovery objective for order fulfillment is four hours and no reliable fallback mode is active after that time, the crisis level must be reassessed.
The issue of personal data requires special attention. Unavailability does not necessarily imply a data breach, but the possibility of a data exfiltration must be investigated. The Data Protection Officer and the legal department evaluate the available information, the applicable obligations, and the notification procedures. Requirements vary depending on the industry, the nature of the data, the contracts involved, and the relevant jurisdictions.
Communicate accurately, without downplaying or overinterpreting
Effective IT crisis communication relies on factual, consistent, and proportionate messages. Employees need to know what they can do, what they should avoid, and whom to contact if they encounter a problem. Affected customers should receive useful information about the impact on the service, available temporary solutions, and the next update.
It is better to say that the organization is investigating a cybersecurity incident affecting certain services rather than stating too early that no data has been accessed or extracted. Similarly, announcing a recovery time without confirmation from the recovery team creates a risk of losing trust if the deadline is not met.
Communication must be managed, but it must not become a bottleneck. Pre-approved message templates tailored to key scenarios speed up the response while ensuring consistency with legal requirements and the crisis strategy.
Take your time to recover safely rather than rush the restoration
The recovery phase does not begin when the files are restored. It begins when the organization has established an environment that is sufficiently secure to restart services without reintroducing the compromise. In the scenario described, backups are tested in an isolated environment. Privileged accounts are reset, exploited vulnerabilities are addressed, and monitoring mechanisms are strengthened before services are restored to production.
The recovery order is determined based on business priorities, application dependencies, and team availability. A customer portal may seem like a priority because it is visible, but it may be more important to first restore the databases, authentication functions, or the application used to perform critical operations. The IT recovery plan must therefore be aligned with continuity objectives, not just with the technical architecture.
The recovery validation process involves both IT teams and business representatives. A service that is technically available is not necessarily operational: data may be incomplete, interfaces may not be synchronized, or control procedures may not have been carried out. The return to normal operations is gradual and must include the processing of transactions carried out in degraded mode.
Turning the Scenario into a Useful Exercise
A crisis scenario is only valuable if it allows for the testing of real-world decisions. A relevant exercise confronts participants with incomplete information, tight deadlines, and realistic trade-offs. It does not seek to trap teams, but rather to assess the effectiveness of procedures, the clarity of roles, and the ability to maintain priority activities.
For this example of an IT crisis scenario, stress tests may include the discovery of a suspected data exfiltration, the unavailability of a cloud service provider, a major client demanding immediate assurances, or the emergence of unverified information on social media. Each scenario must be linked to an exercise objective: testing escalation procedures, communication, fallback procedures, coordination with a third party, or recovery governance.
The post-incident review must lead to specific, time-bound actions that are assigned and tracked. It may reveal a lack of failover procedures, unclear responsibilities, outdated contact information, an unidentified dependency, or differing interpretations of crisis thresholds. It is precisely these discrepancies, identified before an actual incident occurs, that strengthen resilience.
Preparedness is not about predicting every attack. It is about providing decision-makers and teams with a reliable framework for taking action when information is incomplete and time is limited. Regularly practiced scenarios, linked to the business continuity plan (BCP), risk assessment plan (RAP), and crisis governance, transform this requirement into a measurable operational capability.
This post is also available in:
