Cloud, Outsourcing and Third-Party Technology Risk

Introduction and Context

Cloud computing and technology outsourcing have changed the boundary of organisational responsibility. An enterprise may no longer own the data centre, operate the hardware, administer every operating system, or develop every software component on which its services depend. Nevertheless, legal, regulatory and fiduciary obligations usually remain with the organisation that determines the purposes of processing, provides regulated services, or owes duties to customers and shareholders.

This creates a central compliance principle: outsourcing a function does not outsource accountability. A cloud provider may operate infrastructure, but the customer remains responsible for selecting an appropriate service, configuring it correctly, protecting information, monitoring performance and demonstrating compliance.

Third-party technology risk therefore combines information security, procurement, operational resilience, privacy, contract law, business continuity and governance. It is not merely a supplier-management issue. It is a strategic risk-management discipline concerned with concentration risk, dependency, recoverability and the enforceability of contractual protections.

Learning Objectives

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

1. Distinguish cloud service and deployment models and explain their compliance implications.
2. Apply a shared-responsibility model to security, privacy and operational controls.
3. Evaluate vendor contracts covering data residency, subcontractors, audit, resilience and exit.
4. Analyse supply-chain and concentration risks in outsourced technology services.
5. Design a proportionate third-party risk-management and assurance programme.
6. Assess regulatory expectations and ethical issues associated with outsourced processing.

1. Cloud and Outsourcing as Governance Problems

Outsourcing is the use of an external organisation to perform a business or technology activity. Cloud computing is a model for on-demand access to shared computing resources that can be rapidly provisioned and released. Cloud is therefore an operating and delivery model; outsourcing is a sourcing decision. They often overlap, but they are not identical. A private cloud operated internally may not be outsourced, while an externally hosted dedicated platform is outsourced even if it is not highly elastic or shared.

The principal cloud service models are:

Deployment models include public, private, hybrid and community cloud. The label alone does not establish risk. A private cloud can be poorly controlled, and a public cloud can provide strong assurance. Risk depends on architecture, information sensitivity, control design, contractual terms, provider competence and the customer's own configuration.

Criticality and materiality

A provider should be assessed according to the importance of the service, not only its technical features. A supplier supporting payroll may be inconvenient to replace; a supplier supporting payment settlement, emergency healthcare or identity verification may threaten safety, legal compliance and organisational survival if unavailable.

A practical classification considers:

• confidentiality, integrity and availability requirements;
• impact on customers, citizens and essential services;
• regulatory and contractual obligations;
• substitutability and switching time;
• dependency on subcontractors and shared infrastructure;
• geographical and geopolitical exposure; and
• systemic or concentration risk.

The assessment should distinguish inherent risk, before controls, from residual risk, after controls and risk acceptance.

2. The Shared-Responsibility Model

The shared-responsibility model allocates controls between provider and customer. It is not a universal legal rule and must be verified for each service. In IaaS, the customer normally secures guest operating systems and workloads. In SaaS, the provider manages more of the stack, but the customer still controls account administration, data classification, retention, user permissions and lawful use.

Responsibility has at least four layers:

1. Provider obligations: physical security, core infrastructure, service availability, platform security and provider personnel controls.
2. Customer obligations: identity management, secure configuration, data governance, endpoint security and lawful processing.
3. Joint obligations: incident response, vulnerability management, continuity testing, logging and assurance.
4. Contractual obligations: notification, cooperation, audit evidence, deletion, subcontractor controls and remedies.

A frequent failure is confusing a provider's certification with complete compliance. A certificate may cover a defined system, period and control framework; it does not prove that the customer's tenant configuration is secure or that every regulatory duty has been discharged.

Control mapping

A useful practice is to create a responsibility matrix. For every material control, identify the control owner, evidence, frequency, dependency and escalation route. For example, the provider may encrypt storage infrastructure, while the customer chooses whether a sensitive database is encrypted, manages keys, restricts administrative access and validates restoration.

