At 8:15 a.m., ransomware blocks access to business applications; customers are already calling, and management is asking for an update. In this scenario, a crisis management team guide should not be a theoretical document tucked away in a shared folder. It must enable the right people to be brought together, the facts to be assessed, critical operations to be protected, and decisions to be made within a controlled framework.

An effective crisis management team is therefore more than just a list of contacts. It is a temporary governance mechanism that is activated when an event exceeds normal response capabilities. Its role is to manage trade-offs, coordinate expertise, ensure business continuity, and organize reliable communication with stakeholders.

Define the task force’s mission before the incident

The primary challenge lies not in the composition of the crisis management team, but in the clarity of its mandate. A crisis management team does not replace operational teams or permanent management bodies. It creates a decision-making framework tailored to a deteriorating situation, where time, information, and resources are limited.

Its mandate must specify the events that could justify its activation: a cyberattack, the unavailability of a critical site or supplier, a serious accident, a social crisis, reputational damage, an infrastructure failure, or a major regulatory incident. The nature of the risk varies by sector, but the principle remains the same: activation must be based on observable criteria, not solely on a contact’s perception of severity.

It is also important to define the scope of decision-making. The task force may, for example, set priorities for resuming operations, authorize degraded operating modes, mobilize service providers, suspend an activity, or approve external communications. Decisions that fall under the purview of the board of directors, a regulatory authority, or senior management must be clearly identified to avoid deadlocks or uncoordinated initiatives.

Crisis Management Team Guide: Organizing Roles

The quality of the response depends less on the number of participants than on the complementarity of their roles. A task force that is too large slows down communication and dilutes accountability. A task force that is too small risks making decisions without the necessary expertise.

The core team typically includes a crisis director with explicit authority, a coordination manager, a representative from the affected business units, a security or cybersecurity liaison, a business continuity manager, and a communications manager. Depending on the context, the legal, compliance, human resources, security, finance, customer relations, or institutional relations functions may be integrated into the response team.

The crisis manager acts as the decision-maker and enforces decisions. The coordinator ensures that the pace is maintained, prepares status updates, monitors actions, and maintains traceability. This distinction is essential: the same person may fill both roles in a small organization, but the risk of overload becomes high as the event escalates.

Each member must have a trained and reachable alternate. Reliance on a single person is a common weakness, particularly during a prolonged crisis, on holidays, or outside of business hours. Contact information, delegations of authority, and procedures for convening meetings must be reviewed periodically, including when the usual communication tools are unavailable.

Ensure that activation is simple and traceable

An activation procedure that is too complex is rarely implemented at the right time. Designated individuals must be able to trigger the procedure quickly, based on a documented threshold. This could include a threat to personal safety, the interruption of a critical process for longer than a defined duration, a suspected data breach, or media exposure requiring a coordinated response.

As soon as the response is activated, the initial actions are critical. It is necessary to verify the available facts, appoint a crisis manager, issue a call to action, open a log, and schedule the first status update. The incident log records decisions, their rationale, assigned tasks, deadlines, and information still to be verified. It preserves the collective memory of the crisis and facilitates a post-crisis review when the time comes.

The initial assessment should not attempt to resolve every issue. It should answer four questions: What do we know for certain? Which activities or populations are at risk? What immediate measures are needed? And what is the next decision-making timeline? Explicitly stating uncertainties prevents assumptions from being treated as established facts.

Making Decisions Despite Incomplete Information

In a crisis situation, waiting for perfect information is often incompatible with protecting people, data, or essential operations. Deciding quickly does not mean deciding without a method. The task force must distinguish between reversible decisions—which can be tested and then adjusted—and decisions that are difficult to reverse, such as a public announcement, the suspension of a critical service, or the implementation of a costly contingency plan.

Prioritization must be based ona business impact analysis and on the business continuity objectives established by the organization. In the event of a cyber incident, isolating an environment may preserve the integrity of the information system but temporarily disrupt a critical function. In a facility incident, evacuating or closing a site protects people but may require a switch to limited capabilities. These trade-offs must be defined, accepted, and documented.

A concise decision matrix is useful when it specifies, for each action, the person responsible, the deadline, dependencies, and status. It does not replace the judgment of those in charge, but it helps prevent oversights during periods of high cognitive load.

Making Communication a Controlled Process

