Third-Party, Vendor, and Multi-Cloud Risk

Introduction

Cloud computing rarely operates as a single-provider relationship. An organisation may depend on a hyperscale infrastructure provider, a software-as-a-service supplier, a managed security service, a payment gateway, a data-centre operator, and several subcontractors at the same time. Each supplier introduces dependencies, control assumptions, legal obligations, operational risks, and potential failure points.

Third-party risk is therefore not limited to asking whether a provider has secure technology. It concerns whether the provider can reliably deliver agreed services, protect information, meet regulatory duties, disclose material changes, support investigation, and enable an orderly exit. Multi-cloud arrangements add further complexity: they may reduce dependence on one provider, but they can also increase integration, identity, monitoring, skills, and governance challenges.

This chapter presents a practical approach to evaluating cloud providers and suppliers. It covers due diligence, contracts, service-level agreements, assurance reports, concentration and lock-in analysis, continuous monitoring, exit planning, and assessment of shared controls.

Learning Objectives

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

1. Explain why cloud suppliers create strategic, operational, legal, and security risk.
2. Conduct proportionate third-party due diligence.
3. Distinguish contracts, service-level agreements, and security schedules.
4. Interpret assurance reports and identify their limitations.
5. Analyse concentration risk, portability, and vendor lock-in.
6. Design continuous supplier-monitoring activities.
7. Develop an exit and transition plan.
8. Assess shared responsibilities across customers, providers, and subcontractors.
9. Recommend appropriate governance controls for single-cloud and multi-cloud environments.

1. The Nature of Cloud-Supplier Risk

A cloud service is delivered through a chain of relationships. A customer may contract directly with a cloud provider, while the provider relies on telecommunications companies, hardware manufacturers, identity services, support partners, colocation facilities, and subcontracted processors. The customer’s risk is affected by this entire service chain, even when those organisations are not visible in the customer’s portal.

Supplier risk can be grouped into several categories:

Risk should be evaluated in relation to the service’s importance. A supplier hosting a public information website does not normally require the same scrutiny as a supplier processing health records, payment data, or critical operational workloads.

A useful principle is proportionality: the depth of assessment should reflect information sensitivity, business criticality, regulatory exposure, dependency duration, and the realistic consequences of failure.

2. Governance and Accountability

Supplier governance begins before procurement. Business owners, security teams, legal advisers, privacy officers, procurement staff, enterprise architects, and continuity managers should agree on minimum requirements. Procurement should not select a supplier solely on price or technical functionality.

A typical governance structure includes:

• Business owner: defines service outcomes and accepts business risk.
• Procurement: manages commercial competition, pricing, and supplier records.
• Information security: evaluates technical and organisational safeguards.
• Privacy or data-protection function: assesses personal-data processing and transfers.
• Legal counsel: negotiates liability, jurisdiction, intellectual property, and termination terms.
• Architecture and operations: assess integration, resilience, portability, and supportability.
• Risk committee: approves exceptions and monitors material residual risk.

The board or senior management remains accountable for organisational risk. Outsourcing a service does not outsource accountability. A provider may operate a control, but the customer must still determine whether that control is sufficient for its obligations.

3. Third-Party Due Diligence

Due diligence is the structured investigation of a supplier before entering or materially changing a relationship. It should produce evidence, not merely assurances.

3.1 Scoping the assessment

The assessment should first identify:

• What data will be processed?
• Where will data be stored, transmitted, and backed up?
• Which business processes depend on the service?
• What availability and recovery objectives apply?
• Which regulations and contractual obligations are relevant?
• What administrative access will the provider have?
• Which subcontractors are involved?
• How easily could the service be replaced?

A data-flow diagram and dependency map are useful. The assessment should distinguish direct provider controls from controls the customer must configure.

3.2 Evidence sources

Common evidence includes security policies, independent assurance reports, penetration-test summaries, certifications, incident statistics, resilience test results, privacy documentation, business-continuity plans, financial information, data-location lists, and subcontractor registers.

Evidence must be evaluated for scope, date, independence, exceptions, and relevance. A certificate may confirm that a management system was assessed against a standard, but it does not prove that every customer configuration is secure.

3.3 Due-diligence questions

A practical questionnaire may address:

1. Governance: Who owns security and how is it reported?
2. Identity: How are privileged accounts protected, reviewed, and logged?
3. Data protection: What encryption, key-management, retention, and deletion controls exist?
4. Infrastructure: How are tenants isolated and infrastructure changes controlled?
5. Operations: How are vulnerabilities, patches, incidents, and capacity managed?
6. Resilience: What redundancy, backup, recovery, and testing arrangements exist?
7. Personnel: Are staff screened, trained, and subject to confidentiality obligations?
8. Subcontractors: Who can access or affect the service, and how are they governed?
9. Transparency: What notification is provided for incidents, changes, and assurance findings?
10. Exit: Can data and configuration be exported in usable formats within an agreed period?

