Datenaufbewahrung im Jahr 2026: Was die Aufsichtsbehörden jetzt von deiner cloud erwarten – und wie du das nachweisen kannst

Frag ein Compliance-Team, wo sich die EU-Kundendaten befinden, und die meisten werden selbstbewusst auf ein Dashboard zeigen, das eine Region in Frankfurt oder Dublin anzeigt. Frag ihren Rechtsberater, ob diese Daten außerhalb der Reichweite einer ausländischen Regierungsanordnung liegen, und die Zuversicht schwindet meist. 

Das sind zwei verschiedene Fragen. Seit dem 12. September 2025 gibt es eine datierte EU-Verpflichtung, bei der es eher um die zweite als um die erste Frage geht.

Warum Datenstandort und Datenhoheit nicht mehr dasselbe Thema sind

Das Wichtigste auf einen Blick: Datenstandort bedeutet, dass deine Daten innerhalb einer definierten geografischen Grenze gespeichert sind. Datenhoheit bedeutet, dass Daten den Gesetzen des Ortes unterliegen, an dem sie sich befinden – einschließlich der Frage, wer rechtlich Zugriff darauf erzwingen kann. Ein Unternehmen kann die erste Anforderung vollständig erfüllen und dennoch bei der zweiten Anforderung anfällig bleiben.

Diese Unterscheidung ist wichtig, weil genau darauf sich Audits und behördliche Prüfungen zunehmend konzentrieren. Da 18 U.S.C. 2713, hinzugefügt durch den US-Cloud-Act, die Einrede der Extraterritorialität gegenüber US-Rechtsverfahren aufhebt, muss ein Anbieter von elektronischen Kommunikations- oder Remote-Computing-Diensten, der der US-Gerichtsbarkeit unterliegt, in Bezug auf Daten, die sich in seinem Besitz, seiner Verwahrung oder seiner Kontrolle befinden, reagieren – unabhängig davon, wo sich die Server befinden. Das Hosten von Daten in einer EU-Region schützt diese also nicht automatisch vor rechtlichen Forderungen aus den USA. 

Aufsichtsbehörden mehrerer EU-Datenschutzbehörden haben bereits festgestellt, dass bestimmte US-cloud-Vereinbarungen genau aus diesem Grund im Widerspruch zur DSGVO stehen: Die österreichische Datenschutzbehörde stellte in einer im Dezember 2021 erlassenen und im darauffolgenden Monat veröffentlichten Teilentscheidung fest, dass die fortgesetzte Nutzung eines in den USA gehosteten Analysetools gegen die Datenexportvorschriften der DSGVO verstößt, und die französische CNIL kam im darauffolgenden Monat zu demselben Ergebnis. Beide Entscheidungen gingen auf die 101 Beschwerden zurück, die noyb im August 2020 EU- und EWR-weit eingereicht hatte – wenige Wochen, nachdem das Urteil „Schrems II“ den bisherigen Rahmen für Datenübermittlungen zwischen der EU und den USA für ungültig erklärt hatte. 

Beide Entscheidungen stammen aus der Zeit vor der Angemessenheitsentscheidung zum EU-US-Datenschutzrahmen vom Juli 2023, die in Kraft ist und die Bewertung wesentlich verändert, wenn der Importeur nach dem DPF zertifiziert ist. Das Gericht wies die Klage von Latombe im September 2025 ab, und ein Berufungsverfahren ist anhängig, sodass der Rahmen vorerst gilt, ohne endgültig geklärt zu sein.

Das ist kein hypothetisches Problem, mit dem sich die Regulierungsbehörden vielleicht irgendwann mal befassen werden. Es ist die aktuelle Unterscheidung, die neue Produktkategorien (souveräne cloud-Regionen großer Anbieter), neue nationale Programme (das französische SecNumCloud-Zertifizierungssystem unter der ANSSI, Deutschlands Cloud-Vereinbarungen für den öffentlichen Sektor) und eine messbare Verlagerung der Unternehmensausgaben vorantreibt. 

Lies dir das genau durch: Bei einigen handelt es sich um europäische Einrichtungen, die Technologien von US-Anbietern unter nationaler Aufsicht betreiben, was die operative Kontrolle verbessert, ohne die Frage der gerichtlichen Zuständigkeit auszuräumen. 