Communication that is delayed, contradictory, or overly assertive can exacerbate the initial impact. The task force must develop messages tailored to employees, customers, suppliers, government agencies, the media, and partners. These audiences do not all have the same need for information, nor do they all expect the same level of detail.

The guiding principle is simple: communicate confirmed facts, outline the measures taken, and announce the next update when the situation remains fluid. It is better to say that an investigation is underway rather than downplay an incident whose scope has not yet been determined. Conversely, a communication that causes anxiety without verified data can create an avoidable crisis of confidence.

The spokesperson must be designated in advance. Technical experts provide input for the message, but should not be contacted directly by all external parties. This ensures that the task force maintains a consistent message and protects the teams working on the resolution.

Test the system under realistic conditions

A plan tested solely through review does not allow for an assessment of how a team actually functions. Exercises must expose participants to incomplete information, conflicting trade-offs, and time pressure similar to that of a real incident. The goal is not to trick the teams, but to reveal the gaps between the written plan and its actual implementation.

A tabletop exercise is suitable for working on governance, roles, and decision-making processes. A more advanced simulation can include the loss of tools, fake customer messages, a request for authorization, or the failure of a service provider. The scenario must be commensurate with the organization’s maturity and its priority risks.

The debriefing phase is what transforms the exercise into operational progress. It must identify concrete actions: clarifying a delegation of authority, updating an escalation procedure, completing a response checklist, strengthening a supplier contract, or training a substitute. Each action must be assigned an owner and a deadline; otherwise, the findings will have no effect.

Integrate the unit into the business continuity framework

The crisis response team cannot be viewed in isolation from the business continuity plan, the disaster recovery plan, security incident management, and regulatory requirements. It must be familiar with the organization’s critical operations, minimum acceptable resources, fallback solutions, and communication commitments.

Standards such as ISO 22301 provide a useful framework for integrating crisis management into a business continuity management system. However, they do not eliminate the need to adapt them to business realities, decision-making culture, and industry-specific constraints. A highly centralized organization does not activate its crisis response team in the same way as a multi-site group with significant local authority.

The professional development of incident response team members enhances this ability to adapt. The specialized training offered by DRI France, in particular, helps integrate governance, business continuity, cyber resilience, and crisis management practices into a framework that can be immediately applied.

The value of a unit is not measured by the quality of its organizational chart, but by its ability to make clear decisions when the usual points of reference disappear. Preparing it regularly means giving the organization the means to protect its priorities before an emergency forces it to do so.

A prolonged outage of the information system, the unavailability of a site, a ransomware attack, or the failure of a critical supplier do not have the same effects. Yet they all raise the same governance question: Can the organization maintain its priority activities at an acceptable level? To develop a business continuity strategy, therefore, it is necessary to go beyond simply producing a written plan and to make explicit choices regarding which activities to protect, which resources to preserve, and which decisions to make under constraints.

An effective business continuity strategy links business requirements to verifiable operational capabilities. It provides direction for business unit leaders, IT, cybersecurity, procurement, human resources, and crisis management. It must also be defensible before an auditor, regulator, or executive committee, with consistent assumptions, priorities, and evidence of preparedness.

Start with business challenges rather than solutions

Business continuity does not begin with the selection of a fallback site or the implementation of technical replication. These measures may be necessary, but they do not constitute a strategy in and of themselves. The starting point is understanding the consequences of a disruption on the organization’s missions, customers, regulatory obligations, contractual commitments, and reputation.

A Business Impact Analysis(BIA) provides a structured framework for this understanding. It identifies critical processes, their dependencies, the duration of an outage, and the minimum acceptable service levels. In particular, it helps define the maximum permissible downtime, often expressed as MTPD or MAO depending on best practices, as well as the recovery objectives specific to the resources in question.

This analysis must be conducted in collaboration with the business units, not solely based on questionnaires sent to managers. A process labeled “critical” without justification, identified dependencies, or a realistic recovery objective does not allow for the prioritization of investments. Conversely, an overly detailed BIA can delay decision-making without improving the organization’s ability to respond. The appropriate level of granularity depends on the organization’s size, its risk exposure, and its industry-specific requirements.

Set Consistent Business Continuity Objectives

Once the priority activities have been identified, the strategy translates business needs into measurable objectives. These objectives do not pertain solely to recovery time. They also specify the level of service to be maintained, the minimum processing volume, the necessary data, the required staffing levels, and the terms of communication with stakeholders.