Questionnaires are useful for consistency but should not replace interviews, technical validation, and contractual safeguards.

4. Contracts and Service-Level Agreements

A master services agreement establishes the legal relationship. A statement of work or service description defines what is being purchased. A security or data-processing schedule defines security, privacy, and compliance duties. A service-level agreement (SLA) specifies measurable service commitments and remedies.

Important contractual subjects include:

• permitted use and service scope;
• confidentiality and information classification;
• data ownership and use restrictions;
• processing instructions and privacy obligations;
• data location and cross-border transfer mechanisms;
• encryption and key-management responsibilities;
• access control and personnel requirements;
• incident notification and cooperation;
• vulnerability disclosure and remediation expectations;
• audit, inspection, and evidence rights;
• subcontractor approval and flow-down obligations;
• backup, retention, and secure deletion;
• business continuity and disaster recovery;
• change notification and termination rights;
• intellectual property and assistance with transition;
• liability, indemnity, insurance, and regulatory cooperation.

SLAs and meaningful measurement

An SLA should measure outcomes that matter to the customer. Availability is often expressed as a percentage of agreed service time. If a service is available for 43,200 minutes in a 30-day month and the agreed availability is 99.9%, the permitted unavailability is:

This calculation assumes a 30-day month, continuous service measurement, and no exclusions. Actual contracts may exclude scheduled maintenance, force majeure, customer-caused failures, or dependent services. Therefore, an advertised percentage is not meaningful unless the measurement window, exclusions, service credits, and reporting method are defined.

Other SLA measures may include response time, restoration time, support severity, backup success, recovery-point objective (RPO), and recovery-time objective (RTO). Service credits are usually compensation mechanisms, not a substitute for resilience. A credit may be commercially useful, but it does not restore lost data, reputation, or public trust.

5. Assurance Reports and Certifications

Assurance reports provide independent evidence about a provider’s controls. Common examples include reports based on control-attestation frameworks, information-security management standards, cloud-control frameworks, and privacy standards. Their value depends on what was assessed and how.

A professional review should ask:

• Is the report current for the service being purchased?
• Does its scope include the relevant region, product, and environment?
• Is it a design assessment or an operating-effectiveness assessment?
• What period does it cover?
• Were there exceptions or qualified conclusions?
• Which controls are identified as customer responsibilities?
• Are complementary user-entity controls clearly stated?
• Does the report cover subcontractors through a suitable method?

A report is evidence, not a guarantee. A provider can have effective platform controls while a customer misconfigures storage, exposes credentials, or grants excessive privileges. The customer must map provider controls to its own risk assessment and configuration responsibilities.

6. Shared Responsibility and Shared Controls

Cloud security is a distributed-control problem. In an infrastructure service, the provider generally manages physical facilities, hardware, and core infrastructure, while the customer manages operating systems, identities, applications, data, and configuration. In a software service, the provider manages more layers, but customers still control users, data governance, access settings, and business processes.

The exact boundary varies by service model and provider. It should be documented in a responsibility matrix rather than assumed.

Shared controls require named owners, evidence requirements, test frequency, and escalation routes. “The provider handles security” is not a control assignment.

7. Concentration Risk and Multi-Cloud Strategy

Concentration risk occurs when many important services, applications, data sets, or suppliers depend on the same provider, region, network, identity system, or technology. A provider can be highly reliable and still create systemic exposure if a single failure affects the whole organisation.

Multi-cloud can reduce some concentration risks by distributing workloads across providers. However, it can also create:

• inconsistent identity and policy models;
• duplicated monitoring and compliance processes;
• greater network and data-transfer cost;
• more complex incident response;
• skills shortages and operational error;
• inconsistent security configurations;
• difficult portability between incompatible services;
• increased dependence on common upstream suppliers.

Multi-cloud is not automatically more secure or resilient. It is beneficial only when the added complexity is justified by business requirements and the organisation can operate the design effectively.

A concentration review should examine provider, region, service, identity, network, personnel, subcontractor, and data dependencies. For each critical workload, ask whether a common failure could affect both the primary and supposedly independent recovery environment.

8. Lock-In and Portability

Vendor lock-in is the condition in which changing suppliers becomes technically, financially, legally, or operationally difficult. Lock-in may arise from proprietary APIs, specialised databases, platform-native identity, unique managed services, data-egress charges, long contract terms, scarce skills, or accumulated operational knowledge.

