Business Continuity, Disaster Recovery, and Cyber Resilience

Introduction and Context

Organizations depend on information systems to deliver products, process transactions, communicate with stakeholders, comply with law, and protect valuable information. A cyberattack, power failure, fire, flood, pandemic, cloud outage, hardware failure, or supplier disruption can interrupt these activities. Cybersecurity management therefore extends beyond preventing incidents. It must also ensure that the organization can continue essential operations during disruption, restore services within acceptable limits, and adapt to changing threats.

Business continuity, disaster recovery, and cyber resilience are related but distinct disciplines. Business continuity focuses on maintaining critical products and services. Disaster recovery focuses primarily on restoring information technology, applications, infrastructure, and data. Cyber resilience combines protection, continuity, recovery, and adaptation in the face of cyber threats. Effective programs integrate governance, risk management, technology, people, suppliers, communications, and exercising.

This chapter presents a practical framework for conducting business impact analysis, defining recovery objectives, selecting continuity and recovery strategies, managing backups, improving ransomware resilience, exercising plans, and assessing operational and systemic resilience.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the relationships among business continuity, disaster recovery, incident response, and cyber resilience.
2. Conduct a business impact analysis and identify critical dependencies.
3. Define and apply recovery time objectives, recovery point objectives, maximum tolerable periods of disruption, and related measures.
4. Select continuity, disaster-recovery, backup, and ransomware-resilience strategies.
5. Design and evaluate exercises, tests, and improvement processes.
6. Assess operational, organizational, and systemic resilience.
7. Address governance, legal, ethical, supply-chain, and communication requirements.

1. Foundational Concepts

Business continuity

Business continuity is the capability of an organization to continue delivering acceptable products or services during and after a disruptive event. It includes more than IT. A continuity plan may address alternate facilities, manual procedures, staffing, communications, suppliers, transportation, finance, and customer support.

Continuity is concerned with the question: How can essential business activity continue? For example, a hospital may need to continue emergency care even if its electronic records system is unavailable. A bank may need to maintain payment processing despite a data-center outage.

Disaster recovery

Disaster recovery is the coordinated process of restoring technology, data, applications, facilities, and supporting services after a disruptive event. It is a component of business continuity. A technically successful recovery is not sufficient if employees lack access, suppliers remain unavailable, or the restored application cannot support the business process.

Incident response

Incident response addresses the detection, analysis, containment, eradication, and handling of a security incident. It usually emphasizes the immediate response to malicious activity. Disaster recovery begins when systems or services must be restored, although the two activities overlap. For example, a ransomware response may require containment by the incident-response team and restoration from clean backups by the recovery team.

Cyber resilience

Cyber resilience is the ability to anticipate, withstand, recover from, and adapt to adverse cyber events. It recognizes that prevention is imperfect. Resilient organizations assume that controls may fail and therefore design for graceful degradation, rapid recovery, learning, and adaptation.

A useful distinction is:

• Resistance: reducing the likelihood or impact of disruption.
• Reliability: performing consistently under expected conditions.
• Resilience: continuing or recovering performance under adverse conditions.
• Adaptability: changing processes, architecture, or controls after experience or environmental change.

Disruption categories

Disruptions may be accidental, natural, technical, human, malicious, or systemic. Examples include:

• cyberattacks, ransomware, destructive malware, and denial-of-service attacks;
• hardware, software, network, cloud, or telecommunications failures;
• fires, floods, earthquakes, storms, and extended power loss;
• pandemics, labor shortages, and loss of key personnel;
• supplier, logistics, utility, or concentration failures; and
• regulatory, geopolitical, or financial events.

Plans should be capability-based rather than written for only one imagined disaster. A plan designed solely for a flood may fail during ransomware because systems, credentials, and backups require different treatment.

2. Governance and the Continuity Lifecycle

A mature continuity program is governed by senior management and connected to enterprise risk management. Typical responsibilities include:

