Contingency Management practice questions

Increase the RTO buffer time in the Service Level Agreement (SLA).

Why it fails: Adjusting contractual Recovery Time Objective buffers fails to address the root cause of the failure, which is the physical absence of metadata tags required for dependency sequencing during automated orchestration. Service Level Agreement buffers are tempting because they establish acceptable recovery timeframes with external vendors and mitigate contractual penalties when system restoration takes longer than anticipated. They represent the correct choice when managing business expectations and legal liabilities regarding downtime limits caused by provider-side infrastructure delays rather than resolving internal configuration drift or missing cloud orchestration assets.

Switch from automated restoration to manual snapshot-based restores.

Why it fails: Manual snapshot-based restores rely on human intervention to sequence complex multi-tier dependencies, meaning they fail to deliver the speed and zero-human-error execution required when handling large-scale hybrid cloud disaster recovery. This approach is tempting because manual snapshots serve as a reliable fallback for recovering isolated compute instances or preserving baseline disk states when metadata is unavailable, and it would be the correct choice when validating point-in-time data integrity for a single standalone database rather than orchestrating a multi-component distributed cloud topology.

Implement a manual verification step in the Disaster Recovery Plan (DRP) documentation.

Why it fails: Manual steps are prone to failure during a disaster and do not solve the automated tool failure.

Implement a redundant secondary site for all identified Tier 1 applications.

Why it fails: Redundant infrastructure addresses availability for specific applications but fails to resolve the systemic risk of cascading failure caused by missing dependency mappings. Without understanding the interconnectedness of cross-functional processes, an ISSMP cannot identify the sequence of recovery required to prevent bottlenecks. This strategy is useful for ensuring high availability and meeting stringent Recovery Time Objectives for critical systems, making it a valid choice when the primary objective is hardware or application resilience rather than orchestrating complex, interdependent business service restoration.

Initiate a value chain analysis using the SCOR model to identify inter-process dependencies.

Why it fails: The Supply Chain Operations Reference (SCOR) model is effective for mapping internal process dependencies.

Mandate an immediate increase in the frequency of full-scale BCP simulation exercises.

Why it fails: Exercises test existing plans; they do not fix the lack of dependency visibility in the BIA.

Identifying the critical staff needed for recovery.

Why it fails: Staff resource allocation and personnel requirements are determined by Business Impact Analysis (BIA) metrics that evaluate human capital dependencies and minimum staffing levels, rather than the maximum tolerable downtime of a process. This option is tempting because identifying recovery personnel is a core BIA deliverable executed alongside timeline calculations, and it would be the correct choice if the question asked what is used for staffing plans or human resource scheduling during an operational disruption.

Assessing the data loss tolerance.

Why it fails: Assessing data loss tolerance defines the Recovery Point Objective (RPO) rather than the Recovery Time Objective, measuring the maximum acceptable age of data lost during an interruption. This choice is tempting because both RPO and RTO are critical metrics established during a Business Impact Analysis to quantify disaster recovery requirements. The RPO would be the correct choice if the question specifically asked about determining how much transactional data can be sacrificed before causing unacceptable operational damage, whereas RTO strictly measures the maximum allowable downtime for restoring system functionality.

Calculating the financial impact of the event.

Why it fails: Impact analysis is done during the BIA; RTO is the target for restoration.

Sending a self-assessment questionnaire to the vendor.

Why it fails: Questionnaires are subjective and are less reliable than empirical evidence.

Performing an independent penetration test on the vendor's network.

Why it fails: Security testing does not validate recovery/availability capability.

Requiring vendors to sign an updated Service Level Agreement.

Why it fails: An SLA is a legal promise, not verification of capability.

The disaster declaration authority is not documented in the DR plan.

Why it fails: The scenario describes a failed restoration outcome, not a governance gap. The recovery team was activated and performed restores, so the authority to declare a disaster was evidently exercised. The root cause is that the recovered data is 26 hours stale and incrementals are unverified, which is a backup integrity and recovery point problem, not a declaration authority problem. Fixing documentation would not improve the achieved recovery point.

The business impact analysis did not identify the maximum tolerable downtime for clinical systems.

Why it fails: A BIA gap would show up as an inability to prioritize systems or justify recovery targets, neither of which is described. The team knew what to restore and did restore it; the issue was the age and unverified state of the backup data. The BIA may well have produced the four-hour target, so the failure is in operational backup assurance rather than in impact analysis.