Responsibility should also be mapped to legal roles. Under privacy law, the customer may be a controller or data fiduciary and the provider a processor or service provider. The contract must reflect the actual relationship rather than use a label that obscures decision-making power.

3. Contractual Architecture for Cloud Services

A cloud relationship is usually governed by a master agreement, service order, service-level agreement, data-processing agreement, security schedule, acceptable-use policy and provider policies incorporated by reference. The customer should identify which documents control in case of conflict. A unilateral online policy that can change without notice may undermine negotiated protections.

Essential contractual provisions

Scope and service description. The contract should specify environments, regions, support levels, dependencies, maintenance windows and excluded functions. Ambiguous service descriptions make compliance and performance difficult to test.

Security obligations. Requirements should cover identity and privileged access, encryption, vulnerability management, secure development, logging, personnel screening, physical safeguards and incident response. Controls should be measurable where possible rather than expressed only as broad promises of “industry-standard security.”

Data ownership and use. The provider should receive only the rights necessary to deliver the service. Secondary use, advertising, model training, analytics and disclosure to affiliates require explicit governance. Ownership of customer data, metadata, derived data and backups should be addressed separately.

Confidentiality and privacy. The agreement should identify processing instructions, permitted purposes, retention, assistance with data-subject rights, breach cooperation, international transfers and deletion. It should allocate responsibility for unlawful instructions and provider-caused violations.

Service levels and remedies. Availability commitments should define the measurement point, exclusions, maintenance treatment, credits and escalation. Service credits may be inadequate where an outage causes regulatory breach or major business loss; liability and indemnity provisions should be considered separately.

Audit and assurance. The customer may require independent assurance reports, certifications, penetration-test summaries, control questionnaires, evidence of remediation and regulatory access. Audit rights should include reasonable access to relevant records and personnel, subject to protection of other customers' information. A report that is too generic, too old or outside the relevant service boundary may not be sufficient assurance.

Incident notification. Notification should be tied to a workable trigger, such as confirmed or reasonably suspected unauthorised access, loss, alteration or service compromise. The agreement should state a time limit, communication channels, required content, evidence preservation and cooperation duties. A provider should not wait for perfect forensic certainty where early notification is legally required.

Subcontracting. The provider should disclose material subcontractors, locations and functions; conduct due diligence; impose equivalent obligations; monitor performance; and remain responsible for subcontractor acts. The customer may require notice, objection rights or termination for material changes.

Exit and deletion. Exit clauses should address export formats, assistance, migration periods, cost, continued access, deletion certificates, backups, encryption keys and legal holds. Deletion from production systems is not the same as immediate deletion from immutable backups; the schedule should explain how residual copies are controlled and eventually overwritten.

4. Data Residency, Sovereignty and International Transfers

Data residency means the geographical location where data is stored or processed. Data sovereignty concerns the legal authority and jurisdiction under which data, provider entities and infrastructure may fall. These concepts overlap but are not identical. Data can be stored in one country while support personnel, encryption-key administrators or legal compulsion arise in another.

A residency analysis should map:

• primary data, replicas, caches and backups;
• logs, telemetry and support tickets;
• administrator access locations;
• subcontractor processing locations;
• encryption keys and key-management services; and
• legal transfer mechanisms and government-access risks.

Organisations must distinguish legal requirements from internal preferences. Some rules require local storage; others permit cross-border transfers subject to safeguards, risk assessments, contractual measures or approved mechanisms. A contractual statement that data is “hosted in Europe” may not address remote access from another jurisdiction or provider support tools that copy diagnostic information.

Data minimisation, pseudonymisation, customer-managed keys, regional service configuration and strict support-access controls can reduce exposure, but none automatically eliminates legal transfer obligations. Residency should be tested operationally through architecture, provider documentation and audit evidence rather than accepted solely on the basis of marketing language.

5. Supply-Chain Security and Subcontractor Risk