• Board or governing body: oversees resilience risk and approves risk appetite.
• Executive sponsor: provides authority, funding, and cross-functional coordination.
• Continuity manager: maintains the program, methodology, plans, and exercises.
• Business owners: identify critical services, impacts, dependencies, and recovery priorities.
• IT and security teams: design recovery architecture, protect backups, and coordinate technical restoration.
• Legal, privacy, compliance, and communications teams: address notification, evidence, contractual duties, and public messaging.
• Suppliers and partners: provide recovery capabilities and participate in assurance activities.

The lifecycle commonly includes program initiation, risk assessment, business impact analysis, strategy selection, plan development, implementation, training, exercising, performance measurement, and continual improvement. It is cyclical because organizational processes, technology, suppliers, threats, and regulations change.

Governance should establish approval authority, escalation thresholds, plan ownership, emergency procurement rules, records retention, and decision rights. A plan that has no owner, resources, or authority is documentation rather than capability.

3. Business Impact Analysis

Purpose and scope

A business impact analysis (BIA) identifies essential activities, the consequences of disruption, recovery priorities, dependencies, and the resources required for recovery. It is not simply an inventory of systems. It begins with business services and processes, then traces their technology, people, facilities, information, suppliers, and dependencies.

A BIA should answer:

1. What products or services must continue?
2. What activities produce them?
3. What happens if each activity is unavailable or degraded?
4. How quickly must it be restored?
5. How much data loss is tolerable?
6. What resources and dependencies are necessary?
7. Which activities must be restored first, and why?

BIA method

A practical BIA can follow these steps:

1. Define scope and criteria. Establish organizational boundaries, disruption scenarios, impact categories, and rating scales.
2. Identify services and processes. Use interviews, workshops, process maps, service catalogs, and observation.
3. Estimate time-dependent impacts. Consider financial loss, safety, legal exposure, operational failure, customer harm, privacy, reputation, and strategic effects.
4. Identify dependencies. Record applications, data, identities, networks, facilities, staff, suppliers, utilities, and upstream or downstream processes.
5. Determine recovery requirements. Establish recovery time and data-recovery needs with accountable business owners.
6. Prioritize and validate. Compare results across departments and obtain management approval.
7. Review periodically. Reassess after major changes, incidents, acquisitions, or new regulation.

Impacts often increase with time, but not always linearly. A service may tolerate a brief outage and then experience a sharp increase in harm when legal deadlines, safety limits, market windows, or customer expectations are exceeded.

Recovery terminology

Maximum tolerable period of disruption (MTPD) is the maximum time that a disruption can continue before the organization suffers unacceptable harm. It is a business tolerance, not a technical promise.

Recovery time objective (RTO) is the targeted time within which a process, service, or system should be restored after disruption. The RTO must normally be shorter than the MTPD, allowing time for residual degradation and stabilization.

Recovery point objective (RPO) is the point in time to which data should be recovered after disruption. An RPO of four hours means that, under the approved recovery design, the organization accepts the possibility of losing up to approximately four hours of data, subject to implementation and operational conditions.

Work recovery time (WRT) is the time required after technical restoration to validate data, reconnect users, reconcile transactions, and return to normal operation. Thus, a service may have a technical recovery time plus WRT before full business functionality is achieved.

Minimum business continuity objective (MBCO) describes the minimum level of products or services that must be maintained during a disruption. It is useful when full performance is temporarily impossible.

RTO and RPO are requirements, not automatically available capabilities. Lower objectives usually require greater investment, architectural complexity, testing, and operational discipline.

Worked example: interpreting recovery objectives

Suppose an online order service has an MTPD of 12 hours. Business owners set an RTO of 4 hours and an RPO of 30 minutes. The recovery design must therefore restore the service within four hours and recover data to a point no more than about 30 minutes before the incident, assuming the backup and replication mechanisms operate as intended. If technical restoration takes three hours and business validation takes two hours, the effective recovery time is five hours, which fails the four-hour RTO. The organization must either reduce restoration or validation time, revise the objective with management approval, or accept the risk formally.

