Third-Party and Concentration Risk in Financial Cloud Estates
Knowing What You Depend On, Including the Things You Never Contracted For
Ask a bank for its list of critical third parties and you will get a procurement register. Ask what would break if a specific managed queue service degraded in one region for six hours, and the answer usually requires a week of investigation across several teams. The gap between those two things is where concentration risk lives.
It exists because dependencies do not arrive through procurement. They arrive when an engineering team picks the convenient managed option, when a vendor changes its own subcontractor, and when three unrelated services quietly standardise on the same component. Managing third party concentration risk cloud estates create therefore starts with discovery from the live environment rather than with a better spreadsheet.
What are you actually trying to manage?
The possibility that one failure outside your control takes down several critical services at once.
Concentration is a correlation problem rather than a vendor management problem. A single provider dependency is tolerable if it affects one non-critical service and serious if it sits under six critical ones, and the register that lists both identically tells you nothing about which is which.
Which types of concentration exist?
Six, and institutions typically track only the first.
| Type | Example | Usually tracked |
|---|---|---|
| Provider | Most critical workloads on one cloud provider | Yes |
| Service | Many services depending on one managed database or queue | Rarely |
| Region | Critical workloads and their recovery in the same region | Sometimes |
| Subcontractor or nth party | Several vendors relying on the same underlying provider | Almost never |
| Skills and knowledge | One team or a few individuals who can operate a critical platform | No |
| Sector level | Many institutions depending on the same provider at once | Monitored by authorities, rarely by firms |
Service-level and nth-party concentration cause the incidents that surprise people, because they are invisible in a contract-based view. Region-level exposure is similarly underestimated, which is the argument made in cloud region exposure and why multi-cloud is not diversification.
Why does nth-party dependency defeat most registers?
Because you have no contract, often no visibility, and the failure presents as someone else's outage.
Your payments vendor runs on a cloud provider, which runs on a content delivery network, which depends on a DNS provider. When the bottom layer fails, you see your vendor unavailable with no explanation and no ability to act. The FSB's toolkit on enhancing third-party risk management and oversight, published in December 2023, specifically addresses identifying critical third-party services and monitoring systemic third-party dependencies, which is the frame to borrow: ask each critical provider which of their own dependencies would take your service down, and make the answer a contractual reporting obligation rather than a goodwill enquiry.
Do you know which single managed service sits under the largest number of your critical workloads?
Talk to Digiqt about a dependency and concentration assessment
How do you build a dependency inventory that stays true?
By deriving it from the running estate and reconciling it against contracts, not the other way round.
Surveys and registers go stale immediately because they capture intent at a point in time. Your estate, by contrast, tells the truth continuously if you read it.
Where do undeclared dependencies show up?
In billing, egress, DNS, package manifests, and infrastructure code.
Cloud billing reveals every managed service actually in use, including the ones nobody documented. Network egress destinations reveal external calls from production. DNS query logs reveal integrations that appear nowhere in architecture diagrams. Package manifests and container images reveal software supply chain dependencies. Infrastructure code reveals regions, services, and account structure. Pull all five continuously, map them to business services, and reconcile against the outsourcing register so the discrepancies become work items rather than surprises. The move from documented process maps to live dependency data is precisely the shift described in going from critical-process maps to live dependencies.
How do you connect a dependency to a business service?
Through service ownership metadata applied at deployment, so the mapping is a byproduct rather than a project.
Require every deployed component to declare the business service it supports and its criticality, enforce that at deployment time, and derive the dependency map from telemetry rather than from documentation. That turns the question of what breaks if a specific service degrades into a query rather than an investigation, which is the difference between answering a supervisor in an afternoon and in a month.
How do you assess criticality and substitutability?
Criticality from business impact, substitutability from whether an alternative is named, tested, and owned.
| Rating | Criticality meaning | Substitutability meaning |
|---|---|---|
| High | Failure breaches an impact tolerance quickly | Alternative named, tested, owner assigned |
| Medium | Failure degrades service or delays obligations | Alternative identified, not tested |
| Low | Failure is inconvenient and absorbable | Alternative obvious and commodity |
| None | Not applicable | No realistic alternative exists |
The cell that matters is high criticality combined with no substitutability, and every institution has some. The correct response is not to pretend otherwise but to document the acceptance, add compensating controls such as degraded-mode operation, and report it to the board as a knowingly accepted risk. Supervisors respond considerably better to that than to an implausible mitigation, and the Basel Committee's Principles for operational resilience, published in March 2021, frame exactly this expectation of understanding and managing dependencies rather than eliminating them.
What makes a substitute real rather than theoretical?
A named target, a tested path, an owner, and a known switch time.
An alternative provider that exists in the market is not a substitute. A named alternative with a tested migration path, an accountable owner, and a measured switch time is. Test one substitution per cycle even at small scale, since the exercise reveals the dependencies that make substitution harder than the paper suggests, and it feeds directly into the exit work described in cloud exit and stressed exit planning.
How should ongoing monitoring work?
On a small set of signals per critical provider, reviewed on a cadence, with escalation defined in advance.
Watch performance and availability against contractual commitments using your own telemetry rather than the provider's status page, since the two frequently disagree during incidents. Track incident history and the quality of post-incident information, because a provider that explains failures poorly is harder to manage than one that fails slightly more often. Monitor security posture through assurance reports and vulnerability disclosure behaviour. Watch financial and corporate signals, including ownership changes, since acquisition frequently changes service and pricing. And require notification of material subcontractor changes, which is the only practical route to nth-party visibility. Where the industry publishes shared outage analysis, use it, because correlated sector-wide events are the ones your own telemetry cannot anticipate, as discussed in common cloud outages and non-malicious accumulation.
Do you measure provider availability from your own telemetry or from their status page?
What about emerging concentration in newer services?
Treat compute-intensive and model-serving dependencies as concentration risks now, before they become critical.
Specialised infrastructure creates concentration faster than general compute, because the supply of suitable capacity is narrower and the alternatives are fewer. Institutions adopting model-serving platforms, specialised accelerators, and vendor-hosted inference are accumulating dependencies with very limited substitutability, often through individual team decisions rather than architectural review. Bring those into the inventory early and assess substitutability honestly, because the window in which the choice is reversible is short. The exposure cluster this creates is examined in AI compute concentration as a new exposure.
How should scenario testing be done?
By testing the failure of the dependency rather than the failure of the application.
Run scenarios that name the third party: this region becomes unavailable, this managed service degrades to fifty percent, this vendor is compromised, this subcontractor fails and your provider cannot say why. Then measure whether the affected business services stay inside their tolerances and whether your response worked. Include partial degradation rather than only total failure, since partial is more common and harder to detect. Tolerance setting and service mapping are the prerequisite for judging the results, which is the subject of mapping critical business services and setting impact tolerances.
What belongs in board reporting?
Critical services with single points of failure, concentration trend, substitutability gaps, and accepted risks.
| Report element | Why the board needs it |
|---|---|
| Critical services and their single points of failure | The concentration picture in business terms |
| Concentration trend by provider, service, and region | Drift happens quietly through engineering choices |
| Substitutability status for high-criticality dependencies | Distinguishes managed risk from hope |
| Provider incidents and response quality | Early signal of a deteriorating relationship |
| Nth-party visibility coverage | How much of the chain remains unknown |
| Knowingly accepted concentrations | Explicit acceptance rather than implicit exposure |
Keep it short and keep the trend, because a board can act on a direction of travel and cannot act on a hundred-row register.
How should delivery be phased?
Discovery first, then service mapping, then substitutability assessment, then monitoring and testing.
Start with automated discovery from billing, egress, DNS, manifests, and infrastructure code, since that is where the unknown dependencies are. Then build the mapping from dependency to business service through deployment metadata. Then assess criticality and substitutability for the high-impact set, and accept explicitly where no substitute exists. Then stand up ongoing monitoring with defined signals and escalation, and add dependency-named scenario testing. Then tie the whole thing into your outsourcing register so the register becomes a view of reality rather than a parallel document, which is what supervisors examining the arrangements described in cloud migration regulatory approval will expect.
Which metrics show the risk is being managed?
Inventory coverage and freshness, single points of failure under critical services, substitutability coverage, nth-party visibility, and scenario coverage.
Report the share of production dependencies discovered automatically rather than declared, and how recently the inventory refreshed. Count single points of failure under critical services and track the number down deliberately. Measure substitutability coverage for high-criticality dependencies, with tested status distinguished from identified. Report nth-party visibility as the share of critical providers who have disclosed their own critical dependencies. And track scenario coverage, meaning how many of your top dependencies have been tested by failure rather than discussed.
Concentration risk is the one exposure that grows without anyone deciding to take it on, one convenient managed service at a time. The institutions that control it are the ones that read their own estate continuously, mapped dependencies to business services, and told the board plainly which single points of failure they have chosen to live with.
Frequently Asked Questions
What kinds of concentration actually matter?
Provider, individual service, region, subcontractor, scarce internal skills, and sector-level concentration where many institutions depend on the same provider simultaneously.
Why do registers miss the real dependencies?
Because they record contracts, and dependencies arrive through engineering choices. A managed service adopted by three teams becomes critical without any procurement event.
How do you find undeclared dependencies?
From the estate rather than from surveys: billing data, network egress destinations, DNS queries, package manifests, and infrastructure code all reveal what production actually calls.
What is nth-party risk?
Dependence on your provider's providers. You have no contract with them, often no visibility, and their failure can present as your provider's outage with no explanation available.
What makes a service genuinely substitutable?
A named alternative, a tested migration path, and an owner. Anything short of that is a substitute in principle, which does not help during an incident.
How do you monitor a provider you cannot audit?
Through assurance reports, contractual reporting obligations, your own telemetry on their service, incident history, financial and security posture signals, and pooled industry oversight.
Is multi-cloud the answer to concentration?
Rarely as a whole-estate strategy. Targeted independence for the most critical services usually delivers more resilience per unit of cost and complexity than broad duplication.
What should the board actually see?
Critical services and their single points of failure, concentration trend, substitutability status, unresolved provider incidents, and which risks the bank is knowingly accepting.