Modern services are layered chains. A SaaS provider may depend on a cloud infrastructure provider, identity service, content-delivery network, managed database, open-source library and specialist support firm. A security incident in any layer can affect the customer.

Important supply-chain controls include:

• an inventory of direct and material indirect dependencies;
• supplier due diligence proportionate to criticality;
• software bills of materials where relevant;
• signed code, provenance and protected build pipelines;
• vulnerability disclosure and patch expectations;
• segregation of development, test and production environments;
• continuous monitoring of exposed assets and certificates;
• subcontractor approval and flow-down clauses; and
• tested incident and recovery coordination.

Subcontractor approval should not be reduced to a one-time consent. Material change notification, risk reassessment and the right to object are more effective. However, unlimited veto rights may be commercially impractical in highly standardised cloud services. A balanced contract can use categories of approved subcontractors, advance notice, objection based on reasonable security grounds and termination where no mitigation is possible.

Open-source components create a related governance issue. Their availability does not mean they are unsupported or risk-free. Organisations should understand licensing, maintenance, known vulnerabilities, provenance and the ability to replace a critical component.

6. Resilience, Availability and Concentration Risk

Resilience is the ability to prepare for, withstand, respond to and recover from disruptive events while maintaining important services. It is broader than backup. A resilient design considers failure of hardware, software, networks, identity services, personnel, regions, suppliers and management processes.

Useful concepts include:

• Recovery point objective (RPO): maximum tolerable amount of data loss measured in time.
• Recovery time objective (RTO): target time to restore a service after disruption.
• Maximum tolerable period of disruption (MTPD): longest period before disruption causes unacceptable harm.
• Availability: proportion of a defined measurement period during which a service is usable under stated conditions.

A simplistic availability estimate is:

Uptime and downtime must use the same time unit and the contract must define exclusions, measurement methods and maintenance treatment. For example, 43,190 minutes of uptime and 10 minutes of downtime in a 43,200-minute month gives availability of approximately 99.98%. This calculation does not prove that the service met a regulatory resilience requirement, because impact, recovery objectives and excluded failures also matter.

Resilience measures may include multi-zone deployment, regional recovery, independent backups, tested restoration, offline or immutable copies, alternative communications, manual workarounds and documented failover authority. Multi-region deployment does not automatically provide independence if both regions share identity, control-plane, software-release or network dependencies.

Concentration risk arises when many services depend on one provider, region, platform or technology. It may be economical to consolidate, but the organisation should understand correlated failure. Mitigations include portability standards, contractual assistance, secondary providers, diversified critical dependencies, tested exports and realistic exit plans. Multi-cloud is not inherently safer: complexity can increase misconfiguration, inconsistent controls and operational burden.

7. Audit, Assurance and Continuous Monitoring

Assurance should be risk-based and continuous. Common evidence includes independent control reports, certifications, penetration-test summaries, vulnerability metrics, incident records, recovery-test results, access reviews and subcontractor registers.

A useful assurance hierarchy is:

1. provider assertions and questionnaires;
2. independent reports and certifications;
3. customer review of relevant evidence and exceptions;
4. direct audit or technical testing where justified; and
5. regulatory or independent specialist examination.

No single level is universally sufficient. A low-risk office application may be supported by a current independent report and configuration review. A critical payment platform may require direct testing, resilience exercises, regulatory access and executive oversight.

Audit clauses should address notice, scope, frequency, confidentiality, cost, use of specialists, remediation tracking and access during serious incidents. Restrictions intended to protect the provider's other customers should not eliminate meaningful assurance. A customer should also assess its own controls; provider assurance cannot compensate for weak identity governance or unmonitored integrations.

8. Regulatory and Ethical Expectations

Although exact rules vary by jurisdiction and sector, regulators commonly expect organisations to:

• identify and classify important outsourced functions;
• perform due diligence before appointment;
• retain accountable senior oversight;
• maintain written contracts with enforceable protections;
• monitor performance and control effectiveness;
• manage subcontractors and concentration risk;
• notify and manage incidents;
• test continuity and exit arrangements; and
• maintain records sufficient for supervisory examination.