The example illustrates why recovery measurements must include business usability rather than merely server boot time.

4. Continuity and Disaster-Recovery Strategies

Strategy selection principles

Strategy selection should follow the BIA and risk assessment. Important considerations include required RTO and RPO, threat scenarios, geographic risk, data sensitivity, cost, staffing, supplier reliability, legal constraints, and operational complexity. A strategy should be tested under realistic conditions; an impressive design that cannot be operated under pressure is weak resilience.

Facilities and processing arrangements

Common arrangements include:

• Cold site: space and basic facilities are available, but equipment and data restoration take substantial time.
• Warm site: some infrastructure and services are prepared, reducing restoration time.
• Hot site: near-ready infrastructure and replicated services support rapid recovery, usually at higher cost.
• Reciprocal arrangement: organizations agree to assist one another, although capacity, security, and competing emergencies may limit reliability.
• Distributed or multi-region architecture: services operate across separated locations, reducing dependence on one site but increasing design and governance complexity.

Geographic separation must be evaluated against common-cause risks. Two facilities in different buildings may still share the same power grid, floodplain, cloud region, identity provider, or telecommunications carrier.

High-availability and redundancy

High availability reduces interruption during component failure, while disaster recovery restores service after a larger disruption. Techniques include clustering, load balancing, redundant networks, multiple identity services, replicated databases, spare equipment, and geographically separated operations. Redundancy does not eliminate risk: synchronized corruption, compromised administrative credentials, software defects, and common suppliers can affect all redundant components.

Manual workarounds and graceful degradation

Continuity may involve reduced service rather than immediate full restoration. Examples include manual admission procedures, offline transaction forms, emergency communication channels, prioritized customer services, or temporary processing limits. Manual procedures must be documented, secured, staffed, and reconciled after restoration. Otherwise, they can introduce fraud, privacy, and data-integrity risks.

Cloud and outsourced services

Cloud services can improve elasticity and geographic diversity but do not transfer accountability. Organizations remain responsible for understanding service dependencies, identity controls, data locations, backup arrangements, provider recovery commitments, and exit options. Contracts should address recovery objectives, incident notification, evidence preservation, service credits, audit rights, subcontractors, and termination assistance.

A cloud backup is not automatically an independent backup. If the same compromised identity can delete production data and its backup, logical separation is absent even if the storage is geographically separate.

5. Backup Management and Ransomware Resilience

Backup principles

A dependable backup program protects confidentiality, integrity, availability, and recoverability. It should define what is backed up, how often, where copies are stored, how long they are retained, who can access them, and how restoration is verified.

A commonly used design principle is the 3-2-1 rule: maintain at least three copies of data, on at least two different storage media or platforms, with at least one copy offline or isolated. It is a baseline rather than a complete security architecture. Some organizations extend it with immutable copies and geographically separated copies.

Important controls include:

• encryption in transit and at rest, with protected key management;
• separate backup identities and least privilege;
• multifactor authentication and administrative approval for destructive actions;
• immutable or write-once retention where appropriate;
• network and credential isolation from production;
• monitoring for unusual deletion, encryption, or backup-volume changes;
• documented retention and legal-hold requirements; and
• regular restoration tests using representative data.

A backup that has never been restored is an assumption, not evidence of recoverability.

Ransomware-resilient recovery

Ransomware resilience requires more than malware detection. Organizations should reduce attack paths, segment privileged administration, protect identity systems, patch exploitable vulnerabilities, restrict macros and scripts where appropriate, monitor endpoint and network behavior, and maintain tested recovery paths.

During a suspected ransomware event, priorities generally include protecting people and safety, activating incident and continuity leadership, isolating affected systems, preserving evidence, preventing further spread, protecting backup environments, determining the scope of compromise, and restoring from verified clean sources. Investigators should avoid destroying evidence through uncontrolled reimaging. Legal and regulatory teams should be involved early.

