96% Breached: Third-Party Cyber Risk in Europe's Top 100 Banks

The Universality of Third-Party Breach Exposure

When 96% of a population shares a characteristic, that characteristic is no longer a risk factor — it is a baseline condition. SecurityScorecard's 2025 report on Europe's top 100 financial institutions crossed that threshold: 96 of 100 banks experienced at least one third-party breach, up from 78% the previous year. Fourth-party exposure — breaches at the suppliers of suppliers — reached 97%.

These are not theoretical exposures derived from vulnerability scanning. They are documented security incidents at third-party providers that maintain contractual relationships with the assessed banks. The breach may have been a ransomware attack on a SaaS provider, a data exfiltration from a managed service provider, a credential compromise at a consulting firm with network access, or a supply chain attack through a software vendor's update mechanism. The common thread: the bank's security perimeter was violated not through its own systems but through the systems of organizations it depends on.

The year-over-year acceleration — from 78% to 96% — is the more alarming signal. It indicates that third-party breach exposure is not plateauing but intensifying. The 18-percentage-point increase in a single year reflects both the expanding scope of third-party relationships (more vendors, more integrations, more data sharing) and the increasing sophistication of attacks targeting the technology supply chain.

For DORA compliance, the implications are foundational. Pillar IV (Art. 28-44) was designed for exactly this risk landscape. But the 96% figure suggests that even DORA's requirements, as currently implemented, may be insufficient if institutions approach third-party risk management as a compliance exercise rather than an operational imperative.

The Geography of Breach Exposure

SecurityScorecard's country-level data reveals significant geographic variation in third-party breach exposure, correlated with the sophistication and interconnectedness of each country's financial sector:

Switzerland's position at the top of the ranking is not surprising. Swiss banks are among the world's most technologically sophisticated, with extensive global operations, complex wealth management platforms, and deep integrations with financial market infrastructure. Each integration point, each technology vendor, each managed service represents a potential breach vector. The 171.5 average means that a typical major Swiss bank experienced third-party breaches at a rate of more than three per week — a tempo that overwhelms any manual monitoring capability.

The Netherlands' second-place ranking and 42% year-over-year increase reflect the Dutch financial sector's particular characteristics: high technology adoption, concentrated market structure (a few large banks with extensive vendor ecosystems), and deep integration with EU financial market infrastructure.

The geographic pattern carries a consistent message: the more technologically sophisticated and interconnected a country's financial sector, the higher its third-party breach exposure. Technology sophistication creates operational efficiency but simultaneously expands the attack surface. DORA's Art. 4 proportionality principle — which calibrates requirements to the entity's "size and overall risk profile, and the nature, scale, and complexity of their services, activities, and operations" — should be read in this context. More complex institutions face more complex third-party risk, and proportionality demands correspondingly more rigorous management.

The Concentration Multiplier: 15 Companies, 62% of Market

The concentration data underlying the breach statistics is arguably more consequential than the breach rates themselves. SecurityScorecard's analysis found that just 15 companies represent 62% of the global technology market. When those companies experience security incidents, the blast radius extends across the financial sector:

The concentration creates a mathematical certainty of correlated breach exposure. If a bank uses 200 technology vendors, and the top 15 technology companies provide services to (directly or through the supply chain) most of those vendors, a breach at any of those 15 companies cascades through the bank's vendor ecosystem. The bank may have "diversified" its vendor portfolio, but the underlying technology infrastructure is concentrated in the same 15 providers.

This is the concentration risk that Art. 29 addresses. Art. 29(2) requires financial entities to consider whether contractual arrangements would lead to concentration risks including: (a) contracting with a provider that is not easily substitutable, (b) multiple arrangements with the same or closely linked providers, and (c) dependency on a provider on which other financial entities also rely.

The SecurityScorecard data proves that (c) is not a hypothetical risk. It is the dominant risk. The shared dependency on a small number of technology providers creates correlated breach exposure that no individual institution can manage through bilateral vendor governance alone.

From Third-Party to Fourth-Party: The Depth of Dependency

The 97% fourth-party breach rate reveals the next layer of the problem. Fourth-party risk — exposure through the suppliers of your suppliers — is both harder to assess and harder to manage than third-party risk.

Consider the dependency chain for a typical banking service: the bank contracts with a SaaS provider (third party) that runs on AWS (fourth party) and uses a specific database service (fourth party) and a monitoring platform (fourth party). The SaaS provider may also rely on a code repository (fourth party), a CI/CD pipeline service (fourth party), and a secrets management tool (fourth party). A breach at any point in this chain can propagate to the bank's data and operations.

DORA's Art. 28(8) addresses subcontracting — the contractual dimension of fourth-party risk. Art. 30(2)(a) requires contractual provisions ensuring that the ICT third-party service provider obtains the financial entity's approval before sub-outsourcing services supporting critical functions. But contractual provisions, while necessary, are not sufficient to manage the actual risk.