Financial services, healthcare, telecommunications, public-sector and critical-infrastructure organisations may face additional requirements concerning operational resilience, outsourcing registers, audit access, localisation, incident reporting and supervisory approval. Organisations must consult applicable law, sector rules and regulator guidance rather than assume that a generic cloud contract is adequate.

Ethically, outsourcing raises questions beyond compliance. Customers may not understand where their data is processed or how automated systems use it. Low-cost sourcing can transfer risk to workers, communities or vulnerable users. Procurement decisions should consider privacy, fairness, accessibility, environmental impact and the consequences of provider lock-in. Artificial intelligence services deserve particular scrutiny concerning training-data rights, confidential prompts, model outputs, bias, explainability, human oversight and the retention of interaction data.

9. A Practical Third-Party Risk Lifecycle

A mature lifecycle contains six connected stages.

1. Identify and classify. Record the service, data, business owner, criticality, jurisdictions, dependencies and exit difficulty.

2. Assess. Evaluate inherent risks, provider capability, financial and operational stability, legal exposure, security posture and concentration. Identify control gaps and residual risk.

3. Select and contract. Compare providers against requirements; negotiate security, privacy, audit, resilience, subcontractor and exit provisions; obtain appropriate approvals.

4. Onboard securely. Configure identity, logging, encryption, network controls, retention and backup. Validate the provider's stated service boundary.

5. Monitor and test. Review incidents, changes, assurance reports, service levels, access, vulnerabilities, subcontractors and recovery exercises. Reassess when the service, threat or law changes.

6. Exit or renew deliberately. Test data export and restoration, revoke access, migrate dependencies, verify deletion and document lessons. Renewal should be based on current risk, not inertia.

Risk scoring can help prioritise effort, but numerical scores should not create false precision. If a model multiplies impact and likelihood, the scales, definitions, evidence and treatment thresholds must be documented. A high-impact low-likelihood event may still demand action where legal duties or catastrophic consequences are involved.

Applied Case: Meridian Health's Hosted Patient Portal

This is an illustrative case.

Background

Meridian Health, a regional hospital group, proposes a SaaS patient portal hosted by a multinational provider. The portal stores appointment information, secure messages and selected clinical documents. The provider uses a hyperscale infrastructure platform and a support subcontractor in another jurisdiction.

Problem

The procurement team focuses on price and a 99.9% availability commitment. The draft contract permits broad provider use of telemetry, gives only annual audit evidence, allows unrestricted subcontractor changes and provides thirty days for data export after termination. The security team discovers that administrators can use remote support tools and that backups are retained for ninety days.

Analysis

The service is high criticality because confidentiality failures could harm patients and availability failures could obstruct care. The 99.9% figure alone is inadequate: it does not address RTO, RPO, restoration testing, identity dependency or clinical fallback. Cross-border support creates a transfer and access question. Broad telemetry rights may conflict with purpose limitation. The exit period is unrealistic for a large clinical data set and integrated workflows.

Approach and solution

Meridian establishes a responsibility matrix and requires strong multifactor authentication, privileged-access logging, customer-controlled retention settings and encryption-key governance. The contract limits data use to service delivery and expressly excludes model training without written authorisation. It requires notice of material subcontractors, equivalent obligations and continued provider responsibility.

The parties define an incident-notification window, cooperation duties, evidence preservation and regulator support. Meridian receives current independent assurance reports, vulnerability summaries and recovery-test results, with enhanced audit rights for serious concerns. The provider must demonstrate restoration against agreed RTO and RPO values, support export in documented interoperable formats and assist migration for a defined period. Backup deletion is addressed through a schedule rather than an unrealistic promise of instantaneous erasure.

Meridian also retains a read-only emergency process, tests manual clinical procedures and avoids making identity services solely dependent on the same provider. The board risk committee approves residual risks and reviews concentration exposure annually.

