Business Continuity, Disaster Recovery, and Resilience

Introduction and context

Cloud computing has changed the way organisations provide and consume information services. Applications, data, identities, networks, and operational tools may be distributed across regions, providers, and third-party platforms. This distribution can improve availability, but it does not eliminate risk. A cloud service can still be disrupted by software defects, cyberattacks, configuration errors, power failures, provider outages, telecommunications failures, natural hazards, or failures in the organisation’s own processes.

Business continuity, disaster recovery, and operational resilience are related but distinct disciplines. Business continuity concerns the continuation of critical business activities during disruption. Disaster recovery concerns the restoration of technology services, data, and supporting infrastructure after a disruptive event. Operational resilience is the broader organisational capability to prevent, withstand, adapt to, and recover from disruption while continuing important business services.

Cloud security professionals must therefore design more than backups. They must understand business priorities, define recovery objectives, identify dependencies, select appropriate redundancy, establish crisis-management arrangements, test them, and improve them using evidence. The central question is not simply “Can the system be restored?” It is “Can the organisation continue to deliver its most important outcomes within an acceptable level of disruption?”

Learning objectives

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

• distinguish business continuity, disaster recovery, high availability, and operational resilience;
• identify critical business services, dependencies, threats, and recovery priorities;
• define and apply recovery time objectives (RTOs) and recovery point objectives (RPOs);
• compare backup, redundancy, replication, and disaster-recovery architectures;
• design practical cloud continuity and recovery arrangements;
• explain crisis-management roles, communication requirements, and governance responsibilities;
• calculate basic availability and recovery measures;
• plan, conduct, and evaluate recovery tests; and
• assess ethical, regulatory, supplier, and operational limitations in cloud recovery.

1. Fundamental concepts

Business continuity

Business continuity is the organisation’s capability to continue delivering products or services at an acceptable predefined level following a disruptive incident. It includes people, facilities, processes, suppliers, communications, information, and technology. A business continuity plan may specify manual workarounds, alternate workplaces, emergency staffing, customer communications, and prioritised restoration of applications.

Continuity is therefore not synonymous with keeping every server running. A business may continue operating temporarily with reduced functionality, manual processing, delayed reporting, or an alternate service. The acceptable level must be agreed by business owners and documented before a crisis occurs.

Disaster recovery

Disaster recovery is the coordinated restoration of information systems, applications, infrastructure, and data after a major disruption. It is a technical and managerial component of business continuity. Disaster recovery commonly addresses backup restoration, infrastructure reconstruction, identity services, network connectivity, data validation, application sequencing, and return to normal operations.

High availability and disaster recovery

High availability aims to reduce service interruption during ordinary failures by using components such as redundant instances, load balancing, health checks, automatic failover, and multiple availability zones. Disaster recovery addresses larger failures, including regional outages, destructive cyber incidents, or loss of a primary environment. High availability reduces the likelihood and duration of some outages; disaster recovery provides a controlled recovery path when prevention and local redundancy are insufficient.

Resilience

Resilience is the ability of a system or organisation to absorb disturbance, continue essential functions, adapt to changing conditions, and recover effectively. It includes resistance before an event, response during an event, and learning after an event. Resilience is not equivalent to unlimited availability. A resilient design recognises that failures are inevitable and makes their consequences manageable.

Important terminology

A disaster is an event that causes disruption beyond the organisation’s normal operational capacity or predefined tolerance. A disruption is any event that interrupts or degrades an activity or service. A business impact analysis (BIA) identifies the consequences of disruption over time and establishes recovery priorities. A risk assessment identifies threats, vulnerabilities, likelihood, and impact. A recovery strategy describes the selected means of achieving recovery objectives. A runbook provides detailed operational steps for a known procedure. A playbook provides a structured response to a class of incidents, such as ransomware or regional cloud failure.

2. Business impact analysis and risk-based prioritisation

Continuity design should begin with business services rather than with individual servers. Examples of business services include online payments, clinical appointment scheduling, student registration, order fulfilment, and payroll. Each service should be mapped to its applications, data, identities, networks, facilities, personnel, suppliers, and legal obligations.

A BIA normally asks:

1. What service or activity is being analysed?
2. Who owns it and who depends on it?
3. What is the impact if it is unavailable for one hour, one day, or one week?
4. Which data must be available, and how much data loss is tolerable?
5. What minimum functionality is required during degraded operation?
6. Which dependencies must be restored first?
7. What recovery time and recovery point are required?
8. What obligations arise from contracts, regulation, safety, or privacy?

Impacts may include financial loss, safety consequences, legal penalties, loss of confidentiality, reputational damage, customer harm, and interruption of dependent services. Impact is often time-dependent: a delay that is tolerable overnight may be unacceptable during a payment-clearing period.

A simple risk model can support prioritisation:

Likelihood and impact may be expressed qualitatively, such as low, medium, and high, or by numerical scales. The expression is a prioritisation aid, not a law of nature. It assumes that the scales are defined consistently and that multiplying them does not create a false impression of precision. Organisations should also consider uncertainty, dependency concentration, and low-frequency catastrophic events that may not be well represented by a simple product.

The result of a BIA should be a service catalogue with recovery tiers. For example, a payment service may require continuous operation, a management dashboard may tolerate several hours of interruption, and an archival reporting system may be restored within several days.

3. Recovery objectives and service measures

Recovery time objective

The recovery time objective (RTO) is the maximum targeted elapsed time between service disruption and restoration of the service to a specified acceptable level. RTO is a target, not a guarantee, and must include realistic activities such as detection, decision-making, access approval, infrastructure deployment, data restoration, testing, and business validation.

If an application has an RTO of four hours, a design that restores the virtual machines in two hours but requires six additional hours to validate data and reconfigure dependent identity services does not meet the objective.

Recovery point objective

The recovery point objective (RPO) is the maximum targeted period of data loss measured backward from the time of disruption. An RPO of 15 minutes means that, under the recovery design, the organisation aims to lose no more than approximately 15 minutes of accepted data changes. RPO does not necessarily mean that a backup is created exactly every 15 minutes; continuous replication, transaction logs, or application-level mechanisms may be used.

RPO is different from backup retention. Retention answers how far back historical copies are kept; RPO answers how current the recovered data must be.

Maximum tolerable period of disruption

The maximum tolerable period of disruption (MTPD), sometimes called the maximum acceptable outage, is the longest period for which an activity can be unavailable or operate below an agreed level before unacceptable consequences arise. A recovery design should normally target an RTO shorter than the MTPD, leaving time for uncertainty and stabilisation.

Availability

Availability describes the proportion of time that a service is operational and accessible according to an agreed definition. A basic period-based measure is:

The variables must use the same time unit, such as minutes per month. Planned maintenance may be excluded only if the service agreement explicitly defines it as excluded. Availability measurements should also specify what counts as unavailable, because a responding server with unusable business functionality is not necessarily an available service.

For independent components connected in series, where all components are required, approximate system availability is:

This assumes component failures are independent and that the system is unavailable when any required component is unavailable. Real cloud systems may violate these assumptions because failures can be correlated, such as a regional power problem affecting multiple services. Redundancy changes the model and must be analysed according to the actual architecture.

Worked example: availability and RPO

A service has 30 days of agreed service time, or 43,200 minutes. It experiences 45 minutes of unavailability. Its availability is:

The result is approximately 99.90%, not 99.99%. A target that appears to differ by only a few decimal places can represent a large operational difference. For a 30-day month, 99.9% permits approximately 43.2 minutes of unavailability, while 99.99% permits approximately 4.32 minutes, assuming the target is measured over the full month and all downtime is counted.

Suppose transaction logs are copied every 10 minutes, but a replication failure is not detected for 20 minutes. The theoretical copy interval suggests an RPO of 10 minutes, but the effective RPO during this incident may be approximately 30 minutes. Monitoring and recovery procedures are therefore part of the practical RPO.

4. Backup, replication, and redundancy

Backups

A backup is a separate copy of data maintained so that data can be restored after loss, corruption, deletion, or compromise. Good backup design addresses:

• frequency: how often copies are created;
• retention: how long copies are preserved;
• integrity: whether copies can be successfully read and restored;
• independence: whether the backup is protected from the same failure as production;
• immutability: whether an attacker or compromised administrator can alter or delete it;
• confidentiality: whether encryption and access controls protect it;
• recoverability: whether the organisation can locate, restore, and validate it.

