Fourth-Party Risk in 2026: NYDFS, DORA, and the MOVEit/SolarWinds Lessons

TL;DR

• Fourth-party risk is exposure from your vendors’ vendors — entities you don’t contract with but can still crater your operations.
• MOVEit, SolarWinds, and CrowdStrike all demonstrated that downstream dependencies are the attack surface no one mapped.
• NYDFS (October 2025), DORA, and the OCC/FDIC/Fed interagency guidance now expect documented fourth-party oversight — not just a vendor list.
• The practical fix: contractual flow-down provisions, vendor subcontractor disclosure requirements, and a concentration risk analysis of your critical vendors’ own dependencies.

Your vendor management program probably looks solid on paper. You’ve got a tiered vendor list, due diligence questionnaires, and annual reviews for your critical third parties. What you probably don’t have is a clear picture of who your vendors depend on.

That’s fourth-party risk. And it’s been behind some of the most damaging incidents of the past five years.

What Fourth-Party Risk Actually Means

The terminology is straightforward but the problem is not. In TPRM terms:

• First party: You (your organization)
• Second party: Your customer or counterparty
• Third party: A vendor or service provider you directly contract with
• Fourth party: A subcontractor, sub-processor, or downstream dependency your vendor relies on — with whom you have no direct relationship

The problem with fourth parties isn’t obscurity — it’s invisibility. When your payroll provider gets breached, you’re affected whether or not their database vendor was on your approved vendor list. When your cloud infrastructure provider goes down, your whole stack goes with it even if your direct vendor contracts look fine.

According to Verizon’s 2025 Data Breach Investigations Report, third-party breaches doubled to 30% of all incidents — and a significant portion of that expansion traces directly to cascading fourth-party exposures. The average breach now costs $4.44 million. Most of that pain is downstream.

The Three Incidents That Made Fourth-Party Risk a Regulatory Priority

MOVEit (2023): The Payroll Chain Attack

Progress Software’s MOVEit Transfer vulnerability, exploited by the Cl0p ransomware group in 2023, is the canonical fourth-party risk case study. The breach compromised over 1,000 organizations and exposed the personally identifiable information of approximately 60 million individuals.

Here’s the fourth-party dimension: the majority of affected organizations were not direct MOVEit customers. They were customers of payroll processors, benefits administrators, HR platforms, and government contractors who were MOVEit customers. When those vendors’ data transfer infrastructure was breached, the data of their clients — your employees, your customers — was exposed.

Your vendor relationship was fine. Your vendor’s vendor was the problem.

SolarWinds (2020): The Software Build Pipeline

The SolarWinds Orion attack demonstrated a different fourth-party vector: compromised software updates. Nation-state actors injected malicious code into SolarWinds’ legitimate software build pipeline, which then distributed a poisoned update to approximately 18,000 customers — including U.S. federal agencies, the Treasury Department, and Fortune 500 companies.

Most of those 18,000 customers had SolarWinds Orion as a direct third-party vendor. But the actual threat actor was operating at the fourth-party level: the software components and build infrastructure that SolarWinds itself relied on.

CrowdStrike (2024): The Update That Crashed the World

The CrowdStrike Falcon sensor incident in July 2024 showed that fourth-party risk doesn’t require malicious intent. A faulty content configuration update from a dominant endpoint security vendor rendered millions of Windows systems inoperable within hours. Airlines, hospitals, banks, and emergency services were affected — not because they had a bad vendor contract, but because their vendor’s internal release process failed.

The U.S. GAO specifically cited this event as highlighting key cyber vulnerabilities in software update supply chains.

What Regulators Now Expect

Fourth-party risk has moved from a theoretical gap to an explicit regulatory expectation. Here’s what the major frameworks are demanding.

NYDFS October 2025 Guidance

On October 21, 2025, the New York Department of Financial Services published an Industry Letter clarifying expectations under Part 500 (specifically §500.11) for third-party service provider risk management. The guidance explicitly addresses fourth-party (downstream service provider) management as a key component of a mature TPRM program.

