Sovereign cloud for banks in Europe

Three things get mixed together under one word. Data residency says the data is stored in a named country or region. Operational sovereignty says the people who administer the platform sit in the EU and are employed by an EU entity, so no remote support session from outside reaches production. Jurisdictional sovereignty says no law outside the EU can compel disclosure, which is the part a residency clause alone does not deliver: a European data center run by a company incorporated in the United States is still in reach of the CLOUD Act, which lets US authorities request data held by US companies wherever it is stored.

That gap is why the European Commission wrote its own measurable criteria instead of taking a provider's word. Its Cloud Sovereignty Framework turns sovereignty into procurement criteria across eight objectives, covering security, compliance, supply-chain and technological transparency, the environment, EU law, EU strategy and EU operations. When the Commission bought cloud services for its own institutions, it awarded the framework contract to four European providers, among them a consortium of Post Telecom with Clever Cloud and OVHcloud, plus StackIT, Scaleway and Proximus. The framework also introduces Sovereignty Effectiveness Assurance Levels, abbreviated SEAL, so a provider's sovereignty properties get a graded assessment instead of a yes or no. A bank can read that criteria list as a template for its own questionnaire, and the SEAL grade as the shape its own scoring should take.

Next to the code of conduct sits a certification scheme that is not finished: the European Cybersecurity Certification Scheme for Cloud Services, EUCS, drafted under the Cybersecurity Act. Its draft levels run from basic through substantial to high, and the argument that has held it up is whether the highest level should carry immunity from non-EU law, which would exclude providers under foreign disclosure obligations from the top tier.

Industry has not waited. The European Sovereign Tech Industry Alliance, ESTIA, founded by twelve European companies including Sopra Steria, Airbus, Deutsche Telekom, Orange, OVHcloud and Schwarz Digits, names an EUCS High+ standard in its own definition of a sovereign cloud, with European control, data localization and protection from extraterritorial law as the properties it means. For a bank writing a contract today, the practical move is to put the substance of those properties in the clauses, instead of waiting for a certificate that may arrive with different wording.

Two instruments change this picture while a bank's current contract is running. The EU Data Act obliges cloud providers to let a customer switch, with notice periods, transition assistance and the removal of switching charges after a phase-in, which gives the exit clause a statutory floor it did not have. And a Cloud and AI Development Act is in preparation, which is where a binding definition of a sovereign cloud and a European preference in public procurement would land.

The Draghi report put a number behind the political pressure: close to 90 percent of European data is processed outside the EU. A bank does not have to take a position on that figure to plan around its consequence, which is that the rules on where data may sit are being tightened and not loosened, and a contract written to today's minimum will need renegotiating.

The EU Cloud Code of Conduct is a code of conduct under Article 40 GDPR for cloud providers acting as processors. A provider that adheres to it has declared that a named service meets the code's requirements for implementing Article 28 GDPR, and an accredited monitoring body under Article 41 GDPR checks that declaration. Adherence is per service and not per company, so the entry a bank reads has to name the service it is buying.

Adherence answers a data protection question and nothing else. It does not replace the contract clauses DORA requires, it does not substitute for a transfer impact assessment where data leaves the EU, and it says nothing about resilience or exit. The page on the EU Cloud Code of Conduct goes through the adherence levels and the public register. A separate instrument with a similar name, the European Code of Conduct for Data Centre Energy Efficiency, deals with power use and has no bearing on data protection.

Gaia-X does not run servers. It is an association in Brussels that publishes a Trust Framework: rules for how a provider describes its own service in a machine-readable self-description, and compliance rules against which that description is checked. The point is comparability, so a bank can read two providers' claims about residency and jurisdiction in the same format instead of two marketing pages. The Gaia-X and finance page covers the framework and the finance data spaces built on it.

Press coverage sometimes treats Gaia-X as a European answer to the hyperscalers. It is a specification body, and a bank that wants a cloud still buys it from a provider.

Buying cloud makes the provider an ICT third-party service provider of the bank, and that triggers duties the bank cannot delegate. DORA requires a register of information listing every contractual arrangement for ICT services, with the provider, the function it supports and whether that function is critical or important. The register is reported to the supervisor, which is how the European authorities see concentration across the sector at all. A provider the authorities then designate as a critical ICT third-party provider falls under direct EU oversight, with a lead overseer that can examine it and issue recommendations.

For a bank supervised in Germany, BaFin and the Bundesbank apply those rules, and the DORA in Germany page covers the German supervision, the register and TIBER-DE. The European frame sits on digital operational resilience in Europe. The same logic reaches further than cloud: a regulated firm that reads a blockchain through one hosted endpoint has an ICT dependency of exactly this kind, which the page on RPC providers works through.

A bank has to be able to leave. DORA expects contracts for critical or important functions to carry exit strategies and transition periods during which the provider keeps delivering, so the bank can move a workload without a gap in service. The test is whether the bank has ever run the clause: the data format it gets back, the time to stand the function up elsewhere, and who pays for the egress.

Two things make an exit expensive and both are architectural. Managed services that exist only at one provider have no equivalent elsewhere, so leaving means a rewrite. And an exit plan that assumes a calm, negotiated handover does not help when the trigger is the provider's own failure. The useful version names the second provider, the data copy the bank already holds, and the last date the plan was tested.

Because the supervisory and the political question arrived together. DORA made ICT concentration a reported, supervised fact instead of an internal matter, and at the same time European institutions started buying cloud under sovereignty criteria of their own. A bank writing its next cloud contract is answering both: the supervisor's questions about concentration and exit, and its own board's question about which jurisdiction holds the data.

No. Location settles residency and nothing else. If the operating company is incorporated outside the EU, foreign disclosure law can still reach the data, and if administrators outside the EU hold production access, operational control is outside the EU too. Residency, operations and jurisdiction have to be read as three separate clauses. Frankfurt happens to hold a large share of European hosting capacity, which the page on data centers for finance in Frankfurt covers, but the city in the address does not decide the legal question.

DORA sets the ICT risk and third-party rules directly, and BaFin supervises their application alongside the national requirements for outsourcing. In practice a German bank documents the arrangement in the DORA register of information, classifies whether it supports a critical or important function, secures audit and access rights for itself and for the supervisor, and holds an exit plan. Where personal data is involved, the GDPR processor requirements run in parallel, which is where the EU Cloud Code of Conduct is evidence a bank can use.