A customer service department, for example, can continue to operate in degraded mode with reduced processing capacity and temporary manual tracking. Operations involving payments, healthcare, or industrial safety will often have a much lower tolerance for disruption. Business continuity, therefore, does not necessarily aim for an immediate return to normal operations; rather, it ensures continuity that is proportionate to the criticality of the operation and the consequences of an outage.

Objectives must be compatible with one another. A two-hour IT recovery objective is not sufficient if reference data, remote access, business procedures, or authorized personnel are not available within that same timeframe. This alignment between business continuity, the IT disaster recovery plan, cybersecurity, and crisis management is one of the key criteria for assessing the maturity of a system.

Determining the level of protection

Any ability to ensure continuity comes at a cost: redundancy, safety stock, alternative sites, telework solutions, supplier contracts, drills, and maintenance of operational readiness. The strategy must make these trade-offs clear.

An organization may choose accelerated recovery for its most critical processes, a more gradual recovery solution for important activities, and then deferred recovery for the rest. The key is that these choices be approved at the appropriate governance level. Without formal decision-making, business continuity objectives often become implicit, contradictory, or dependent on decisions made under pressure.

Building a governance structure that enables action

Developing a business continuity strategy requires a clear division of responsibilities. Senior management sets the risk appetite and allocates resources. Business unit leaders define operational priorities and approve continuity plans. IT ensures the restoration of digital services and infrastructure. Security, risk management, compliance, procurement, and human resources each contribute their specific requirements.

The business continuity manager should not be the sole custodian of the system. His or her role is to coordinate the process, consolidate analyses, monitor action plans, and flag any deviations. Responsibility for business continuity remains shared among process owners and custodians of critical resources.

A regularly convening steering committee is useful when it makes decisions: validating scopes, addressing unaddressed dependencies, accepting residual risks, scheduling exercises, and monitoring corrective actions. A governance structure that is limited to receiving dashboards does not reduce operational vulnerability.

Treating addictions, including external ones

Major incidents rarely result from a single failure. A critical operation depends on applications, data, facilities, expertise, telecommunications, service providers, power, and sometimes regulatory approvals. The strategy must identify these dependencies end-to-end and then determine which ones require a backup solution or a specific contractual commitment.

Suppliers are a particular area of concern. It is not enough simply to ask a service provider whether it has a business continuity plan. It is necessary to verify whether its recovery objectives align with the organization’s needs, whether responsibilities are contractually defined, and whether crisis communication procedures have been tested. For critical outsourced services, business continuity must be assessed as early as the selection phase, not only when an incident occurs.

Human dependencies require the same level of rigor. A procedure can be properly documented yet still be unworkable if it relies on a single person, on non-transferable authorizations, or on skills that are rarely used. Versatility, designated substitutes, and secure access to operational information are all part of the solution.

Formulate operational responses

Business continuity plans translate strategy into concrete actions. They must be designed to be used under pressure by people who may not have been involved in drafting them. Concise procedures, explicit activation criteria, up-to-date contact lists, and decision sheets are often more useful than a comprehensive document that is difficult to use.

The plan must cover activation, operation in degraded mode, crisis management, communication, recovery, and a controlled return to normal operations. Communication requires specific preparation: customer messages, notifications to authorities, instructions for employees, and coordination with partners. A technically effective response can lose its value if communications are delayed or inconsistent.

Alignment with the principles of ISO 22301 provides a useful framework for organizing this process. It helps integrate policy, risk analysis, BIA, continuity strategies, plans, exercises, and continuous improvement into a coherent management system.

Test the strategy before it’s needed

A plan that has not been tested remains merely a hypothesis. Exercises verify both the feasibility of the measures and the quality of decisions, escalation procedures, and communications. They should increase in complexity: literature review, technical test, tabletop exercise, crisis simulation, and then an operational exercise when conditions permit.

The goal is not to prove that everything works perfectly. A useful exercise reveals the gaps between the planned system and reality: unavailable access points, outdated contacts, overlooked dependencies, decisions that take too long, or unrealistic goals. These findings must lead to specific actions that are scheduled, assigned, and tracked until completion.

The frequency of testing depends on the criticality of operations, changes to the information system, organizational changes, and regulatory requirements. Following a major transformation, the introduction of a new critical tool, or a change in service provider, waiting for the annual testing cycle may not be sufficient.

