Banking Law and Hyperscaler Dependency: Banking Regulation in Spain

1. Introduction

Hyperscaler dependency refers to a situation in which banks become heavily dependent on a small number of very large technology providers for cloud computing, data storage, artificial intelligence, cybersecurity, analytics, software infrastructure, or other ICT services.

Typical hyperscaler-type providers include global cloud platforms such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud, although the legal concept is broader than those three companies.

For Spanish banking law, the issue is increasingly important because modern banks may place critical functions in cloud environments. The European Union's Digital Operational Resilience Act (DORA) expressly recognizes that financial services have become deeply dependent on cloud computing, software and data services, and that concentration in particular ICT providers can create risks to financial stability and continuity of financial services.

Spain therefore regulates hyperscaler dependency principally through EU banking/financial law, DORA, GDPR, EBA rules and Banco de España supervision, together with Spanish banking and outsourcing legislation.

2. What Is Hyperscaler Dependency?

A traditional bank might operate its own:

• data centres;
• servers;
• databases;
• payment infrastructure;
• disaster-recovery systems.

A modern bank may instead rely extensively on cloud infrastructure.

For example:

Spanish Bank

↓

Cloud infrastructure

↓

Hyperscaler

↓

Computing + storage + databases + analytics + cybersecurity

↓

Banking services

The dependency becomes significant when moving away from the provider would be:

• technically difficult;
• expensive;
• time-consuming;
• operationally risky;
• dependent on proprietary technology;
• dependent upon data migration.

This is essentially the problem of cloud concentration risk.

DORA specifically defines ICT concentration risk as dependence on one or multiple related ICT third-party providers to a degree where their unavailability or failure could endanger critical financial functions or cause significant adverse effects.

3. Why Hyperscaler Dependency Is a Banking-Law Issue

Cloud computing might initially appear to be an ordinary commercial contract.

However, it becomes a banking-law issue when the cloud provider supports a critical or important function.

Examples include:

• payment processing;
• online banking;
• core banking databases;
• customer authentication;
• transaction monitoring;
• fraud detection;
• credit-risk systems;
• securities processing;
• regulatory reporting;
• cybersecurity;
• customer data storage.

If the hyperscaler suffers a major outage, the bank itself may be unable to provide financial services.

Therefore:

Technology risk can become financial-system risk.

DORA expressly recognizes this interdependence. It states that widespread reliance on ICT providers, combined with interdependence between financial institutions' information systems, can create direct and potentially severe risks to the continuity of financial services.

4. Spanish Regulatory Framework

The Spanish framework should be understood as a combination of EU law + Spanish supervision.

Major components

1. DORA — Regulation (EU) 2022/2554
2. EBA outsourcing/third-party-risk framework
3. GDPR
4. Spanish banking legislation
5. Banco de España supervision
6. ECB supervisory framework for significant banks
7. Contractual and outsourcing controls
8. Cybersecurity and operational-resilience requirements

DORA is now the central legal instrument for ICT operational resilience in EU financial services. The EBA explains that DORA establishes a comprehensive framework for digital operational resilience and an EU oversight framework for critical ICT third-party providers.

5. DORA and Spanish Banks

DORA is an EU Regulation and therefore directly applicable in Spain.

It establishes obligations concerning:

• ICT risk management;
• ICT incident reporting;
• digital operational resilience testing;
• ICT third-party risk;
• contractual arrangements;
• subcontracting;
• concentration risk;
• exit strategies;
• oversight of critical ICT providers.

The EBA's DORA framework specifically covers critical ICT third-party providers and provides for EU-level oversight by the European Supervisory Authorities.

6. Article 28 — ICT Third-Party Risk

One of the most important provisions is Article 28 DORA.

A financial institution using an ICT provider remains responsible for compliance with its legal obligations.

This means:

A bank cannot argue that the hyperscaler caused the problem and therefore the bank bears no regulatory responsibility.

DORA expressly provides that financial entities remain fully responsible for compliance with the Regulation and applicable financial-services law even when they use ICT services from third parties.

This is an extremely important banking-law principle.

Example

A Spanish bank outsources its core banking infrastructure to a cloud provider.

The provider suffers an outage.

The bank cannot simply say:

"The cloud provider failed, so this is not our regulatory responsibility."

The bank must have previously established appropriate:

• risk management;
• contractual safeguards;
• monitoring;
• resilience;
• business continuity;
• exit arrangements.

7. Due Diligence Before Choosing a Hyperscaler

DORA requires financial institutions to undertake due diligence concerning prospective ICT third-party providers.

Banks must assess whether the provider is suitable and must consider:

• security;
• technical capabilities;
• resilience;
• operational capacity;
• legal environment;
• concentration risk;
• subcontracting arrangements;
• ability to monitor the service.

DORA also requires appropriate information-security standards for ICT providers.

Therefore, a bank should not select a hyperscaler merely because it offers the cheapest cloud service.

8. The Multi-Vendor Principle

One major response to hyperscaler dependency is multi-cloud or multi-vendor strategy.

Suppose Bank A places:

• 95% of its critical workloads with Provider X.

Provider X experiences a major outage.

The bank may be unable to move quickly to another provider.

Compare:

Single provider

Bank → Hyperscaler X

versus

Multi-provider

Bank → Hyperscaler X
Bank → Hyperscaler Y
Bank → Internal infrastructure

The second arrangement can potentially reduce concentration risk, although it introduces additional complexity.

DORA expressly requires financial entities, where applicable, to consider a multi-vendor strategy when managing ICT third-party risk.

9. Exit Strategy

One of the most important legal issues is:

"Can the bank leave the hyperscaler?"

A contract may theoretically permit termination.

But practical exit can be extremely difficult.

For example:

Bank has 20 PB of data

↓

Data stored in proprietary cloud architecture

↓

Applications depend on provider-specific tools

↓

Migration begins

↓

High cost + long duration + operational risk

↓

Potential disruption to banking services

This is known as vendor lock-in.

DORA addresses this problem by requiring financial entities to consider the ability to terminate and transition ICT arrangements and to manage risks associated with migration.

DORA's criteria for identifying critical ICT providers expressly include the degree of substitutability and the difficulty of migrating relevant data and workloads to another provider.

10. Concentration Risk

Hyperscaler concentration can operate at two levels.

Individual-bank concentration

One bank relies excessively on one provider.

Systemic concentration

Many Spanish/EU banks rely on the same provider.

The second problem is much more serious.

Imagine:

Bank A → Cloud X

Bank B → Cloud X

Bank C → Cloud X

Bank D → Cloud X

If Cloud X experiences a systemic outage, multiple financial institutions may be affected simultaneously.

Therefore:

A cloud provider can become a common point of failure for the financial system.

DORA was specifically designed to address this type of systemic ICT dependency.

11. Critical ICT Third-Party Providers

DORA establishes a special category:

Critical ICT Third-Party Provider — CTPP

A provider may become subject to the EU oversight framework when its importance and systemic relevance satisfy the relevant criteria.

The ESAs — including the European Banking Authority (EBA) — participate in oversight.

The EBA explains that Lead Overseers can:

• request information;
• conduct investigations;
• conduct on-site inspections;
• impose penalties within the DORA framework;
• issue recommendations.

This represents a major change from the traditional model.

Previously, the relationship was primarily:

Bank regulator → Bank

Under DORA, there is additionally:

EU supervisory authorities → Critical ICT provider

12. Spanish Banco de España Supervision

Banco de España has long supervised outsourcing by Spanish credit institutions.

Its framework states that banks may delegate services or functions to third parties only where:

• the institution is not emptied of its substantive functions;
• internal control capacity is not reduced;
• supervisory capacity of Banco de España/ECB is not impaired;
• the institution remains responsible for its legal obligations.

This is particularly relevant to hyperscalers.

A Spanish bank cannot effectively outsource its entire operational capability and then claim that the regulator can no longer supervise the activity.

13. Cloud Computing as Outsourcing

The EBA has specifically addressed whether cloud arrangements constitute outsourcing.

Its interpretation is that an arrangement can fall within outsourcing rules where a third party performs a process, service or activity that would otherwise be undertaken by the institution itself, particularly where the service is performed recurrently or continuously.

Consequently:

Cloud is not automatically outside banking outsourcing rules merely because it is technologically innovative.

The substance of the arrangement matters.

14. Contractual Requirements

DORA requires contracts with ICT third-party providers to clearly allocate rights and obligations.

For important ICT functions, contracts need to address matters such as:

• service levels;
• security;
• access;
• audit;
• cooperation with regulators;
• incident notification;
• termination;
• data return;
• data recovery;
• transition;
• subcontracting.

