Fourth-Party Risk Under DORA: The Supply Chain Attack Surface You Can't See

The Invisible Layer

In December 2020, the SolarWinds attack compromised 18,000 organizations — including government agencies, critical infrastructure operators, and financial institutions — through a supply chain compromise. The attackers did not target the victims directly. They compromised a software vendor (SolarWinds) that the victims relied on, injecting malicious code into a routine software update. The victims were not managing SolarWinds as a risk. They were consuming SolarWinds as a tool.

In June 2023, the MOVEit file transfer vulnerability affected hundreds of organizations through a zero-day exploit in a file transfer product used by thousands of enterprises. Financial institutions that had never heard of MOVEit discovered that their payroll providers, benefits administrators, and data processors relied on it. The attack surface was not their own systems — it was the systems underneath their systems.

In 2024, the Marquis Financial Group breach exposed data from 672,000 people across 74 banks. The breach occurred not at the banks but at a third-party marketing services vendor that maintained customer data for those banks.

This is fourth-party risk: the risk that arises from your vendors' vendors, your partners' partners, the dependencies underneath the dependencies you manage. DORA addresses this through its subcontracting provisions, but the practical challenge of visibility into the fourth-party layer remains the most significant gap in most institutions' ICT third-party risk management programmes.

DORA's Subcontracting Chain Requirements

Art. 29: Subcontracting Oversight

Art. 29 establishes the framework for managing subcontracting chains. It requires financial entities to assess whether and how long or complex chains of subcontracting may impact their ability to monitor the contracted ICT services and the competent authority's ability to effectively supervise the financial entity.

The critical provisions:

The Register of Information Challenge

The register of information required under Art. 28(3) must capture ICT third-party arrangements — but the level of detail expected for subcontracting chains is where practical challenges emerge. The ESA Regulatory Technical Standards on the register template include fields for subcontractors, but most financial institutions cannot populate these fields because they lack visibility into their vendors' supply chains.

Mapping the Fourth-Party Attack Surface

The Typical Financial Institution Supply Chain

A mid-sized European bank with 50 direct ICT vendors may have 200-500 fourth parties — the vendors behind those vendors. The concentration patterns are striking:

Several patterns emerge from this mapping:

Shared fourth-party concentration. Multiple direct vendors depend on the same fourth parties. If three of your five critical vendors use the same DNS provider, your concentration risk extends beyond the first tier. The HHI analysis must account for shared dependencies.

Open source as a fourth party. Virtually every ICT vendor uses open source software. The Log4j vulnerability (December 2021) demonstrated that a single open source library embedded in thousands of products creates systemic fourth-party risk. Your core banking vendor's use of a vulnerable logging library is a fourth-party exposure.

Infrastructure convergence. The global internet infrastructure converges on a small number of DNS providers, CDN providers, certificate authorities, and cloud regions. A failure at any of these convergence points affects thousands of financial institutions simultaneously — through their fourth-party exposure, not their direct relationships.

Quantifying the Exposure

Why Current Approaches Fail

The Questionnaire Problem

Most institutions assess third-party risk through questionnaires sent to vendors. These questionnaires ask about the vendor's security posture, business continuity plans, and incident response capabilities. They rarely ask about the vendor's vendors. When they do, the vendor's response is typically a general assurance ("we manage our supply chain risk") rather than specific disclosure of fourth-party dependencies and their risk profiles.

The Contractual Gap

DORA Art. 30 requires contractual provisions covering subcontracting. But contractual provisions are only as strong as the institution's ability to enforce them. A contractual right to approve subcontracting changes is meaningless if the institution does not know when a subcontracting change occurs.

The Concentration Blindspot

Standard concentration risk analysis — including HHI calculations — operates at the first tier. An institution may conclude that it has adequate vendor diversification because it uses three cloud providers. But if all three cloud providers use the same underlying DNS infrastructure, the diversification is illusory. The 19 critical third-party providers designated under DORA's oversight framework represent first-tier concentration. The fourth-party concentration underneath them is largely unmapped.