Fostering continuity as a management skill

Business continuity cannot be maintained simply by updating a document once a year. It evolves alongside projects, process changes, new cyber risks, restructuring, and changes in suppliers. Targeted metrics make it possible to track coverage of critical activities, the completion of drills, the progress of actions, and the management of residual risks.

This discipline also relies on recognized skills. Professionals responsible for leading or auditing a program must be well-versed in the relevant standards, know how to conduct a BIA, challenge recovery objectives, and engage stakeholders. The training programs and certifications offered by DRI France meet this need for professional development by linking international methods to the operational realities of French and French-speaking organizations.

The value of a business continuity strategy is ultimately measured when the organization must make decisions, take action, and communicate in a disrupted environment. Preparing for these decisions in advance makes it possible to protect what matters most without having to improvise on matters that should already be under control.

A few hours after services are restored, the pressure often subsides too quickly. Technical teams shift their focus to remediation, business units catch up on backlogs, and management wants to move on. Yet it is at this point that a post-incident review of a corporate cyber crisis yields the most value. It allows an organization to turn an incident into verifiable decisions that strengthen business continuity, governance, and response capabilities.

A post-incident review, or REX, is not about compiling an exhaustive timeline or assigning individual blame. It is a structured process that examines the facts, decisions, interdependencies, and discrepancies between planned procedures and actual operations. Its purpose is clear: to mitigate the consequences of a similar incident and improve control over critical operations.

Why Lessons Learned from Cyber Crises Are Crucial

A cyber crisis rarely reveals a single failure. A breach can expose technical debt, poorly managed access rights, an unidentified dependency on a service provider, insufficient information for decision-makers, or unrealistic recovery procedures. Focusing solely on the attack vector amounts to addressing only part of the problem.

REX fosters a cross-functional perspective. It integrates cybersecurity analysis, crisis management mechanisms, business continuity planning, IT disaster recovery planning, and business requirements. This approach is particularly useful in regulated organizations, where availability, data integrity, and the traceability of decisions must be demonstrable.

The right time depends on the nature of the event. An initial “hot” debrief, held within 24 to 72 hours, helps keep perceptions and decisions fresh in everyone’s minds. It does not replace the in-depth lessons learned session, which should take place after the situation has stabilized, once the technical, contractual, and operational details are available. For a complex attack, this second phase may require several workshops and validation by the relevant managers.

Frame the feedback without turning it into a trial

The quality of the outcome depends on the framework established from the outset. Management must appoint a legitimate leader capable of coordinating the functions of information security, IT, business continuity, risk management, legal affairs, communications, and business units. Depending on the context, this responsibility may fall to the crisis manager, the business continuity plan (BCP) manager, or an independent oversight function. The key is to ensure both methodological expertise and sufficient freedom to speak openly.

The terms of reference must specify the incident under investigation, the time period covered, the entities involved, the critical activities affected, and the expected deliverables. Confidentiality rules should also be established, particularly when the investigation is ongoing, when personal data is involved, or when litigation is a possibility.

The vocabulary used matters. Wording that focuses on procedural deviations and decision-making criteria fosters productive discussions. Asking why a mechanism failed is more productive than immediately seeking to determine who made a mistake. This distinction does not absolve management or compliance of responsibility when it must be established, but it protects the primary purpose of the REX: to learn and correct.

Reconstructing the facts and decisions

The timeline forms the foundation of the analysis, provided it is not reduced to a mere sequence of technical logs. It is necessary to link the detected signals, the escalated alerts, the decisions made, the communications issued, the containment measures, the business continuity switches, and the recovery steps. Each sequence must be linked to a source: a support ticket, a log, a crisis team report, a security log, a decision email, or a statement from a participant.

This reconstruction often reveals telling discrepancies. An alert may have been correctly classified by the SOC but may not have reached the decision-maker with the necessary authority. A recovery plan may be documented but rely on credentials that were inaccessible during the incident. A business workaround may have preserved operations while creating a risk to data quality or reconciliation.

Review the decision points

The analysis must focus on critical decisions: activating the crisis response team, isolating affected areas, suspending or maintaining a service, triggering the business continuity plan, informing customers, notifying authorities, engaging a specialized service provider, and authorizing the resumption of operations. For each decision, it is helpful to identify the information available at the time, the decision-maker, the options that were ruled out, and the observed consequences.