Laut Gartner werden die weltweiten Ausgaben für souveräne cloud-basierte IaaS-Dienste im Jahr 2026 voraussichtlich 80 Milliarden US-Dollar erreichen – ein Anstieg von 35,6 % gegenüber 2025 –, wobei regulierte Branchen und Organisationen mit kritischer Infrastruktur neben der Regierung selbst zu den Hauptabnehmern zählen. Speziell in Europa sollen die Ausgaben für souveräne cloud-basierte IaaS-Lösungen von 6,9 Milliarden US-Dollar im Jahr 2025 auf 12,6 Milliarden US-Dollar im Jahr 2026 steigen und bis 2027 auf 23,1 Milliarden US-Dollar anwachsen. 

Das ist kein Nischenposten im Bereich Compliance. Es handelt sich um eine strukturelle Umverteilung der Ausgaben für Unternehmensinfrastruktur, die genau durch die Lücke zwischen Datenstandort und Souveränität getrieben wird, die die meisten Compliance-Programme noch nicht geschlossen haben.

Was sich bei den regulatorischen Erwartungen tatsächlich geändert hat

Das Wichtigste auf einen Blick: Drei separate regulatorische Bereiche – Datenschutz, operative Widerstandsfähigkeit und Cybersicherheit – laufen auf dieselbe grundlegende Anforderung hinaus: Beweise, dass deine Datenverwaltung einer genauen Prüfung standhält, statt sie nur in einem Richtliniendokument zu beschreiben.

• Die Durchsetzung der DSGVO hat sich verstärkt auf Transparenz und grenzüberschreitende Datenübermittlung konzentriert, nicht nur auf den Speicherort. Die Verordnung bleibt die Grundlage für den Datenschutz in der EU, aber nach „Schrems II“ hat sich die praktische Compliance-Frage von der bloßen geografischen Lage hin zur Beurteilung verschoben, welche Rechtsordnung für den Anbieter gilt und ob technische Schutzmaßnahmen den Zugriff ausländischer Regierungen während des gesamten Datenlebenszyklus verhindern. Standardvertragsklauseln allein gelten nicht mehr als ausreichend, wenn der zugrunde liegende Rechtsrahmen des Heimatlandes des Anbieters einen Zugriff zulässt, der diese vertraglichen Zusagen außer Kraft setzt.
• Der EU-Datenschutzgesetzentwurf fügt für eine bestimmte Datenkategorie eine konkrete, einklagbare Anforderung hinzu. Ab September 2025 verpflichtet Kapitel VII des EU-Datengesetzes Anbieter von Datenverarbeitungsdiensten – unabhängig von ihrem Niederlassungsort –, sofern sie Kunden in der Union bedienen, alle angemessenen technischen, organisatorischen und rechtlichen Maßnahmen, einschließlich Verträgen, zu ergreifen, um den Zugriff von Regierungen aus Drittländern auf in der Union gespeicherte nicht personenbezogene Daten sowie deren Übermittlung zu verhindern, sofern dieser Zugriff im Widerspruch zum Recht der EU oder der Mitgliedstaaten stünde – ein Schutz, der zusätzlich zu und anders ausgestaltet ist als der Schutz personenbezogener Daten, den Artikel 48 der DSGVO bereits vorsieht. Damit wird ein zuvor abstraktes Souveränitätsanliegen in eine konkrete Verpflichtung für Anbieter umgewandelt, wobei Organisationen ihre Daten korrekt als personenbezogen oder nicht personenbezogen einstufen müssen, um zu wissen, welcher Schutz tatsächlich gilt.
• NIS2 erweitert die Anforderungen über den Datenschutz hinaus auf die operative Cybersicherheit. Die Umsetzungsfrist endete am 17. Oktober 2024, doch die Umsetzung ist noch nicht abgeschlossen: Im Juli 2026 hat die Kommission Irland, Spanien, Frankreich und die Niederlande vor dem Gerichtshof verklagt, weil sie es versäumt hatten, nationale Maßnahmen zu melden. Dort, wo NIS2 bereits umgesetzt wurde, schreibt die Richtlinie Maßnahmen zum Cybersicherheits-Risikomanagement vor, ermächtigt die zuständigen Behörden, unabhängige Sicherheitsaudits bei wesentlichen Einrichtungen zu verlangen, und schreibt eine stufenweise Meldung von Vorfällen vor: eine Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden eines schwerwiegenden Vorfalls, eine ausführlichere Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats nach dieser Meldung. Das ist ein anderer regulatorischer Hebel als die DSGVO, zielt aber in dieselbe Richtung: eine nachweisbare, überprüfbare Kontrolle über deine Infrastruktur und darüber, wie sie auf Vorfälle reagiert.
• DORA (das EU-Gesetz zur digitalen operativen Widerstandsfähigkeit) fügt speziell für Finanzunternehmen eine Ebene der Widerstandsfähigkeit und Prüfung hinzu. Es gilt seit Januar 2025 und verpflichtet Finanzunternehmen, vertragliche Prüf- und Zugriffsrechte gegenüber ihren IKT-Anbietern zu haben. Außerdem gewährt es den Europäischen Aufsichtsbehörden direkte Kontrollbefugnisse über die Anbieter, die sie als kritisch einstufen – davon gab es im November 2025 insgesamt 19. Artikel 30 schreibt zudem vor, dass verbindliche Vertragsbedingungen an IKT-Anbieter in jedem Sektor weitergegeben werden müssen, sobald ein Finanzunternehmen Kunde wird.
• Großbritannien schlägt unabhängig davon denselben Weg ein und treibt die Entwicklung zügig voran. Der „Cyber Security and Resilience Bill“ wurde im Juni 2026 vom Unterhaus verabschiedet und durchläuft derzeit das Oberhaus; die königliche Zustimmung wird noch in diesem Jahr erwartet, und die schrittweise Umsetzung soll bis 2028 erfolgen. Er dehnt Verpflichtungen im Stil der NIS-Richtlinie auf Managed-Service-Anbieter, Rechenzentren und kritische Lieferanten aus, was bedeutet, dass die regulatorischen Anforderungen in Großbritannien auch außerhalb der spezifischen EU-Rahmenbedingungen steigen.