The practical challenge is informational. Financial entities generally do not have visibility into their third-party providers' technology dependencies. The SaaS provider does not typically disclose that it runs on AWS, uses MongoDB Atlas for its database, and Datadog for monitoring — this is considered proprietary architecture information. Yet each of these dependencies is a potential breach vector that affects the bank's data.

DORA's Register of Information (Art. 28(3)) includes sub-outsourcing fields, but the ESAs' first round of validation checks in April-May 2025 found these fields among the most sparsely populated in submitted registers. Institutions acknowledged the requirement but could not obtain the data needed to fulfill it.

The Attack Vector Shift: Supply Chain as Primary Target

The doubling of supply chain attacks between 2021 and 2025 is a structural shift in the threat landscape. Attackers are rationally adapting their strategies to the concentration of the technology market. Why compromise one bank — which has invested heavily in perimeter security, endpoint detection, and security operations — when you can compromise one technology provider and gain access to 100 banks simultaneously?

The economics are compelling. A direct attack on a major bank might require months of reconnaissance, custom exploit development, and careful lateral movement to avoid detection. A supply chain attack on a technology vendor might require exploiting a single vulnerability in a software update mechanism — and the compromised update is then distributed, by the vendor's own infrastructure, to every customer.

The 30% figure — nearly a third of all breaches involving third parties as the initial attack vector — confirms that the financial sector's security investment is creating a displacement effect. As banks' direct security posture improves, attackers route around it through the softer targets in the supply chain.

For DORA compliance, this shift has three implications:

Testing must include supply chain scenarios. Art. 25's resilience testing requirement must encompass scenarios where a trusted vendor's software or service is compromised. Testing only the bank's own systems against external attacks misses the primary attack vector.

Incident detection must cover supply chain indicators. Art. 17's incident management requirement must include detection capabilities for supply chain compromises — which often manifest not as traditional security alerts but as anomalous behavior from trusted software. The CrowdStrike incident of July 2024 demonstrated that a supply chain compromise can look identical to a legitimate software update until the moment of impact.

Third-party risk assessment must be continuous, not periodic. Art. 28's third-party risk management requirements cannot be satisfied by annual vendor assessments. The threat landscape changes faster than assessment cycles. Continuous monitoring of third-party security posture — through external scoring services, dark web monitoring, and real-time threat intelligence — is the operational minimum.

What DORA Pillar IV Actually Requires

Against this backdrop, DORA's Pillar IV requirements are not bureaucratic impositions. They are the minimum governance infrastructure for operating in a technology ecosystem where third-party breach exposure is universal:

Art. 28(1-2) — Risk management principles. The foundational requirement: financial entities must manage ICT third-party risk as part of their overall ICT risk management framework. This means third-party risk is not a procurement function or a compliance exercise — it is a core risk management discipline with board-level governance.

Art. 28(3) — Register of Information. The register provides the data foundation for all other Pillar IV requirements. Without knowing who your providers are, what services they deliver, which functions they support, and where they process data, no meaningful risk management is possible.

Art. 28(4-7) — Contractual requirements for critical functions. For services supporting critical or important functions, DORA requires enhanced contractual protections including service levels, audit rights, incident notification, subcontracting approval, data location specificity, and exit strategies. These provisions create the contractual infrastructure for managing the relationship during a breach event.

Art. 29 — Concentration risk. The requirement to assess and manage concentration risk — including systemic provider dependency, corporate group concentration, and substitutability — directly addresses the 15-company, 62%-market-share reality documented by SecurityScorecard.

Art. 30 — Key contractual provisions. The detailed contractual requirements ensure that financial entities have the rights and information needed to manage third-party risk operationally — not just on paper.

Art. 31-44 — CTPP oversight. The Lead Overseer regime provides a regulatory backstop for the concentration risk that individual institutions cannot address alone. When a technology provider is so systemically important that its breach affects the entire financial sector, individual institution-level governance is necessary but insufficient.

A Third-Party Risk Management Maturity Model

The SecurityScorecard data allows institutions to benchmark their third-party risk management against the empirical threat landscape:

Most institutions assessed by SecurityScorecard are at Level 1 or 2. The 96% breach rate is the empirical consequence of operating at these maturity levels. The transition to Level 3 — continuous monitoring with structured response — is the minimum capability needed to manage the current threat landscape. Level 4 — integration with the broader ICT risk framework — is what DORA's architecture envisions as the steady state.

Actionable Recommendations

For institutions processing the 96% breach reality, five actions are immediate:

1. Map your actual concentration. Not the vendor count in your register — the real technology concentration in your infrastructure. If 60% of your critical services ultimately depend on the same three cloud platforms, your concentration risk is high regardless of how many vendor names appear in the register. Use the HHI methodology weighted by function criticality.