This method avoids a common bias: judging a past decision based on information obtained later. A decision may have been reasonable given the information available at the time, even if the outcome was unfavorable. Conversely, a decision that turned out favorably by chance does not prove that the process was under control.

Test the interfaces, not just the teams

Cyber incidents often escalate at the interfaces—between IT and business units, between security and the managed service provider, between the incident response team and communications, or between technical recovery and verification of restored data. The post-incident review must therefore verify roles, escalation thresholds, emergency contact information, contractual commitments, and validation procedures.

The goal is not to increase the number of procedures. It is to ensure that existing procedures remain usable under stress, including when email, the internal network, or ticketing tools are unavailable. Any crisis procedure that relies on access to compromised systems must be reviewed as a priority.

Turning Findings into an Improvement Plan

A REX report without a structured action plan has little impact. Each recommendation must specify an objective, a person responsible, a deadline, the necessary resources, and a completion criterion. “Improving crisis communication” is merely an intention. “Update message templates, designate approvers, and conduct a distribution exercise outside the internal messaging system by June 30” is a verifiable action.

Prioritization must take into account business criticality, the likelihood of the scenario, the level of exposure, dependence on third parties, and the effort required for implementation. Some actions are immediate: revoking accounts, correcting a filtering rule, or updating an on-call roster. Others require management decision-making: architectural segmentation, changes to supplier contracts, an overhaul of the backup system, or strengthening the skills of crisis managers.

We must also accept trade-offs. A faster recovery may increase the risk of reintroducing malicious code or corrupted data. Very early communication may meet a transparency requirement, but it must be sufficiently substantiated so as not to mislead stakeholders. The REX must make these trade-offs explicit so that governance can address them.

Ensure that training is integrated into business continuity

The lessons learned from a crisis only become lasting if they lead to changes in standard operating procedures. Crisis management plans, business continuity plans (BCPs), and disaster recovery plans (DRPs) must be updated—and also tested. An update to documentation that is not put into practice remains merely a hypothetical scenario.

Exercise scenarios are based on actual failures: simultaneous unavailability of the directory and email systems, compromise of a service provider, data recovery requiring enhanced controls, loss of visibility into assets, or overload of the approval process. Participants must be faced with real-world decisions, working with incomplete information and under credible time constraints.

The professionalization of stakeholders is a key driver. Managers responsible for business continuity, cybersecurity, risk, and crisis management must share a common language, methods, and standards. With this in mind, DRI France’s specialized training programs can help structure practices related to business continuity, organizational resilience, and crisis management.

A useful post-incident review does not seek to prove that the organization had anticipated everything. It demonstrates that the organization knows how to learn thoroughly, assess its shortcomings, and improve its capabilities before the next incident once again puts its critical operations to the test.

When a major incident occurs, the challenge lies not only in its severity. It stems primarily from the need to make quick decisions based on incomplete information, while protecting people, critical operations, and the organization’s reputation. Knowing how to develop a crisis plan therefore involves establishing this decision-making capacity before the crisis limits the organization’s room to maneuver.

A crisis plan is more than just an emergency contact list or a set of sample press releases. It formalizes governance, activation criteria, roles, coordination procedures, and communication mechanisms. It must be consistent with the organization’s business continuity framework, disaster recovery plans, risk management, and compliance requirements.

Distinguishing the Crisis Plan from the Business Continuity Plan (BCP) and the Disaster Recovery Plan (DRP)

The business continuity plan defines how to maintain or restore priority operations within an acceptable timeframe. The disaster recovery plan deals more specifically with the restart of systems, infrastructure, or services following an outage. The crisis plan addresses another need: managing the event, making decisions, coordinating stakeholders, and preserving the organization’s ability to act.

In practice, these measures overlap. A cyberattack may require the activation of a disaster recovery plan, the use of business continuity solutions, and the immediate mobilization of a crisis response team. However, confusing them often creates a gap: the organization knows how to technically restore a service, but does not know who decides on a planned outage, who notifies the authorities, or how to approve sensitive external communications.

For regulated or highly digital-dependent environments, the relationship between these plans must be clearly defined. The crisis plan establishes the command structure. The Business Continuity Plan (BCP) and the Disaster Recovery Plan (DRP) provide the operational and technical options necessary for decision-making.