Einzeln betrachtet handelt es sich um separate Regulierungswege mit unterschiedlichen Geltungsbereichen. Zusammen genommen deuten sie jedoch auf dieselbe organisatorische Anforderung hin: die Fähigkeit, nicht nur zu behaupten, sondern auch nachzuweisen, wo sich Daten befinden, wer darauf zugreifen darf und auf welcher rechtlichen Grundlage.

Warum die Wahl der Region dadurch zu einer Governance-Entscheidung wird

Das Wichtigste auf einen Blick: Die Entscheidung, wo eine Workload ausgeführt wird, war früher eine Frage der Latenz und der Kosten. Heute ist es eine Compliance-Entscheidung, die mit einer nachvollziehbaren Begründung einhergeht.

Während des größten Teils des letzten Jahrzehnts war die Auswahl der Region eine operative Entscheidung: Man wählte die Region, die den Nutzern am nächsten lag, oder die mit den besten Preisen für die jeweilige Workload. Diese Überlegung ist nicht verschwunden, reicht aber allein nicht mehr aus. 

Eine Aufsichtsbehörde oder ein Prüfer, der nach den Daten eines bestimmten Kunden fragt, erwartet nun eine konkrete, nachvollziehbare Antwort: Welche Region, unter welcher rechtlichen Zuständigkeit des Anbieters und mit welchen Sicherheitsvorkehrungen für den Datentransfer, falls Daten während der Verarbeitung, der backups oder des Supportzugriffs eine Grenze überschreiten.

Für die meisten Unternehmen, die mit mehreren Clouds und Anbietern arbeiten, ist das schwieriger, als es klingt, denn die Auswahl der Region erfolgt oft auf der Infrastrukturebene, wird einmalig von demjenigen festgelegt, der einen bestimmten Dienst eingerichtet hat, und nur selten überdacht, es sei denn, etwas funktioniert nicht mehr. 

Die Compliance-Frage erfordert dagegen eine Antwort, die für jede Arbeitslast, jedes Kundensegment und jede geltende Vorschrift stichhaltig ist – das ist eine grundlegend andere Detailebene, als sie die meisten Infrastrukturentscheidungen ursprünglich vorsehen.

Was der Nachweis tatsächlich erfordert

Das Wichtigste auf einen Blick: Um die Einhaltung von Anforderungen an Datenstandort und Souveränität nachzuweisen, muss man auf Anfrage zeigen können, wo sich die Daten einer bestimmten Workload befinden, welches regulatorische Rahmenwerk gilt und welche Governance-Kontrollen diese Platzierung durchsetzen – und nicht nur die Richtlinie beschreiben, die das eigentlich vorsehen soll.

Unternehmen, die Fragen zur Datenstandort- oder Souveränitätsanforderung schnell beantworten können, haben eine gemeinsame Eigenschaft: Ihre Regionsauswahl ist als tatsächlicher Bereitstellungsstatus abrufbar und überprüfbar, mit einer Aufbewahrungsfrist, die das Prüfungsfenster abdeckt – und wird nicht als separates Richtliniendokument geführt, das bei einer Anfrage erst mit der Realität abgeglichen werden muss. 