Recovery should proceed in a controlled order: identity and core infrastructure, essential network services, critical applications, validated data, and dependent business processes. Credentials may need to be reset, privileged accounts rebuilt, and restored systems monitored closely. The organization should not assume that a backup is clean merely because it is available.

Backup performance measures

Useful measures include backup success rate, restore success rate, time to restore, percentage of critical systems covered, age of the newest recoverable copy, number of privileged backup accounts, and the proportion of recovery procedures tested within the required period. Metrics should distinguish a completed backup job from a verified, usable recovery point.

6. Plan Development and Activation

A continuity or recovery plan should be concise enough to use under stress and detailed enough to guide action. It commonly includes:

• purpose, scope, assumptions, and activation criteria;
• roles, alternates, contact methods, and authority levels;
• safety and emergency procedures;
• escalation and communications arrangements;
• service priorities and dependency information;
• technical recovery procedures and restoration sequences;
• manual workarounds and minimum service levels;
• supplier and facility procedures;
• data, evidence, privacy, and records requirements;
• return-to-normal procedures; and
• checklists, diagrams, inventories, and references.

Activation may be based on time, impact, loss of capability, safety risk, or anticipated escalation. Decisions should be recorded, including who authorized activation and why. Plans must be accessible when normal systems are unavailable; secure offline copies and alternate communication methods are therefore important.

Communications should be accurate, timely, accessible, and coordinated. Internal audiences need practical instructions. Customers and regulators may need information about service effects, safety, privacy, and expected updates. Speculation, blame, and unsupported assurances can increase harm.

7. Exercising, Testing, and Continual Improvement

Training explains roles and procedures; an exercise evaluates whether people and capabilities can perform them. A mature program uses progressively demanding methods:

• Orientation or awareness session: introduces roles and assumptions.
• Tabletop exercise: discusses a scenario and decision points without changing production.
• Walkthrough: examines procedures and dependencies in detail.
• Simulation: reproduces actions and communications under controlled conditions.
• Technical recovery test: restores systems or data in an isolated environment.
• Full-scale exercise: coordinates multiple teams, facilities, suppliers, and communications.

Exercise objectives should be specific and measurable, such as verifying that a critical service can be restored within its RTO or that an alternate communication channel reaches all required personnel. Scenarios should include uncertainty, conflicting information, supplier failure, unavailable staff, or compromised credentials. Safety and production protection must constrain exercise design.

After-action reviews should identify strengths, gaps, owners, priorities, and deadlines. Findings should be tracked to closure. Repeated exercises that produce reports but no remediation create an illusion of preparedness.

8. Measuring Operational and Systemic Resilience

Resilience assessment should combine evidence, not rely on a single score. Useful dimensions include:

Operational resilience asks whether a particular organization can continue important services. Systemic resilience asks whether interconnected organizations, sectors, and infrastructures can withstand shared disruption. Concentration in one cloud provider, payment network, telecommunications carrier, software dependency, or managed service can create systemic risk even when each organization appears individually well prepared.

Quantitative measures can support decisions, but they require consistent definitions. For example, service availability over a measurement period can be expressed as:

Availability is dimensionless and often reported as a percentage. The measure must define scheduled time, exclusions, planned maintenance, partial outages, and the boundary of the service. It does not by itself measure data integrity, recovery quality, or customer impact.

Expected annual loss can also support prioritization:

Here, SLE is single-loss expectancy, the estimated loss from one event, and ARO is annualized rate of occurrence, the expected frequency of that event per year. The formula assumes that the estimates are meaningful and that multiplying event impact by frequency is an acceptable approximation. It should not be treated as a precise prediction, especially for low-frequency catastrophic events, cascading failures, or nonfinancial harms.

9. Governance, Ethics, and Regulation

Continuity decisions involve ethical choices. Prioritizing one service may delay another; restoring systems may expose personal data; paying a ransom may create legal and social consequences; and communicating uncertainty may conflict with pressure for reassurance. Decisions should be guided by safety, fairness, proportionality, legal duties, documented authority, and respect for affected stakeholders.

