In August, Andrew Bailey, chair of the Financial Stability Board, delivered a specific warning to G20 finance ministers: the immediate threat to global financial stability isn’t frontier AI itself, but frontier AI concentrated in a small number of third-party technology providers. His words to regulators were direct: “For the financial system, the most immediate concern is the potential impact of frontier AI on cyber risk. Frontier AI may have the ability materially to alter the speed, scale and economics of cyber risk, which could undermine market confidence system-wide, especially due to highly concentrated third-party service providers.”
What Bailey describes is third-party risk at systemic scale, where a small number of concentrated providers sit beneath the financial system. If one is compromised, the damage doesn’t stay inside one firm. It cascades.
Most third-party risk programs can’t see this concentration risk. Your program has a vendor inventory, a questionnaire, and a renewal calendar, but what it doesn’t have is visibility into how exposed you actually are when a vendor concentration risk surfaces.
Why your vendor list doesn’t show concentration risk
No large enterprise runs anything alone anymore. Your core finance system runs on a cloud provider, your email on another, your analytics on a third, your security monitoring on a fourth. These providers appear separate in your inventory, but beneath that neat list, they share hidden infrastructure dependencies that fundamentally change your entire risk profile.
When you actually map those dependencies, the picture shifts. Three of your most critical providers may run infrastructure on the same cloud region. Two may use the same AI provider for intelligence features. One may have a single point of failure in a key API that no other vendor provides. When you build the actual dependency graph, you discover it’s not five independent vendors but five vendors betting on the same infrastructure, all vulnerable to the same failure.
Vendor concentration risk is invisible until it surfaces, and by then it’s too late.
How concentration risk hides inside separate programs
An enterprise runs a vendor assessment program where each year the bank talks to fifty vendors, each assessed in isolation. The questions are straightforward:
- Does this vendor have security controls? Yes.
- A business continuity plan? Yes.
- 99.9% uptime? Yes.
All answers are yes, so all vendors are approved.
Then a vendor has an outage that traces back to a failure in a shared infrastructure layer. The bank never asked about it because the vendor assessment program was built to evaluate individual vendors, not to understand how vendors depend on each other. Two other critical vendors were also affected because they use the same shared layer. The trading desk goes offline for two hours, and the CISO later has to explain to regulators why the bank didn’t ask about the key dependencies in the vendor’s architecture or connect that dependency across vendors.
A vendor questionnaire is a snapshot valid on the day you send it and increasingly inaccurate every day after. A vendor’s security posture changes, a vendor gets acquired, infrastructure shifts, and dependencies evolve. None of this appears in a questionnaire that doesn’t get re-asked until renewal. A year later, the vendor landscape has changed three times while your risk assessment still uses last year’s answers.
Why your risk programs aren’t talking to each other
Concentration risk stays hidden because it lives at the intersection of multiple programs that should coordinate but don’t. Most enterprises have three separate functions that need visibility into each other, and they rarely have it.
The third-party risk program assesses vendors for security controls, business continuity, and data governance. It identifies that Vendor A is critical and rates it High Risk because the vendor processes payment data. Meanwhile, your operational resilience program is mapping critical services and their dependencies and has discovered that three services are critical to market operations, with all three using the same provider for a key service component. The operational resilience team notes this in their testing plan but doesn’t formally escalate it as a risk. At the same time, your cybersecurity program monitors third-party security incidents and tracks which incidents could affect your operations. Vendor A has had no incidents, so Vendor A remains approved.
Now the shared infrastructure provider that all three services depend on goes down, and all three critical services fail at once. Your operational resilience test breaks. Your third-party risk program has no mechanism to escalate because each vendor was rated individually, and your cybersecurity program has nothing to track because the provider that failed isn’t in your primary vendor inventory. It’s in the dependency layer. What should have been a containable failure becomes a systemic risk that lives in the gaps between three separate programs, none of which saw it coming.
Moving to dependency mapping
Closing this gap requires one shift: moving from a vendor inventory to a vendor dependency map. A vendor inventory tells you “we work with this vendor.” A vendor dependency map tells you “we work with this vendor, this vendor depends on three others, those vendors share infrastructure in this region, and if that region fails, these critical services fail with this cascade to our controls.”
This is where third-party risk intelligence makes the difference. Archer Evolv™ tracks vendor relationships, vendor dependencies, and shared infrastructure risks automatically, identifying changes as they happen and mapping their impact to your obligations and controls. More critically, it connects third-party risk to your actual control landscape. You know not just that you depend on three vendors in the same region, but which of your obligations depend on each vendor, which controls would break if that region went down, and exactly how much risk you’re carrying. When the Financial Stability Board warning about AI provider concentration becomes your problem, you’re not scrambling. You already have the map.
Continuous monitoring finds the gaps
Enterprises running continuous third-party monitoring detect concentration risks before they become systemic. They know about vendor incidents in real time, not through annual questionnaires or breach notifications months later. Infrastructure shifts appear immediately. A vendor goes down, and in minutes you know exactly how deep the impact runs across your operations.
The practical benefit is time compression. The gap between when a vendor risk surfaces and when your program can respond shrinks from months to hours. Your risk team stops spreadsheet firefighting and starts doing actual risk management, and your vendors stay current because you’re monitoring them continuously rather than annually.
An episodic vendor program captures risk after it happens. A program running on continuous intelligence captures it before it happens. That’s the difference between a vendor program and a defensible one. The choice isn’t between more oversight and less, but between oversight that lets you stay ahead of concentration risk and oversight that leaves you explaining gaps after the cascade starts.
See a demo of Archer’s third-party risk intelligence.
This is part of The Signal, Archer’s series on GRC industry news and events. Read more about regulatory change management and what it takes to keep compliance programs aligned as requirements evolve in The Signal: September 2026.
Frequently Asked Questions
Third-party concentration risk occurs when an organization relies on multiple vendors that share the same underlying service providers, infrastructure or technology. A disruption affecting one shared provider can impact several vendors and critical business services simultaneously. For financial institutions and other highly regulated organizations, these dependencies can create systemic operational and cybersecurity risks that individual vendor assessments may not identify.
Organizations can identify vendor concentration risk by mapping relationships between third parties, their subcontractors, cloud providers, AI providers and other critical infrastructure dependencies. Connecting these relationships to critical business services, regulatory obligations and internal controls helps risk teams identify shared points of failure and assess the potential impact of a disruption. Continuous monitoring can also help detect changes in vendor relationships and dependencies before they create significant exposure.
Traditional third-party risk management often evaluates vendors individually through questionnaires, security assessments and periodic reviews. Although these activities help assess individual vendor risk, they may not reveal dependencies shared across multiple providers or business services. Without visibility across third-party risk, operational resilience and cybersecurity programs, organizations can overlook common points of failure that could disrupt multiple critical operations at once.
Continuous monitoring helps organizations identify changes in vendor security posture, service availability, ownership and infrastructure dependencies between scheduled assessments. When combined with dependency mapping, it enables risk teams to understand which critical services, controls and regulatory obligations could be affected by a vendor disruption. Third-party risk intelligence solutions such as Archer Evolv™ help connect vendor relationships and emerging risks to an organization’s broader risk and compliance framework, supporting more informed and timely decisions.
