Business Continuity, Resilience and Third-Party Risk

Introduction and Context

Cloud computing has changed the way organisations obtain infrastructure, platforms and software. It has also changed the nature of operational risk. An organisation may no longer own the servers on which its critical processes run, yet it remains accountable to customers, regulators and shareholders when those processes become unavailable. Business continuity in the cloud is therefore not simply a matter of purchasing a highly available service. It requires coordinated decisions about architecture, people, processes, contracts, data, suppliers and recovery capability.

This chapter examines three connected risk domains. Availability risk concerns interruption or degradation of a service. Concentration risk arises when excessive dependence is placed on one provider, region, technology or supplier ecosystem. Supply-chain risk arises when a weakness in a vendor, subcontractor, software component or managed service affects the organisation. These risks must be managed through business impact analysis, recovery objectives, resilient architecture, tested backups, disaster-recovery planning and effective third-party governance.

A useful principle is that cloud providers may operate the underlying service, but the customer remains responsible for determining business criticality, classifying data, configuring controls, validating recovery and ensuring that contractual commitments are adequate.

Learning Objectives

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

• distinguish business continuity, disaster recovery, high availability and cyber resilience;
• evaluate availability, concentration and supply-chain risks;
• establish recovery time objectives (RTOs) and recovery point objectives (RPOs);
• design backup, disaster-recovery and cyber-resilience strategies;
• assess providers using contracts, service-level agreements (SLAs) and assurance reports;
• analyse a cloud-resilience scenario and justify a proportionate response.

1. Core Concepts

Business continuity and resilience

Business continuity management (BCM) is the discipline of preparing for, responding to and recovering from disruptive events while maintaining important products and services. It includes governance, impact analysis, continuity strategies, response plans, communications and exercising.

Disaster recovery (DR) is the subset of continuity management concerned primarily with restoring technology services, data and supporting infrastructure after a disruption. DR is necessary but not sufficient: a technically restored system may still fail if staff, facilities, suppliers, procedures or customer communications are unavailable.

High availability (HA) seeks to reduce the probability and duration of service interruption during normal operation. It commonly uses redundancy across components, zones or regions. HA is primarily a preventive and operational capability.

Resilience is the broader ability of an organisation or system to anticipate, withstand, adapt to, recover from and learn from adverse conditions. Resilience includes failures that are accidental, environmental, malicious or caused by dependencies.

Cyber resilience applies resilience principles to cyber threats. It assumes that prevention will sometimes fail and therefore emphasises identity protection, segmentation, detection, containment, recovery, forensic evidence and learning.

These concepts overlap, but they are not interchangeable. Replicating a database across two availability zones may improve HA; it does not automatically protect against ransomware, a corrupted database, a malicious administrator or a faulty software release replicated to both locations.

Important terminology

• Disruption: an event that interrupts or degrades a product, service or supporting activity.
• Critical service: a service whose disruption could cause unacceptable harm to objectives, people, legal obligations or stakeholders.
• Dependency: a resource or service required for delivery, such as identity, DNS, telecommunications or a payment gateway.
• Recovery tier: a category of recovery capability associated with defined business requirements and cost.
• Failover: transferring operation to an alternate component or location.
• Failback: returning operation to the preferred environment after recovery.
• Immutable backup: a backup protected from alteration or deletion for a defined retention period.
• Assurance report: an independent report describing the design and/or operating effectiveness of controls, such as a SOC 1, SOC 2 or ISO certification statement.

2. Risk Assessment for Cloud Availability

Availability risk

Availability risk can arise from hardware failure, software defects, capacity exhaustion, human error, cyberattack, power or network failure, poor configuration, natural hazards and provider-wide incidents. A cloud service can be technically available while a customer application is unavailable because of an expired certificate, incorrect identity policy, exhausted quota or failed dependency.

Availability analysis should therefore consider the complete service chain:

Figure: A business service depends on multiple technical and third-party failure domains.

Availability is often expressed as a proportion of time during which a service is usable. If downtime is measured over an observation period:

The result may be expressed as a percentage. The calculation assumes that the measurement window, exclusions, maintenance rules and definition of downtime are agreed. A 99.9% monthly availability target allows approximately 43.2 minutes of unavailability in a 30-day month, because 30 × 24 × 60 × 0.001 = 43.2 minutes. This is not necessarily a customer’s actual business availability, because the SLA may exclude scheduled maintenance, customer-caused incidents or dependencies outside the provider’s service boundary.

Availability should be analysed alongside reliability, recoverability, capacity and security. A service that is available but returning incorrect or corrupted data is not resilient.

Concentration risk

Concentration risk exists when many important services depend on the same provider, region, identity platform, network carrier, software framework or specialist supplier. Cloud concentration can produce economies of scale and operational consistency, but it may also create correlated failure. Two applications hosted in different accounts are not independent if both depend on the same provider control plane, DNS service or identity provider.

A practical assessment asks:

1. Which services share a provider, region, availability zone or management plane?
2. Which suppliers are subcontractors to multiple critical providers?
3. Can the organisation operate if the provider account, credentials or control plane are unavailable?
4. What data, skills and tooling would be required to move?
5. Is the proposed alternative genuinely independent, or merely another product in the same failure domain?

Multi-cloud is not automatically resilient. It can increase complexity, skills requirements, egress costs, inconsistent security controls and recovery time. It is justified when the business impact of concentration exceeds these costs and when portability is designed and tested rather than assumed.

Supply-chain risk

A cloud supply chain includes the primary provider, subcontractors, managed security services, software libraries, container images, infrastructure-as-code modules, hardware manufacturers, telecommunications providers and consultants. Risks include compromised updates, vulnerable dependencies, counterfeit or tampered components, supplier insolvency, opaque subcontracting, unauthorised data access and inadequate incident notification.

Useful controls include software bills of materials (SBOMs), signed artefacts, dependency scanning, version pinning, secure build pipelines, least-privilege vendor access, supplier due diligence, vulnerability notification obligations, right-to-audit clauses and tested exit arrangements. Risk should be assessed according to actual service criticality rather than supplier size or brand reputation.

3. Business Impact Analysis and Recovery Objectives

Business impact analysis

A business impact analysis (BIA) identifies important products and services, determines the consequences of disruption over time and establishes recovery priorities. It should involve business owners, technology teams, security, legal, compliance, finance and relevant suppliers.

The BIA should document:

• maximum tolerable period of disruption (MTPD);
• impacts at different interruption durations;
• dependencies and minimum resources;
• legal, regulatory and contractual obligations;
• acceptable data loss;
• manual workarounds;
• recovery order and business owner approval.

RTO and RPO

The recovery time objective (RTO) is the target time within which a service should be restored after disruption. The recovery point objective (RPO) is the maximum tolerable period of data loss measured backward from the disruption. An RPO of 15 minutes means that, under the recovery design, the organisation aims to restore data to a point no more than 15 minutes before the incident; it does not mean that every transaction is guaranteed to be preserved.

RTO and RPO are business requirements, not merely technical settings. They should be feasible, tested and consistent with the MTPD. In general, RTO should be shorter than the MTPD, allowing time for residual degradation after restoration. Recovery objectives also require clarity about whether they apply to a complete service, a database, a user interface or a supporting component.

Recovery strategies

The selected strategy should be based on impact, not on fashionable architecture. A low-criticality archive may use tested backup and restore, while a payment service may require geographically separated active capacity and carefully controlled data replication.

Worked example: setting objectives

An online examination service has an MTPD of four hours. A BIA estimates that disruption costs increase sharply after two hours. The business therefore sets an RTO of two hours and an RPO of 15 minutes. The proposed design takes 45 minutes to activate infrastructure, 30 minutes to validate application integrity and 20 minutes to communicate readiness. The planned recovery time is:

45 + 30 + 20 = 95 minutes.

Because 95 minutes is less than the two-hour RTO, the design has a nominal 25-minute margin. This margin is not proof of compliance: testing must include realistic delays, dependency failures and decision-making. If testing repeatedly produces 130 minutes, the design fails the requirement even if the architecture appears capable on paper.