Organizations may have obligations relating to privacy, critical infrastructure, financial services, health, employment, records, contracts, and breach notification. Requirements vary by jurisdiction and sector. Legal advice should be obtained for specific incidents. Plans should identify notification triggers, evidence preservation duties, contractual time limits, and regulator contacts without assuming that one rule applies everywhere.

Accessibility and inclusion are also continuity requirements. Emergency communications should accommodate disability, language, remote work, and unequal access to technology. Employee safety, psychological welfare, and protection from retaliation support reliable response performance.

10. Technology, Automation, and AI

Automation can improve monitoring, backup verification, dependency mapping, notification, and recovery orchestration. Infrastructure-as-code can make environments reproducible, while immutable configuration records can reduce unauthorized drift. However, automation can amplify an error or compromise. Recovery automation must include authorization, separation of duties, logging, rollback, and safe failure modes.

Artificial intelligence may assist with event correlation, impact analysis, prioritization, drafting communications, and identifying anomalous backup behavior. It should not independently make high-consequence recovery or disclosure decisions without accountable human oversight. AI systems themselves require continuity planning: model availability, data integrity, prompt or configuration protection, vendor dependency, explainability, and fallback procedures must be considered.

11. Illustrative Case: Ransomware at a Regional Logistics Company

Background

Northstar Logistics, a fictional regional company, operates warehouses, delivery scheduling, customer portals, and electronic proof-of-delivery services. Its scheduling application has an RTO of six hours and an RPO of one hour. Warehouse safety and dispatch are considered critical services.

Problem

A ransomware attack encrypts file servers and several application servers. The attackers also use a compromised administrator account to delete accessible backups. Dispatch staff cannot access normal schedules, while the customer portal is unavailable. The company has a cloud backup provider, but restoration procedures have not been tested for eighteen months.

Analysis

The BIA shows that dispatch can operate manually for a limited period, but warehouse congestion and missed delivery windows increase rapidly after four hours. Identity services, network connectivity, scheduling data, mobile devices, and telecommunications are dependencies. The deleted backups demonstrate that geographic separation alone did not provide logical independence.

Approach and solution

The incident commander activates the continuity plan. Security staff isolate affected networks and preserve evidence. Operations establish a controlled manual dispatch process using preapproved forms and an alternate communication channel. Backup administrators disable compromised credentials and protect the backup environment. The recovery team identifies a dated, immutable copy and restores core identity and network services in an isolated environment before restoring the scheduling application.

Business owners validate restored schedules against shipment records. The customer portal remains offline until its code, credentials, and supporting data are checked. Communications explain the service limitations without speculating about the attacker. Legal and privacy teams assess notification obligations.

After recovery, Northstar implements separate backup identities, multifactor authentication, immutable retention, privileged-access monitoring, quarterly restoration tests, segmented administration, and a supplier review. It also revises the BIA to include manual capacity limits and adds a dependency on identity recovery.

Outcome and learning points

Northstar restores dispatch in five hours, but full customer-portal functionality takes longer. The organization meets the dispatch RTO through manual continuity and technical recovery, although it does not meet the original portal objective. The case demonstrates that recovery objectives must be service-specific, backups must be protected from the production trust boundary, manual workarounds require capacity planning, and exercises expose weaknesses that documentation conceals.

Challenges and Limitations

Continuity planning is difficult because future events are uncertain, impact estimates are subjective, and dependencies cross organizational boundaries. Budgets may favor preventive controls over recovery capability, even though prevention cannot eliminate all risk. Highly available systems can create false confidence when common credentials, providers, or software affect every replica. Third-party assurances may be incomplete, and contractual recovery commitments may not match organizational needs.