The recovery time objective is too aggressive because tape restore always exceeds four hours.

Why it fails: The scenario does not state that the restore exceeded four hours; it states the recovered data was 26 hours old. Tape restore speed is a recovery time concern, but the observed failure is data currency. Blaming the RTO misdiagnoses the problem and could lead to lowering the objective rather than fixing backup verification and restore testing, which is where the actual gap lies.

Cancel the warm site contract and build a cold site.

Why it fails: Downgrading to a cold site fails because a facility lacking adequate bandwidth cannot even store basic non-operational infrastructure components or provide the rapid hardware provisioning required for a warm site recovery strategy. This choice is tempting because cold sites are standard, cost-effective alternatives for non-critical systems with minimal operational dependencies. It would be the correct response if the organisation needed to recover non-essential functions where extended downtime and lengthy hardware procurement cycles are acceptable.

Require all employees to work from home during a disaster to save bandwidth.

Why it fails: Shifting the entire workforce to remote work relies on residential internet connections rather than corporate infrastructure, completely failing to address the warm site's dedicated WAN circuit limitations for server-to-server replication and centralised database synchronisation. This strategy is designed for pandemic responses or localized office closures where staff must remain productive outside corporate facilities, and it *would* be the correct choice if the disaster scenario involved physical building access loss while enterprise network capacity remained fully operational and unconstrained.

Accept the risk formally via the Risk Register without further mitigation.

Why it fails: Formally accepting this deficiency through the risk register ignores an operational vulnerability that directly invalidates the recovery strategy, as a warm site with insufficient bandwidth will inevitably fail during an actual failover under peak load. Such an acceptance strategy is tempting when management evaluates residual risk against the capital expenditure required to upgrade network infrastructure, and it would represent a valid approach if the business impact analysis determined that reduced operational capacity during a disaster was an acceptable trade-off for cost savings.

Choosing the restore point from the offsite immutable backup.

Why it fails: Selecting a restore point is a technical task delegated to backup administrators or systems engineers rather than a strategic decision for the Information Systems Security Management Professional. While immutable backups are essential for ensuring data integrity and facilitating recovery after a ransomware event, this specific action occurs only after the organisation has formally authorised the recovery process. The ISSMP must focus on the overarching business impact and risk assessment required to determine if the DRP should be invoked, rather than managing individual recovery parameters.

Performing the initial forensic image of the infected servers.

Why it fails: Technical forensic imaging is a tactical task performed by incident responders, not a strategic governance function assigned to an Information Systems Security Management Professional (ISSMP). While capturing bit-level evidence is vital for preserving the chain of custody during a post-incident investigation, the ISSMP must focus on high-level risk assessment and business continuity alignment. This option is tempting because forensic preservation is a standard procedure in ransomware response, yet it represents a hands-on technical execution rather than the executive decision-making role required by the question.

Directing the IT team to disconnect the network immediately.

Why it fails: Disconnecting the network destroys volatile memory and active connections, which are essential for conducting a forensic investigation into the ransomware's entry point and lateral movement. While this action is a standard containment procedure during an active, uncontained breach to prevent further data exfiltration, it prematurely terminates the evidence collection process required for the incident response lifecycle. The ISSMP must prioritise balancing forensic preservation against operational recovery, rather than unilaterally ordering a network isolation that compromises the integrity of the digital evidence.

Mean Time to Recovery (MTTR) reports from previous tests.

Why it fails: Mean Time to Recovery measures the speed of service restoration and system availability rather than data currency, meaning it fails to verify how much transaction data would be lost during an outage. This metric is tempting because service providers routinely track and report it during high-availability failover tests to demonstrate operational responsiveness. It would be the correct choice if the audit objective were to validate compliance with the organisation's Maximum Tolerable Downtime or Recovery Time Objective constraints.

Service Level Agreement (SLA) uptime percentages.

Why it fails: Service Level Agreement uptime percentages measure infrastructure availability and operational reliability, failing to track data freshness or the volume of transactional data lost during an interruption. Consequently, they cannot verify whether a database cluster can restore state within a specific temporal threshold like a Recovery Point Objective. These metrics are tempting because they represent standard contractual commitments for cloud and recovery services, making them the correct choice when evaluating overall system accessibility and guaranteed service uptime rather than data loss tolerances.

Annual penetration test results.

