Cloud, Platforms, and Third-Party Cyber Risk

Introduction

Modern organisations rarely operate entirely within their own data centres. They use infrastructure providers, software-as-a-service (SaaS) applications, managed security services, payment processors, consultants, open-source packages, application programming interfaces (APIs), container registries, and external data-processing partners. This interconnected model creates operational agility, but it also changes cybersecurity management. A security failure may originate outside the organisation while still causing internal data loss, service interruption, regulatory exposure, or reputational damage.

Third-party cyber risk is therefore not simply a procurement issue. It is an enterprise risk involving technology architecture, governance, legal obligations, resilience, privacy, and business continuity. Effective management requires the organisation to understand what it has outsourced, what remains its responsibility, how suppliers depend on other suppliers, and how security evidence will be obtained throughout the relationship.

This chapter examines shared responsibility, cloud and SaaS risks, container and API governance, outsourcing, vendor due diligence, contractual controls, service-level requirements, concentration risk, continuous monitoring, and supply-chain dependencies.

Learning Objectives

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

1. Explain shared-responsibility models in infrastructure, platform, and software services.
2. Assess major risks associated with cloud, SaaS, containers, APIs, and outsourcing.
3. Design a proportionate vendor due-diligence and continuous-monitoring process.
4. Identify security, privacy, resilience, audit, and termination requirements in contracts.
5. Analyse concentration risk and fourth-party supply-chain dependencies.
6. Apply these concepts to a practical third-party risk scenario.

1. The Changing Boundary of Organisational Control

Traditional security models assumed that an organisation owned its servers, networks, applications, and operational processes. Cloud computing replaces this relatively clear boundary with a distributed control model. A customer may control identities, configurations, data, and workloads, while a provider controls physical facilities, hypervisors, hardware, and parts of the operational environment.

The important question is not whether a service is “in the cloud.” The important questions are:

• Which party controls each security function?
• Which party performs it?
• Which party provides evidence that it was performed?
• What happens when the service fails or the contract ends?

Responsibility and accountability are related but different. A provider may be responsible for patching a managed database platform, but the customer remains accountable for choosing secure access controls, classifying data, and configuring network exposure. Outsourcing execution does not automatically outsource legal or managerial accountability.

Service Models and Responsibility

These categories are useful abstractions, not guarantees. A particular provider may offer customer-managed encryption keys, optional logging, or configurable network controls. The contract, technical documentation, and actual configuration must therefore be examined together.

2. Shared Responsibility as a Governance Model

A shared-responsibility model should be expressed as a control matrix rather than a slogan. The matrix identifies controls, owners, evidence, frequency, and escalation arrangements.

A useful governance practice is to map each material control to a named accountable role. “The cloud provider handles security” is not an acceptable control statement because it conceals customer responsibilities such as disabling unused accounts, restricting public storage, rotating credentials, and monitoring unusual access.

Misconfiguration and the Control Plane

Cloud incidents frequently result from errors in the control plane: excessive permissions, publicly exposed storage, unprotected secrets, insecure network rules, disabled logging, or incorrect backup settings. The control plane is especially important because a single administrative action can affect many resources. Strong practices include multifactor authentication, least privilege, separation of duties, policy-as-code, approved infrastructure templates, configuration monitoring, and alerts for high-risk changes.

3. Cloud and SaaS Risk Assessment

Cloud risk assessment begins with business impact and data classification. A payroll system, public website, research repository, and safety-critical operational system should not be assessed identically. Relevant dimensions include confidentiality, integrity, availability, privacy, regulatory significance, recovery requirements, and dependence on the supplier.

Common Cloud Risks

Misconfiguration risk arises when resources are unintentionally exposed or controls are weaker than intended. Examples include public object storage, unrestricted security groups, excessive administrator privileges, and unencrypted backups.

Identity risk includes stolen credentials, weak federation settings, dormant accounts, inadequate privileged-access management, and insecure service accounts.

Availability risk may result from provider outages, regional failures, quota limits, denial-of-service attacks, or dependencies on a single identity, network, or DNS service.

Data-location and legal risk concerns where data is stored, processed, replicated, and accessed. Jurisdictional requirements may apply to personal, financial, health, government, or export-controlled information.

Visibility risk occurs when customers cannot obtain sufficient logs, detect provider-side events, or investigate incidents using evidence that meets legal and forensic needs.

Exit risk occurs when data cannot be exported, systems cannot be rebuilt elsewhere, or contractual termination causes unacceptable interruption.