RTO and RPO can also be misunderstood as guarantees. They are targets supported by controls, resources, and assumptions. A recovery plan may fail because staff are unavailable, data is corrupted, restoration capacity is insufficient, or the event affects the recovery environment itself. For these reasons, resilience should be treated as an evidence-based capability that is continuously tested and improved.

Best-Practice Checklist

A practical program should:

• identify critical services before selecting technology;
• obtain accountable approval for MTPD, RTO, RPO, and minimum service levels;
• map people, facilities, suppliers, identity, data, and technology dependencies;
• design recovery for common-cause and cyber-compromise scenarios;
• maintain isolated, protected, and regularly tested backups;
• provide secure offline plans and alternate communications;
• exercise both technical recovery and business decision-making;
• measure usable service restoration rather than server availability alone;
• track findings to accountable owners and deadlines; and
• review plans after incidents, exercises, major changes, and emerging threats.

Chapter Summary

Business continuity maintains essential products and services during disruption, while disaster recovery restores technology, data, and supporting capabilities. Cyber resilience unites prevention, resistance, continuity, recovery, and adaptation. A business impact analysis identifies critical services, time-dependent impacts, dependencies, and recovery priorities. MTPD expresses the maximum tolerable disruption; RTO specifies a restoration target; RPO specifies an acceptable data-recovery point; and WRT recognizes the time needed to return restored services to usable operation.

Effective strategies combine appropriate architecture, geographic and logical separation, manual workarounds, supplier assurance, protected backups, and tested restoration. Ransomware resilience requires isolation, identity protection, immutable or offline copies, evidence preservation, clean recovery, and post-incident improvement. Exercises should test people, decisions, communications, suppliers, and technology, not merely the existence of documents. Finally, resilience assessment must consider both organizational capability and systemic dependencies such as shared cloud, telecommunications, identity, and software providers.

Key Terms

Business continuity: Capability to continue delivering acceptable products or services during disruption.

Business impact analysis: Process for identifying disruption consequences, priorities, dependencies, and recovery requirements.

Cyber resilience: Ability to anticipate, withstand, recover from, and adapt to adverse cyber events.

Disaster recovery: Restoration of technology, data, applications, facilities, and supporting services after disruption.

Incident response: Coordinated handling of detection, analysis, containment, eradication, and recovery activities for an incident.

Maximum tolerable period of disruption (MTPD): Longest period a disruption can continue before unacceptable harm occurs.

Recovery time objective (RTO): Target time for restoring a process, service, or system.

Recovery point objective (RPO): Point in time to which data should be recovered after disruption.

Work recovery time (WRT): Time required after technical restoration to make a service fully usable.

Minimum business continuity objective (MBCO): Minimum acceptable level of service during disruption.

High availability: Design approach that reduces interruption through redundancy and rapid failover.

Cold site: Recovery location requiring substantial equipment and data restoration before operation.

Hot site: Prepared recovery environment capable of supporting rapid service restoration.

Immutable backup: Backup protected from alteration or deletion during its retention period.

Logical separation: Isolation based on accounts, permissions, networks, or systems rather than location alone.

3-2-1 backup rule: Baseline approach using three copies, two media or platforms, and one offline or isolated copy.

Tabletop exercise: Facilitated discussion of actions and decisions for a disruption scenario.

Operational resilience: Capacity to continue important services despite disruption.

Systemic resilience: Capacity of interconnected organizations or sectors to withstand shared disruption.

After-action review: Structured evaluation used to identify strengths, weaknesses, and improvements after an event or exercise.

Review Questions

Short Answer Questions

1. Distinguish business continuity from disaster recovery.
2. What is the difference between an RTO and an RPO?
3. Why is a geographically separate backup not necessarily independent?
4. What is the purpose of a business impact analysis?
5. Name two limitations of relying only on high availability.

Long Answer Questions

1. Explain a complete BIA process, including service identification, impact assessment, dependency analysis, validation, and review.
2. Compare cold-site, warm-site, hot-site, and distributed recovery strategies.
3. Explain how an organization can design a ransomware-resilient backup and recovery program.
4. Discuss the roles of governance, suppliers, communications, and legal teams in continuity management.
5. Explain how exercises and after-action reviews contribute to continual improvement.