The common “3-2-1” principle recommends at least three copies, on at least two types of storage or media, with at least one copy separated from the primary environment. It is a useful baseline rather than a universal guarantee. Cloud organisations should also consider a logically separate account or subscription, a separate region, offline or immutable storage, and protection of backup-management credentials.

A backup that is continuously accessible using the same administrative identity as production may be technically separate but operationally vulnerable to ransomware. Separation must be considered across accounts, credentials, networks, control planes, and legal ownership.

Replication

Replication copies data or service state from one environment to another. Synchronous replication attempts to commit changes to multiple locations before confirming the transaction. It can offer a very small data-loss window but requires suitable network performance and can propagate corruption or malicious changes. Asynchronous replication confirms locally and transfers changes later. It generally introduces a non-zero RPO but may work across greater distances.

Replication is not a replacement for backups. If a user deletes data or ransomware encrypts a database, replication can reproduce the damaging change. Point-in-time backups, versioning, delayed replicas, and immutable snapshots provide additional recovery choices.

Redundancy and fault domains

Redundancy provides more than one component or path capable of performing a function. Cloud designs should place redundant resources across meaningful fault domains, such as separate availability zones or regions. Two instances in the same zone may not protect against a zone-level outage. Two regions may still share a provider identity system, deployment pipeline, DNS dependency, software defect, or common misconfiguration.

Redundancy can be active-active or active-passive. In an active-active design, multiple sites serve traffic simultaneously. This may reduce failover time but increases complexity in data consistency, traffic management, monitoring, and cost. In an active-passive design, a standby environment is activated after failure. It may be cheaper but can take longer to scale and may contain configuration drift.

5. Cloud disaster-recovery architectures

The principal recovery patterns are not mutually exclusive:

A recovery strategy should be selected by comparing service requirements, risk reduction, cost, technical feasibility, and operational capability. A highly available multi-region design may be unsuitable if the organisation cannot monitor it, secure its identities, or test failover safely.

Infrastructure as code can improve repeatability by defining networks, policies, compute resources, and monitoring configurations in version-controlled files. It does not automatically make a design recoverable. Secrets, external dependencies, data state, licensing, DNS, certificates, quotas, and provider limits must also be addressed. Recovery automation should use least privilege, approval controls, logging, and tested rollback procedures.

6. Crisis management and incident response

A disaster-recovery plan is only effective when people can coordinate under pressure. Crisis management establishes authority, priorities, communications, and decision-making arrangements. Typical roles include:

• incident or crisis commander: coordinates the response and establishes priorities;
• technical recovery lead: directs restoration of infrastructure and applications;
• security lead: investigates compromise, preserves evidence, and prevents unsafe recovery;
• business service owner: confirms business priorities and accepts degraded operation;
• communications lead: coordinates internal, customer, regulator, and media communications;
• supplier manager: coordinates cloud providers, telecommunications companies, and other vendors;
• scribe or situation manager: maintains the timeline, decisions, actions, and outstanding risks.

The exact names vary, but authority must be clear. A technical team should not restore compromised systems merely to meet an RTO if restoration would reintroduce malware or destroy evidence. Security containment, forensic preservation, legal advice, and business urgency must be balanced.

A crisis process commonly follows these stages:

1. detect and verify the event;
2. classify severity and activate the appropriate plan;
3. protect people, safety, evidence, and critical information;
4. establish a common operating picture;
5. communicate through approved channels;
6. contain the incident and preserve essential services;
7. recover services in business priority order;
8. validate security, data integrity, and functionality;
9. return to normal operations or a stable alternate mode; and
10. conduct a post-incident review and improve controls.

Communication plans should include out-of-band methods because corporate email, identity systems, or collaboration platforms may be unavailable or compromised. Contact lists must be current, and messages should distinguish confirmed facts from assumptions. Unauthorised disclosure during a crisis can create privacy, legal, and reputational harm.

7. Testing and continuous improvement

Plans that have not been tested are assumptions. Testing should progress from low-risk validation to realistic exercises:

• document review: confirms ownership, contacts, dependencies, and accuracy;
• walkthrough or tabletop exercise: participants discuss actions using a scenario;
• technical component test: validates backup restoration, failover, or infrastructure deployment;
• simulation: exercises multiple teams and communications under time pressure;
• full interruption or failover test: moves production or critical operations, subject to risk controls.

