Souveräne Cloud für Banken in Europa

Unter einem Wort stecken drei Dinge. Der Datenstandort sagt, dass die Daten in einem benannten Land oder einer Region liegen. Operative Souveränität sagt, dass die Administratoren der Plattform in der EU sitzen und bei einer EU-Gesellschaft angestellt sind, dass also keine Fernwartung von außen an die Produktion kommt. Rechtliche Souveränität sagt, dass kein Recht außerhalb der EU eine Herausgabe erzwingen kann. Das leistet eine Standortklausel allein nicht: Ein europäisches Rechenzentrum einer US-Gesellschaft bleibt im Zugriff des CLOUD Act, nach dem US-Behörden Daten von US-Unternehmen verlangen können, wo diese auch liegen.

Wegen dieser Lücke hat die EU-Kommission eigene messbare Kriterien geschrieben, statt dem Anbieter zu glauben. Ihr Cloud Sovereignty Framework macht aus Souveränität Vergabekriterien in acht Zielen: Sicherheit, Compliance, Transparenz der Lieferkette und der Technik, Umwelt, EU-Recht, EU-Strategie und EU-Betrieb. Für die eigenen Institutionen hat die Kommission den Rahmenvertrag an vier europäische Anbieter vergeben (auf Englisch), darunter ein Konsortium aus Post Telecom mit Clever Cloud und OVHcloud sowie StackIT, Scaleway und Proximus. Das Rahmenwerk führt zudem Sovereignty Effectiveness Assurance Levels ein, kurz SEAL, die Souveränitätseigenschaften eines Anbieters also abgestuft bewerten statt mit Ja oder Nein. Die Kriterienliste taugt als Muster für den eigenen Fragebogen, die SEAL-Stufe als Form der eigenen Bewertung.

Neben dem Verhaltenskodex steht ein unfertiges Zertifizierungsschema: das European Cybersecurity Certification Scheme for Cloud Services, EUCS, entworfen nach dem Cybersecurity Act. Seine Entwurfsstufen reichen von basic über substantial bis high, und aufgehalten hat es der Streit, ob die höchste Stufe Immunität gegen Nicht-EU-Recht tragen soll. Das würde Anbieter mit fremden Herausgabepflichten aus der Spitzenstufe ausschließen.

Die Branche hat nicht gewartet. Die European Sovereign Tech Industry Alliance, ESTIA, gegründet von zwölf europäischen Unternehmen, darunter Sopra Steria, Airbus, Deutsche Telekom, Orange, OVHcloud und Schwarz Digits, nennt einen EUCS-High+-Standard (auf Englisch) in ihrer eigenen Definition einer souveränen Cloud, mit europäischer Kontrolle, Datenlokalisierung und Schutz vor extraterritorialem Recht als den gemeinten Eigenschaften. Wer heute einen Vertrag schreibt, nimmt diese Eigenschaften praktisch in die Klauseln, statt auf ein Zertifikat zu warten, das mit anderer Formulierung kommen kann.

Zwei Instrumente ändern dieses Bild, während ein laufender Vertrag noch gilt. Der EU Data Act verpflichtet Cloud-Anbieter, einen Kunden wechseln zu lassen, mit Kündigungsfristen, Unterstützung beim Übergang und dem Wegfall von Wechselgebühren nach einer Einführungszeit. Das gibt der Ausstiegsklausel eine gesetzliche Untergrenze, die sie nicht hatte. Und ein Cloud and AI Development Act ist in Vorbereitung; dort landet eine verbindliche Definition der souveränen Cloud und eine europäische Präferenz in der öffentlichen Vergabe.

Der Draghi-Bericht hat dem politischen Druck eine Zahl gegeben: Knapp 90 Prozent der europäischen Daten werden außerhalb der EU verarbeitet. Eine Bank muss zu dieser Zahl keine Haltung haben, um die Folge einzuplanen: Die Regeln, wo Daten liegen dürfen, werden strenger und nicht laxer, und ein Vertrag am heutigen Minimum wird nachverhandelt.

Der EU Cloud Code of Conduct (auf Englisch) ist ein Verhaltenskodex nach Artikel 40 DSGVO für Cloud-Anbieter als Auftragsverarbeiter. Ein beigetretener Anbieter erklärt, dass ein benannter Dienst die Anforderungen des Kodex zu Artikel 28 DSGVO erfüllt; eine akkreditierte Überwachungsstelle nach Artikel 41 DSGVO prüft diese Erklärung. Der Beitritt gilt je Dienst, nicht je Unternehmen. Der Eintrag muss also den Dienst nennen, den die Bank kauft.

Der Beitritt beantwortet eine Datenschutzfrage und sonst keine. Er ersetzt die Vertragsklauseln aus DORA nicht, er ersetzt keine Übermittlungs-Folgenabschätzung bei Datenabfluss aus der EU, und zu Ausfallsicherheit und Ausstieg sagt er nichts. Die Seite zum EU Cloud Code of Conduct geht die Beitrittsstufen und das öffentliche Register durch. Ein Instrument mit ähnlichem Namen, der European Code of Conduct for Data Centre Energy Efficiency, regelt den Stromverbrauch und hat mit Datenschutz nichts zu tun.