Analytical / Application Questions

1. A payment service has an MTPD of eight hours, an RTO of three hours, and an RPO of fifteen minutes. Technical restoration takes two hours, but validation and reconciliation take two additional hours. Analyze whether the recovery design meets the stated objective and recommend actions.
2. A company replicates production data continuously to a second cloud region, but both regions use the same administrator directory and provider control plane. Evaluate the resilience benefits and identify the common-cause risks.
3. Design an exercise for a hospital ransomware scenario. Specify objectives, participants, safety constraints, expected evidence, and the process for converting findings into improvements.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes business continuity from disaster recovery?

A. Business continuity focuses only on cybersecurity controls, while disaster recovery focuses only on physical facilities.

B. Business continuity maintains essential business services, while disaster recovery restores technology and supporting capabilities.

C. Business continuity occurs after recovery, while disaster recovery occurs before an incident.

D. Business continuity is a supplier activity, while disaster recovery is exclusively a board activity.

Correct Answer: B. Business continuity maintains essential business services, while disaster recovery restores technology and supporting capabilities.

Question 2

An RPO of one hour primarily indicates which requirement?

A. The service must be fully restored within one hour.

B. The organization accepts no more than one hour of possible data loss, subject to the recovery design.

C. The system must remain available for one hour after an attack.

D. The organization must test its plan every hour.

Correct Answer: B. The organization accepts no more than one hour of possible data loss, subject to the recovery design.

Question 3

Which backup characteristic most directly protects against an attacker deleting backups with compromised production credentials?

A. Higher screen resolution on backup consoles

B. Logical isolation and separate privileged access

C. Storing all copies on the production network

D. Using the same administrator account for production and backup systems

Correct Answer: B. Logical isolation and separate privileged access

Question 4

A service has scheduled service time of 1,000 hours and unplanned downtime of 10 hours. What is its availability?

A. 90%

B. 98%

C. 99%

D. 99.9%

Correct Answer: C. 99%

Question 5

Which activity is the primary purpose of a business impact analysis?

A. Selecting a firewall brand

B. Identifying service impacts, dependencies, and recovery priorities

C. Writing malware signatures

D. Replacing all manual procedures with automation

Correct Answer: B. Identifying service impacts, dependencies, and recovery priorities

Question 6

Why can redundant systems still fail together?

A. Redundancy always reduces availability.

B. They may share common credentials, providers, software defects, or other common-cause dependencies.

C. Redundant systems cannot use encryption.

D. Redundant systems are never tested.

Correct Answer: B. They may share common credentials, providers, software defects, or other common-cause dependencies.

Question 7

Which exercise normally involves facilitated discussion without changing production systems?

A. Tabletop exercise

B. Full destructive failover

C. Live malware deployment

D. Uncontrolled restoration test

Correct Answer: A. Tabletop exercise

Question 8

What is work recovery time?

A. The time needed to purchase a new building

B. The time after technical restoration needed to validate data and return the service to usable operation

C. The time before an incident is detected

D. The time required to calculate annualized rate of occurrence

Correct Answer: B. The time after technical restoration needed to validate data and return the service to usable operation

Question 9

Which practice best supports ransomware recovery?

A. Allowing backup administrators to use production credentials

B. Testing restoration from protected, isolated, and verified copies

C. Keeping only one online backup copy

D. Reimaging systems before preserving evidence in every case

Correct Answer: B. Testing restoration from protected, isolated, and verified copies

Question 10

Systemic resilience is primarily concerned with which issue?

A. The password length of one employee

B. The performance of one isolated workstation

C. Shared dependencies and cascading disruption across interconnected organizations or sectors

D. The color scheme of a continuity plan

Correct Answer: C. Shared dependencies and cascading disruption across interconnected organizations or sectors