Outcome

The project proceeds with a higher initial cost but clearer accountability, stronger patient protections and a credible exit. The organisation treats assurance as an ongoing activity rather than a procurement event.

Learning points

1. Criticality determines the depth of due diligence and contractual protection.
2. Availability percentages do not replace recovery engineering.
3. Subcontractors, support access and telemetry may create hidden processing locations.
4. Exit capability must be designed and tested before the service becomes indispensable.
5. Provider certification is evidence, not a substitute for customer governance.

Challenges and Limitations

Cloud contracts are frequently standardised, creating limited negotiation power, especially for smaller customers. Technical portability may be constrained by proprietary APIs, data models and operational knowledge. Audit rights can be difficult to exercise in multi-tenant environments. Regulations may conflict across jurisdictions, and provider disclosures may change faster than internal risk assessments.

Risk frameworks also have limitations. Questionnaires can become compliance theatre; certifications may omit customer configuration; quantitative scores can hide severe single points of failure; and resilience tests may not reproduce correlated, systemic events. Effective governance therefore combines documentation with technical validation, independent challenge, executive accountability and learning from incidents.

Best-Practice Checklist

• Maintain an inventory of all material technology suppliers and subcontractors.
• Classify services by business impact, data sensitivity and substitutability.
• Map provider, customer and joint responsibilities for every critical control.
• Contract for security, privacy, audit, incident response, resilience and exit.
• Verify actual data, metadata, backup and support locations.
• Monitor configuration, identity, vulnerabilities, service performance and changes.
• Test restoration, failover, manual workarounds and data export.
• Review concentration, financial, geopolitical and fourth-party risks.
• Align procurement, legal, privacy, security, continuity and business owners.
• Reassess risk at renewal and after material changes or incidents.

Chapter Summary

Cloud and outsourcing arrangements create shared operational responsibility but do not transfer organisational accountability. Effective governance begins with criticality, data and dependency classification, followed by a service-specific shared-responsibility matrix. Contracts must address security, privacy, data location, subcontractors, audit, incidents, service levels, resilience, liability and exit. Data residency requires analysis of storage, replicas, logs, support access, keys and legal jurisdiction. Supply-chain risk extends beyond the direct vendor, while concentration risk can make apparently reliable services vulnerable to common failure. Assurance must combine independent evidence, customer configuration review, continuous monitoring and practical testing. Regulatory expectations generally require due diligence, accountable oversight, enforceable contracts, resilience, incident management and credible exit. Strategic cloud governance therefore integrates legal analysis, engineering controls, procurement discipline and ethical responsibility.

Key Terms

Cloud computing: On-demand access to shared computing resources that can be rapidly provisioned and released.

Outsourcing: Use of an external organisation to perform a business or technology activity.

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

IaaS: Cloud model providing virtualised infrastructure resources.

PaaS: Cloud model providing managed application platforms and runtimes.

SaaS: Cloud model providing a complete hosted software application.

Data residency: Physical or geographical location in which data is stored or processed.

Data sovereignty: Legal authority and jurisdiction applicable to data and its processing.

Subcontractor: A third party engaged by a primary provider to perform part of the service.

Fourth-party risk: Risk arising from dependencies below the direct supplier relationship.

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

RPO: Maximum tolerable period of data loss measured in time.

RTO: Target time for restoring a service after disruption.

MTPD: Longest period of disruption before unacceptable harm occurs.

Operational resilience: Ability to prepare for, withstand, respond to and recover from disruption.

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

Exit plan: Documented arrangements for migration, data export, access revocation and deletion.

Residual risk: Risk remaining after controls are implemented.

Supply-chain security: Protection of technology components, suppliers and dependencies throughout their lifecycle.

Review Questions

Short Answer Questions

1. Why does outsourcing not eliminate an organisation's accountability?
2. Distinguish data residency from data sovereignty.
3. What are RPO and RTO?
4. Why is a provider certification not sufficient evidence of customer compliance?
5. Name four matters that should be addressed in a subcontracting clause.