Why it fails: Annual penetration test results validate the security posture and vulnerability management of the provider's infrastructure against cyber threats, but they provide zero empirical data regarding transaction rollback limits or data currency. This option is tempting because auditors frequently rely on third-party security assessments to evaluate overall supplier risk, and it would be the correct choice if the audit objective were to verify resistance to unauthorised access, boundary compromises, or software vulnerabilities rather than measuring data loss thresholds.

Business Impact Analysis (BIA)

Why it fails: The Business Impact Analysis evaluates operational dependencies and quantifies downtime losses to determine recovery time objectives, making it the wrong choice because it lacks real-time operational procedures, escalation paths, and communication roles. It is tempting because practitioners rely on its output to understand criticality before a crisis, and it serves as the correct choice during the pre-incident risk assessment phase when an organisation must identify maximum tolerable periods of disruption for critical business functions.

Standard Operating Procedure (SOP)

Why it fails: Standard Operating Procedures detail step-by-step instructions for routine technical tasks and predictable operational processes, meaning they lack the strategic authority, dynamic governance structures, and enterprise-wide accountability required to manage a high-impact crisis. Practitioners often find this option tempting because these documents govern daily incident response workflows and tactical remediation steps. Consequently, an SOP would be the correct choice when defining the repeatable, granular actions technicians must execute to isolate a compromised host or patch a vulnerability during standard operational maintenance.

Disaster Recovery Plan (DRP)

Why it fails: A DRP restores IT systems and data after disruption; it does not define crisis triggers, escalation paths or communication roles. It is tempting because DRPs are invoked during major incidents, but crisis governance sits with the Crisis Management Plan, which coordinates responders and stakeholders rather than recovery procedures.

Parallel processing test.

Why it fails: A parallel processing test fails this scenario because it requires running live transactional workloads simultaneously on both primary and recovery infrastructure, introducing resource contention and operational overhead that violates the requirement to leave production operations entirely undisrupted. It remains an attractive option because its intended purpose is to validate that secondary processing facilities can accurately handle real-time production data loads under full operating conditions, making it the correct choice when rigorous verification of throughput capacity and data integrity during an active operational state is explicitly mandated.

Cutover test.

Why it fails: Executing a cutover test involves migrating live operations entirely to the secondary site while decommissioning the primary environment, which inevitably causes significant operational downtime and directly violates the mandate to avoid disrupting production. This destructive validation method is tempting because it provides absolute proof that the disaster recovery site can fully assume primary processing responsibilities. It represents the final implementation phase for transitioning operations during a planned site relocation or when permanently switching over to a redundant secondary data centre.

Full-scale simulation.

Why it fails: Full-scale simulation involves deploying all personnel, equipment, and alternate sites in real time, meaning it fails this scenario because it inherently carries a high risk of disrupting live production operations. It remains tempting because it provides the highest level of assurance by validating the complete end-to-end disaster recovery infrastructure under actual stress conditions. Therefore, this method would be the correct choice when organisations require mandatory regulatory verification or have scheduled maintenance windows specifically designated for large-scale operational disruption testing.

Cross-region cold standby snapshots.

Why it fails: Relying on cold standby snapshots across regions fails to meet the strict recovery time objectives required for modern cloud-native microservices during a sudden regional outage, as restoring infrastructure and database state from static images introduces unacceptable downtime. This approach is primarily designed for long-term disaster recovery compliance and archiving, where extended outages are tolerable, and would be the correct choice when organisations need a cost-effective method to safeguard historical data against rare catastrophic failures without paying for idle compute capacity.

On-premises hot-site failover.

Why it fails: Maintaining business continuity for a cloud-native microservices architecture requires dynamic, elastic scaling across distributed availability zones that traditional static infrastructure cannot support. Relying on an on-premises hot-site failover fails in this scenario because physical hardware lacks the container orchestration, API gateways, and automated state management native to the cloud deployment, preventing seamless traffic rerouting during a regional outage. This strategy is tempting because it provides traditional disaster recovery for legacy monoliths with strict data sovereignty mandates, making it the correct choice for on-premises workloads requiring isolated hardware redundancy rather than elastic cloud resilience.

Single-region immutable backups.

Why it fails: Relying solely on single-region immutable backups fails this scenario because recovering from them requires provisioning fresh compute instances and restoring data volumes in an alternative geographic zone or provider, introducing prohibitive Recovery Time Objectives during a wide-scale regional outage. This approach is tempting because immutability provides critical protection against ransomware and accidental data deletion by enforcing write-once-read-many (WORM) storage policies, making these backups the correct choice for mitigating localized data corruption or malicious tampering within a primary operational region.