Wenn die Region einer Workload über eine API aus dem Bereitstellungsstatus abrufbar ist, anstatt in einem Richtlinien-Dokument festgelegt zu sein, ist die Antwort auf die Frage „Wo befinden sich diese Daten?“ eine Abfrage des tatsächlichen Bereitstellungsstatus – und kein Dokument, bei dem jemand überprüfen muss, ob es noch korrekt ist.

Dies gewinnt insbesondere für Unternehmen mit mehreren Regionen und in mehreren clouds zunehmend an Bedeutung. Die Bereitstellung über Regionen von AWS, Azure, Google Cloud, IBM oder OVHcloud hinweg, um die Standortanforderungen eines bestimmten Kunden zu erfüllen, funktioniert nur dann als Governance-Lösung, wenn die Regionszuordnung konsistent und überprüfbar ist und sich bei Infrastrukturänderungen nicht unbemerkt verschiebt. 

Ein Unternehmen, das dies Region für Region und Workload für Workload nachweisen kann, beantwortet eine grundlegend andere (und viel aussagekräftigere) Frage als eines, das auf eine allgemeine Richtlinie zur Datenresidenz verweisen kann und hofft, dass die zugrunde liegende Infrastruktur noch damit übereinstimmt.

Ein nützlicher erster Ansatz: Nimm die Workload, die deine am stärksten regulierten Daten enthält, und versuche, vier Dinge dazu zu ermitteln. Wo sie bereitgestellt ist, wobei du den tatsächlichen Bereitstellungsstatus heranziehst und nicht ein Dokument, und wie lange sie aufbewahrt wird – und zwar über einen Zeitraum, der dein Prüfungsfenster abdeckt. Wer hat sie geändert und wann? Welche Unterauftragsverarbeiter kommen mit ihren Daten in Berührung, einschließlich backups, Protokollen, Support-Tools und etwaiger Inferenz-Endpunkte? Und ob es sich bei diesen Daten um personenbezogene oder nicht-personenbezogene Daten handelt. Was auch immer du nicht nachweisen kannst, ist das Ergebnis.

Führe die Bewertung der cloud-Bereitschaft unter Einhaltung der Vorschriften durch 

Häufig gestellte Fragen (FAQ)

Was ist der praktische Unterschied zwischen Datenresidenz und Datenhoheit? 
Datenresidenz bedeutet, dass deine Daten physisch innerhalb einer definierten geografischen Grenze gespeichert sind, zum Beispiel in der EU. Datenhoheit bedeutet, dass die Daten während ihres gesamten Lebenszyklus der rechtlichen Zuständigkeit dieser Gerichtsbarkeit unterliegen, einschließlich der Frage, wer den Zugriff darauf erzwingen kann. Ein Unternehmen kann vollständige Datenresidenz (Daten werden in Frankfurt gespeichert) erreichen, während es in Bezug auf die Datenhoheit weiterhin Risiken ausgesetzt ist, wenn der Betreiber der US-Gerichtsbarkeit unterliegt und dem „Possession, Custody or Control“-Standard des US-cloud-Acts unterliegt. Um diese Souveränitätslücke zu schließen, ist in der Regel ein operativ unabhängiger, nicht von den USA kontrollierter Anbieter oder architektonische Kontrollmaßnahmen wie vom Kunden verwaltete Verschlüsselungsschlüssel erforderlich. Beachte die Einschränkung bei dieser zweiten Option: Die Schlüsselverwahrung hilft bei ruhenden und übertragenen Daten, nützt aber nichts, wenn die Plattform die Daten im Klartext benötigt, um deine Anwendung auszuführen – was bei den meisten Anwendungsplattformen der Fall ist.

Erfüllt die Wahl einer EU-Region automatisch die DSGVO? 
Sie erfüllt zwar die Komponente des Speicherorts, aber die DSGVO-Konformität geht über den Speicherort hinaus. Sie erfordert einen rechtmäßigen Übermittlungsmechanismus für alle Daten, die Grenzen überschreiten (wie Standardvertragsklauseln oder eine Angemessenheitsentscheidung), angemessene technische Schutzmaßnahmen sowie genaue Aufzeichnungen über Verarbeitungsaktivitäten, einschließlich Support- und Telemetriedatenflüsse, die bei einer ausschließlich auf den Speicherort bezogenen Bewertung oft übersehen werden.