4. Backup, Disaster Recovery and Cyber Resilience

Backup design

A robust backup programme addresses confidentiality, integrity, availability and recoverability. Important design decisions include:

• Scope: databases, object stores, configuration, keys, identity information, logs and infrastructure definitions;
• frequency: selected to meet the RPO rather than an arbitrary schedule;
• retention: aligned with operational, legal and regulatory requirements;
• separation: copies should be isolated from the production account and credentials;
• immutability: write-once or retention-locked copies reduce ransomware risk;
• geographic diversity: location should address environmental and regional threats;
• encryption: protect data in transit and at rest, with carefully governed key recovery;
• verification: check that backups are complete, readable and internally consistent;
• restoration: perform representative recovery tests, not only backup-success checks.

The familiar “3-2-1” principle—three copies, on two media or storage types, with one copy off-site—is a useful starting point, not a universal rule. Cloud environments may require additional separation from the production identity domain and protection against provider-wide or tenant-wide control-plane compromise.

A backup that cannot be restored is not a recovery capability. Restoration tests should measure elapsed time, data completeness, application consistency, security configuration, dependency availability and business acceptance.

Disaster-recovery architecture

A DR design normally contains:

1. Detection and declaration: monitoring, severity criteria and authority to declare a disaster;
2. Containment: prevent propagation of corruption or attack;
3. Recovery environment: infrastructure, network, identity, secrets and data;
4. Validation: technical tests and business verification;
5. Controlled return: failback only when data integrity and operational readiness are established;
6. Post-incident learning: root-cause analysis, corrective actions and plan updates.

Infrastructure as code can accelerate reconstruction and reduce configuration drift, but it must be version-controlled, reviewed and protected. Secrets should not be embedded in templates. Recovery automation should use separate, strongly protected credentials and should be tested in a manner that does not overwrite production.

Cyber-resilience requirements

Cyber-resilience changes the assumption that the primary environment is trustworthy. Effective designs include phishing-resistant administrator authentication, privileged-access management, separation of duties, network segmentation, central logging, endpoint protection, vulnerability management, tested incident playbooks and clean-room recovery procedures.

Recovery from ransomware requires more than restoring encrypted files. The organisation must determine the initial access vector, eradicate persistence, rotate credentials and keys, validate backup integrity and decide whether restored systems can safely reconnect. Logging and forensic evidence must be preserved without allowing investigation to compromise recovery.

Artificial intelligence can assist anomaly detection, log triage and recovery prioritisation, but it introduces model, data and automation risks. Automated responses require guardrails, human oversight, explainable escalation and testing against adversarial or unusual conditions. AI should not be granted unrestricted authority to delete, isolate or restore critical resources.

5. Third-Party Governance, Contracts and Assurance

Due diligence and risk classification

Supplier assessment should be proportionate to the service. A critical provider assessment may cover ownership, financial stability, locations, personnel screening, security architecture, resilience testing, subcontractors, data use, incident history, regulatory exposure and exit capability. Evidence should be verified rather than accepted as marketing material.

A useful classification considers:

• criticality of the supplied service;
• sensitivity and jurisdiction of data;
• substitutability and portability;
• concentration and systemic dependencies;
• provider access to privileged functions;
• speed and quality of incident notification;
• maturity of independent assurance.

Contract and SLA review

An SLA is only one part of a contract. It typically defines service metrics, measurement methods, exclusions, service credits and reporting. Service credits may compensate for a breach but may not cover business losses or guarantee recovery.

Contracts for important cloud services should address:

• precise service scope and availability measurement;
• RTO, RPO and recovery-testing commitments where appropriate;
• incident notification timeframes and cooperation duties;
• security responsibilities and audit evidence;
• data ownership, use, location, retention and deletion;
• encryption and key-management responsibilities;
• subcontractor approval and flow-down obligations;
• vulnerability disclosure and remediation expectations;
• regulatory cooperation and access to records;
• suspension, termination assistance and data portability;
• exit charges, data export formats and destruction evidence;
• liability, indemnity and insurance provisions.