Lock-in is not always undesirable. A proprietary service may deliver valuable functionality, performance, or security. The important issue is whether lock-in is deliberate, understood, priced, and governed.

Portability analysis should consider:

• data format and export completeness;
• metadata, permissions, logs, and audit history;
• application dependencies and interfaces;
• infrastructure-as-code portability;
• encryption keys and secrets;
• network addressing and DNS changes;
• identity and access-policy translation;
• service performance after migration;
• migration tooling and testing;
• contractual assistance and cost.

A practical portability exercise exports a representative data set, deploys a small workload in a target environment, validates integrity and functionality, and records the time, skills, and cost required. A theoretical statement that data “can be exported” is weaker than a tested migration procedure.

9. Continuous Monitoring

Supplier risk changes after contract signature. Providers release new products, acquire companies, change subprocessors, suffer incidents, alter pricing, and modify service architectures. Continuous monitoring should therefore combine scheduled reviews with event-driven reassessment.

Monitoring activities may include:

• reviewing assurance reports and certifications;
• tracking incidents, vulnerabilities, and regulatory actions;
• monitoring service health and SLA performance;
• reviewing subcontractor and data-location changes;
• testing access and configuration controls;
• validating backup and recovery evidence;
• checking financial and operational indicators;
• reviewing changes to terms, APIs, and pricing;
• conducting annual or risk-based reassessments;
• testing notification and escalation procedures.

Useful indicators include unresolved high-risk findings, repeated SLA breaches, delayed incident notifications, loss of certification, increased concentration, unsupported technologies, and inability to produce evidence. Thresholds should trigger action rather than merely generate reports.

Monitoring must also be risk-based. A critical provider may require monthly service review and quarterly risk reporting, while a low-impact supplier may receive an annual review.

10. Exit Planning and Transition

Exit planning should begin during procurement. It is a resilience control, not an admission that the relationship will fail. Triggers may include persistent service failure, regulatory change, insolvency, security concerns, strategic realignment, unacceptable price increases, or termination of the service.

An exit plan should identify:

1. decision authority and exit triggers;
2. target provider or replacement architecture;
3. data, metadata, logs, keys, and configuration to be transferred;
4. migration sequence and validation criteria;
5. dependencies that must remain available during transition;
6. staff, tools, budget, and specialist support;
7. communication to users, regulators, and business partners;
8. retention and secure deletion requirements;
9. continued support and access during the transition;
10. evidence that the old environment has been decommissioned.

A transition should preserve confidentiality, integrity, availability, and evidential records. Data should be reconciled after transfer, access rights should be recreated deliberately rather than copied blindly, and old credentials should be revoked only after dependencies are removed. Exit clauses should address assistance, export format, notice periods, fees, deletion certificates, and survival of confidentiality obligations.

11. Illustrative Case: A Retailer’s Multi-Cloud Decision

Background

A medium-sized online retailer uses one cloud provider for its website, inventory system, analytics, and identity service. A second provider hosts backups. The retailer believes this arrangement eliminates concentration risk.

Problem

A regional outage affects the primary provider. The retailer discovers that its backup environment depends on the primary provider’s identity federation, network address management, and monitoring platform. The backup data is available, but staff cannot authenticate to the recovery environment quickly. The retailer also learns that application data uses a proprietary database service that cannot be restored directly elsewhere.

Analysis

The retailer has diversified providers but not dependencies. Its effective concentration remains high because identity, operational access, database technology, and recovery procedures share a common foundation. The organisation performed supplier due diligence but did not test a complete provider-independent recovery scenario.

Approach and solution

The retailer establishes a dependency register and maps critical control paths. It introduces an emergency identity method protected by strong controls, exports critical data in an open format, and designs a recovery environment using more portable database technology for selected workloads. It negotiates contractual support for data extraction and incident cooperation. Twice each year, it performs a controlled recovery exercise that measures restoration time, data completeness, access, monitoring, and business validation.

The retailer retains proprietary services where their benefits justify the risk, but records the lock-in decision and maintains a tested transition path for the most critical systems.

Outcome

The organisation does not remove all risk, nor does it require every workload to run on two providers. Instead, it reduces hidden common dependencies, improves recovery evidence, and makes portability a conscious business decision.

Learning points

• Two providers do not guarantee independence.
• Identity and management-plane dependencies can be as important as data location.
• Recovery must be tested end to end.
• Portability should be assessed by workload, not through a single organisation-wide label.
• A documented exception can be acceptable when supported by compensating controls and senior approval.