Ist DORA auch außerhalb des Finanzsektors relevant? 
Ja, wenn du solche Dienstleistungen erbringst. DORA gilt für in der EU tätige Finanzunternehmen und deren kritische IKT-Anbieter, und Artikel 30 überträgt verbindliche Vertragsbedingungen auf IKT-Anbieter in jedem Sektor, sobald ein Finanzunternehmen Kunde wird – darunter fallen Prüfungsrechte, Ausstiegspläne, Untervergabe und die Meldung von Vorfällen. Direkte Aufsichtsinspektionen gelten nur für die Anbieter, die von den europäischen Aufsichtsbehörden als kritisch eingestuft werden. Die Kernanforderungen – nachweisbare operative Widerstandsfähigkeit und Zugang der Aufsichtsbehörden zu relevanten Systemen – sind jedoch ein Muster, das sich auch auf andere Rahmenwerke wie NIS2 und den britischen „Cyber Security and Resilience Bill“ ausweitet. Unternehmen außerhalb des Finanzdienstleistungssektors sollten die Anforderungen von DORA als Indikator dafür betrachten, in welche Richtung sich die allgemeinen regulatorischen Erwartungen entwickeln.

Wie wirkt sich ein Multicloud- oder Multi-Region-Einsatz auf die Einhaltung der Residenzvorschriften aus? 
Das kann hilfreich oder nachteilig sein, je nachdem, ob die Regionszuordnung konsequent durchgesetzt wird. Ein regionenübergreifender Einsatz ermöglicht es einer Organisation, unterschiedliche Residenzanforderungen für verschiedene Kundensegmente oder Rechtsräume zu erfüllen, was ein echter Vorteil ist. Dies funktioniert jedoch nur dann als Compliance-Lösung, wenn die Regionszuordnung für jede Arbeitslast dokumentiert und überprüfbar ist und keine Abweichungen zwischen der deklarierten und der tatsächlich implementierten Zuordnung bestehen. Ohne diese Konsistenz erhöht ein regionenübergreifender Einsatz die Komplexität, ohne die Compliance-Lücke zu schließen.

Schützt das EU-Datengesetz personenbezogene Daten auch vor dem Zugriff ausländischer Regierungen? Kapitel VII 
des Datengesetzes befasst sich ausdrücklich mit nicht-personenbezogenen Daten. Personenbezogene Daten werden durch eine anders formulierte Bestimmung in Artikel 48 der DSGVO geregelt, die die Anerkennung von Entscheidungen ausländischer Gerichte oder Behörden einschränkt, die die Übermittlung personenbezogener Daten ohne ein gültiges internationales Abkommen verlangen. Der EDPB hat in den Leitlinien 02/2024 ausdrücklich klargestellt, dass Artikel 48 an sich kein Übermittlungsgrund ist, und der Artikel endet mit den Worten „unbeschadet anderer Übermittlungsgründe gemäß Kapitel V“, sodass er nicht als Sperrklausel fungiert. Er befasst sich zudem mit Zustellungen an das EU-Unternehmen und bietet kaum Halt, wenn sich die Zwangsmaßnahme gegen eine Muttergesellschaft außerhalb der EU richtet. In der Praxis bedeutet das, dass Unternehmen einen bestimmten Datensatz korrekt als personenbezogen oder nicht personenbezogen einstufen müssen, um zu wissen, welcher Schutz vor Zwangsmaßnahmen tatsächlich darauf zutrifft – eine Entscheidung, die wichtig ist, da sich die beiden Regelungen überschneiden, anstatt sich gegenseitig auszuschließen. Sind personenbezogene und nicht personenbezogene Daten untrennbar miteinander verknüpft, gilt die DSGVO für den gesamten Datensatz, während Artikel 32 die Verpflichtung für den nicht personenbezogenen Teil weiterhin deinem Anbieter auferlegt.

Was sollte ein IT-Verantwortlicher eigentlich als Erstes prüfen? 
Beginne damit, zu überprüfen, ob die Regionszuordnung für jede Arbeitslast so deklariert ist, dass sie abgefragt und verifiziert werden kann – anstatt einmal festgelegt zu werden und einfach als korrekt anzunehmen. Ermittle anschließend, welche rechtlichen Rahmenbedingungen tatsächlich für welche Workloads und Kundensegmente gelten, da DSGVO, DORA und NIS2 unterschiedliche Geltungsbereiche und spezifische Anforderungen haben. Die Lücke zwischen vermuteter und nachweisbarer Compliance zeigt sich meist bei dieser Zuordnung, nicht in der zugrunde liegenden Infrastruktur selbst.