A test should have defined objectives, scope, success criteria, observers, safety constraints, and an evidence-collection method. For example, “test disaster recovery” is vague; “restore the customer-order service in the recovery region, recover data to within 15 minutes, validate ten representative transactions, and complete business sign-off within four hours” is measurable.

Useful measures include:

• actual recovery time compared with RTO;
• actual recovered data age compared with RPO;
• percentage of critical dependencies included in testing;
• number and severity of failed steps;
• time to detect and escalate;
• accuracy of contact information;
• restoration integrity and security findings; and
• time required to close corrective actions.

Testing must not create an avoidable outage or expose personal data. Use non-production data where possible, obtain approvals, define abort criteria, and ensure that test credentials and copies are controlled. After-action reviews should identify root causes rather than blame individuals. Plans should be revised when systems, suppliers, threats, regulations, or business priorities change.

8. Governance, responsibility, and regulatory considerations

Cloud continuity follows a shared-responsibility model. The provider may be responsible for physical facilities, core infrastructure, and certain platform controls, while the customer remains responsible for configuration, identities, data protection, application design, recovery objectives, and testing. The exact division depends on the service model and contract.

A provider’s service-level agreement is not a complete disaster-recovery plan. Customers should examine:

• service availability definitions and exclusions;
• provider recovery commitments and service credits;
• data export and portability mechanisms;
• regional and jurisdictional dependencies;
• backup and restoration responsibilities;
• notification and incident-cooperation terms;
• subcontractors and concentration risk;
• audit evidence and assurance reports; and
• termination and exit procedures.

Regulated organisations may need to demonstrate resilience, retention, notification, privacy, records management, or sector-specific continuity controls. Personal data in backups remains personal data. Encryption, key recovery, access logging, retention limits, secure deletion, and cross-border transfer requirements must be addressed. A backup encrypted with a key that is lost during the disaster is not a recoverable backup.

Ethically, recovery decisions should account for affected people, not only financial value. Restoring a profitable service while delaying a safety-critical or accessibility-related service may be unacceptable. Recovery priorities should be transparent, proportionate, and consistent with legal and organisational duties.

9. Contemporary developments and the role of AI

Modern resilience programmes increasingly use immutable storage, confidential computing, policy-as-code, automated compliance checks, multi-region architectures, and continuous control monitoring. Zero-trust principles are relevant to recovery because emergency access must still be authenticated, authorised, logged, and reviewed. Dependency mapping and software bills of materials can help identify recovery implications of vulnerable components.

Artificial intelligence can assist with anomaly detection, event correlation, dependency discovery, exercise generation, and drafting incident communications. However, AI outputs may be incomplete, biased, or confidently wrong. An AI system should not independently decide to destroy data, disable protective controls, or declare a service safe to restore. Human approval, explainable evidence, access restrictions, logging, and tested fallback procedures remain necessary. AI services themselves become dependencies and must be included in continuity analysis.

10. Illustrative case: regional outage and ransomware risk

Background

The following is a fictional illustrative case. Meridian Retail operates an online ordering platform in a public cloud. Its order database is in Region A, with asynchronous replication to Region B. Web servers are deployed across three availability zones in Region A. Daily backups are stored in the same cloud account, and the backup administrator uses the corporate identity platform.

The business has defined an RTO of two hours and an RPO of 15 minutes for orders. However, the recovery plan has never been tested. The deployment pipeline is available only in Region A, and the DNS provider and payment gateway are external dependencies.

Problem

A compromised administrator account is used to encrypt production databases and delete recent snapshots. The attacker also attempts to access the backup account. At the same time, a regional network problem affects some services in Region A. The company discovers that replication has copied corrupted data to Region B. The technical team initially proposes immediate failover.

Analysis

Immediate failover would expose customers to corrupted records and could destroy evidence. The BIA identifies order acceptance, payment confirmation, customer notification, and fulfilment as the highest priorities. The security lead recommends isolating compromised credentials, preserving logs, and validating the last known clean backup. The business owner accepts a temporary read-only catalogue and manual order-confirmation process while the order service is rebuilt.

The review identifies several design weaknesses:

• backup copies were not sufficiently isolated from production;
• replication was treated as backup even though it reproduced corruption;
• the RTO excluded business validation and external dependencies;
• the recovery region lacked an independently tested deployment path;
• emergency access depended on the potentially compromised identity service; and
• no clear authority existed for the decision to fail over.

Approach and solution