Define the scope and objectives of the plan

Before drafting procedures, it is necessary to specify the situations the plan is intended to address. A plan that is too generic becomes difficult to implement. Conversely, a plan built solely around a specific scenario risks being ill-suited to a different event. The right approach is to define a common framework and then provide action sheets or appendices for each type of crisis.

The scope depends on the risk analysis, the business impact analysis, and industry-specific requirements. Depending on the organization, it may cover widespread IT downtime, ransomware, a data breach, a supply chain disruption, an on-site incident, a labor dispute, the failure of a critical service provider, or an event affecting personal safety.

Objectives must be formulated in operational terms. These include, for example, protecting employees and third parties, quickly assessing the incident, ensuring decisions are made at the appropriate level, minimizing the impact on critical services, and providing reliable information to the parties involved. This clarification prevents the crisis response team from becoming merely a forum for sharing information.

Establish a governance structure capable of making decisions

The quality of a crisis plan depends first and foremost on the clarity of its governance structure. In a crisis situation, standard approval processes are often too slow. Responsibilities, delegations of authority, and escalation procedures must therefore be defined in advance.

The crisis management team typically includes a crisis management leadership team, a coordination lead, and representatives from the affected business units, IT or cybersecurity, communications, legal affairs, human resources, and, when necessary, security or compliance. Its exact composition depends on the size of the organization and the nature of the risk. A structure that is too broad slows down decision-making; a structure that is too narrow may deprive the team of critical information.

Each position must have a documented role. The crisis director acts as the decision-maker and leads the organization. The coordinator organizes meetings, follows up on decisions, and maintains an overview of the situation. Experts provide the facts, hypotheses, impacts, and options. The communications team should not be called upon only at the end; it must be involved from the outset in managing messages, channels, and target audiences.

The plan must also provide for substitutes. A critical role without an available substitute—especially outside of business hours—is a common point of vulnerability. Contact information must be protected, regularly verified, and accessible in a fallback mode if the usual tools become unavailable.

Developing Alert and Activation Criteria

The activation of a crisis response team should not depend solely on an intuitive assessment. The plan must include thresholds or criteria based on potential consequences: harm to individuals, disruption of a critical activity, compromise of sensitive data, mandatory reporting requirements, media exposure, significant financial impact, or lasting disruption of an essential service.

These criteria do not replace the judgment of those in charge. They provide a common language and reduce the risk of underestimating the situation during the initial hours. It is helpful to distinguish between several response levels, such as local incident management, enhanced coordination, and a formal crisis response. This graduated approach prevents the unnecessary mobilization of the entire organization, while ensuring that escalation occurs promptly when necessary.

The activation procedure must specify who can trigger the alert, how to contact the response team members, where the team meets, and which fallback solutions to use. A virtual crisis room may be appropriate, but it should not be the sole point of reliance. In the event of a cyber incident, standard communication channels may no longer be trustworthy.

Formalize the procedures that support the decision

An operational plan does not seek to anticipate every detail. It provides the essential guidelines so that teams can act in a coordinated manner. At the onset of a crisis, the response team must be able to establish an initial assessment: the nature of the event, the time it was detected, the affected area, observed impacts, measures already taken, major uncertainties, and upcoming decisions.

A crisis log is essential. It records information received, hypotheses, decisions, the rationale behind them, the actions taken, and their status. This practice improves coordination during the incident and subsequently facilitates lessons learned, audits, and communication with authorities.

The procedures must also include the following functions:

• assessing and updating the situation;
• the protection of people, assets, and evidence;
• assessing the business, legal, financial, and reputational impacts;
• managing decisions and priority actions;
• internal, external, and institutional communication;
• monitoring the return to a stable situation.

For each procedure, prioritize short, actionable checklists that can be used under pressure. A quick-reference checklist can specify the trigger, the person in charge, the initial actions, the information to gather, the people to contact, and the decisions to be submitted. The level of detail depends on the maturity of the teams: a new program will need more step-by-step instructions, while an experienced organization will prefer more flexible decision-making frameworks.

Prepare a well-thought-out message, without rushing

Crisis communication must balance speed, accuracy, and consistency. Prolonged silence creates a vacuum that rumors can fill. However, communicating too hastily can spread inaccurate information, undermine an investigation, or create commitments that are impossible to fulfill.