What NYDFS is looking for:

• Subcontractor disclosure requirements: Contract language requiring your vendors to disclose any subcontractors that may have access to your information systems or nonpublic information (NPI)
• Rejection rights: The ability to reject specific subcontractors after conducting appropriate due diligence — even mid-contract
• Lifecycle oversight: Due diligence that extends through the entire vendor relationship, not just onboarding
• Flow-down obligations: Your security requirements flowing down to your vendors’ own subcontractors

The letter is framed as guidance — not new regulation — but NYDFS routinely uses its guidance documents as the practical benchmark during examinations.

DORA: Concentration Risk at the European Level

For financial entities subject to the EU’s Digital Operational Resilience Act (effective January 2025), fourth-party risk sits at the center of concentration risk requirements under Articles 28 and 29.

DORA requires:

• Mapping dependencies on ICT third-party service providers and their subcontractors
• Identifying where multiple critical functions rely on the same underlying infrastructure provider
• Justifying concentration risks where they exist
• Registering critical ICT providers — the European Supervisory Authorities began designating these in mid-2025 with associated oversight obligations

DORA is the only framework that has gone as far as regulatory designation of critical fourth parties (essentially).

OCC and Interagency Guidance

The OCC has flagged growing concerns about concentration risk in core banking technology — a small number of providers dominate core processing, cloud infrastructure, and data management for the industry. The 2023 OCC/FDIC/Federal Reserve interagency guidance on third-party relationships specifically expects institutions to understand material dependencies at multiple levels.

Examination teams are increasingly asking: “What happens if [critical vendor X] fails?” and then following up with: “And what does [vendor X] itself depend on?”

The Practical Framework for Managing Fourth-Party Risk

You can’t audit every fourth party. That’s not realistic. But you can build a proportionate program that satisfies regulators and actually reduces your exposure.

Step 1: Identify Your Critical Third Parties First

Fourth-party oversight starts with a clear picture of your Tier 1 vendors — those providing critical or significant functions. For each critical vendor, fourth-party visibility becomes a requirement, not an optional enhancement. For your Tier 3 commodity vendors, lighter treatment is defensible.

Vendor risk tiering is the foundation. Without it, you can’t prioritize which fourth-party relationships to investigate.

Step 2: Build Contractual Visibility Into Every Critical Vendor Contract

This is the most actionable and immediately implementable step. Before you can manage fourth-party risk, you need the right to see it. Your vendor contracts for critical third parties should include:

Many vendors will push back on rejection rights and right-to-audit clauses. This is where vendor risk assessment leverage matters — the due diligence stage is when you have the most negotiating power.

Step 3: Map Fourth-Party Dependencies for Your Highest-Risk Vendors

For your top 10-20 critical vendors, conduct a fourth-party mapping exercise. You’re looking for:

Concentration risk: Do five of your critical vendors all run on AWS us-east-1? On the same core banking processor? On the same CDN?

Systemic exposure: Is there a single fourth-party failure that could cascade across multiple critical functions simultaneously?

Lack of alternatives: If a critical fourth party fails, can your vendor — and you — recover without it?

The mapping doesn’t have to be exhaustive. At minimum, you want one level of visibility below each critical vendor: their top five subcontractors or infrastructure dependencies.

This information comes from:

• Vendor questionnaires (include fourth-party mapping in your annual due diligence)
• Vendor-provided SOC 2 reports (the complementary user entity controls section often references subcontractors)
• Public information and OSINT — most major SaaS vendors publish their own subprocessor lists

Step 4: Assess Concentration Risk Formally

Concentration risk is where fourth-party risk crosses into enterprise risk management. A concentration exists when a failure at a single fourth party could affect multiple critical functions or vendor relationships simultaneously.

Common concentrations to investigate:

• Cloud infrastructure: AWS, Azure, GCP — which critical vendors rely on which cloud, and which regions?
• CDN and DDoS protection: Cloudflare, Akamai — how many of your vendors depend on the same provider?
• Core banking platforms: Jack Henry, FIS, Fiserv — how many of your fintech partners share the same core?
• Data enrichment and verification: Plaid, Experian, TransUnion — what happens if one disappears?
• Identity and authentication: Okta, Ping, Duo — a single platform failure can disable access across your entire stack

