Fourth-Party Risk Management

What Is Fourth-Party Risk Management?

Fourth-party risk management is the discipline of identifying, assessing, and monitoring the cybersecurity risk your vendors' vendors introduce, companies that touch your data indirectly through a third party but that you never contracted with or assessed yourself. It extends third-party risk management one layer further, into the dependencies those vendors rely on.

Why Can't Traditional Vendor Risk Management Programs See Fourth Parties?

Traditional vendor risk management programs can't see fourth parties because they were built to evaluate a single, named counterparty at a time, not the chain of infrastructure and subcontractors sitting underneath it. A security questionnaire asks your direct vendor about its own controls. It rarely asks what cloud provider hosts its environment, what payment processor handles its transactions, or what file-transfer tool moves its data, and even when a questionnaire does ask, the answer is only accurate on the day it's submitted.

This gap isn't a flaw in execution. It's structural. Most vendor risk assessment processes were designed around a contract, and there is no contract between your organization and your vendor's vendor. Without a contractual relationship to anchor the assessment, fourth parties simply fall outside the frame most programs were built to capture.

What Does a Fourth-Party Risk Management Program Actually Require?

A fourth-party risk management program requires three things a standard third-party program doesn't: discovery, prioritization, and ongoing visibility. Discovery means identifying which fourth parties actually exist underneath your vendor portfolio. Vendor disclosure requests and subprocessor lists are a starting point, but they're rarely complete, which is why discovery increasingly relies on evidence a vendor doesn't control: its digital footprint, the subdomains tied to its infrastructure, and the technology signatures its own websites expose.

Prioritization means recognizing that not every fourth party deserves the same scrutiny. A cloud infrastructure provider underneath a dozen of your critical vendors warrants close attention, since that single provider represents concentration risk across your entire portfolio, not just one vendor relationship. A minor analytics plugin used by a low-tier vendor probably doesn't. The same logic that governs how closely you watch a direct vendor should apply to what's sitting underneath it.

Ongoing visibility means treating fourth-party exposure as something that changes, not a static fact captured once at onboarding. A vendor can switch fourth-party providers with no notice to you, which is why fourth-party risk management leans on continuous monitoring far more heavily than on periodic reassessment.

What Happens When Fourth-Party Risk Management Fails?

When fourth-party risk management fails, the organization that absorbs the damage is rarely the one that made the mistake. Your direct vendor didn't necessarily do anything wrong. Its own vendor did, and your organization inherits the consequences anyway: the regulatory exposure, the customer notifications, the operational disruption, all landing on a business that had no direct relationship with the company at fault. That's the defining trait of fourth-party failure, the same domino effect that defines cascading risk more broadly. Accountability and impact end up on opposite sides of the relationship.

This is also where the cost compounds. A breach that originates four tiers removed from you takes longer to trace, longer to attribute, and longer to remediate than one at a vendor you actually assessed, because nobody had a map of the dependency until it broke.

Who Owns Fourth-Party Risk Management Inside an Organization?

Fourth-party risk management usually sits with the same TPRM team that owns third-party risk, but it rarely stays there alone. Ownership typically splits across three groups:

• The TPRM team retains ownership of prioritization and vendor communication.
• Security operations often co-owns discovery and monitoring, since fourth-party exposure surfaces through infrastructure signals rather than contract terms.
• CISOs typically want fourth-party exposure rolled up into the same risk reporting they already receive on direct vendors, rather than tracked as a separate, parallel program that competes for attention and budget.

In practice, the organizations that manage fourth-party risk well tend to avoid creating a standalone fourth-party function. They extend their existing third-party program one tier deeper instead of building a second program from scratch, treating it as one layer of the same supply chain cyber risk management effort rather than a separate initiative competing for its own budget.

How Do Regulations Push Organizations Toward Fourth-Party Oversight?

Regulations increasingly push organizations toward fourth-party oversight by extending compliance obligations past the first vendor tier. The EU's DORA (Digital Operational Resilience Act) requires financial entities to assess subcontracting chains for critical ICT services under Article 28, not just the direct provider relationship. Delegated Regulation (EU) 2025/532, which fleshes out those subcontracting obligations, pushes that requirement further still, covering material fourth-party dependencies within the chain. In practice, that means firms can no longer treat their vendor's vendor as out of scope.

Black Kite covers what the DORA regulation's first year of enforcement actually found. Third-party dependencies remain a primary driver of major incidents, and most financial entities are still failing to map that exposure. The NIS2 Directive applies similar logic to essential and important entities across the EU, holding organizations accountable for supply chain risk that extends beyond their immediate suppliers.

The direction of travel is consistent across frameworks. Regulators no longer accept "we didn't know our vendor's vendor existed" as a defensible position. Fourth-party risk management is becoming less of a maturity differentiator and more of a compliance baseline, particularly in financial services, healthcare, and critical infrastructure.

How Does Black Kite Operationalize Fourth-Party Risk Management?

Black Kite® operationalizes fourth-party risk management by combining discovery, criticality context, and continuous monitoring in a single workflow instead of three disconnected processes. Fourth party vendor risk management through Black Kite Extend maps the infrastructure and service dependencies underneath your direct vendors, surfacing fourth parties that vendor questionnaires alone would never reveal. In practice, that means:

• Discovery runs on evidence a vendor can't edit or withhold — digital footprint data, subdomain patterns, and website technology signatures — instead of relying on a vendor to self-report.
• Prioritization surfaces through ratings and FocusTag® alerts applied to system-monitored fourth parties, so the ones sitting under your most critical vendors don't get lost among the rest.
• Monitoring feeds fourth-party findings into the same Vendor Risk Management (VRM) workflows your team already uses, rather than requiring a separate process run in parallel.

The scale of the problem is why this matters operationally, not just theoretically. Black Kite's 2026 Third-Party Breach Report analyzed 136 major third-party breach events, exposing more than 433 million records, and found that the average vendor breach now cascades to 5.28 downstream victim organizations. A meaningful portion of those downstream organizations had never assessed, and in many cases never heard of, the fourth party that ultimately caused their exposure. Fourth-party risk management exists to close exactly that gap, before the next breach notification arrives.

Related Terms

• Fourth Party
• Nth Party
• Vendor Risk Management (VRM)
• Concentration Risk
• Cascading Risk
• Criticality Tiering