Higher risk of data corruption.

Why it fails: Synchronous replication does not inherently increase data corruption risks because writes are committed to both the primary and replica storage subsystems simultaneously before acknowledging the transaction to the client, ensuring parity. This approach is tempting when designing high-availability architectures requiring zero RPO (Recovery Point Objective), where immediate failover without data loss is mandatory. It would be the correct choice when regulatory mandates or critical business operations dictate that even a momentary transaction gap is unacceptable, provided the network latency between sites remains sufficiently low to support atomic commits.

Increased probability of backup failure.

Why it fails: Synchronous replication commits database transactions to both primary and replica storage volumes simultaneously before confirming completion to the client, which directly impacts transaction latency and write performance rather than introducing risks to backup execution schedules. Administrators often consider this configuration when aiming to eliminate recovery point objectives during catastrophic failures, as it guarantees zero data loss by ensuring the replica is fully synchronised at every commit point. However, this trade-off involves accepting write latency overhead and potential application stalls during network delays, completely unrelated to the integrity or success rate of secondary backup jobs.

Limited scalability of the database cluster.

Why it fails: Synchronous replication's real cost is write latency: every commit must be acknowledged by the standby before returning, so throughput and response times degrade as distance or load grows. Scalability limits are tempting because replication does constrain topology, but the defining trade-off is latency versus durability, not cluster size.

Mismatched firmware versions between servers.

Why it fails: Mismatched firmware versions between servers can cause operational instability and unpredictable hardware interactions, making this a tempting distractor when troubleshooting unexpected system crashes. Administrators often suspect firmware discrepancies because strict version parity is crucial during initial cluster provisioning and rolling updates to ensure hardware-level compatibility and proper execution of synchronous replication protocols. However, firmware disparity does not generate conflicting heartbeat signals or independently sever communication links between isolated data centres, meaning it cannot trigger the simultaneous dual-master activity that defines a split-brain scenario.

Inadequate storage capacity for incoming logs.

Why it fails: Running out of storage capacity causes replication queues to overflow and log synchronization to drop, which halts data streams rather than creating conflicting active nodes. This distractor is tempting because managing log storage is critical for maintaining point-in-time recovery and transactional integrity in continuous data protection environments. It would be the correct choice if the disaster recovery failure stemmed from storage exhaustion halting the replication pipeline prior to the failover event, rather than simultaneous independent operations occurring across isolated networks.

Insufficient cooling at the hot site.

Why it fails: Environmental controls such as insufficient cooling directly threaten physical hardware longevity and server uptime, making it a tempting distraction during any catastrophic facility failure. In an extreme thermal event where HVAC systems collapse, servers undergo emergency thermal shutdown to prevent permanent silicon damage. However, this environmental fault affects thermal capacity rather than network partition visibility, whereas a split-brain condition specifically arises from a loss of heartbeat communication between surviving sites operating concurrently.

To allow marketing teams to create brand-focused content.

Why it fails: Marketing teams focus on brand-building and customer engagement, which makes their tone fundamentally unsuited for managing critical incidents; crisis communication requires rapid, legally vetted, and factual messaging rather than promotional language. This approach is tempting because organisations routinely rely on marketing departments for external messaging and public relations. Such content creation *would* be the correct choice during routine product launches or brand campaigns, where polished commercial messaging and aesthetic appeal take precedence over immediate transparency and operational containment.

To bypass legal review during the crisis.

Why it fails: Pre-approved templates exist to accelerate the dissemination of information while ensuring organisational messaging remains consistent and accurate under pressure. Attempting to bypass legal review creates significant liability risks, as crisis communications must be vetted to prevent regulatory non-compliance or reputational damage. This option is tempting because templates do reduce the time required to draft responses; however, they serve to streamline the approval workflow rather than eliminate the necessity of legal oversight. Legal scrutiny remains a mandatory control, regardless of how quickly a communication must be released.

To fulfill regulatory requirements for daily status reports.