Gaia-X betreibt keine Server. Es ist ein Verein in Brüssel, der ein Trust Framework veröffentlicht: Regeln, wie ein Anbieter seinen Dienst in einer maschinenlesbaren Selbstbeschreibung darstellt, und Prüfregeln dazu. Der Zweck ist Vergleichbarkeit: Zwei Anbieterangaben zu Standort und Rechtsordnung stehen im gleichen Format, statt auf zwei Werbeseiten. Die Seite Gaia-X und Finanzwesen behandelt das Framework und die darauf gebauten Datenräume der Branche.

Die Presse behandelt Gaia-X manchmal als europäische Antwort auf die Hyperscaler. Es ist ein Normungsgremium, und eine Bank kauft ihre Cloud weiterhin bei einem Anbieter.

Mit dem Cloud-Einkauf wird der Anbieter zum IKT-Drittdienstleister der Bank, und daraus folgen Pflichten, die die Bank nicht abgeben kann. DORA verlangt ein Informationsregister über jede vertragliche Vereinbarung zu IKT-Diensten, mit Anbieter, gestützter Funktion und der Einordnung, ob diese Funktion kritisch oder wichtig ist. Das Register geht an die Aufsicht; nur so sehen die europäischen Behörden die Konzentration im Sektor überhaupt. Wen die Behörden dann als kritischen IKT-Drittdienstleister einstufen, steht unter direkter EU-Aufsicht mit einem federführenden Überwacher, der prüfen und Empfehlungen aussprechen kann.

Für eine in Deutschland beaufsichtigte Bank wenden BaFin und Bundesbank diese Regeln an; die Seite DORA in Deutschland behandelt die deutsche Aufsicht, das Register und TIBER-DE. Den europäischen Rahmen hat die Seite digitale operative Resilienz in Europa. Das gilt über die Cloud hinaus: Wer als beaufsichtigtes Haus eine Blockchain über einen gehosteten Endpunkt liest, hat genau so eine IKT-Abhängigkeit. Die Seite zu RPC-Anbietern arbeitet das durch.

Eine Bank muss gehen können. DORA erwartet für kritische oder wichtige Funktionen Ausstiegsstrategien und Übergangsfristen, in denen der Anbieter weiter liefert, damit die Bank eine Last ohne Betriebsunterbrechung verlegen kann. Die Probe ist, ob die Bank die Klausel schon einmal gezogen hat: in welchem Format sie die Daten zurückbekommt, wie lange der Aufbau woanders dauert und wer den Datenabfluss zahlt.

Zwei Dinge machen einen Ausstieg teuer, und beide liegen in der Architektur. Verwaltete Dienste, die es nur bei einem Anbieter gibt, haben woanders kein Gegenstück; Gehen heißt dann Neubau. Und ein Ausstiegsplan, der eine ruhige, verhandelte Übergabe voraussetzt, hilft nicht, wenn der Anlass der Ausfall des Anbieters ist. Die brauchbare Fassung nennt den zweiten Anbieter, die Datenkopie im eigenen Haus und das Datum des letzten Tests.

Weil die Aufsichtsfrage und die politische Frage zusammen kamen. DORA hat IKT-Konzentration zu einer gemeldeten, beaufsichtigten Tatsache gemacht, und gleichzeitig kaufen europäische Institutionen Cloud nach eigenen Souveränitätskriterien. Wer den nächsten Cloud-Vertrag schreibt, beantwortet beides: die Fragen der Aufsicht zu Konzentration und Ausstieg und die Frage des eigenen Vorstands, welche Rechtsordnung die Daten hält.

Nein. Der Ort klärt den Datenstandort und sonst nichts. Sitzt die Betreibergesellschaft außerhalb der EU, reicht fremdes Herausgaberecht weiter an die Daten, und halten Administratoren außerhalb der EU Produktionszugriff, liegt auch die operative Kontrolle außerhalb. Standort, Betrieb und Rechtsordnung sind drei getrennte Klauseln. In Frankfurt steht ein großer Teil der europäischen Hosting-Kapazität, dazu die Seite Rechenzentren für die Finanzbranche in Frankfurt. Die Stadt in der Anschrift klärt die Rechtsfrage aber nicht.

DORA setzt die Regeln zu IKT-Risiko und Drittdienstleistern unmittelbar, und die BaFin beaufsichtigt ihre Anwendung neben den nationalen Auslagerungsanforderungen. In der Praxis dokumentiert eine deutsche Bank die Vereinbarung im DORA-Informationsregister, ordnet ein, ob sie eine kritische oder wichtige Funktion stützt, sichert Prüf- und Zugangsrechte für sich und die Aufsicht und hält einen Ausstiegsplan. Bei personenbezogenen Daten laufen die DSGVO-Pflichten des Auftragsverarbeiters parallel; dort ist der EU Cloud Code of Conduct ein brauchbarer Nachweis.