Third-Party, Supply-Chain and Cloud Risk

Introduction

Modern organisations rarely operate entirely within their own technical boundaries. They depend on cloud platforms, managed security providers, software vendors, telecommunications companies, logistics partners, payment processors, consultants, open-source components and subcontractors. These relationships create efficiency and innovation, but they also extend the organisation’s risk perimeter.

A security failure at a supplier can affect confidentiality, integrity, availability, regulatory compliance and reputation even when the organisation’s own controls remain effective. The 2020 SolarWinds compromise, the exploitation of widely used software libraries, cloud-service outages and ransomware attacks against managed service providers demonstrate that cyber risk is frequently transmitted through commercial and technical dependencies.

Third-party risk management (TPRM) is therefore more than a procurement exercise. It is a lifecycle discipline that connects enterprise risk management, information security, legal contracting, resilience, privacy, architecture, internal audit and incident response. This chapter examines how organisations can identify, assess, contract for, monitor and govern third-party, supply-chain and cloud risk.

Learning Objectives

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

1. Distinguish third-party risk, supply-chain risk, concentration risk and cloud risk.
2. Design a proportionate vendor due-diligence and tiering process.
3. Evaluate contractual security, service-level and incident-management requirements.
4. Analyse software supply-chain exposure, including open-source and build-pipeline risks.
5. Apply the cloud shared-responsibility model to governance and assurance.
6. Interpret assurance evidence such as SOC reports, ISO certifications and penetration-test summaries.
7. Establish continuous monitoring, escalation and third-party incident obligations.
8. Critically evaluate limitations of assurance, scoring models and contractual controls.

1. The Extended Enterprise and Risk Transmission

A third party is an external organisation that provides goods, services, technology, personnel or infrastructure to an organisation. A fourth party is a supplier used by that third party. For example, a hospital may contract with a cloud-hosted patient-record provider, which in turn uses a data-centre operator and an identity-management provider.

Supply-chain risk concerns the possibility that weaknesses in an upstream or downstream dependency will harm the organisation. It includes cyber, operational, financial, geopolitical, quality, legal and continuity risks. Cyber supply-chain risk is not limited to software: hardware components, firmware, managed services, data processors and privileged support channels may all be relevant.

Risk is transmitted through several mechanisms:

• Access dependency: a vendor receives privileged credentials, remote access or API permissions.
• Data dependency: sensitive information is stored, processed or transferred by the vendor.
• Availability dependency: a business process cannot operate during vendor downtime.
• Trust dependency: the organisation relies on the vendor’s identity, code, configuration or security claims.
• Concentration dependency: many services rely on the same cloud, network, software or geographic region.
• Change dependency: supplier updates or configuration changes alter the organisation’s exposure.

A useful governance principle is that outsourcing execution does not outsource accountability. The organisation remains responsible for understanding its reliance, selecting suitable controls, supervising material suppliers and meeting legal and regulatory duties.

2. A Lifecycle Model for Third-Party Risk

A mature TPRM programme follows a lifecycle rather than a one-time questionnaire.

Figure: A lifecycle model for governing third-party relationships.

2.1 Identification and Inventory

The organisation should maintain a central inventory of suppliers, services, owners, data categories, locations, contracts, renewal dates, sub-processors, connectivity and business processes supported. Discovery should include shadow procurement, free SaaS adoption, embedded software and suppliers inherited through mergers or acquisitions.

The inventory should record dependencies rather than merely supplier names. “Cloud provider X” is insufficient if the record does not identify the region, service, identity integration, backup arrangement, critical workload and recovery alternative.

2.2 Inherent Risk and Tiering

Inherent risk is the exposure before considering mitigating controls. Tiering allocates assessment effort according to consequences and dependency. A practical classification is:

Tiering should consider impact, not only spend. A low-cost authentication provider may be more important than a high-value stationery supplier.

A qualitative risk statement can be expressed as:

Likelihood and impact may be ordinal categories rather than precise probabilities. The formula is a prioritisation aid, not a physical law. It assumes that the organisation defines consistent scales and that multiplying categories does not create false precision. Where reliable data exists, expected loss may instead be estimated as:

Here, P(event) is the probability of the event during a defined period and Loss(event) is the monetary or quantified consequence. The units of expected loss are currency or another explicitly defined impact unit. Estimates should include uncertainty and should not be interpreted as guarantees.

2.3 Due Diligence

Due diligence should be risk-based and evidence-led. Common domains include:

• governance, policies and security ownership;
• identity, access control and privileged access;
• vulnerability, patch and secure-development practices;
• encryption, key management and data segregation;
• logging, detection and incident response;
• business continuity, disaster recovery and testing;
• privacy, data residency and sub-processing;
• personnel screening and security awareness;
• physical and environmental safeguards;
• financial viability and geopolitical exposure;
• software provenance, open-source governance and release integrity.

Questionnaires are useful for initial screening but are weak evidence by themselves. A supplier may answer “yes” while applying a control only to part of its service, excluding subcontractors or lacking objective validation. Assessors should request policy extracts, independent reports, test summaries, architecture diagrams, sample recovery results and explanations of exceptions.

The assessment should distinguish:

• design effectiveness: whether a control is suitably designed;
• operating effectiveness: whether it operated consistently over a period;
• residual risk: exposure remaining after controls;
• accepted risk: residual risk formally approved by an accountable authority.

3. Contractual Risk Management

A contract transforms expectations into enforceable obligations. Security requirements should be incorporated into the main agreement, a security schedule, a data-processing agreement and, where relevant, a service-level agreement (SLA). Legal enforceability depends on jurisdiction and drafting; security teams should therefore work with qualified legal counsel.

Important provisions include:

1. Scope and service description: precisely define systems, data, regions and interfaces.
2. Security baseline: require appropriate administrative, technical and physical controls, including least privilege, encryption, secure development and vulnerability management.
3. Access and personnel: control privileged access, remote support, authentication, personnel changes and background screening where lawful.
4. Subcontracting: require disclosure, approval or notification of material subcontractors and flow-down of equivalent obligations.
5. Incident notification: define trigger, deadline, communication channel, minimum content and cooperation duties.
6. Evidence and audit: provide access to relevant assurance reports, remediation information and proportionate audit rights.
7. Data governance: specify ownership, permitted processing, location, retention, deletion, return and legal disclosure procedures.
8. Continuity and recovery: define recovery objectives, testing frequency, dependencies and emergency support.
9. Change management: require notice of material architectural, ownership, location or control changes.
10. Exit and transition: require data portability, deletion evidence, knowledge transfer and assistance with migration.
11. Liability and remedies: align indemnities, service credits, liability caps and insurance with realistic exposure.

Service-Level Requirements

Availability is often expressed as a percentage over a measurement period. If a service has availability A and the measurement period has T minutes, permitted downtime is:

For a 99.9% monthly SLA and a 30-day month, T = 30 × 24 × 60 = 43,200 minutes. Permitted downtime is 43,200 × 0.001 = 43.2 minutes. This calculation assumes that the SLA uses the full calendar month and that exclusions, maintenance windows and measurement methods are defined separately. A high availability percentage does not guarantee rapid recovery, data integrity or acceptable performance.

Other useful service measures include recovery time objective (RTO), recovery point objective (RPO), response time, restoration time, defect-remediation time and incident-notification time. Metrics must define the clock, measurement source, exclusions, reporting frequency and consequences of failure.

4. Software Supply-Chain Security

Software supply-chain risk arises from dependencies among source code, developers, repositories, build systems, package registries, signing services, deployment pipelines and runtime platforms. Attackers may compromise a maintainer, insert malicious code, exploit dependency confusion, steal signing keys or alter build artifacts.

Controls should cover the software lifecycle:

• maintain a software bill of materials (SBOM) identifying components and versions;
• use approved repositories and pin or constrain dependency versions;
• scan dependencies for vulnerabilities and malicious packages;
• verify package signatures, hashes and provenance where supported;
• isolate build systems and protect build credentials;
• apply code review, branch protection and separation of duties;
• use reproducible or attestable builds where practical;
• sign releases and verify signatures during deployment;
• monitor end-of-life components and transitive dependencies;
• test emergency patching and rollback procedures.