SaaS-Specific Concerns

SaaS reduces infrastructure-management effort but can increase dependence on the vendor’s application, identity model, release process, and data-handling practices. Due diligence should address:

• tenant isolation and segregation;
• administrative access by vendor personnel;
• encryption in transit and at rest;
• retention, deletion, and backup policies;
• export formats and migration support;
• integration permissions and token management;
• subcontractors and hosting regions;
• security incident notification;
• software-development and vulnerability-management practices.

A SaaS application may be technically secure yet still create business risk if it permits uncontrolled data sharing, lacks adequate retention controls, or cannot support the organisation’s legal discovery obligations.

4. Containers, Platforms, and APIs

Container Security Governance

Containers package application code and dependencies into portable units. They improve consistency and deployment speed, but they do not eliminate security responsibilities. Important control layers include:

1. Source and dependency layer: scan source code and third-party libraries for vulnerabilities and licensing concerns.
2. Image layer: use approved minimal base images, scan images, sign them, and prohibit unauthorised registries.
3. Registry layer: enforce authentication, immutable tags where appropriate, retention rules, and malware or vulnerability scanning.
4. Orchestration layer: restrict administrative access, isolate namespaces, protect secrets, and apply network policies.
5. Runtime layer: monitor processes, privileges, system calls, unexpected outbound connections, and image drift.
6. Operational layer: patch nodes, test recovery, record ownership, and remove abandoned workloads.

Containers are not equivalent to virtual machines. A container may share a host kernel, so a kernel vulnerability or excessive privilege can affect multiple workloads. Running containers as non-root, using read-only filesystems when feasible, dropping unnecessary capabilities, limiting resources, and separating sensitive workloads reduce exposure.

Governance should define who may build images, which registries are trusted, how vulnerabilities are prioritised, and whether emergency exceptions require documented approval. “Latest” tags can create uncertainty because the deployed software may change without a controlled release record; immutable digests provide stronger traceability.

API Security Governance

APIs expose business functions and data to internal systems, partners, mobile applications, and customers. Their security is a lifecycle concern rather than merely an authentication problem. Governance should cover design, documentation, testing, deployment, monitoring, and retirement.

Key controls include:

• strong authentication appropriate to the client and data sensitivity;
• authorisation at the object and function level;
• schema validation and input handling;
• rate limits, quotas, and abuse detection;
• protection against replay and token theft;
• secure secrets and certificate management;
• logging of meaningful security events without unnecessary sensitive data;
• versioning and controlled deprecation;
• inventory of internal, partner, and public APIs.

A common failure is authenticating a user or application but failing to verify whether it is authorised to access a particular record. This is an object-level authorisation failure. API governance must therefore test business rules, not just transport encryption and login mechanisms.

5. Outsourcing and Vendor Due Diligence

Vendor selection should be risk-based. A supplier processing sensitive personal data, operating a critical platform, or holding privileged network access deserves deeper assessment than a supplier providing a low-impact office service.

A Due-Diligence Process

Step 1: Classify the service. Identify data, critical processes, access privileges, geographic scope, recovery needs, and regulatory obligations.

Step 2: Identify inherent risk. Consider the consequences before controls are applied. Factors include sensitivity, concentration, external exposure, dependency, and substitutability.

Step 3: Assess supplier capability. Review governance, security policies, independent assurance, vulnerability management, incident history, personnel controls, resilience, privacy practices, and subcontractors.

Step 4: Validate evidence. A questionnaire is an assertion, not proof. Examine audit reports, penetration-test summaries, certifications, architecture documents, sample policies, test results, and relevant technical demonstrations.

Step 5: Evaluate residual risk. Determine whether identified gaps are acceptable, require remediation, require compensating controls, or justify rejection.

Step 6: Establish monitoring and review. Risk changes when the provider changes ownership, architecture, regions, subcontractors, products, or financial condition.

A mature process distinguishes between control design and control effectiveness. A written incident-response policy demonstrates design; evidence of exercises, response records, and lessons learned provides stronger evidence of effectiveness.

6. Contracts and Service-Level Requirements

Security requirements should be contractual wherever they are material. Policies or marketing statements that can be changed unilaterally may not provide adequate protection.

Important provisions include:

• defined services, systems, data, and responsibilities;
• security standards and minimum controls;
• confidentiality and privacy obligations;
• approved processing locations;
• subcontractor notification, approval, and flow-down duties;
• access restrictions for supplier personnel;
• vulnerability remediation expectations;
• incident notification timeframes and cooperation duties;
• audit and assurance rights;
• logging, evidence preservation, and forensic support;
• backup, recovery, and resilience requirements;
• business continuity and disaster-recovery testing;
• data ownership, return, deletion, and certification of destruction;
• portability formats, transition assistance, and termination support;
• liability, indemnity, insurance, and remedies;
• change-management and material-change notification.

Service-Level Agreements

A service-level agreement (SLA) should measure outcomes that matter to the business. Availability alone is insufficient. The contract may define service availability, response time, recovery time objective (RTO), recovery point objective (RPO), support response, incident notification, and restoration targets.

RTO is the maximum acceptable duration before a service or process is restored after disruption. RPO is the maximum acceptable period of data loss measured in time. For example, an RPO of four hours means that, after a severe failure, the organisation may lose no more than approximately four hours of transactions, subject to the agreed measurement method. RTO and RPO are business requirements; a provider’s advertised capability does not automatically satisfy them.

SLA credits may compensate for poor performance but may not compensate for regulatory penalties, lost trust, or operational harm. Contract negotiation should therefore combine service credits with remediation rights, escalation, audit access, termination rights, and clearly defined evidence.

7. Concentration Risk and Fourth Parties

Concentration risk exists when many critical services depend on the same provider, region, platform, identity service, telecommunications carrier, or software component. A provider can be individually well controlled while still creating systemic exposure because a single failure affects many business processes.

Fourth parties are suppliers used by an organisation’s direct supplier. For example, a SaaS provider may rely on a cloud infrastructure provider, a payment gateway, an identity platform, and an external support company. The customer may have limited contractual visibility into these dependencies.

Assessment should examine:

• common providers supporting multiple critical services;
• shared geographic regions or availability zones;
• common identity, DNS, certificate, or connectivity dependencies;
• proprietary technologies and switching costs;
• alternative suppliers and realistic migration time;
• financial, geopolitical, and operational stability;
• correlated failure scenarios.

Controls may include multi-region design, independent backups, tested alternative providers, offline recovery copies, exit plans, contractual subcontractor transparency, and limits on critical functions sharing one dependency. Multi-cloud is not automatically safer: it can introduce complexity, inconsistent controls, higher cost, and new integration dependencies. Resilience must be demonstrated through testing rather than assumed from architectural diversity.

8. Continuous Monitoring and Metrics

Point-in-time due diligence is inadequate for dynamic cloud services. Continuous monitoring combines automated technical signals, supplier attestations, independent assurance, incident intelligence, and periodic reassessment.

Useful indicators include:

Metrics require interpretation. A low incident count may indicate strong security, under-reporting, or poor detection. A high vulnerability count may reflect excellent scanning and transparent reporting rather than poor overall security. Metrics should therefore be combined with context, trends, severity, business criticality, and evidence quality.

A practical monitoring cycle is: establish a baseline, collect evidence, compare against requirements, investigate exceptions, assign remediation, verify closure, and escalate unacceptable residual risk. Material changes should trigger reassessment rather than waiting for the annual review.

9. Illustrative Case: Northbridge University Research Cloud

Background

Northbridge University uses a SaaS research-management system, a public cloud platform for laboratories, and an external managed security provider. The research system contains personal information and confidential partner data. The cloud platform hosts computational workloads, while the security provider receives logs and can initiate containment actions.

Problem

An assessment discovers that the SaaS contract does not specify deletion certification, the cloud environment has several long-lived administrator accounts, and the managed security provider relies on a subcontracted log-hosting service. All three suppliers advertise strong security certifications, but the university has not mapped responsibilities or fourth-party dependencies.

Analysis

The certifications provide useful assurance but do not prove that the university’s configuration is secure. The SaaS supplier may protect its application while the university remains responsible for user access and data retention. Long-lived administrator accounts create an identity and accountability risk. The log-hosting subcontractor creates a fourth-party dependency and may affect evidence availability during an incident.

The university also identifies concentration risk: the cloud platform and log service depend on the same regional connectivity provider. A regional outage could disrupt both operations and monitoring.

Approach and Solution

The university creates a service-risk register and shared-responsibility matrix. It requires phishing-resistant multifactor authentication for privileged accounts, performs quarterly access reviews, removes dormant accounts, and uses short-lived administrative elevation. It revises the SaaS contract to define retention, export, deletion evidence, incident cooperation, and subcontractor disclosure.

