Fourth-party risk and beyond: what your inventory doesn't see

The inventory that ends where the problem begins

Most third-party risk management programmes are built to answer a reasonable question: who do we work with directly, and how risky are they? That question makes sense as a starting point. The problem arises when it is accepted as the finishing line.

Fourth-party risk — and, more broadly, nth-party risk — describes precisely what that inventory fails to capture: the vendors of your vendors, the subcontractors of your subcontractors, the chain of dependencies that extends several links beyond any contract you have signed. Their absence from your register does not mean they cannot affect you. It means you will not see them coming.

In English-language TPRM literature, the vocabulary for this area is reasonably well settled. “Fourth-party risk” and “nth-party risk” appear consistently across FSB guidance, industry frameworks and regulatory technical standards. What is less well developed — in any language — is the specific regulatory treatment of subcontracting chains under EU law, and in particular the way GDPR and DORA each impose obligations that extend beyond the direct contractual relationship. That is the gap this article addresses.

First, second, third — and the tier nobody monitors

In standard risk management terminology, the first party is your own organisation. The second party is your customer. The third party is any external vendor with whom you maintain a direct contractual relationship: the cloud infrastructure provider, the software developer, the payment processor, the industrial control systems maintenance firm.

The fourth party is that vendor's vendor — the subcontractor delivering critical services to your third party without your knowledge, without a contract between you, and without any visibility on your side. The fifth party is that subcontractor's supplier. And so on, forming a chain whose actual length is almost never known with precision.

The term “nth-party” is the shorthand for any link beyond the third party, regardless of how many tiers of subcontracting exist. The precise number of tiers matters less than the underlying fact: each one can materialise a real risk for your organisation despite the absence of any formal relationship with the actors involved.

SolarWinds: the anatomy of a fourth-party incident

The SolarWinds attack, discovered in December 2020, remains the most thoroughly documented example of how supply chain risk propagates through layers of subcontracting. The attackers — attributed to the APT29 group — did not compromise affected government agencies and enterprises directly. They compromised the software build pipeline of SolarWinds, a network management tool vendor used by thousands of organisations. Through a backdoor inserted into legitimate updates of the Orion product, they gained access to the networks of approximately 18,000 customers.

For most affected organisations, SolarWinds was a third party. The actual attack vector, however, was SolarWinds' own software supply chain: a fourth-party problem that no vendor assessment questionnaire in any organisation's TPRM programme was designed to detect. The right question was not “does SolarWinds have sound security practices?” but “what access do SolarWinds' own suppliers have to its development pipeline?” — and that question was not in anyone's inventory.

The incident also illustrates why fourth-party risk is not merely theoretical: the harm flowed through a relationship that the affected organisations did not know existed, could not have discovered through standard due diligence and had no contractual mechanism to govern. That combination — invisible, uncontracted and consequential — is precisely what makes this category of risk structurally different from direct vendor risk.

What GDPR says about sub-processors

European regulation addressed the subcontracting chain problem before the TPRM field had settled on terminology, though from the specific vantage point of personal data processing. Article 28(2) of the General Data Protection Regulation establishes that a processor cannot engage a sub-processor without the prior specific or general written authorisation of the controller. Where general authorisation is granted, the processor must inform the controller of any intended changes, and the controller retains the right to object.

Article 28(4) is where the fourth-party management mechanism becomes explicit: the same data protection obligations imposed on the processor by the controller must be imposed on the sub-processor by contract. If the sub-processor fails to comply, the original processor remains fully liable to the controller. Responsibility cannot be delegated further down the chain; liability follows the original contractual relationship upward regardless of how many tiers exist below it.

The European Data Protection Board reinforced this interpretation in a 2024–2025 opinion on reliance on processors and sub-processors, clarifying that the chain of obligations must be unbroken at every link and that controllers carry a duty to verify, not merely to contractually require, that sub-processor arrangements satisfy the regulation's requirements.

The practical consequences are serious. Data protection authorities across the EU have sanctioned processors for engaging sub-contractors without controller authorisation, applying fines that reflect the gravity of the infraction rather than its complexity. A sub-processor arrangement that was never disclosed to the controller is not a paperwork failure — it is a material breach of the legal basis on which the processing rests.