Document your concentration risk analysis and present findings to senior management. Regulators want to see that you’ve thought about this, not just that you know what “concentration risk” means.

Step 5: Monitor — But Proportionately

Ongoing fourth-party monitoring is still emerging as a practice. Not many organizations have continuous fourth-party intelligence. What’s practical:

• Annual questionnaire update: Add a fourth-party subcontractor section to your existing critical vendor reviews
• OSINT monitoring for key fourth parties: If you know your core banking provider runs on AWS, monitor AWS status and incident disclosures
• Incident trigger reviews: Any major incident involving a critical fourth party (CrowdStrike-scale event, major cloud outage, significant data breach) triggers a rapid assessment of your exposure
• Regulatory intelligence: When DORA or OCC issues guidance on concentration risk, map it against your known dependencies

The Vendor Conversation You Need to Have

One of the hardest parts of fourth-party risk management is that you’re asking your vendors to do work — and they may not see it as their problem. A few approaches that work:

Frame it as mutual risk: Your vendor’s reputational exposure from a fourth-party breach that affects your customers is as bad as yours. MOVEit vendors lost clients. SolarWinds nearly destroyed the company. This is their risk too.

Reference regulatory expectations: NYDFS, DORA, and OCC language gives you cover. “We’re required to understand your subcontractor dependencies as part of our regulatory compliance program” is a harder conversation to deflect than “we’d like more information.”

Make it a contract requirement, not a request: Negotiating fourth-party disclosure clauses into contracts at renewal is far easier than trying to add them retroactively.

Use your leverage at onboarding: The vendor onboarding process is when you have the most negotiating power. Before a vendor is embedded in your operations, you can make fourth-party visibility a condition of contract.

Concentration Risk: The Board-Level Conversation

Senior management and boards increasingly need to hear about concentration risk — not just third-party risk. The question isn’t “which vendors could fail?” It’s “which single failure could take down multiple critical functions simultaneously?”

For the board presentation, three things matter:

1. Where are your critical concentrations? Name the specific providers (AWS us-east-1, FIS, Cloudflare) and which of your functions depend on them.
2. What’s your response plan if they fail? Not a generic BCP — a specific scenario response for your highest-probability concentrations.
3. What are you doing to reduce concentration over time? Regulators don’t expect perfection; they expect a risk-informed plan.

So What Does This Mean for Your Program?

Fourth-party risk management doesn’t require rebuilding your entire TPRM program. It requires three additions to what you likely already have:

1. Contract language: Add subcontractor disclosure, material change notification, and flow-down security obligations to every critical vendor contract at next renewal.
2. Due diligence scope: Add a fourth-party mapping section to your critical vendor questionnaires — five questions asking about their top subcontractors and dependencies is enough to start.
3. Concentration risk analysis: Document where multiple critical vendors share the same fourth-party infrastructure, and bring that analysis to senior management.

The gap regulators are probing isn’t technical sophistication. It’s documentation and intentionality. They want to see that you’ve mapped the dependency chain and thought about what breaks if something in that chain fails.

The Third-Party Risk Management (TPRM) Kit includes a vendor due diligence questionnaire with fourth-party visibility sections, concentration risk analysis templates, and contract clause guidance aligned to the 2023 OCC/FDIC/Fed interagency guidance and NYDFS 2025 requirements.

Sources:

• NYDFS Industry Letter, October 21, 2025: Guidance on Managing Risks Related to Third-Party Service Providers
• What the MOVEit Breach Tells Us About Third-Party Risk in 2025 — Framework Security
• CrowdStrike Chaos Highlights Key Cyber Vulnerabilities with Software Updates — U.S. GAO
• TPRM, Fourth-Party Risk Management, and Concentration Risk in Banking — Aravo
• NYDFS’s 2025 Guidance: Elevates Third-Party Oversight & Security — Protiviti