A Practical Framework for Fourth-Party Risk Visibility

Phase 1: Map Critical Dependencies

Start with the institution's critical and important functions (per the BIA) and their direct vendor dependencies. For each critical vendor, request disclosure of:

• Material subcontractors supporting the service provided to the institution
• Infrastructure dependencies (cloud hosting, DNS, CDN, certificate authority)
• Open source dependencies via Software Bill of Materials (SBOM)

Phase 2: Identify Convergence Points

Analyze fourth-party disclosures for convergence — shared dependencies across multiple direct vendors. A single fourth party supporting three or more critical vendors represents a systemic concentration risk that must be assessed and reported.

Phase 3: Embed in Ongoing Risk Management

Fourth-party risk is not a one-time assessment. It requires continuous monitoring:

• Threat intelligence feeds that flag breaches and vulnerabilities at fourth-party providers (subscribing to information sharing arrangements under DORA Art. 45)
• SBOM monitoring that alerts when a known vulnerability affects an open source component embedded in a vendor's product
• Contractual notification requirements that obligate vendors to inform the institution of material subcontracting changes

Phase 4: Integrate Into Register of Information

The Art. 28(3) register must capture fourth-party information for critical ICT third-party arrangements. This does not mean mapping every fifth-party chip fabricator. It means documenting:

• Material subcontractors for critical ICT services
• Shared fourth-party dependencies across multiple direct vendors (convergence points)
• Known fourth-party risks and mitigating measures
• Subcontracting notification and approval provisions in contracts

Supervisory Expectations

The ESAs and the ECB are increasingly focused on subcontracting chain risk. The designation of critical third-party providers under DORA's oversight framework (Art. 31-44) creates direct supervisory access to the largest ICT providers — but this covers only the first tier.

Supervisory questions to prepare for:

• "What visibility do you have into your critical vendors' subcontracting chains?"
• "How do you assess concentration risk beyond the first tier?"
• "What happened the last time a vulnerability was discovered in a component used by one of your vendors?"
• "How quickly can you determine which of your systems are affected by a fourth-party compromise?"

Key Takeaways

• Fourth-party risk is the supply chain attack surface most institutions cannot see. SolarWinds, MOVEit, and the Marquis breach all exploited dependencies beyond the first vendor tier.
• DORA Art. 29 requires assessment of subcontracting chain complexity — institutions must know the depth and concentration of their supply chains.
• Fourth-party concentration (shared dependencies across multiple direct vendors) is a systemic risk that standard HHI analysis at the first tier misses.
• Open source software is a fourth party — every vendor's SBOM is a window into fourth-party exposure.
• Practical visibility requires phased approach: map critical dependencies, identify convergence points, embed in ongoing monitoring, integrate into the register of information.
• Contractual provisions are necessary but insufficient without ongoing monitoring and enforcement mechanisms.

---

Resume en francais

Le risque de quatrieme partie — les fournisseurs de vos fournisseurs — constitue la surface d'attaque de la chaine d'approvisionnement la plus dangereuse car la moins visible. Les attaques SolarWinds (2020), MOVEit (2023) et Marquis Financial Group (2024) ont toutes exploite des dependances au-dela du premier niveau de sous-traitance. L'article 29 de DORA exige l'evaluation de la complexite des chaines de sous-traitance, et l'article 28(3) impose un registre d'information incluant les sous-traitants. En pratique, une banque europeenne de taille moyenne avec 50 fournisseurs directs peut avoir 200 a 500 quatriemes parties et 5 000 a 20 000 dependances open source. Les points de convergence — un meme fournisseur DNS servant quatre de vos cinq fournisseurs critiques — creent un risque de concentration systemique invisible dans les analyses HHI de premier niveau. Ce guide propose un cadre en quatre phases : cartographier les dependances critiques, identifier les points de convergence, integrer dans la surveillance continue (threat intelligence, SBOM, notifications contractuelles) et documenter dans le registre d'information. Les provisions contractuelles (Art. 30) sont necessaires mais insuffisantes sans mecanismes de surveillance et d'application actifs.