Why it fails: Pre-approved templates serve to minimise response latency and ensure message consistency during the initial, chaotic phase of a crisis, whereas regulatory reporting requirements typically necessitate bespoke, auditable documentation tailored to specific legal frameworks. This option appears attractive because organisations often maintain automated reporting schedules to satisfy compliance mandates. However, such reporting mechanisms function as periodic administrative controls rather than the rapid, standardised communication tools required to manage stakeholder expectations during an active security incident or business disruption.

Update the organizational chart.

Why it fails: Updating the organisational chart focuses on administrative personnel changes rather than the technical validation of recovery procedures, making it irrelevant to the operational outcomes of a disaster recovery exercise. This action is typically performed during routine human resources management or following corporate restructuring to ensure accurate reporting lines and access control permissions. While maintaining an accurate directory is necessary for administrative governance, it does not address the identification of process failures or technical gaps discovered during the simulation.

Verify the status of the offsite backup tapes.

Why it fails: Verifying offsite backup tapes focuses on the integrity and availability of physical media rather than the evaluation of organisational response processes. This task belongs to routine operational maintenance or a specific recovery validation phase, where administrators confirm that data restoration points are current and accessible. While ensuring backup viability is essential for disaster readiness, a lessons learned meeting serves to analyse human performance, communication gaps, and procedural inefficiencies observed during the exercise, rather than confirming the technical state of storage hardware.

Evaluate the performance of the IT staff for disciplinary purposes.

Why it fails: Disaster recovery exercises focus on identifying systemic weaknesses and process improvements rather than individual performance management. While human error often contributes to recovery failures, using a post-exercise review for disciplinary action discourages honest reporting and undermines the blameless culture necessary for effective organisational resilience. Performance appraisals and disciplinary procedures remain distinct human resources functions, reserved for formal reviews or specific conduct investigations where the objective is to address individual professional development or policy violations rather than technical recovery capability.

The maximum acceptable age of data in the event of a system crash.

Why it fails: Defining the maximum acceptable age of data describes the Recovery Point Objective (RPO), which measures data loss tolerance rather than the temporal limit for system unavailability. This option is tempting because stakeholders often conflate the two metrics during business continuity planning. RPO is the correct metric when determining the frequency of backups or replication intervals to minimise data loss, whereas the Maximum Tolerable Downtime specifically quantifies the duration a business process can remain offline before incurring unacceptable operational or financial consequences.

The time taken to fail over to the secondary site during a disaster.

Why it fails: Failing over to a secondary site describes the Recovery Time Objective (RTO) rather than the Maximum Tolerable Downtime (MTD), which measures the total operational outage an organisation can endure before permanent damage occurs. This confusion arises because RTO and MTD are both critical time-based disaster recovery metrics measured in hours or minutes. RTO would correctly define this failover duration if the executive team were planning the speed of technical restoration instead of calculating the outer limit of tolerable business disruption.

The time required to restore the application from the latest tape backup.

Why it fails: Defining MTD based solely on tape restoration time conflates a business-level requirement with a specific recovery mechanism. This metric represents the Recovery Time Objective (RTO), which focuses on the technical duration needed to restore services from a backup. While RTO is a critical component of disaster recovery planning, MTD encompasses the total duration an organisation can tolerate an outage before unacceptable consequences occur. Organisations often use RTO to validate whether their chosen backup strategy can meet the broader, business-mandated MTD threshold.

A complete replica of the production environment is running 24/7.

Why it fails: Running a complete replica 24/7 describes a 'Hot Standby' or multi-site active-active architecture rather than the requested 'Pilot Light' approach. This option fails because a Pilot Light strategy maintains only core critical services—such as database replication and foundational infrastructure configurations—in a powered-down or minimal state until a disaster occurs, whereas running full production capacity continuously incurs unnecessary compute and licensing costs. Organisations are often tempted by this fully operational model because it eliminates the recovery time needed to spin up infrastructure during an outage, making it the correct choice when business continuity SLAs demand near-zero recovery time objectives regardless of budget constraints.

The environment only exists as data snapshots in cold storage.

Why it fails: Describing an environment that exists solely as dormant data snapshots in cold storage defines a Backup and Restore strategy rather than a Pilot Light approach. This option is tempting because cold storage snapshots represent a highly cost-effective method for long-term data retention and regulatory compliance. It would be the correct choice in a scenario where an organisation prioritises minimising storage expenditure over achieving rapid recovery time objectives, and where administrators are prepared to manually provision and configure core infrastructure from scratch during an emergency declaration.

The environment is hosted on-premises and fails over to a secondary data center.