Long Answer Questions

1. Explain the shared-responsibility model across IaaS, PaaS and SaaS, using examples of customer and provider controls.
2. Analyse the contractual provisions required for a critical cloud service.
3. Discuss how data residency, remote support and encryption-key location affect international data governance.
4. Explain the relationship between resilience, concentration risk and exit planning.
5. Design a lifecycle-based third-party technology-risk programme for a regulated organisation.

Analytical / Application Questions

1. A provider offers 99.99% availability but refuses recovery testing and gives no subcontractor notice. Should a critical service accept the offer? Analyse the decision.
2. An enterprise uses one cloud provider for identity, backups, analytics and customer applications. Identify correlated failure scenarios and propose proportionate mitigations.
3. Review a hypothetical SaaS contract that permits unlimited telemetry use, annual assurance only and thirty-day termination export. Identify legal, technical and governance deficiencies and propose amendments.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the shared-responsibility model?

A. The provider is always responsible for all security controls.

B. The customer is always responsible for physical data-centre security.

C. Responsibilities are allocated between provider and customer according to the service and configuration.

D. Responsibility is transferred entirely to the party that owns the data centre.

Correct Answer: C. Responsibilities are allocated between provider and customer according to the service and configuration.

Question 2

Which contract provision most directly addresses provider dependency on external service firms?

A. A marketing and branding clause

B. A subcontractor notification and flow-down clause

C. A general limitation-of-liability clause

D. A product roadmap clause

Correct Answer: B. A subcontractor notification and flow-down clause

Question 3

What does an RPO measure?

A. The target time to restore service

B. The maximum acceptable amount of data loss measured in time

C. The percentage of monthly service availability

D. The duration of a security audit

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 4

A service has 43,190 minutes of uptime and 10 minutes of downtime in a 43,200-minute month. What is its approximate availability?

A. 99.00%

B. 99.50%

C. 99.90%

D. 99.98%

Correct Answer: D. 99.98%

Question 5

Which statement about data residency is most accurate?

A. It concerns only the location of primary production databases.

B. It automatically eliminates all international-transfer issues.

C. It should include replicas, backups, logs and remote support access.

D. It is identical to data ownership.

Correct Answer: C. It should include replicas, backups, logs and remote support access.

Question 6

Which is the strongest example of concentration risk?

A. Using two independent backup formats

B. Depending on one provider for identity, applications and recovery

C. Reviewing a supplier's incident history

D. Maintaining a current asset inventory

Correct Answer: B. Depending on one provider for identity, applications and recovery

Question 7

Why are exit plans tested before termination?

A. To increase provider marketing opportunities

B. To verify that data, integrations and operational capability can realistically be migrated

C. To remove the need for contractual controls

D. To guarantee that no outage can ever occur

Correct Answer: B. To verify that data, integrations and operational capability can realistically be migrated

Question 8

Which evidence is most directly useful for evaluating recovery capability?

A. A provider's advertising brochure

B. A current, relevant recovery-test report and restoration results

C. The provider's brand ranking

D. An unsigned informal email

Correct Answer: B. A current, relevant recovery-test report and restoration results

Question 9

A cloud provider's security certificate primarily demonstrates that:

A. The customer's configuration is automatically secure

B. All regulatory obligations have been discharged

C. Specified controls within a defined scope were assessed against a framework

D. The provider can never experience an incident

Correct Answer: C. Specified controls within a defined scope were assessed against a framework

Question 10

Which approach best reflects proportionate third-party risk management?

A. Apply identical controls to every supplier regardless of importance.

B. Assess criticality, data sensitivity, dependency and substitutability before determining assurance depth.

C. Rely exclusively on supplier questionnaires.

D. Review suppliers only after a breach occurs.

Correct Answer: B. Assess criticality, data sensitivity, dependency and substitutability before determining assurance depth.