A provider’s standard SLA may not match the customer’s business requirement. For example, a 99.9% service target does not establish a two-hour RTO, a 15-minute RPO or recovery from malicious deletion.

Assurance reports

Common assurance evidence includes ISO/IEC 27001 certification, SOC 1 reports focused on controls relevant to financial reporting, and SOC 2 reports covering trust-service criteria such as security, availability, processing integrity, confidentiality and privacy. The assessment must examine the report period, scope, locations, system boundaries, exceptions, complementary user-entity controls and the independent practitioner’s opinion.

A clean report does not mean that every customer configuration is secure. Cloud services generally operate under a shared-responsibility model. The provider may secure physical facilities and core infrastructure, while the customer must configure identity, network rules, data protection, logging and workloads. Assurance reports provide evidence about stated controls; they do not replace customer risk assessment or technical testing.

Exit and portability

Exit planning is a resilience control. It should identify data formats, export interfaces, dependent services, licensing constraints, encryption keys, staff skills, alternate providers, migration sequencing and acceptance criteria. An exit plan that has never been tested may fail because of undocumented dependencies, data-transfer time, incompatibility or unavailable credentials.

Portability is multidimensional: data portability, application portability, operational portability and contractual portability. Containers may simplify packaging but do not guarantee portability where applications depend on proprietary databases, identity services, queues or provider-specific APIs.

6. Applied Case: Meridian Payments

The following is an illustrative case, not a report of a real organisation.

Background

Meridian Payments, a regional payment processor, runs customer-facing APIs and transaction processing in one cloud provider’s primary region. It uses a separate managed identity provider, a telecommunications carrier and a third-party fraud-detection API. Its board requires payment processing to resume within two hours and permits no more than five minutes of transaction data loss.

Problem

An assessment finds that the database is replicated across two availability zones, but both zones share the provider’s regional control plane. Backups are stored in the same cloud account, administrators use the same identity service for production and recovery, and the fraud-detection provider has no tested continuity commitment. The SLA promises high availability for individual components but does not promise the business RTO or RPO.

Analysis

The architecture has good local HA but weak regional and dependency resilience. A compromised administrator could delete production and backups. A regional control-plane failure could prevent failover. The external fraud service could block transactions even if Meridian’s application is operating. The stated five-minute RPO also requires transaction replication and reconciliation controls; ordinary daily backups cannot meet it.

Approach and solution

Meridian adopts the following programme:

1. It separates production and recovery accounts and establishes an independently protected emergency identity path.
2. It stores encrypted, immutable backups in a second region with retention lock and performs monthly restoration tests.
3. It deploys a warm standby application and database design in another region, with asynchronous replication targeted at a five-minute RPO.
4. It creates a controlled degraded mode in which low-risk transactions can proceed when the fraud provider is unavailable, subject to limits and later reconciliation.
5. It contracts for incident notification, recovery cooperation, evidence access and tested subcontractor controls.
6. It develops a provider-exit exercise using portable data exports and infrastructure definitions.
7. It tests regional failure, identity failure, corrupted replication, ransomware recovery and loss of the fraud API.

Outcome

A later exercise shows that infrastructure recovery meets the two-hour RTO, but transaction reconciliation takes an additional 50 minutes. Meridian therefore revises the recovery design and business procedure rather than claiming compliance prematurely. It also discovers that its telecommunications carrier is a hidden common dependency and adds a diverse connectivity path.

Learning points

The case demonstrates that zone redundancy is not equivalent to regional resilience; RPO is a data and business property, not simply a backup interval; external dependencies can defeat application recovery; contracts should reflect actual requirements; and exercises reveal operational weaknesses that architecture diagrams conceal.

7. Governance, Regulation and Ethical Considerations

Business continuity decisions can affect safety, privacy, access to essential services and economic fairness. Recovery prioritisation should not favour profitable customers while exposing vulnerable groups to unreasonable harm. Personal data copied to recovery locations remains subject to privacy, retention and cross-border transfer requirements. Encryption-key loss can make a technically available backup unusable, while excessive retention can increase privacy exposure.