An SBOM improves visibility but does not prove that software is safe. It may be incomplete, stale, difficult to interpret or unable to reveal intentionally malicious logic. Vulnerability severity also depends on exploitability, exposure, reachability and compensating controls.

The SLSA framework provides a way to reason about increasing levels of software supply-chain integrity and provenance. NIST guidance on secure software development and software supply-chain risk management, together with standards such as ISO/IEC 27001, can support governance. Organisations should map any framework to actual contractual and technical requirements rather than treating a framework level as a universal security guarantee.

5. Cloud Risk and the Shared-Responsibility Model

Cloud computing changes where controls are implemented, but it does not eliminate responsibility. In a typical infrastructure-as-a-service arrangement, the provider secures physical facilities, core hardware and certain foundational services. The customer remains responsible for identities, configurations, workloads, data and appropriate network controls. Responsibility varies by service model:

These are general patterns, not contractual rules. The provider’s documentation and contract control the actual allocation. Misconfigured storage, excessive permissions, exposed secrets, insecure APIs and weak tenant governance remain frequent customer-side problems.

Cloud assessment should examine:

• account and tenant structure;
• identity federation, privileged roles and conditional access;
• logging, monitoring and retention;
• network segmentation and private connectivity;
• encryption and customer-managed keys;
• backup, recovery and regional resilience;
• configuration baselines and policy-as-code;
• service limits, portability and exit feasibility;
• provider outages, support access and legal jurisdiction;
• sub-processors and data-location controls.

A sound architecture uses defence in depth. It should not assume that the provider will detect every customer misconfiguration or that a provider’s platform certification covers the customer’s implementation.

6. Assurance Reports and Evidence Evaluation

Common assurance sources include ISO/IEC 27001 certification, SOC 1 reports, SOC 2 reports, independent penetration tests, cloud security alliance questionnaires, regulatory assessments and internal audit reports.

A SOC 1 report focuses on controls relevant to financial reporting. A SOC 2 report evaluates controls against Trust Services Criteria, commonly security and potentially availability, processing integrity, confidentiality and privacy. Type I generally addresses design at a point in time; Type II provides evidence of operating effectiveness over a specified period. Neither report automatically proves that every customer requirement is satisfied.

When reviewing an assurance report, ask:

1. What service and locations are within scope?
2. What period does the report cover?
3. Which controls are tested and what exceptions were identified?
4. Are complementary user-entity controls assigned to the customer?
5. Are subservice organisations included or carved out?
6. Are management responses and remediation dates credible?
7. Does the report address the organisation’s actual threat and regulatory context?

Assurance evidence should be triangulated. A current report may be supplemented by contractual commitments, incident history, architecture evidence, vulnerability disclosures and management interviews. Certifications reduce uncertainty; they do not transfer accountability or guarantee future performance.

7. Continuous Monitoring and Metrics

Risk changes after onboarding. Ownership changes, new vulnerabilities appear, subcontractors are added, services migrate between regions and financial stress may reduce a supplier’s ability to operate. Continuous monitoring should combine automated signals with periodic human review.

Possible signals include:

• security ratings and exposure intelligence;
• vulnerability and breach notifications;
• certificate and domain changes;
• service availability and SLA performance;
• changes in ownership, geography or subcontractors;
• expired certifications or overdue reports;
• unresolved audit findings;
• financial and operational distress indicators;
• threat intelligence relevant to the supplier’s technology;
• customer complaints and incident trends.

Metrics should measure risk and control performance rather than activity alone. Examples include the percentage of critical suppliers with current assessments, percentage with tested recovery plans, mean age of high-risk findings, time to notify incidents, number of suppliers without viable exit plans and concentration exposure by provider or region.

Monitoring systems can generate false positives and may rely on incomplete public data. Automated ratings must therefore trigger investigation, not replace professional judgement.

8. Concentration Risk and Resilience

Concentration risk occurs when multiple important services depend on one provider, technology, geography, telecommunications carrier, identity system or specialist supplier. It may be visible at the direct-supplier level but hidden in fourth-party dependencies. For example, several independent SaaS vendors may rely on the same cloud region or identity provider.

Assessment should map critical services to common dependencies and ask:

• What fails if the provider becomes unavailable for 24 hours, one week or permanently?
• Can workloads or data be transferred to another provider?
• Are skills, licences and interfaces available for migration?
• Are backups independent from the primary provider?
• Does geographic diversity actually provide independence?
• Could simultaneous disruption affect multiple suppliers?

Resilience options include multi-region deployment, multi-provider design, offline or independent backups, contractual transition support, tested manual workarounds and alternative suppliers. Redundancy is not automatically resilience: duplicated systems may share the same software, identity provider, network or operational team.

9. Incident Response and Third-Party Obligations

Third-party incidents require coordinated action because the organisation may not control the affected infrastructure or possess complete forensic evidence. Contracts should require prompt notification of suspected or confirmed incidents affecting the organisation, its data or service availability. They should specify a practical deadline, such as “without undue delay and within a defined number of hours,” while recognising that regulatory notification periods may begin before all facts are known.

The supplier should provide:

• incident time line and affected services;
• data types and populations potentially affected;
• indicators of compromise and containment measures;
• forensic preservation and investigative cooperation;
• customer communication support;
• regulator, law-enforcement and insurer coordination;
• remediation and lessons-learned reports.

The customer should maintain an incident playbook covering supplier contacts, escalation paths, contractual rights, legal privilege, evidence handling, public communications, business continuity and alternate processing. Incident response should be exercised with critical suppliers, including scenarios in which the supplier is unable or unwilling to provide timely information.

10. Governance, Ethics and Regulation

Third-party governance must reconcile security with privacy, competition, accessibility, labour rights and proportionality. Excessive monitoring may collect personal information about supplier employees. Background checks and location restrictions must comply with applicable law. Small suppliers may be unable to satisfy large-enterprise questionnaires even when their actual risk is manageable; proportionate evidence is more defensible than arbitrary barriers.

Regulatory expectations increasingly emphasise accountability, resilience, supply-chain visibility, incident reporting and oversight of critical technology providers. Relevant sources may include data-protection law, sectoral outsourcing rules, operational-resilience regimes, national cyber-security legislation and contractual obligations. Requirements vary by jurisdiction; legal and compliance teams should map obligations to the organisation’s locations and services.

Artificial intelligence introduces additional third-party risks. Organisations should identify where vendors use AI to process confidential data, whether prompts and outputs are retained, how models are trained, which subcontractors receive data, and how harmful or inaccurate outputs are managed. AI-generated code also creates provenance, licensing, vulnerability and confidentiality concerns. These risks should be included in procurement, architecture review and secure-development controls.

11. Illustrative Case: A Healthcare Cloud and Software Dependency Failure

Background

A regional healthcare network migrated appointment scheduling and patient messaging to a SaaS provider. The provider hosted its service on a major cloud platform and used an open-source logging library. The healthcare network classified the provider as high risk because it processed personal data and supported a patient-facing service, but it did not identify the logging library or the cloud identity provider as critical dependencies.

Problem

A vulnerability was discovered in the logging library. The SaaS provider initially believed the vulnerable function was not exposed, but later found that a legacy component remained active in one environment. At the same time, the provider’s cloud identity service experienced an outage. The healthcare network could not access the administrative console, while the SaaS provider delayed notification because it had not confirmed patient-data impact.

Analysis

The original due diligence relied heavily on a questionnaire and an annual SOC 2 report. The contract required incident notification but did not define a specific time threshold or minimum information. The recovery plan assumed that administrative access would remain available. No independent export test had been performed, and the organisation had not mapped the common identity dependency.

The residual risks were:

• incomplete software-component visibility;
• excessive reliance on supplier representations;
• weak incident-notification precision;
• concentration in cloud identity services;
• untested data portability and administrative recovery;
• ambiguity about responsibility for vulnerability analysis.

Approach and Solution

The healthcare network required an updated SBOM and vulnerability response process, introduced contractual notification within 24 hours of a credible incident, and required monthly critical-vulnerability reporting. It established a break-glass administrative process, independent backups, quarterly export tests and an alternate communication channel. The supplier was required to disclose material sub-processors and identity dependencies. A joint tabletop exercise tested technical recovery, clinical operations, privacy assessment and public communication.

