Most organizations have gotten reasonably good at managing the risk of their direct vendors. They send questionnaires, review SOC 2 reports, include security requirements in contracts, and conduct periodic reassessments. It is not perfect, but it is a start.
What far fewer organizations have figured out is what happens one layer deeper. Your cloud storage vendor uses a sub-processor for data indexing. Your payroll provider relies on a third-party authentication platform. Your cybersecurity monitoring tool pulls threat intelligence from an external feed. None of these relationships are yours directly. You did not choose them, you cannot audit them, and in many cases you do not even know they exist.
That is fourth-party risk. And in 2026, it is one of the things keeping compliance and risk leaders up at night, because the regulatory expectation and the practical reality have diverged sharply. Regulators hold you accountable for it. Your visibility into it is often close to zero.
What Is Fourth-Party Risk?
Fourth-party risk refers to the risk introduced by the subcontractors, sub-processors, and service providers that your direct vendors rely on to deliver their services to you. Your vendors are your third parties. Their vendors are your fourth parties.
The terminology is straightforward. What is less straightforward is the implication: your organization carries risk from entities you have never contracted with, never assessed, and may not be able to name. When a fourth-party sub-processor experiences a breach, the data it was processing on behalf of your vendor, which was ultimately processing it on your behalf, is compromised. The breach happened three relationships away from your organization. The regulatory exposure, the customer notification obligation, and the reputational damage land on your desk.
This is not hypothetical. The SolarWinds attack compromised thousands of organizations through a software update from a trusted vendor. The Change Healthcare breach in 2024, which exposed over 100 million records, originated in a sub-processor relationship that most affected organizations had no direct visibility into. Fourth-party risk is not an edge case. It is how some of the most significant incidents in recent memory actually happened.
Why Fourth-Party Risk Is Harder Than Third-Party Risk
Third-party risk is difficult enough. Fourth-party risk is harder for reasons that are structural rather than just operational.
You have no direct relationship. With a third-party vendor, you can require questionnaire responses, audit rights, and contractual security obligations. With fourth parties, you have none of that. The only leverage you have is through your third party, and that leverage is only as strong as the contractual requirements you put in your vendor agreements.
Visibility is limited by design. Many vendors are reluctant to fully disclose their own sub-processor and subcontractor relationships, either for competitive reasons or because they themselves do not have complete visibility into their supply chain. The TPRM landscape in 2026 reflects this reality: regulators now mandate concentration risk reporting precisely because organizations consistently underestimate how deep their dependency chains run.
The chain does not stop at four. Fourth parties have their own vendors, which makes them fifth parties relative to your organization. In complex technology supply chains, the dependency chain can extend considerably further. The practical challenge is determining how deep meaningful oversight needs to go and where the risk of a sub-processor failure actually becomes material to your organization.
Traditional due diligence does not reach this far. Standard third-party due diligence processes are designed for direct vendor relationships. Applying the same process to fourth parties is often impractical because the organization has no direct access to those parties for assessment purposes.
Where Fourth-Party Risk Shows Up in Practice
Sub-processors in data processing chains. GDPR explicitly requires data processors to disclose their sub-processors and obtain controller authorization before using them. This creates a formal framework for managing one category of fourth-party risk in EU data processing contexts. Outside that context, disclosure obligations are less consistent, and oversight is patchier.
Cloud infrastructure dependencies. A SaaS vendor may be hosted on AWS, Azure, or Google Cloud, with their data storage, compute, and networking all dependent on that underlying infrastructure. An outage or security incident at the cloud provider affects every SaaS vendor running on it, and through them, every customer of those vendors.
Software supply chain. The software your vendors use to deliver their services may itself contain components from open-source libraries, third-party code modules, or commercial software tools whose security is not within your vendor’s control. The Log4Shell vulnerability in 2021 demonstrated how a widely used open-source library could expose thousands of organizations simultaneously through the products of vendors who had incorporated it.
Financial and operational subcontractors. Vendors who subcontract portions of service delivery to other firms introduce operational risks that may not be visible from the outside. If a critical subcontractor fails or is acquired, your vendor’s ability to deliver may be affected in ways that your direct vendor agreement did not anticipate.
Managing Fourth-Party Risk: What Organizations Can Actually Do
Full visibility into every fourth-party relationship is not realistic for most organizations. What is realistic is a risk-based approach that focuses attention on the fourth-party dependencies that actually matter.
Require fourth-party disclosure in vendor contracts. The most direct lever available is contractual. Vendor agreements should require disclosure of material sub-processors and subcontractors, restrict the use of new sub-processors without prior notification, and flow down security and compliance requirements to the vendor’s own supply chain. This does not give you direct oversight of fourth parties, but it creates accountability in your third-party relationship for managing the risks that fourth parties introduce.
Map critical dependency chains for your highest-risk vendors. For vendors who are critical to your operations or who handle your most sensitive data, ask specifically about their sub-processor and subcontractor relationships. Understand which of their capabilities are delivered in-house versus subcontracted. This mapping will not be comprehensive, but it will reveal the most material dependencies.
Incorporate fourth-party risk into your TPRM framework. A mature third-party risk management program does not treat fourth-party risk as a separate topic. It builds fourth-party considerations into the assessment process: Does this vendor’s questionnaire response indicate material reliance on sub-processors? Have they disclosed those relationships? Have they required their sub-processors to meet comparable security and compliance standards?
Monitor for fourth-party incidents. Even without direct assessment access, organizations can monitor for publicly disclosed incidents involving known sub-processors and cloud infrastructure providers. When a major cloud provider experiences an outage or a widely-used software component has a critical vulnerability disclosed, the question is immediately which of your vendors are affected and what the downstream impact on your organization might be. Establishing TPRM policies that explicitly include fourth-party monitoring as a component keeps this on the radar rather than waiting for something to go wrong before asking the question.
Use concentration risk analysis. If multiple critical vendors rely on the same underlying infrastructure provider, cloud platform, or critical sub-processor, your organization has concentrated fourth-party risk that may not be visible when looking at each vendor relationship individually. A portfolio-level view of vendor dependencies reveals these concentrations before they become disruptions.
What Regulators Expect
The regulatory expectation around fourth-party risk is moving faster than most organizations’ practices. GDPR’s sub-processor disclosure requirements set an early standard in data protection contexts. Financial services regulators in the US and EU have increasingly focused on operational resilience and concentration risk in ways that explicitly include subcontractor and subprocessor relationships.
The 2026 CMEP priorities from NERC, for example, include supply chain risk management as a specific focus area, reflecting the recognition that energy sector cyber risk often enters through the supply chain rather than through direct attacks. DORA (the EU’s Digital Operational Resilience Act) requires financial entities to assess ICT concentration risk, including at the subcontractor level.
The direction of travel is clear: organizations that cannot demonstrate at least a reasonable approach to understanding and managing their fourth-party exposure will find themselves on the wrong side of regulatory expectations as enforcement in this area matures.
How VComply Supports Fourth-Party Risk Management
VComply’s RiskOps module helps organizations extend their vendor risk management program to incorporate fourth-party visibility. Third-party assessments within VComply can include specific questions about sub-processor and subcontractor relationships, with responses centrally stored and linked to the relevant vendor record.
Where fourth-party dependencies are identified, they can be documented within VComply’s risk register as associated risks to the primary vendor relationship, with monitoring schedules and escalation workflows assigned. When a publicly disclosed incident involves a known fourth-party provider, the affected vendor relationships can be quickly identified and triggered for immediate review.
Portfolio-level dashboards give risk teams visibility into concentration risk: which underlying providers appear across multiple vendor relationships and where a single fourth-party failure could have cascading effects across the vendor ecosystem.
Conclusion
Fourth-party risk is the part of vendor risk management that most organizations know they should be addressing and few have fully figured out. The organizations that take it most seriously are not trying to assess every sub-processor in their extended supply chain, which is neither practical nor proportionate. They are taking a risk-based approach: mapping the dependencies that matter most, building fourth-party requirements into their vendor contracts, monitoring for incidents that affect known sub-processors, and keeping their TPRM framework honest about the limits of their visibility. That approach will not catch everything. But it is significantly better than discovering a material fourth-party dependency for the first time during a breach response.
Ready to extend your vendor risk program to cover fourth-party dependencies? Book a personalized demo with VComply and see how RiskOps helps teams map, monitor, and manage risk across the entire vendor ecosystem.