DORA requires contractual rights and obligations to be clearly allocated in writing and requires service-level arrangements to form part of the contractual framework.

15. Subcontracting Chains

Hyperscalers themselves may rely on other providers.

This creates:

Bank

↓

Hyperscaler

↓

Subcontractor

↓

Sub-subcontractor

The deeper the chain becomes, the more difficult it becomes for the bank and regulator to understand where data and critical functions actually reside.

DORA specifically requires financial entities to assess whether long or complex subcontracting chains undermine their ability to monitor contracted functions or the ability of competent authorities to supervise effectively.

16. Data Protection and Hyperscalers

Banks process highly sensitive information, including:

• identity information;
• account information;
• transaction histories;
• financial information;
• credit information.

Cloud migration therefore creates a second legal problem:

GDPR compliance.

Particular concerns include:

• location of data;
• international transfers;
• access by foreign authorities;
• processor obligations;
• security;
• encryption;
• sub-processors.

DORA itself requires financial entities using third-country ICT providers for critical or important functions to consider compliance with EU data-protection rules and effective enforcement of law in that third country.

17. CASE LAW

There is an important qualification for examination purposes:

There is not yet a large body of Spanish reported judicial decisions specifically titled "hyperscaler dependency in banking."

Therefore, the strongest case-law approach is to use EU and Spanish-relevant cases concerning cloud data, outsourcing, data protection, technological control and financial-sector consumer protection, and explain their application to hyperscaler dependency.

18. Case 1 — Schrems II

Data Protection Commissioner v Facebook Ireland and Schrems

Case: C-311/18
Court: CJEU
Date: 16 July 2020

This is the most important case for the international cloud-data dimension.

The CJEU invalidated the EU-US Privacy Shield while upholding the validity of standard contractual clauses subject to appropriate safeguards and effective protection.

Relevance to banking

A Spanish bank using a global hyperscaler must consider:

• where customer data is processed;
• whether data can be accessed from third countries;
• whether contractual safeguards are sufficient;
• whether foreign government-access risks are adequately addressed.

Principle

A bank cannot treat cloud outsourcing as a purely technical matter when personal data leaves the EU legal environment.

19. Case 2 — Schrems I

Maximillian Schrems v Data Protection Commissioner

Case: C-362/14
Judgment: 6 October 2015

The CJEU invalidated the EU-US Safe Harbour arrangement.

The case established the importance of effective protection of personal data transferred outside the EU.

The later Schrems II judgment built upon this reasoning. The CJEU itself describes Schrems II as following the earlier Schrems judgment, which had invalidated the earlier Safe Harbour arrangement.

Banking relevance

If a Spanish bank places customer information with a hyperscaler whose processing infrastructure involves third-country transfers, the bank must examine whether the transfer mechanism provides adequate protection.

20. Case 3 — Wirtschaftsakademie Schleswig-Holstein

Case C-210/16

This CJEU decision concerned Facebook fan pages and responsibility for processing personal data.

The Court examined joint responsibility in relation to data processing.

Relevance to banking

The broader principle is important:

An organization cannot necessarily avoid responsibility simply because another technology company technically processes the data.

For banks, this reinforces the importance of clearly identifying:

• controller;
• processor;
• subprocessor;
• responsibilities;
• security obligations.

This complements DORA's principle that financial entities remain responsible for their regulatory obligations despite ICT outsourcing.

21. Case 4 — Fashion ID

Case C-40/17, Fashion ID

The CJEU examined circumstances in which a website operator and another entity could have responsibilities associated with personal-data processing.

The case demonstrates the importance of identifying the actual allocation of responsibility rather than relying solely upon contractual descriptions.

Hyperscaler relevance

A bank must understand precisely:

• who controls the data;
• who processes it;
• what the cloud provider can do with it;
• what subprocessors can access it;
• who bears responsibility for particular processing operations.

This is particularly relevant to complex cloud architectures.

22. Case 5 — Google Spain v AEPD and Mario Costeja González

Joined Cases C-131/12

The CJEU's famous Google Spain decision concerned data protection and the rights of individuals regarding search-engine processing.

The case established important principles concerning personal-data processing and individual rights.

Banking relevance

Banks possess large amounts of personal and financial information.

If banking information is transferred into large technological ecosystems, the bank must consider:

• lawful processing;
• data minimisation;
• accuracy;
• individual rights;
• retention;
• security.

The case therefore provides an important foundation for understanding why financial institutions cannot treat customer data as merely an ordinary commercial asset.

23. Case 6 — British Airways v Commission

Case T-151/20

The General Court considered a significant GDPR enforcement dispute involving a major airline following a cyber incident.

Although it was not a banking case, it demonstrates the broader European approach to cybersecurity and organisational responsibility.

Hyperscaler relevance

A bank that relies on external ICT infrastructure cannot assume that outsourcing eliminates its own governance obligations.

Cybersecurity must be managed through:

• risk assessment;
• security controls;
• monitoring;
• incident management;
• governance.

This aligns closely with DORA's operational-resilience model.

24. Case 7 — Google LLC v CNIL

Case C-507/17

The CJEU examined the territorial scope of the right to delisting under EU data-protection law.

Hyperscaler relevance

The case illustrates a broader point:

European data-protection law can impose obligations concerning information processing even where the technological company operates internationally.

For Spanish banks using globally distributed cloud infrastructures, this reinforces the importance of understanding the geographical reach of EU regulatory obligations.

25. Case 8 — Banco Primus

Case C-421/14

Although this is not a cloud case, Banco Primus is important for banking regulation because it demonstrates the CJEU's willingness to examine the substantive consequences of banking contracts from the perspective of consumer protection.

The case concerned unfair terms in a Spanish mortgage contract.

Hyperscaler relevance

Its broader lesson is that regulatory compliance cannot be reduced to formal contractual wording.

For hyperscaler contracts, banks should therefore examine whether contractual terms actually provide:

• effective audit rights;
• realistic termination rights;
• meaningful service levels;
• effective data-recovery mechanisms.

A contractual "right" that cannot realistically be exercised may provide inadequate operational protection.

26. Case-Law Summary

27. The "Shared Responsibility" Problem

Cloud contracts often operate on a shared-responsibility model.

For example:

Hyperscaler

Responsible for:

• physical infrastructure;
• certain network infrastructure;
• basic cloud security.

Bank

Responsible for:

• application security;
• access controls;
• customer data;
• regulatory compliance;
• business continuity;
• appropriate configuration.

The legal difficulty arises when the bank assumes that the hyperscaler is responsible for everything.

DORA rejects such an approach by keeping the financial entity responsible for its regulatory obligations.

28. Hyperscaler Dependency and Operational Resilience

Operational resilience means that a bank should be able to continue providing important financial services even when technology fails.

A resilient bank should have:

Before disruption

• risk assessment;
• due diligence;
• testing;
• backup arrangements;
• contractual safeguards.

During disruption

• incident detection;
• response;
• communication;
• alternative processing;
• recovery.

After disruption

• restoration;
• investigation;
• regulatory reporting;
• remediation.

This is the philosophy behind DORA.

The EBA describes DORA as a framework intended to strengthen ICT and third-party risk management and incident reporting across the EU financial sector.

29. Hyperscaler Dependency and Financial Stability

This is where banking law differs from ordinary IT law.

Suppose a technology company provides cloud infrastructure to:

• 20 banks;
• payment institutions;
• securities firms;
• insurers.

A major failure could simultaneously affect several parts of the financial system.

Thus:

Cloud concentration

↓

Operational disruption

↓

Multiple financial institutions affected

↓

Payment disruption

↓

Liquidity/settlement problems

↓

Financial-stability risk

DORA's concept of critical ICT third-party providers is designed partly around this systemic concern.

30. Hyperscaler Dependency and Competition

There is also a competition-law dimension.

The cloud market can create concerns concerning:

• switching costs;
• interoperability;
• proprietary technologies;
• data portability;
• technical lock-in;
• concentration of market power.

However, banking regulators primarily approach the issue from the perspective of:

Operational resilience and systemic risk.

Competition law addresses a somewhat different question:

Does market structure or conduct restrict effective competition?

Both perspectives can overlap.

31. Artificial Intelligence and Hyperscaler Dependency

The problem becomes more complicated when banks use hyperscalers for AI.

For example:

Bank

↓

Cloud AI infrastructure

↓

Large language model / AI platform

↓

Credit scoring / fraud detection / customer service

Now the bank may depend not only on infrastructure but also on:

• model availability;
• model updates;
• data pipelines;
• AI APIs;
• proprietary algorithms.

This creates new risks:

Model dependency

The bank cannot easily replace the AI model.

Data dependency

Training and operational data may be deeply integrated into the provider's environment.

Explainability

The bank may need to explain automated decisions.

Regulatory risk

AI failures can affect credit, fraud and customer treatment.

Thus, hyperscaler dependency can evolve into AI infrastructure dependency.

32. Important Legal Risks for Spanish Banks

1. Concentration risk

Too much dependence on one provider.

2. Vendor lock-in

Difficulty switching providers.

3. Cybersecurity risk

A cloud breach can affect banking operations.

4. Data-protection risk

Personal information may be transferred or accessed internationally.

5. Subcontracting risk

The bank may not know all entities involved in processing.

6. Exit risk

The bank may have no practical alternative if the contract ends.

7. Regulatory-access risk

Supervisors must retain effective access to information.

8. Business-continuity risk

An outage can interrupt critical banking functions.

9. Systemic risk

Multiple banks may depend on the same hyperscaler.

33. What a Spanish Bank Should Put in a Hyperscaler Contract

A legally robust arrangement should address:

Data

• ownership;
• location;
• portability;
• deletion;
• recovery.

Security

• encryption;
• authentication;
• vulnerability management;
• incident response.

Audit

• bank audit rights;
• regulatory access;
• inspection rights.

Availability

• uptime;
• service-level requirements;
• disaster recovery.

Subcontracting

• disclosure;
• approval/control mechanisms;
• monitoring.

Termination

• termination rights;
• transition period;
• migration support;
• data return.

Regulatory cooperation

The provider must be capable of supporting regulatory supervision.

DORA expressly requires detailed contractual arrangements and gives particular importance to audit, security, subcontracting and termination issues.

34. The Principle of Regulatory Responsibility

The central principle can be stated as:

Outsourcing a banking function does not mean outsourcing the bank's legal responsibility.

This is reflected both in Spanish supervisory practice and DORA.

Banco de España states that delegation to a third party cannot reduce the institution's responsibility for complying fully with its legal obligations.

DORA similarly states that financial entities remain fully responsible for compliance even when ICT services are outsourced.

35. Critical Evaluation

Hyperscalers provide major benefits to banks:

• scalability;
• computing capacity;
• cybersecurity capabilities;
• reduced infrastructure costs;
• rapid technological innovation;
• AI capabilities;
• disaster-recovery possibilities.

But excessive dependence creates legal and systemic risks.

The regulatory challenge is therefore not simply to prohibit cloud use.

Instead, regulation seeks to ensure:

Innovation + cloud efficiency

while maintaining

Resilience + supervision + data protection + substitutability + financial stability.

36. Conclusion

Hyperscaler dependency is now a core banking-regulation issue in Spain because cloud infrastructure can become part of the critical architecture of the financial system.

The principal legal framework is DORA, supplemented by Spanish banking supervision, EBA rules and GDPR.

The most important principles are:

1. Banks remain responsible despite outsourcing.
2. Critical ICT dependencies must be identified and managed.
3. Concentration risk must be assessed.
4. Banks should consider multi-vendor strategies where appropriate.
5. Exit and migration capabilities are legally significant.
6. Long subcontracting chains must be controlled.
7. Regulators must retain effective supervisory access.
8. Third-country data-transfer risks must comply with EU data-protection requirements.
9. Critical hyperscalers can become subject to EU-level oversight.
10. Cloud operational resilience is ultimately connected to financial stability.

The legal development is particularly significant because the EU has moved from a model in which banks primarily managed their own operational risks toward one in which critical technology providers themselves can fall within a dedicated supervisory framework. DORA expressly identifies dependence, substitutability and migration difficulty as relevant factors in determining the systemic significance of ICT providers.

Key cases to remember for an examination

Schrems I — C-362/14
Schrems II — C-311/18
Wirtschaftsakademie — C-210/16
Fashion ID — C-40/17
Google Spain — C-131/12
Google LLC v CNIL — C-507/17
British Airways v Commission — T-151/20
Banco Primus — C-421/14

Together, these cases help establish the legal principles of data protection, responsibility, cybersecurity, cross-border processing, contractual accountability and regulatory protection that become particularly important when Spanish banks depend on global hyperscalers.