The plan must identify priority audiences: employees, customers, suppliers, partners, shareholders, government authorities, the media, or individuals affected by a data breach. It must specify authorized spokespersons, approval processes, and alternative communication channels. Preformatted messages are useful for announcing that an incident has been acknowledged, outlining immediate actions, and providing a timeline for further updates. They must never be used to downplay a situation where the facts remain unclear.

In the event of a cyber incident, coordination among communications, the legal department, the information security department, incident response teams, and business unit leaders is particularly critical. The information disclosed must be consistent with technical findings, regulatory requirements, and the organization’s interests, without compromising remediation efforts.

Test the plan before you need it

An untested plan is a working hypothesis, not a proven capability. Exercises make it possible to verify participants’ availability, their understanding of their roles, the smooth operation of procedures, and the effectiveness of communication channels. They also reveal discrepancies between the organization described in documents and the actual organization.

Table-top exercises are a good starting point. They present participants with a timeline of events and guide them in making decisions, communicating, and coordinating actions. More advanced simulations can incorporate technical disruptions, media constraints, the unavailability of a service provider, or requests from authorities. The goal is not to trip up the teams, but to develop collective reflexes and assess their governance capabilities.

Each exercise must result in a formalized debriefing. Any discrepancies identified must be prioritized, assigned to a responsible party, and tracked until they are resolved. This continuous improvement cycle aligns with the logic of business continuity management systems based on ISO 22301: document, test, measure, correct, and maintain.

Ensuring the plan’s long-term viability

The crisis plan must evolve along with the organization. An acquisition, outsourcing, a change in cloud service provider, a new regulatory requirement, or a change in on-call schedules can render it partially obsolete. A periodic review—at least once a year and after any significant incident—ensures that it remains relevant.

Training plays a central role here. Managers called upon to join a crisis response team must understand the mechanisms of coordination, decision-making, and communication, beyond their functional expertise alone. For business continuity and resilience professionals, a structured approach makes it possible to link the crisis plan to impact analyses, continuity strategies, and governance requirements.

Developing a crisis plan is not about producing yet another document. It is about enabling the organization to make decisions in a systematic manner when its usual points of reference disappear. This capability is built over time by clarifying responsibilities, conducting drills, and rigorously incorporating lessons learned from each experience.

An exercise that is limited to reviewing a business continuity plan does not measure an organization’s actual ability to make decisions under pressure. Knowing how to conduct a tabletop exercise involves precisely bringing the right people together to address a credible scenario, identifying dependencies, and transforming identified gaps into verifiable improvement actions. The goal is not to demonstrate that the BCP exists, but to verify that it can be activated, understood, and managed within timeframes compatible with critical operations.

A tabletop exercise is particularly well-suited for organizations that wish to test their crisis governance, escalation procedures, communication mechanisms, and the coordination between business continuity, IT, cybersecurity, and business functions. It does not replace a technical recovery exercise or a full-scale simulation. However, it helps prepare for these more demanding tests by first clarifying decisions, responsibilities, and interfaces.

Define what the exercise is actually supposed to test

The quality of a tabletop exercise is determined before it even begins. Before drafting the scenario, it is essential to define a specific, observable test objective that is linked to a precise resilience challenge. Attempting to test the activation of the crisis response team, IT recovery, customer communications, fallback solutions, and regulatory compliance all at once often results in an exercise that is too broad in scope and yields only superficial insights.

For example, an objective might focus on the ability to classify a cyber incident affecting a critical application, decide whether to activate the business continuity plan, prioritize which operations to maintain, or coordinate communication with authorities and stakeholders. Each objective must be linked to specific evaluation criteria. This makes it possible to distinguish between issues stemming from a documentation gap, a governance flaw, a lack of resources, or insufficient mastery of a skill.

The scope must be clearly defined. It includes the relevant processes, sites, service providers, information systems, participants, and the hypothetical time period covered by the exercise. This clarity prevents a common problem: participants respond by referring to capabilities that are not available in the scenario or that have never been validated.

Choose a plausible scenario, without making it too comfortable

A good scenario is credible in light of the risk analysis andthe business impact analysis. This could include prolonged unavailability of a critical supplier, a ransomware attack, loss of access to a site, a telecommunications outage, or the unavailability of key personnel. Its value lies less in its dramatic nature than in its ability to prompt difficult decisions.