The crisis team activates an out-of-band communications channel and separates security containment from recovery. A clean, immutable backup is located in a separate account. Infrastructure is recreated in Region B using version-controlled templates, but secrets are reissued and verified rather than copied from the compromised environment. DNS and payment-gateway procedures are tested, and a limited set of transactions is validated before public traffic is shifted.

After recovery, Meridian implements separate backup administration, delayed point-in-time copies, phishing-resistant privileged authentication, cross-region deployment capability, dependency registers, quarterly restoration tests, and an annual scenario involving both cyberattack and regional failure. It also revises the RTO to include validation and supplier coordination.

Outcome and learning points

The service is restored, but not within the original two-hour target. The organisation avoids making the incident worse by refusing to equate replication with a clean recovery source. The principal learning is that resilience depends on governance and operational practice as much as on cloud architecture. A technically sophisticated design can fail if identities, backups, dependencies, decision rights, and testing are neglected.

Best-practice design checklist

A practical cloud continuity programme should:

1. identify critical business services and their owners;
2. complete a BIA and risk assessment;
3. define RTO, RPO, MTPD, minimum service levels, and assumptions;
4. map applications, data, identities, networks, suppliers, and human dependencies;
5. select backup, replication, and redundancy patterns appropriate to each service;
6. isolate and protect backups, keys, and recovery credentials;
7. document manual workarounds and degraded-service procedures;
8. automate repeatable recovery steps while retaining human approval;
9. establish crisis roles and out-of-band communications;
10. test restoration, failover, data integrity, security, and supplier dependencies;
11. measure actual performance against objectives; and
12. update plans after tests, incidents, architecture changes, and organisational change.

Chapter Summary

Business continuity maintains critical business outcomes during disruption, disaster recovery restores technology and data, and operational resilience combines prevention, absorption, adaptation, response, and learning. Effective planning begins with a business impact analysis and risk-based prioritisation of services and dependencies.

RTO specifies the maximum targeted time to restore an acceptable service, while RPO specifies the maximum targeted age of recovered data. Availability can be measured from agreed service time and unavailable time, but architectural calculations require explicit assumptions about component independence and failure relationships. Backups, replication, and redundancy serve different purposes: replication can reduce data-loss windows, but it can also reproduce corruption; redundancy can reduce interruption, but it does not remove common dependencies.

Cloud recovery patterns range from backup-and-restore to active-active operation. Selection should reflect business objectives, cost, complexity, security, provider dependencies, and the organisation’s ability to operate and test the design. Crisis management requires clear authority, communications, technical and business coordination, evidence preservation, and safe recovery decisions. Testing must be measurable, progressively realistic, and followed by corrective action. Governance must address shared responsibility, privacy, regulation, supplier concentration, portability, and ethical recovery priorities. Resilience is ultimately an organisational capability sustained through architecture, people, process, governance, and continuous learning.

Key Terms

Business continuity: The capability to continue delivering important products or services during and after disruption.

Business impact analysis: A structured analysis of disruption consequences, dependencies, and recovery priorities.

Disaster recovery: The coordinated restoration of technology services, infrastructure, applications, and data after disruption.

Operational resilience: The ability to prevent, withstand, adapt to, and recover from operational disruption.

High availability: The design objective of reducing service interruption through fault tolerance and rapid failover.

Recovery time objective (RTO): The maximum targeted time to restore a service to an acceptable level.

Recovery point objective (RPO): The maximum targeted period of data loss measured backward from disruption.

Maximum tolerable period of disruption (MTPD): The longest acceptable period of service unavailability or degraded operation.

Backup: A separate recoverable copy of data.

Replication: The copying of data or state between systems or locations.

Redundancy: The provision of additional components or paths capable of performing a required function.

Fault domain: A set of resources that may fail together because of a shared dependency.

Failover: The transfer of service operation from a failed primary component or environment to an alternate one.

Runbook: Detailed operational instructions for a defined procedure.

Playbook: A structured response guide for a class of incidents or scenarios.

Crisis management: The coordination of decisions, resources, communications, and priorities during a major disruption.

Immutable backup: A backup protected against alteration or deletion for a defined period.

Tabletop exercise: A discussion-based exercise in which participants work through a scenario.

Shared responsibility: The division of security and operational duties between a cloud provider and its customer.

Review Questions

Short Answer Questions

