FRM Exam Part II · Case Study: Third-party Risk Management
Concentration, Fourth-Party and Cloud Risk Explained
Updated 11 October 2026 · Fact-checked
Concentration risk is the danger of relying on one or a few providers, so one failure hits many functions or firms. Fourth-party risk comes from your provider's own subcontractors. Cloud risk combines both. Solve questions by finding the dependency, the failure point, the impact and the control, such as exit plans and diversification.
Understand Concentration, Fourth-Party and Cloud Risk
A third party is a provider you contract with directly, such as a cloud host, payments processor or data vendor. You hold the contract, so you can set service levels, audit rights and exit terms.
A fourth party is a subcontractor your third party uses to deliver your service. You usually have no contract with it. The risk is lower visibility and weaker control. A cloud-based vendor may itself run on a large cloud platform, and you may never see that link unless you ask.
Concentration risk has two levels. Firm-level: your bank depends on one provider for many critical services, so a single outage stops several business lines. Sector-level: many banks depend on the same few cloud providers, so one failure hits many firms at once. This is why supervisors treat it as a systemic risk, not only a firm risk.
Cloud adds specific issues: shared responsibility (the provider secures the infrastructure, you secure your data, configuration and access), limited audit access, data location and legal jurisdiction, and the difficulty of moving workloads away (lock-in). Multi-region setups help against local faults but not against a provider-wide failure or a common software flaw.
The controls follow from the risks: map critical services and the full supply chain, set limits on dependency, negotiate contract rights covering subcontracting and notification, test exit and substitution plans, keep resilience for severe but plausible disruptions, and report to the board. Concentration cannot be removed; it is managed and made visible.
Key formulas to remember
- Third-party vs fourth-party
- Third party = direct contract with you; Fourth party = subcontractor of your third party
- Fourth parties are usually outside your contract, so you rely on the third party's oversight and your contract's flow-down terms.
- Firm-level concentration share
- Dependency share = Critical services using provider ÷ Total critical services
- An illustrative internal metric, not a Basel-mandated formula. Use it to compare dependencies against a limit.
- Concentration index (HHI)
- HHI = Σ (market share of provider i)²
- Shares as fractions give a value up to 1. Higher means more concentrated. Useful for sector-level dependence.
- Cloud shared responsibility
- Provider secures the cloud; you secure what you put in the cloud
- Accountability for the outsourced function stays with the bank.
- Core control set
- Map → Assess → Contract → Monitor → Exit-test
- A memory aid for the lifecycle controls, not a regulatory formula.
How to solve Concentration, Fourth-Party and Cloud Risk questions
Use this sequence on any scenario about providers, subcontractors or cloud.
- 1Identify the dependency: which function relies on which provider, and is it critical or important?
- 2Classify the party: third party (direct contract) or fourth party (subcontractor of the provider).
- 3Decide the level of concentration: one firm relying on one provider, or many firms on the same provider (systemic).
- 4Name the failure mode: outage, cyber event, provider insolvency, subcontractor failure, lock-in, or loss of data access.
- 5Link to impact: which services, customers or markets stop, and for how long compared with impact tolerance?
- 6Pick the control that matches the gap: supply-chain mapping, contract flow-down, diversification, multi-cloud or exit plan, testing.
- 7Check accountability: the bank remains responsible for the outsourced function and board oversight.
- 8Compare options and choose the one that addresses the stated risk, not a generic one.
Quickest way: Dependency-Failure-Control scan
When to use it: Use for multiple-choice questions when options look similar and time is short.
- Underline who contracts with whom to fix third vs fourth party.
- Ask whether the issue is one firm or the whole sector.
- Eliminate options that transfer accountability to the provider.
- Eliminate options that only add redundancy inside the same provider when the risk is provider-wide.
- Choose the option that gives visibility, exit ability or diversification matching the risk.
Common mistakes in Concentration, Fourth-Party and Cloud Risk
Treating fourth parties as having a contract with the bank.
The word 'party' suggests a direct relationship.
Fix: Fourth party means the provider's subcontractor. Control comes through the third party and contract flow-down terms.
Thinking multi-region cloud removes concentration risk.
Geographic redundancy sounds like diversification.
Fix: Multi-region protects against local faults. Provider-wide outages, shared software flaws or account-level issues remain. Only a different provider or tested exit addresses them.
Saying outsourcing transfers risk and accountability.
Contracts and insurance feel like transfer.
Fix: You can transfer the activity, not accountability. The bank and board stay responsible.
Treating concentration as only a firm-level issue.
Candidates view each bank in isolation.
Fix: When many firms share a provider, a single failure is correlated across the sector, which is a systemic concern for supervisors.
Assuming a high SLA availability figure removes resilience needs.
Uptime percentages look reassuring.
Fix: SLAs give remedies, not recovery. Resilience requires testing against impact tolerances and exit options.
Ignoring the shared responsibility model.
Candidates assume the cloud provider secures everything.
Fix: The customer is responsible for configuration, identity and data protection. Misconfiguration is a common cause of cloud incidents.
Worked examples
Example 1
A bank runs payments, treasury and client reporting on one cloud provider. Five of its 20 critical services are hosted there, and it also uses a vendor that itself runs on the same provider. The bank is considering adding a second region. Which risk does a second region fail to address, and what is the dependency share?
Show the solution
- Dependency share = 5 ÷ 20 = 0.25, or 25%, from direct use.
- The vendor running on the same provider is a fourth-party link, so true dependence is higher than 25% and must be mapped.
- A second region within the same provider protects against a regional fault.
- It does not protect against a provider-wide outage, a common software flaw, or account-level failure.
- Needed controls: supply-chain mapping to reveal hidden fourth-party dependence, contractual notification and flow-down rights, and a tested exit or alternate-provider plan.
Answer: Direct dependency is 25%, probably understated because of the fourth-party link. A second region leaves provider-wide concentration risk unaddressed; the bank needs mapping, contract rights and a tested exit or substitution plan.
Example 2
Four cloud providers serve a banking sector with market shares of 50%, 30%, 15% and 5%. Compute the HHI using fractions and explain what it signals.
Show the solution
- Convert shares to fractions: 0.50, 0.30, 0.15, 0.05.
- Square each: 0.25, 0.09, 0.0225, 0.0025.
- Sum: 0.25 + 0.09 + 0.0225 + 0.0025 = 0.365.
- For four equal providers HHI would be 0.25, and for one provider it would be 1. So 0.365 is above the equal-share case.
- Interpretation: the market is moderately concentrated, with the largest provider dominant. A failure at the 50% provider would affect many firms at once, which raises systemic concern.
Answer: HHI = 0.365, indicating notable sector concentration and correlated failure risk through the largest provider.
Exam tips
- Always state who holds the contract. Third versus fourth party is the most common trap.
- If the scenario mentions many banks using the same provider, bring in systemic risk and supervisory concern.
- Reject answers that say the bank transfers accountability to the cloud provider.
- Prefer answers with exit plans, testing and mapping over answers that rely only on SLAs or insurance.
- For numeric items, expect simple shares or HHI; show the squared terms and the sum.
Practice questions from Case Study: Third-party Risk Management
- A mid-sized bank signs a contract with a cloud provider to host its core payments platform. A senior manager argues that because the provide…
- A bank monitors a critical vendor using key risk indicators. Which set would best provide forward-looking early warning of deteriorating ven…
- A bank classifies 40 of its 200 third-party arrangements as critical. Internal audit finds that only 24 of the critical arrangements have a …
- A regional bank contracts a cloud provider to host its customer-facing mobile app. After a service outage, a manager argues that because the…
- A bank's outsourced call-centre vendor has an SLA requiring 99.5% availability over a 30-day month (720 hours). In the month, the vendor rec…
Concentration, Fourth-Party and Cloud Risk: frequently asked questions
What is fourth-party risk?
It is the risk arising from the subcontractors your third-party provider relies on to deliver your service. You normally have no contract with them. You manage it through mapping, contract terms and the provider's own oversight.
What is the difference between third-party and fourth-party risk?
A third party has a direct contract with the bank. A fourth party is engaged by that third party. The bank has less visibility and control over fourth parties, though accountability for the service stays with the bank.
Why is concentration in cloud providers a systemic issue?
If many banks rely on the same few providers, one outage or cyber event can disrupt many institutions at the same time. Failures become correlated across the sector, which individual firm diversification cannot fix.
How do banks reduce cloud concentration risk?
They map critical services and subcontractors, set dependency limits, negotiate audit, notification and exit rights, and test exit or substitution plans. Some use multi-cloud or hybrid designs where practical, accepting the added complexity.