Governance should assign accountable owners, approve risk acceptance, maintain a current dependency register, review critical suppliers periodically and report resilience metrics to senior management. Useful metrics include tested versus required RTO, tested versus required RPO, restore success rate, backup coverage, unresolved critical supplier findings, concentration exposure, time to detect, time to contain and time to recover. Metrics must be interpreted carefully: a high backup-success percentage does not prove successful restoration.

Relevant practices may be informed by business-continuity standards such as ISO 22301, security guidance such as ISO/IEC 27001 and recognised cloud and cyber-risk frameworks. Regulatory requirements vary by sector and jurisdiction; organisations should map specific obligations rather than treating a certification as universal compliance.

8. Challenges, Limitations and Best Practices

No continuity strategy eliminates risk. Geographic replication can replicate corrupted or encrypted data. Independent providers may share telecommunications, hardware or software dependencies. Backups create confidentiality obligations. Recovery exercises may be unrealistic if they exclude suppliers, decision-makers or peak transaction volumes. Multi-cloud can produce more failure modes than it removes.

Best practice is therefore evidence-driven and iterative:

• define critical services before selecting technology;
• set RTO and RPO through BIA and business-owner approval;
• map direct and fourth-party dependencies;
• separate recovery from production identities and administration;
• use immutable, encrypted and geographically appropriate backups;
• monitor both provider SLA performance and end-to-end business performance;
• contract for notification, cooperation, assurance, subcontracting and exit;
• test restoration and failover under realistic conditions;
• include cyberattack, corruption, identity loss and supplier failure in exercises;
• record lessons, assign corrective actions and retest after significant change.

Chapter Summary

Cloud continuity is a business responsibility shared across technology, governance and suppliers. High availability reduces ordinary interruptions, whereas disaster recovery restores services after disruption and resilience includes adaptation and learning. Availability risk must be assessed across the full dependency chain, not only within a provider’s infrastructure. Concentration risk results from common providers, regions, control planes and skills; supply-chain risk extends to subcontractors, software and managed services.

A business impact analysis establishes critical services, MTPD, RTO and RPO. Recovery strategies range from backup and restore to active-active operation, with increasing cost and complexity. Effective backups are isolated, encrypted, protected against alteration, verified and restored through testing. Cyber-resilience requires preparation for compromise, including clean recovery, privileged-access protection and evidence preservation.

Contracts, SLAs and assurance reports are important but limited. Their scope, exclusions, complementary customer controls and exit provisions must be examined. A resilient organisation continually tests assumptions, measures recovery performance and improves its design as business dependencies and threats change.

Key Terms

Business continuity management: Management of preparation, response and recovery for disruptive events.

Business impact analysis: Structured assessment of disruption effects, priorities and recovery requirements.

Cyber resilience: Ability to withstand, respond to, recover from and learn from cyber incidents.

Disaster recovery: Restoration of technology, data and supporting infrastructure after disruption.

Failover: Transfer of operations to an alternate component or location.

High availability: Design and operation intended to minimise service interruption.

Immutable backup: Backup protected from alteration or deletion for a defined period.

MTPD: Maximum tolerable period for which a service may be disrupted.

RPO: Maximum tolerable period of data loss measured backward from an incident.

RTO: Target time for restoring a service after disruption.

Supply-chain risk: Risk arising from suppliers, subcontractors, software or service dependencies.

Concentration risk: Risk created by excessive dependence on a common provider, region or technology.

SLA: Contractual statement of service performance, measurement and remedies.

Assurance report: Independent evidence about the design or operation of controls.

Shared responsibility: Allocation of security duties between provider and customer.

Warm standby: Partially prepared recovery environment requiring activation or scaling.

Exit plan: Procedure for transferring services, data and capability away from a supplier.

Software bill of materials: Inventory of components contained in software.

Review Questions

Short Answer Questions

1. Distinguish high availability from disaster recovery.
2. Define RTO and RPO and explain why they are business requirements.
3. What is cloud concentration risk?
4. Why is a successful backup job not proof of recoverability?
5. Name four issues that should be examined in a cloud contract.