The managed security contract is amended to require log integrity, evidence preservation, service continuity, notification timelines, and flow-down controls for the subcontractor. The university establishes an independent backup for critical security logs and tests an alternative containment procedure if the provider is unavailable. A recovery exercise measures whether critical research services can be restored within the required RTO and with the required RPO.

Outcome

The university reduces excessive privilege, improves evidence availability, and gains visibility into fourth-party dependencies. It does not eliminate all risk; rather, it converts unrecognised dependency into documented, monitored, and tested risk.

Learning Points

1. Certification is evidence, not a complete risk assessment.
2. Customer configuration remains important in managed services.
3. Contracts must address termination, evidence, subcontractors, and incidents.
4. Concentration risk can exist across apparently separate suppliers.
5. Resilience claims require exercises and measurable results.

10. Ethical, Legal, and Governance Considerations

Third-party decisions affect individuals whose data may be processed without direct knowledge of the supplier chain. Organisations should apply data minimisation, purpose limitation, proportional monitoring, and fair access practices. Monitoring supplier personnel or user activity should have a legitimate purpose, appropriate notice, and controlled access to collected information.

Privacy and cybersecurity obligations may arise from national data-protection laws, sectoral regulation, contractual commitments, and records-management requirements. The exact obligations depend on jurisdiction and data type, so legal and privacy specialists should participate in material outsourcing decisions.

Boards and senior managers should receive understandable information about critical dependencies, residual risk, major exceptions, incident readiness, and exit capability. Risk acceptance should be explicit and time-bounded. A supplier cannot be used as a mechanism for avoiding accountability.

Artificial intelligence adds a further supply-chain dimension. Organisations should identify AI services that receive confidential data, determine whether prompts or outputs are retained, examine model and plugin dependencies, validate access controls, and test for data leakage or unsafe automation. AI-enabled services should be governed according to the sensitivity and consequences of their use, not simply their novelty.

11. Best-Practice Implementation Roadmap

A practical implementation sequence is:

1. Inventory suppliers, cloud accounts, SaaS applications, APIs, containers, critical software components, and subcontractors.
2. Classify services by data sensitivity, business criticality, privilege, and substitutability.
3. Build shared-responsibility matrices for material services.
4. Establish minimum security requirements and risk-tiered due diligence.
5. Make security, privacy, resilience, evidence, and exit provisions contractual.
6. Implement strong identity controls, secure configurations, logging, vulnerability management, and approved deployment pipelines.
7. Monitor technical and supplier indicators continuously.
8. Test incident response, recovery, portability, and alternative-provider procedures.
9. Reassess after material changes, incidents, mergers, new subcontractors, or major architecture changes.
10. Report residual risk and overdue remediation to accountable management.

The goal is not to eliminate outsourcing or cloud use. The goal is to make dependencies visible, responsibilities enforceable, and failure survivable.

Chapter Summary

Cloud and third-party cyber risk arise from distributed control and complex dependency chains. Shared-responsibility models clarify which party manages particular controls, but outsourcing execution does not remove customer accountability. Cloud and SaaS assessments must address configuration, identity, data protection, visibility, resilience, jurisdiction, portability, and exit.

Containers require governance across source code, images, registries, orchestration, runtime, and operations. APIs require lifecycle controls, especially object-level authorisation, secure secrets, rate limiting, monitoring, and retirement. Vendor due diligence should be risk-based and should validate both control design and effectiveness.

Contracts and SLAs should specify security, incident cooperation, audit rights, subcontractors, recovery objectives, evidence, portability, and termination support. Concentration and fourth-party risk can create correlated failures even when individual suppliers appear strong. Continuous monitoring, testing, metrics, and explicit risk acceptance transform third-party risk management from an annual questionnaire into an ongoing governance discipline.

Key Terms

Shared responsibility model: A model dividing security duties between a service provider and its customer.

Infrastructure as a Service (IaaS): Cloud provision of computing, storage, and networking infrastructure.

Platform as a Service (PaaS): Cloud provision of managed application platforms and runtimes.

Software as a Service (SaaS): Provider-hosted software accessed by customers over a network.

Control plane: Management layer through which cloud resources, identities, and configurations are administered.

Misconfiguration: An unsafe or unintended setting that weakens security.

Container: A portable package containing application code and dependencies, sharing a host operating-system kernel.

Container registry: Repository used to store and distribute container images.

API: An interface through which software systems exchange functions or data.

Object-level authorisation: Checking whether a requester may access a particular data object or record.

Vendor due diligence: Structured assessment of a supplier’s capability, controls, and risks before or during engagement.