Outcome

The organisation restored administrative access through the break-glass process, confirmed that patient data had not been exfiltrated, and maintained appointment operations through a manual fallback. The exercise revealed that the fallback could operate for only five days and that a key data export lacked message attachments. These weaknesses were assigned owners and remediation deadlines.

Learning Points

1. A supplier’s certification does not replace service-specific analysis.
2. SBOMs and dependency maps should include transitive and fourth-party relationships.
3. Incident clauses must define time, content and cooperation.
4. Recovery depends on independent access, backups and tested portability.
5. Concentration may exist in identity and communication services, not only hosting.

12. Best-Practice Operating Model

An effective programme generally includes:

• board-approved third-party risk appetite;
• a clearly accountable TPRM owner and business service owners;
• a complete, reconciled supplier and dependency inventory;
• risk-based tiering and assessment depth;
• standard security, privacy, resilience and exit clauses;
• documented exceptions and risk acceptance;
• independent review of critical suppliers;
• continuous monitoring supported by human analysis;
• tested incident, continuity and exit plans;
• reporting that links supplier exposure to business services;
• periodic programme assurance and lessons learned.

The central design principle is proportionality. Critical suppliers deserve deep technical and contractual attention, while low-risk relationships should not create unnecessary administrative burden. The programme must also remain adaptive: a supplier may move from moderate to critical when it receives privileged access, becomes embedded in an essential process or becomes difficult to replace.

Challenges and Limitations

Third-party risk cannot be eliminated. Organisations may lack bargaining power, supplier evidence may be proprietary, assurance reports may be delayed, and subcontracting chains may be opaque. Quantitative risk estimates are uncertain because probability and impact data are incomplete. Security ratings can be inaccurate or biased toward observable external signals. Multi-cloud architectures may increase complexity and create new misconfiguration risks. Contractual rights may be difficult to exercise during a crisis or across jurisdictions.

Consequently, mature governance combines contracts, architecture, monitoring, resilience, professional judgement and executive accountability. No single questionnaire, certification, score or framework is sufficient.

Chapter Summary

Third-party and supply-chain risk arises because organisational services depend on external providers, software components, infrastructure and subcontractors. Effective management begins with a complete dependency inventory and risk-based tiering. Due diligence should examine security, privacy, resilience, software provenance, financial viability and concentration rather than relying solely on questionnaires.

Contracts should define security baselines, access, subcontracting, incident notification, evidence rights, service levels, continuity, data handling and exit assistance. Cloud security follows a shared-responsibility model: providers secure parts of the platform, while customers remain responsible for identities, configuration, workloads and data. Assurance reports are useful but must be interpreted for scope, period, exceptions and complementary customer controls.

Software supply-chain controls include SBOMs, dependency governance, protected build pipelines, provenance, signing and vulnerability response. Continuous monitoring is necessary because supplier risk changes over time. Concentration analysis and tested exit, backup and recovery arrangements strengthen resilience. Finally, incident obligations must support rapid communication, evidence preservation, regulatory coordination and joint response.

Key Terms

Third-party risk: Risk arising from dependence on an external organisation.

Supply-chain risk: Risk transmitted through suppliers, dependencies and subcontractors.

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

TPRM: Third-party risk management across the supplier lifecycle.

Inherent risk: Exposure before considering mitigating controls.

Residual risk: Exposure remaining after controls are applied.

Risk acceptance: Formal approval to retain a known residual risk.

Concentration risk: Excessive dependence on a common provider, technology or location.

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

SLA: Contractual agreement defining measurable service performance.

RTO: Target time for restoring a service after disruption.

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

SBOM: Inventory of software components and dependencies.

Software provenance: Evidence about where software originated and how it was built.

SOC 1: Assurance report concerning controls relevant to financial reporting.

SOC 2: Assurance report addressing specified Trust Services Criteria.

Subservice organisation: External provider used by a service organisation.

Continuous monitoring: Ongoing collection and analysis of risk indicators.

Exit plan: Arrangements for migration, data return, deletion and service termination.

Complementary user-entity control: Control the customer must operate for a provider’s control environment to work as intended.

Review Questions

Short Answer Questions