12. Practical Evaluation Framework

A diploma-level assessment can use the following sequence:

1. Classify the service: identify data, criticality, regulations, and users.
2. Map dependencies: include providers, subcontractors, regions, identity, networks, and recovery services.
3. Assess inherent risk: consider impact before supplier controls are applied.
4. Review evidence: examine reports, tests, policies, financial information, and references.
5. Evaluate shared responsibilities: assign every important control to a named party.
6. Negotiate safeguards: address security, privacy, resilience, audit, notification, and exit.
7. Assess concentration and lock-in: identify common failure points and migration barriers.
8. Approve residual risk: document gaps, compensating controls, owner, and review date.
9. Monitor continuously: use indicators, reviews, and event-driven reassessment.
10. Test exit and recovery: demonstrate that critical services can be restored or transferred.

This process should be integrated with enterprise risk management, architecture review, procurement, business continuity, privacy impact assessment, and incident response.

13. Challenges, Ethics, and Regulatory Considerations

Customers often have limited negotiating power with large providers. Standard terms may restrict audit rights, limit liability, permit broad subcontracting, or change without meaningful consultation. Organisations should distinguish negotiable terms from unacceptable exposures and apply compensating controls where negotiation fails.

Privacy and data-protection obligations may require a clear processing purpose, lawful basis, data-subject safeguards, breach notification, retention control, and lawful international-transfer mechanism. Sector regulations may require operational resilience, records retention, location controls, or regulator access.

Ethically, supplier selection should consider surveillance, labour practices, environmental impact, accessibility, and responsible use of data. A technically secure supplier may still create unacceptable social or governance risks. Artificial intelligence services require additional scrutiny concerning training-data use, confidentiality, model outputs, logging, bias, intellectual property, and the ability to remove customer data from future processing.

No assurance framework eliminates judgement. Reports can be incomplete, controls can fail between assessments, and contractual promises can be difficult to enforce after a major incident. Good governance combines evidence, technical testing, contractual clarity, operational competence, and informed leadership.

Best-Practice Checklist

• Classify information and service criticality before procurement.
• Maintain a current supplier and subcontractor inventory.
• Require evidence proportionate to risk.
• Read assurance reports, including exceptions and customer responsibilities.
• Define shared controls in a responsibility matrix.
• Contract for notification, cooperation, audit evidence, and secure deletion.
• Measure SLAs using clear definitions and exclusions.
• Identify common dependencies across supposedly separate providers.
• Record proprietary technology and migration barriers.
• Test data export, recovery, and provider-independent access.
• Monitor financial, operational, security, legal, and concentration indicators.
• Review material changes rather than waiting for the annual assessment.
• Treat service credits as remedies, not resilience.
• Approve and periodically review residual risk.

Chapter Summary

Cloud supplier risk extends beyond the security of a provider’s infrastructure. It includes strategic dependence, shared-control failures, subcontractors, legal exposure, concentration, lock-in, service disruption, and inability to exit. Effective evaluation begins with proportionate due diligence and continues through contracts, assurance review, technical validation, continuous monitoring, and tested transition planning.

Contracts and SLAs should define measurable outcomes, responsibilities, evidence, incident cooperation, resilience, and exit assistance. Assurance reports are valuable but must be interpreted for scope, period, exceptions, and customer responsibilities. Multi-cloud may reduce some dependencies, but it can introduce operational complexity and may fail to remove common identity, network, personnel, or subcontractor risks.

The central governance principle is that outsourcing delivery does not outsource accountability. Organisations must understand which controls are operated by providers, which remain their own responsibility, and how they will respond if a supplier becomes unavailable, unsuitable, or impossible to replace.

Key Terms

Assurance report: Independent evidence about the design or operation of a provider’s controls.

Concentration risk: Exposure created by dependence on one provider, region, technology, or common dependency.

Complementary user-entity control: A control that the customer must operate for a provider’s control objectives to be effective.

Due diligence: Investigation of a supplier’s capability, controls, financial position, and risks before or during engagement.

Exit plan: A documented method for terminating or transferring a service safely.

Lock-in: Difficulty changing suppliers because of technical, financial, legal, or operational barriers.

Multi-cloud: Use of services from two or more cloud providers.

Portability: Ability to move data, applications, configurations, or services to another environment.

Residual risk: Risk remaining after controls and treatments are applied.

Recovery-point objective (RPO): Maximum tolerable amount of data loss measured in time.

Recovery-time objective (RTO): Target time within which a service or process should be restored.

Service-level agreement (SLA): Contractual agreement defining measurable service commitments and remedies.

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