1. Distinguish business continuity from disaster recovery.
2. What is the difference between RTO and RPO?
3. Why is replication not a complete substitute for backup?
4. State two responsibilities commonly retained by a cloud customer under shared responsibility.
5. What is the purpose of a tabletop exercise?

Long Answer Questions

1. Explain how a business impact analysis supports the design of cloud recovery priorities.
2. Compare backup-and-restore, warm standby, and active-active recovery architectures.
3. Explain why cloud redundancy may fail to provide resilience if common dependencies are ignored.
4. Describe the roles and decision-making requirements of an effective crisis-management structure.
5. Discuss the security, privacy, and governance requirements for protecting cloud backups.

Analytical / Application Questions

1. A service has 43,200 minutes of agreed monthly service time and 50 minutes of unavailability. Calculate its availability and explain whether it meets a 99.9% target.
2. An organisation requires an RPO of 15 minutes but detects replication failure after 25 minutes. Analyse the likely effective data-loss exposure and recommend controls.
3. Design a recovery strategy for a cloud-based payment service with a four-hour RTO, a 15-minute RPO, strict privacy obligations, and a requirement to survive a regional outage. State assumptions, dependencies, tests, and residual risks.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an RTO from an RPO?

A. RTO measures acceptable data age, while RPO measures restoration cost.

B. RTO is the targeted restoration time, while RPO is the targeted maximum data-loss period.

C. RTO is the backup-retention period, while RPO is the service-availability percentage.

D. RTO and RPO are two names for the same recovery measure.

Correct Answer: B. RTO is the targeted restoration time, while RPO is the targeted maximum data-loss period.

Question 2

A service has 43,200 minutes of agreed service time and 45 minutes of unavailability. What is its approximate availability?

A. 99.00%

B. 99.50%

C. 99.90%

D. 99.99%

Correct Answer: C. 99.90%

Question 3

Why should replication not be treated as the only backup mechanism?

A. Replication always prevents failover.

B. Replication can reproduce corruption or malicious changes.

C. Replication cannot copy data between cloud regions.

D. Replication is used only for archived data.

Correct Answer: B. Replication can reproduce corruption or malicious changes.

Question 4

Which recovery pattern normally keeps a minimally running version of core services ready for expansion?

A. Backup and restore

B. Pilot light

C. Offline archive

D. Manual workaround only

Correct Answer: B. Pilot light

Question 5

Which activity most directly validates that a backup can actually be used after an incident?

A. Reviewing the provider’s marketing material

B. Increasing the backup retention period

C. Performing a controlled restoration and data validation

D. Adding more production web servers

Correct Answer: C. Performing a controlled restoration and data validation

Question 6

Which condition is an important assumption in the simple series-availability equation A_system = A₁ × A₂ × … × Aₙ?

A. All components are guaranteed to fail together.

B. The components are treated as independent and all are required.

C. At least one component is optional in every transaction.

D. Availability is measured only during planned maintenance.

Correct Answer: B. The components are treated as independent and all are required.

Question 7

During a suspected ransomware incident, what should generally occur before restoring systems from a recovery environment?

A. Disable all logging to improve performance.

B. Validate containment, preserve evidence, and confirm the recovery source is clean.

C. Replicate the compromised database to every region.

D. Delete all backups to prevent confusion.

Correct Answer: B. Validate containment, preserve evidence, and confirm the recovery source is clean.

Question 8

What is a major purpose of a business impact analysis?

A. To select a cloud provider solely by price

B. To identify disruption consequences, dependencies, and recovery priorities

C. To replace all technical security controls

D. To guarantee that no outage will occur

Correct Answer: B. To identify disruption consequences, dependencies, and recovery priorities

Question 9

Which backup characteristic most directly helps resist ransomware deletion or alteration?

A. Immutability

B. Higher web-server capacity

C. Shorter password length

D. Public accessibility

Correct Answer: A. Immutability

Question 10

Why should recovery testing include external suppliers and dependencies where relevant?

A. A recovered application may still fail if DNS, payment, identity, or network services are unavailable.

B. External suppliers are always responsible for the customer’s entire recovery plan.

C. Testing suppliers eliminates the need for internal runbooks.

D. Supplier testing guarantees a zero-minute RPO.

Correct Answer: A. A recovered application may still fail if DNS, payment, identity, or network services are unavailable.