1. Why is third-party risk management considered a lifecycle discipline?
2. Distinguish inherent risk from residual risk.
3. What is the purpose of an SBOM?
4. Explain the shared-responsibility model in cloud computing.
5. Identify four important contractual incident-response provisions.

Long Answer Questions

1. Explain how an organisation should design a risk-based vendor due-diligence process.
2. Critically evaluate the usefulness and limitations of SOC 2 reports and ISO/IEC 27001 certification.
3. Discuss how software supply-chain attacks can occur across development, build and deployment stages.
4. Analyse the relationship between concentration risk, cloud dependency and operational resilience.
5. Design a contractual and operational framework for managing a critical SaaS provider.

Analytical / Application Questions

1. A payment processor has privileged API access, stores cardholder-related data and relies on two undisclosed subcontractors. Determine its likely risk tier and specify the evidence and contract provisions you would require.
2. An organisation uses five SaaS providers that all depend on one cloud identity platform. Analyse the concentration risk and propose technically feasible mitigations.
3. A supplier reports a vulnerability but cannot confirm whether customer data was accessed. Develop an incident-response decision process covering containment, notification, evidence, regulatory assessment and business continuity.

Multiple Choice Questions with Answers

Question 1

Which activity best represents risk-based vendor tiering?

A. Ranking suppliers only by annual expenditure

B. Classifying suppliers according to impact, access, data and dependency

C. Assigning every supplier the same assessment questionnaire

D. Tiering suppliers according to how long they have been trading

Correct Answer: B. Classifying suppliers according to impact, access, data and dependency

Question 2

A 99.9% availability SLA is applied to a 30-day month of 43,200 minutes. What downtime does the formula permit, before exclusions?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 4,320 minutes

Correct Answer: B. 43.2 minutes

Question 3

Which statement most accurately describes an SBOM?

A. A guarantee that software contains no vulnerabilities

B. A list of software components and dependencies

C. A contract defining cloud service availability

D. A replacement for penetration testing

Correct Answer: B. A list of software components and dependencies

Question 4

In a typical IaaS arrangement, which responsibility generally remains with the customer?

A. Operating the provider’s physical data centre

B. Manufacturing the provider’s servers

C. Managing customer identities and guest operating-system configuration

D. Maintaining the provider’s core virtualisation layer

Correct Answer: C. Managing customer identities and guest operating-system configuration

Question 5

What is a principal limitation of a SOC 2 report?

A. It can never contain evidence about operating effectiveness

B. It automatically covers every customer configuration

C. Its scope, period and complementary customer controls must be examined

D. It is applicable only to physical security

Correct Answer: C. Its scope, period and complementary customer controls must be examined

Question 6

Which contractual provision most directly addresses supplier-chain opacity?

A. A stationery purchasing limit

B. Disclosure and flow-down requirements for material subcontractors

C. A general marketing approval clause

D. A restriction on employee holidays

Correct Answer: B. Disclosure and flow-down requirements for material subcontractors

Question 7

What is concentration risk?

A. The risk that one control has too many owners

B. The risk of excessive dependence on a common provider, technology or location

C. The risk that a password is too long

D. The risk that a contract contains too many pages

Correct Answer: B. The risk of excessive dependence on a common provider, technology or location

Question 8

Which practice most improves software-build integrity?

A. Sharing build credentials among developers

B. Disabling code review for emergency releases

C. Protecting build systems and verifying signed or attested artifacts

D. Accepting packages from any public repository

Correct Answer: C. Protecting build systems and verifying signed or attested artifacts

Question 9

Why should third-party incident clauses define notification content as well as timing?

A. To ensure the supplier provides information needed for assessment and response

B. To eliminate the need for forensic investigation

C. To transfer all legal responsibility to the supplier automatically

D. To guarantee that no service interruption will occur

Correct Answer: A. To ensure the supplier provides information needed for assessment and response

Question 10

Which is the strongest evidence that a supplier’s recovery capability is usable?

A. A supplier’s statement that recovery is possible

B. A marketing brochure describing resilience

C. A successfully tested recovery exercise with documented results

D. A high external security rating alone

Correct Answer: C. A successfully tested recovery exercise with documented results