2. Implement continuous third-party monitoring. Annual assessments provide a snapshot; the threat landscape moves daily. External security rating services (SecurityScorecard, BitSight, UpGuard) provide continuous visibility into vendor security posture changes. Dark web monitoring identifies compromised credentials associated with your vendors. These are not replacements for formal assessments — they are the early warning layer.

3. Test your supply chain incident response. When your critical SaaS provider is breached, what do you do? Who is notified? What containment actions are available? Is there a playbook? Has it been exercised? Art. 25's testing requirement should include at least one supply chain compromise scenario per annual testing cycle.

4. Demand sub-outsourcing transparency. The Register of Information's sub-outsourcing fields are sparse because institutions have not demanded the data. DORA Art. 30(2)(a) gives you the contractual basis for demanding sub-outsourcing information. Exercise it — and treat provider resistance to transparency as a risk factor in itself.

5. Participate in sector information sharing. The 10 cybercriminal groups responsible for 44% of global incidents are common adversaries. Intelligence shared between institutions about these groups' tactics, techniques, and procedures (TTPs) reduces the entire sector's exposure. Art. 45's information sharing encouragement is operationally justified by the threat concentration data.

The Structural Challenge

The 96% breach rate is not a problem that individual institutions can solve through individual action. It is a structural characteristic of the technology ecosystem in which European banking operates. The concentration of the technology market, the depth of supply chain dependencies, the sophistication of supply chain attacks, and the expanding scope of digital operations all drive breach exposure upward.

DORA's contribution is not to eliminate this structural risk — no regulation can. Its contribution is to ensure that financial institutions understand, measure, manage, and report the risk rather than ignore it. The Register of Information creates visibility. The concentration risk assessment quantifies exposure. The contractual provisions create governance rights. The testing requirements validate preparedness. The CTPP oversight regime addresses systemic concentration.

The institutions that achieve genuine third-party resilience — not just compliance, but actual preparedness for the breach event that is statistically near-certain — will be those that treat the 96% figure not as a data point but as a design constraint. Third-party breach is the baseline. The question is not whether it will happen, but whether the institution can detect, respond, contain, and recover when it does.

---

This analysis draws on SecurityScorecard's 2025 European Financial Services Cyber Risk Report, ENISA threat landscape data, and DORA Pillar IV requirements. Country-level estimates marked as approximate are extrapolated from published data ranges.

---

96 % impactees : le risque cyber tiers dans les 100 premieres banques europeennes

L'universalite de l'exposition aux violations tierces

Quand 96 % d'une population partage une caracteristique, cette caracteristique n'est plus un facteur de risque — c'est une condition de base. Le rapport SecurityScorecard 2025 a franchi ce seuil : 96 des 100 premieres banques europeennes ont subi au moins une violation tierce, contre 78 % l'annee precedente. L'exposition au quatrieme niveau atteint 97 %. L'acceleration — de 78 % a 96 % en un an — indique que l'exposition aux violations tierces ne plafonne pas mais s'intensifie.

La geographie de l'exposition

La Suisse mene avec 171,5 violations tierces par banque en moyenne, suivie des Pays-Bas (148,4) et du Royaume-Uni (136,2). Le schema geographique porte un message constant : plus le secteur financier d'un pays est technologiquement sophistique et interconnecte, plus son exposition aux violations tierces est elevee.

Le multiplicateur de concentration

Seulement 15 entreprises representent 62 % du marche technologique mondial. Quand ces entreprises subissent des incidents de securite, le rayon d'impact s'etend a travers le secteur financier. Les attaques de chaine d'approvisionnement ont double entre 2021 et 2025. 30 % de toutes les violations impliquent un tiers comme vecteur d'attaque initial.

Ce que le Pilier IV de DORA exige

Registre d'Information (Art. 28(3)), evaluation du risque de concentration (Art. 29), provisions contractuelles cles (Art. 30), et regime de surveillance du Superviseur Principal (Art. 31-44). Le chiffre de 96 % demontre que ces exigences ne sont pas des impositions bureaucratiques mais l'infrastructure de gouvernance minimale pour operer dans un ecosysteme technologique ou l'exposition aux violations tierces est universelle.

Recommandations

Cartographier la concentration reelle, implementer une surveillance tierce continue, tester la reponse aux incidents de chaine d'approvisionnement, exiger la transparence de la sous-traitance, et participer au partage d'information sectoriel. La violation tierce est la condition de base. La question n'est pas si elle se produira, mais si l'institution peut detecter, repondre, contenir et se retablir quand elle se produira.

---

Cette analyse s'appuie sur le rapport SecurityScorecard 2025 sur le risque cyber des services financiers europeens et les exigences du Pilier IV de DORA.