Service-level agreement (SLA): Contractual statement of measurable service and support commitments.

Recovery time objective (RTO): Maximum acceptable time to restore a service or process after disruption.

Recovery point objective (RPO): Maximum acceptable period of data loss measured in time.

Concentration risk: Exposure created by reliance on a common provider, platform, region, or dependency.

Fourth party: A supplier used by an organisation’s direct supplier.

Residual risk: Risk remaining after controls are applied.

Portability: Ability to move data or services to another environment or provider.

Continuous monitoring: Ongoing collection and assessment of technical and supplier-risk evidence.

Review Questions

Short Answer Questions

1. What does a shared-responsibility model explain?
2. Give two examples of cloud misconfiguration risk.
3. Why are container image digests generally more traceable than mutable “latest” tags?
4. What is the difference between RTO and RPO?
5. Define concentration risk in a third-party context.

Long Answer Questions

1. Compare customer responsibilities in IaaS, PaaS, and SaaS.
2. Explain how an organisation should conduct risk-based vendor due diligence.
3. Discuss the security governance requirements of a container platform.
4. Explain why security and resilience requirements should be included in contracts and SLAs.
5. Analyse the relationship between direct suppliers, fourth parties, and supply-chain risk.

Analytical / Application Questions

1. A university stores sensitive research data in a SaaS platform whose provider offers an independent audit report but no deletion certification or export testing. Identify the risks and recommend contractual and technical controls.
2. An organisation uses one cloud region for its website, identity service, logging platform, and backup catalogue. Analyse its concentration risk and propose a tested resilience strategy.
3. A containerised payment application authenticates users successfully but allows any authenticated user to request another customer’s invoice by changing an identifier in the API request. Identify the control failure and design a governance and testing response.

Multiple Choice Questions with Answers

Question 1

Which responsibility most commonly remains with the customer in a SaaS arrangement?

A. Maintaining the provider’s physical data centre

B. Patching the provider’s hypervisor

C. Managing user access and business data governance

D. Replacing failed storage hardware

Correct Answer: C. Managing user access and business data governance

Question 2

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

A. To eliminate the need for contracts

B. To identify control owners, evidence, and accountability

C. To guarantee that outages cannot occur

D. To transfer all legal responsibility to the provider

Correct Answer: B. To identify control owners, evidence, and accountability

Question 3

Which control most directly addresses excessive cloud administrator privilege?

A. Publicly sharing audit reports

B. Short-lived privileged elevation and multifactor authentication

C. Using mutable image tags

D. Disabling security logs

Correct Answer: B. Short-lived privileged elevation and multifactor authentication

Question 4

Why can containers require special security controls compared with virtual machines?

A. Containers never use operating systems

B. Containers always run on separate physical servers

C. Containers may share a host kernel

D. Containers cannot be monitored

Correct Answer: C. Containers may share a host kernel

Question 5

An API verifies that a user is authenticated but does not verify whether the user may access the requested record. What control is missing?

A. Object-level authorisation

B. Disk formatting

C. Physical surveillance

D. DNS registration

Correct Answer: A. Object-level authorisation

Question 6

What does an RPO of four hours specify?

A. The maximum acceptable time to restore service

B. The maximum acceptable period of data loss

C. The maximum password age

D. The maximum incident-notification delay

Correct Answer: B. The maximum acceptable period of data loss

Question 7

Which is the strongest example of fourth-party risk?

A. An employee using a strong password

B. A direct supplier relying on another cloud provider to host customer data

C. A customer reviewing its own firewall rules

D. A provider publishing an uptime dashboard

Correct Answer: B. A direct supplier relying on another cloud provider to host customer data

Question 8

Why is a security certification insufficient as the sole vendor assessment?

A. Certifications are never relevant

B. It may not demonstrate the customer’s configuration or all required controls

C. Certifications always describe only financial performance

D. It prevents contractual enforcement

Correct Answer: B. It may not demonstrate the customer’s configuration or all required controls

Question 9

Which situation best illustrates concentration risk?

A. Two administrators review the same access request

B. Several critical services depend on one identity provider and region

C. A supplier performs quarterly vulnerability scanning

D. A company maintains an independent backup

Correct Answer: B. Several critical services depend on one identity provider and region

Question 10

Which contractual provision most directly supports an orderly supplier exit?

A. A general marketing statement

B. A requirement for data export, deletion evidence, and transition assistance

C. A prohibition on all monitoring

D. An unlimited mutable image tag

Correct Answer: B. A requirement for data export, deletion evidence, and transition assistance