DORA: subcontracting as a systemic risk problem

Where GDPR approached subcontracting chains through the lens of data protection, the Digital Operational Resilience Act — DORA, Regulation (EU) 2022/2554 — approaches them through the lens of financial system stability. The result is a more demanding regime in terms of documentation, governance and subcontracting chain visibility, and one that explicitly frames fourth-party exposure as a source of systemic risk rather than a bilateral compliance issue.

Article 25 of DORA governs subcontracting arrangements supporting critical or important functions of financial entities. An ICT provider wishing to subcontract material parts of a service must obtain prior written authorisation from the financial entity. Any change to subcontractors must be notified with sufficient advance notice for the entity to assess the impact and, if appropriate, object before the change takes effect.

The regulatory technical standards on subcontracting under DORA introduce three operational obligations that go considerably further than contract management. First, providers must maintain a structured subcontractor inventory organised by service delivered — not a generic vendor list, but a document that maps which subcontractors perform which functions within the contracted service. Second, the relevant clauses from Article 30 — the minimum contractual requirements — must be transmitted down the chain by contract, so that every subcontractor involved in a critical function carries the same baseline obligations as the primary provider. Third, financial entities must document their exposure to concentration, specifically including dependence on a single hyperscaler that is shared across multiple tiers of the supply chain.

This third requirement connects directly to nth-party risk in its most common and least visible form: multiple distinct providers that all run on the same cloud infrastructure do not represent independent risks. They represent a single point of failure, invoiced separately.

The inventory problem and how to approach it

Building fourth-party visibility does not require mapping the complete chain down to the last subcontractor of every vendor in your portfolio. That is an operationally unachievable objective that also distracts from the substantive problem. The most effective approach is criticality-based: identify which services provided by third parties are critical to your essential functions, and for those specific services, require the vendor to provide an inventory of their own subcontractors alongside documentation of the obligations they have transmitted to those subcontractors.

The Financial Stability Board articulated this approach in its December 2023 final report on third-party risk management and oversight, emphasising the need for a complete management lifecycle that includes identifying systemic dependencies on shared providers. The recommendation is not to audit every subcontractor of every third party, but to understand the map of critical dependencies well enough to locate the real concentrations of risk — and to be able to demonstrate that understanding to supervisory authorities.

In practical terms, this translates to a specific set of due diligence questions for critical vendor onboarding and periodic review: What proportion of the contracted service is delivered through subcontractors? Which subcontractors have access to critical systems or data? Do those subcontractors carry the same contractual obligations as the primary vendor? How does the provider manage risk from its own supply chain, and how frequently is that supply chain reviewed?

The answers to these questions cannot guarantee that a fourth-party incident will not occur. What they provide is the ability to design compensating controls, build realistic contingency plans and — under DORA — demonstrate to the supervisory authority that the financial entity understands its actual dependency map, as opposed to the version of it that its inventory reflects.

Concentration as a multiplier of nth-party risk

There is one fourth-party risk scenario that deserves specific attention because it is especially difficult to detect through conventional means: shared infrastructure concentration.

When several of your critical vendors use the same hyperscaler to deliver their services, a disruption to that hyperscaler does not generate one vendor incident — it generates all of them simultaneously. Your third-party inventory may show ten distinct vendors with individually acceptable risk ratings, each with its own certifications and its own contractual obligations. If nine of the ten run on the same cloud platform, the effective risk is that of a single provider carrying the combined criticality of all nine. Ten risk assessments have been conducted; one risk has been assessed.

This is precisely the problem that DORA addresses through Article 29 on ICT concentration risk, and that the FSB identifies as one of the primary sources of systemic risk in the financial sector. The European Banking Authority requires financial entities to document and assess this risk explicitly before establishing new ICT vendor relationships, and supervisors expect that documentation to reflect actual infrastructure dependencies — not just the contractual counterparties that appear in the register.

Fourth-party risk is not a theoretical abstraction or a category that regulators have invented to generate paperwork. It is the structural gap between the security perimeter your inventory describes and the actual perimeter that defines your exposure. Closing that gap starts with acknowledging where the inventory ends — which is exactly where the problem begins.