Subcontractor: A supplier engaged by the primary provider to support delivery of the service.

Supplier concentration: Dependence on a limited number of suppliers or common upstream services.

Third-party risk: Risk arising from an external organisation that provides a product, service, or dependency.

Vendor risk management: Governance process for identifying, assessing, treating, and monitoring supplier risk.

Workload portability: Ability to move a particular application or workload between environments with acceptable effort and performance.

Review Questions

Short Answer Questions

1. Why does outsourcing a cloud service not outsource organisational accountability?
2. What is the difference between an SLA and a security schedule?
3. Name four categories of evidence that may be requested during supplier due diligence.
4. What is vendor lock-in, and how can proprietary APIs contribute to it?
5. Why can a multi-cloud design still contain concentration risk?

Long Answer Questions

1. Explain how an organisation should evaluate a cloud provider before signing a contract.
2. Discuss the strengths and limitations of assurance reports and certifications.
3. Describe the major contractual provisions required for a critical cloud service.
4. Explain how shared responsibility changes across infrastructure, platform, and software cloud services.
5. Discuss the components of an effective cloud-service exit plan.

Analytical / Application Questions

1. A provider promises 99.95% monthly availability. Explain why the percentage alone is insufficient for procurement, and identify contractual questions that should be asked.
2. An organisation uses two cloud providers, but both recovery environments depend on the same identity provider and telecommunications carrier. Analyse the concentration risk and propose controls.
3. A supplier refuses customer audits but provides an independent assurance report with customer-responsibility clauses. Decide whether the supplier can be accepted and specify the additional evidence or compensating controls required.

Multiple Choice Questions with Answers

Question 1

Which statement best describes third-party cloud risk?

A. It concerns only the provider’s physical data centres.

B. It includes security, availability, legal, operational, and dependency risks.

C. It exists only when a provider has experienced a breach.

D. It can be eliminated by purchasing a higher service tier.

Correct Answer: B. It includes security, availability, legal, operational, and dependency risks.

Question 2

What is the primary purpose of a shared-responsibility matrix?

A. To allocate cloud subscription costs between departments.

B. To identify which provider and customer controls must be operated.

C. To calculate monthly service credits.

D. To replace the cloud contract.

Correct Answer: B. To identify which provider and customer controls must be operated.

Question 3

A 30-day month contains 43,200 minutes. At 99.9% availability, what downtime is permitted, assuming no exclusions?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 4,320 minutes

Correct Answer: B. 43.2 minutes

Question 4

Which limitation is most important when interpreting an assurance report?

A. It always excludes all technical controls.

B. It proves that every customer configuration is secure.

C. Its scope, period, exceptions, and customer responsibilities must be examined.

D. It is relevant only to financial accounting.

Correct Answer: C. Its scope, period, exceptions, and customer responsibilities must be examined.

Question 5

Which situation is an example of concentration risk?

A. Using multiple independent backup formats.

B. Depending on one identity service for all production and recovery access.

C. Testing recovery twice each year.

D. Using separate administrators for development and production.

Correct Answer: B. Depending on one identity service for all production and recovery access.

Question 6

Which activity provides the strongest evidence of portability?

A. Reading a provider’s marketing statement.

B. Receiving a verbal promise from an account manager.

C. Successfully exporting and restoring a representative workload in a target environment.

D. Buying additional storage capacity.

Correct Answer: C. Successfully exporting and restoring a representative workload in a target environment.

Question 7

Which item should normally be included in an exit plan?

A. A ban on all future supplier assessments.

B. Data export, validation, transition support, and secure deletion.

C. Removal of all monitoring before migration begins.

D. Automatic copying of every old access permission.

Correct Answer: B. Data export, validation, transition support, and secure deletion.

Question 8

Why are service credits insufficient as the only resilience control?

A. They prevent providers from measuring availability.

B. They compensate for some contractual failure but do not restore data or reputation.

C. They always exceed the cost of an outage.

D. They eliminate the need for incident response.

Correct Answer: B. They compensate for some contractual failure but do not restore data or reputation.

Question 9

Which event should trigger an event-driven supplier reassessment?

A. A routine internal staff meeting.

B. A material change in subcontractors or data location.

C. A successful password change by a user.

D. The publication of an unrelated industry article.

Correct Answer: B. A material change in subcontractors or data location.

Question 10

What is a key risk of assuming that two cloud providers are fully independent?

A. Independent providers cannot offer encryption.

B. They may share common identity, network, personnel, or upstream dependencies.

C. They must use identical contracts.

D. They cannot support recovery testing.

Correct Answer: B. They may share common identity, network, personnel, or upstream dependencies.