Why it fails: This option describes a traditional on-premises secondary site architecture rather than a cloud-based disaster recovery model specified by the stem, meaning it fails to utilise cloud infrastructure elasticity for replication. Such a setup is tempting because it represents a standard dual-data-centre High Availability or active-passive DR pattern used to protect legacy physical infrastructure, and it would be the correct choice if the organisation maintained ownership of its own secondary hardware facility instead of leveraging a cloud provider's managed services.

Total expected cost of hardware replacement.

Why it fails: Hardware replacement costs relate strictly to capital expenditure and recovery budgets rather than the temporal constraints defining MTD. While these costs are essential for financial impact assessments and procurement planning during disaster recovery, they do not measure the time-based threshold beyond which business operations suffer irreversible damage. This option is tempting because it represents a tangible metric for calculating the Recovery Cost Objective, which is often evaluated alongside MTD during the business impact analysis phase to justify recovery strategies.

The current availability of spare parts in the data center.

Why it fails: Availability of spare parts relates to Recovery Time Objective (RTO) and physical hardware logistics rather than the Maximum Tolerable Downtime (MTD). MTD represents the absolute limit an organisation can survive without a critical business function before incurring unacceptable losses. While spare parts influence how quickly a technician can repair a server, they do not define the business-driven threshold for operational survival. This factor is relevant when planning maintenance windows or supply chain resilience, but it remains secondary to the strategic impact assessments that dictate MTD.

The number of employees required to perform manual workarounds.

Why it fails: Staffing requirements for manual workarounds relate to the operational feasibility of a continuity strategy rather than the MTD itself. MTD represents the absolute time limit an organisation can survive without a specific service before suffering irreversible damage. This option is tempting because it is a vital consideration when developing the Business Continuity Plan’s recovery procedures, specifically when determining if a manual fallback is viable during the period defined by the Recovery Time Objective (RTO).

Leaving BCP entirely to the discretion of local department managers.

Why it fails: Delegating business continuity planning entirely to local managers allows business units to tailor recovery strategies rapidly to their unique regional risks and operational workflows. This localized autonomy is tempting because it maximizes immediate responsiveness in decentralized environments. However, this decentralized-only approach fails this scenario because it creates fragmented recovery procedures, uncoordinated dependencies, and inconsistent resilience baselines. Global alignment requires centralized governance frameworks, whereas absolute local discretion prevents the organisation from achieving enterprise-wide risk visibility, regulatory harmonization, and cohesive crisis response capabilities across all business units.

A strictly centralized command-and-control model.

Why it fails: Imposing a top-down hierarchy directly conflicts with the autonomy required by distributed business units, causing severe operational bottlenecks during regional disruptions. This rigid framework is designed for hierarchical enterprises seeking absolute compliance and uniform execution, making it the correct choice when uniform regulatory mandates and standardized recovery procedures must override localized operational variance across all corporate sites.

Outsourcing the entire BCP function to a single managed service provider.

Why it fails: Delegating the entire Business Continuity Plan function to a single managed service provider strips a decentralized organisation of the local operational agility required for site-specific nuances. While this approach appears tempting because it centralises oversight, reduces internal administrative overhead, and leverages external expertise for resource-constrained enterprises requiring turnkey compliance, it fails in this scenario by imposing a rigid, monolithic framework that cannot adapt to the autonomous decision-making structures demanded across distributed business units.

An inventory of all software licenses held by the organization.

Why it fails: Maintaining an inventory of software licences is a static administrative task focused on asset management and compliance, whereas a Crisis Management Plan requires dynamic, time-sensitive procedures for incident response and business continuity. While this documentation is vital for software asset management and auditing purposes during routine IT governance, it lacks the operational directives needed to mitigate an active organisational crisis. Organisations use such inventories to track procurement and legal entitlements, but these details do not facilitate the immediate communication or recovery strategies necessitated by a disaster.

Granular technical steps for server restoration.

Why it fails: Granular technical restoration steps belong in a Disaster Recovery Plan rather than a Crisis Management Plan, which focuses on strategic decision-making, communication, and business continuity. Including low-level server configuration details obscures the high-level governance required to manage stakeholders and organisational reputation during an incident. This option is tempting because technical teams often conflate recovery procedures with crisis response; however, such specific instructions are intended for operational staff executing technical remediation, such as restoring identity services via Microsoft Entra ID, rather than for the crisis management team.