The scenario should reveal information gradually. An initial prompt may signal an anomaly or an outage. Subsequent scenarios clarify the scope of the incident, introduce an additional constraint, or present participants with a request from a customer, a regulator, or the media. This progression replicates the uncertainty of a crisis situation without attempting to trap the teams.

It is helpful to establish clearly stated working assumptions: whether or not collaborative tools are available, the status of backups, the availability of service providers, the capacity for remote work, or the expected duration of the disruption. A scenario that is too vague encourages theoretical responses. Conversely, an overly detailed scenario traps participants in a prewritten response. The appropriate level of detail depends on the organization’s maturity and the chosen objective.

How to Conduct a Table-Top Exercise During a Session

The session is based on a clear division of roles. The exercise facilitator sets the framework, presents the rules, and ensures that the time limit is respected. The moderator presents the prompts, asks questions, and keeps the discussion moving without providing answers on behalf of the participants. Observers record decisions, deadlines, deviations, and points requiring further discussion. Finally, participants play their own organizational roles and rely on the resources actually available to them.

From the outset, it is important to note that this exercise is neither an individual audit nor a hierarchical evaluation. This rule promotes transparency, particularly when procedures are vague or responsibilities overlap. Participants must be able to point out when information is missing, when a decision has not been assigned, or when a contingency plan has not been tested.

The workshop should focus on decision-making questions. Who classifies the incident? When is the crisis response team convened? Which authority approves a service interruption? How are priority activities determined if multiple business units are vying for the same resource? What contractual or regulatory obligations require notification? These questions compel teams to align the documentation system with operational realities.

The facilitator must also prevent two common pitfalls. The first is turning the exercise into a problem-solving meeting, where participants immediately devise a future solution. The second is accepting general responses such as “we’ll contact the service provider” without identifying who is responsible, the channel of communication, the timeline, and the alternative plan in case of failure. When a deviation occurs, it must be noted and then addressed in the debriefing.

A two- to three-hour session is often sufficient to test a well-defined crisis scenario. Beyond that, attention wanes and the decisions made become less useful. For a complex scenario, it is better to organize several targeted exercises than a single, overly ambitious event.

Look at the facts, not just the quality of the discussions

The evaluation must focus on verifiable elements. Observers are not seeking to judge the participants’ ease or comfort, but rather the group’s collective ability to apply the intended mechanisms. In particular, they may note:

• the time required to detect, assess, and escalate the incident;
• clarity regarding roles, delegations of authority, and decision-making thresholds;
• effective access to critical contacts, procedures, tools, and information;
• alignment between business priorities, recovery objectives, and technical capabilities;
• the quality of internal, external, contractual, and regulatory communications.

These observations should be considered in light of the governance requirements defined in the business continuity management system. Within a framework based on ISO 22301, this exercise helps demonstrate that continuity strategies and procedures are tested and improved in a planned manner. The goal is not to produce formal evidence disconnected from real-world conditions, but rather to have concrete information to guide continuous improvement.

Turning Feedback into an Improvement Plan

The value of a tabletop exercise becomes clear after the session. A report must be prepared promptly, while the facts and decisions are still fresh in everyone’s minds. It identifies effective practices, observed discrepancies, invalidated assumptions, and decisions that require further validation.

Each action must be formulated in operational terms: a designated person in charge, a deadline, a priority, and a completion criterion. “Update the BCP” is too vague. It is preferable to specify, for example, that the business continuity manager will update the activation procedure to include delegations of authority outside of business hours, and then have it validated and tested during an upcoming exercise. This level of detail facilitates monitoring by the business continuity governance team.

Not all deviations are equally critical. The absence of a secondary point of contact can be corrected quickly. An unmanaged dependency on a service provider, ambiguity regarding the authority to shut down a service, or an inability to communicate outside the corporate network require a more in-depth analysis. Prioritization must take into account the impact on critical operations, regulatory requirements, feasibility, and the level of residual risk accepted by the organization.

A new exercise must then verify the effectiveness of the corrections made. It is this cycle—prepare, practice, analyze, correct, and repeat—that drives progress in operational resilience. The most mature organizations do not seek to produce a perfect exercise. They build a sustainable capacity to recognize their vulnerabilities, make decisions methodically, and improve their systems before a major incident puts them to the test.