Long Answer Questions

1. Explain how a business impact analysis informs cloud recovery architecture.
2. Compare backup-and-restore, warm-standby and active-active strategies, including their limitations.
3. Discuss how cyber resilience changes traditional disaster-recovery assumptions.
4. Explain how assurance reports should be interpreted under the shared-responsibility model.
5. Evaluate the benefits and risks of a multi-cloud strategy.

Analytical / Application Questions

1. A service has an RTO of two hours and an RPO of 15 minutes. Its proposed recovery requires 70 minutes for infrastructure, 35 minutes for validation and 25 minutes for business acceptance. Does the design meet the RTO on paper? What additional evidence is required before approval?
2. An organisation has two applications in separate availability zones, but both use the same identity provider, DNS service and cloud control plane. Analyse its concentration risk and propose three mitigations.
3. A ransomware incident encrypts production data and the most recent backup. Design a recovery sequence that addresses containment, backup integrity, identity, evidence, restoration and business validation.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes RTO from RPO?

A. RTO measures acceptable data loss; RPO measures recovery duration.

B. RTO is the target restoration time; RPO is the acceptable period of data loss.

C. RTO measures provider availability; RPO measures network latency.

D. RTO applies only to backups; RPO applies only to contracts.

Correct Answer: B. RTO is the target restoration time; RPO is the acceptable period of data loss.

Question 2

A 30-day month has a 99.9% availability target. Approximately how much downtime does this represent, assuming the full month is the agreed service time?

A. 4.32 minutes

B. 14.4 minutes

C. 43.2 minutes

D. 432 minutes

Correct Answer: C. 43.2 minutes

Question 3

Which control most directly reduces the risk that ransomware will delete backups?

A. Increasing application CPU capacity

B. Using immutable backups with separated administration

C. Adding a second dashboard

D. Reducing backup retention to one day

Correct Answer: B. Using immutable backups with separated administration

Question 4

Why may two availability zones fail to provide regional resilience?

A. They always use different cloud providers.

B. They may share a regional control plane or other common dependencies.

C. Availability zones cannot replicate data.

D. They cannot support encrypted storage.

Correct Answer: B. They may share a regional control plane or other common dependencies.

Question 5

Which item is most relevant when reviewing an assurance report?

A. The provider’s advertising slogan

B. The report scope, period, exceptions and complementary customer controls

C. The colour of the report cover

D. The number of provider products listed on its website

Correct Answer: B. The report scope, period, exceptions and complementary customer controls

Question 6

A recovery design requires 45 minutes for infrastructure, 30 minutes for validation and 20 minutes for communication. What is the planned recovery time?

A. 75 minutes

B. 85 minutes

C. 95 minutes

D. 105 minutes

Correct Answer: C. 95 minutes

Question 7

Which example best represents supply-chain risk?

A. A user forgets a password

B. A compromised software dependency introduces malicious code into a production build

C. A company changes its office furniture

D. A monitor displays the wrong colour

Correct Answer: B. A compromised software dependency introduces malicious code into a production build

Question 8

What is a principal limitation of a provider SLA?

A. It always guarantees end-to-end business continuity.

B. It may exclude maintenance and customer dependencies and may offer only service credits.

C. It eliminates the need for recovery testing.

D. It automatically establishes the customer’s RPO.

Correct Answer: B. It may exclude maintenance and customer dependencies and may offer only service credits.

Question 9

Which recovery strategy generally provides the fastest restoration but introduces high cost and data-consistency complexity?

A. Unverified archive copies

B. Annual backup restoration

C. Active-active operation

D. Manual spreadsheet processing

Correct Answer: C. Active-active operation

Question 10

What is the primary purpose of an exit plan?

A. To increase dependence on a supplier

B. To define how services and data can be transferred or recovered if a supplier relationship ends

C. To replace all security monitoring

D. To avoid documenting dependencies

Correct Answer: B. To define how services and data can be transferred or recovered if a supplier relationship ends