EU-Hosting vs. US-Cloud: Was bei DSGVO-konformer Softwareentwicklung zu beachten ist

Wenn dein Entwicklungspartner "EU-Hosting" anbietet oder "Server in Frankfurt" verspricht, klingt das nach einer sauberen Lösung für das Datenschutzthema. Tatsächlich ist die Frage, wo deine Daten rechtlich abgesichert sind, komplizierter als die Frage, wo der Server physisch steht. Eine AWS-Instanz in der Region eu-central-1 läuft zwar in Frankfurt, AWS selbst ist aber ein US-Unternehmen - und damit potenziell dem Zugriff US-amerikanischer Behörden unterworfen, unabhängig davon, wo die Festplatte steht. Dieser Artikel klärt, was Serverstandort und Drittlandtransfer rechtlich tatsächlich bedeuten, und gibt dir eine Entscheidungsgrundlage für die Hosting-Wahl in deinem nächsten Softwareprojekt. Vertragliche Absicherung über einen Auftragsverarbeitungsvertrag und die übrige DSGVO-Checkliste für Auftragsentwicklung behandeln wir an anderer Stelle - hier geht es ausschließlich um die Infrastruktur-Entscheidung selbst.

Warum der Serverstandort allein nicht reicht

Die DSGVO knüpft einen Drittlandtransfer nicht am physischen Standort der Festplatte fest, sondern an der Frage, wer Zugriff auf die Daten haben kann - rechtlich wie technisch. Ein US-Unternehmen, das eine Rechenzentrumsregion in der EU betreibt, bleibt ein US-Unternehmen. Es unterliegt damit potenziell dem US CLOUD Act, der US-Behörden erlaubt, von US-Unternehmen die Herausgabe von Daten zu verlangen, unabhängig davon, wo diese Daten weltweit gespeichert sind. Für dein Projekt bedeutet das: "Server in Frankfurt" beantwortet nur die Hälfte der Frage. Die andere Hälfte lautet, wer der Betreiber ist und welcher Rechtsordnung er unterliegt.

Das ist kein theoretisches Problem für kleine Softwareprojekte. Sobald deine Anwendung personenbezogene Daten verarbeitet - Kundendaten, Nutzerkonten, schon eine E-Mail-Adresse -, betrifft dich die Frage direkt bei der Wahl von Hosting-Anbieter, E-Mail-Versanddienst, Monitoring-Tool oder KI-API. Jede dieser Komponenten kann unabhängig von den anderen ein eigenes Drittlandrisiko mitbringen.

Schrems II und die Rechtslage nach dem Urteil

2020 kippte der Europäische Gerichtshof mit dem sogenannten Schrems-II-Urteil das damalige "Privacy Shield"-Abkommen zwischen EU und USA, weil es keinen ausreichenden Schutz vor dem Zugriff US-amerikanischer Geheimdienste bot. Seitdem gilt: Ein Datentransfer in die USA (oder ein anderes Drittland ohne Angemessenheitsbeschluss) braucht eine eigenständige rechtliche Grundlage, meist Standardvertragsklauseln (SCC) der EU-Kommission, ergänzt um zusätzliche technische und organisatorische Maßnahmen wie Verschlüsselung.

2023 trat mit dem EU-US Data Privacy Framework (DPF) ein Nachfolgeabkommen in Kraft, das zertifizierten US-Unternehmen wieder eine einfachere Rechtsgrundlage für den Datentransfer gibt. Die großen Hyperscaler - AWS, Microsoft Azure, Google Cloud - sind mittlerweile DPF-zertifiziert. Das Problem: Das DPF steht rechtlich auf ähnlich wackligem Fundament wie sein Vorgänger. Datenschutzorganisationen haben bereits Klagen angekündigt, und ein drittes Kippen durch den EuGH gilt in Fachkreisen als reale Möglichkeit, nicht als Randszenario. Wer sein Projekt heute vollständig auf das DPF stützt, baut auf eine Rechtsgrundlage, die in ein oder zwei Jahren erneut zur Disposition stehen könnte - mit der Konsequenz, dann kurzfristig Verträge und möglicherweise die Infrastruktur anpassen zu müssen.

Was "EU-Region" bei den Hyperscalern wirklich bedeutet

AWS, Azure und Google Cloud bieten alle EU-Regionen an, in denen Daten physisch innerhalb der EU gespeichert und verarbeitet werden. Das reduziert bestimmte Risiken tatsächlich: Es verhindert automatische, latenzbedingte Datenreplikation in Nicht-EU-Regionen und erfüllt oft branchenspezifische Auflagen zur Datenlokalisierung. Was es nicht auflöst, ist die Konzernzugehörigkeit. Support-Zugriffe, Abrechnungssysteme und im Zweifel auch behördliche Anfragen können weiterhin über die US-Muttergesellschaft laufen. Manche Anbieter haben darauf reagiert: Microsoft bietet mit der "EU Data Boundary" eine Variante, bei der auch Metadaten und Support-Prozesse innerhalb der EU verbleiben sollen, AWS und Google haben vergleichbare, aber unterschiedlich weit reichende Zusagen. Diese Feinheiten unterscheiden sich von Anbieter zu Anbieter und ändern sich mit neuen Vertragsbedingungen - ein Punkt, den du bei der Anbieterwahl konkret nachfragen solltest, statt dich auf "EU-Region" als Gesamtaussage zu verlassen.

Die drei realistischen Optionen für dein Projekt

Für ein neues Softwareprojekt läuft die Hosting-Entscheidung praktisch auf drei Varianten hinaus, mit jeweils eigenem Rechts- und Aufwandsprofil:

EU-souveräne Anbieter (z.B. Hetzner, IONOS, OVHcloud, deutsche/europäische Cloud-Anbieter ohne US-Mutterkonzern): Geringstes Drittlandrisiko, da weder Serverstandort noch Konzernzugehörigkeit eine US-Rechtsordnung ins Spiel bringen. Dafür oft ein kleineres Ökosystem an verwalteten Diensten (Managed Databases, KI-APIs, Monitoring) als bei den Hyperscalern, was mehr Eigenbetrieb bedeuten kann.
Hyperscaler mit EU-Region und DPF-Absicherung: Größtes Angebot an verwalteten Diensten, ausgereifte Skalierung, vertraglich über SCC und DPF-Zertifizierung abgesichert. Trägt das oben beschriebene Restrisiko einer künftigen rechtlichen Kippung des DPF und erfordert eine aktive Prüfung, welche Support- und Backend-Prozesse tatsächlich EU-intern bleiben.
Hyperscaler ohne besondere Zusatzabsicherung: Rechtlich die schwächste Position, in der Praxis aber weiterhin verbreitet, wenn Teams den Unterschied zwischen Serverstandort und Konzernzugehörigkeit nicht kennen. Für ein neues Projekt gibt es keinen guten Grund, hier einzusteigen, wenn die beiden anderen Optionen mit vertretbarem Mehraufwand verfügbar sind.

Welche Option passt, hängt von der Kritikalität der verarbeiteten Daten ab. Für ein internes Tool ohne besonders sensible Daten kann ein Hyperscaler mit EU-Region ausreichend pragmatisch sein. Für eine Anwendung mit Gesundheits-, Finanz- oder anderen besonders schützenswerten Daten lohnt sich der Mehraufwand eines EU-souveränen Anbieters, schon um die Diskussion mit Kunden oder Aufsichtsbehörde erst gar nicht führen zu müssen.

Nebendienste nicht vergessen

Die Hauptdatenbank ist meist der Dienst, über den am längsten diskutiert wird - und gleichzeitig nicht die einzige Stelle, an der Drittlandtransfer entsteht. E-Mail-Versanddienste, Fehler-Tracking-Tools, Analytics und vor allem KI-APIs wie die großen LLM-Anbieter verarbeiten häufig personenbezogene Daten, ohne dass das im Projekt explizit thematisiert wird. Ein Support-Ticket-System, das automatisch Kundennamen und E-Mail-Adressen an einen US-Dienst schickt, hat dasselbe Drittlandproblem wie die Hauptdatenbank, wird aber in der Architekturdiskussion oft übersehen, weil es "nur" ein Hilfswerkzeug ist. Lass dir bei jeder Komponente deiner Architektur schriftlich bestätigen, in welchem Land sie läuft und wer der Betreiber ist - nicht nur bei der Kernanwendung.

Fazit

"EU-Hosting" ist ein Marketingbegriff, kein Rechtsstatus. Die tatsächlich relevante Frage ist, wem der Anbieter gehört und welcher Rechtsordnung er damit unterliegt, nicht nur, wo die Festplatte physisch steht. Für ein neues Projekt lohnt es sich, diese Entscheidung bewusst zu treffen: EU-souveräne Anbieter minimieren das Risiko am konsequentesten, Hyperscaler mit EU-Region und DPF-Zertifizierung sind ein pragmatischer Mittelweg mit einem im Blick zu behaltenden Restrisiko, und die dritte Option gehört bei einem Neuprojekt eigentlich nicht mehr zur Diskussion. Kläre diese Frage vor der ersten Zeile Code, nicht danach - ein späterer Anbieterwechsel ist ungleich teurer als eine bewusste Entscheidung am Projektstart.

Häufig gestellte Fragen

Ist eine AWS- oder Azure-Region in Frankfurt automatisch DSGVO-konform?

Nein. Der physische Serverstandort in der EU löst das Drittlandproblem nicht vollständig, weil AWS und Microsoft US-Unternehmen bleiben und damit potenziell dem US CLOUD Act unterliegen. Für eine belastbare Absicherung braucht es zusätzlich eine Rechtsgrundlage wie das EU-US Data Privacy Framework oder Standardvertragsklauseln.

Was hat sich durch das Schrems-II-Urteil geändert?

Der Europäische Gerichtshof erklärte 2020 das damalige "Privacy Shield"-Abkommen für ungültig, weil es keinen ausreichenden Schutz vor dem Zugriff US-amerikanischer Behörden bot. Seitdem braucht ein Datentransfer in die USA eine eigenständige Rechtsgrundlage, etwa Standardvertragsklauseln mit zusätzlichen technischen Maßnahmen.

Ist das EU-US Data Privacy Framework eine sichere Grundlage für mein Projekt?

Es ist aktuell gültig und wird von den großen Hyperscalern genutzt, gilt in Fachkreisen aber als rechtlich angreifbar. Datenschutzorganisationen haben bereits Klagen angekündigt, ein erneutes Kippen durch den EuGH ist ein reales Szenario. Wer vollständig darauf setzt, sollte den Ausgang laufender Verfahren im Blick behalten.

Sind EU-souveräne Hosting-Anbieter für jedes Projekt die richtige Wahl?

Nicht zwingend. Sie minimieren das Drittlandrisiko am konsequentesten, bieten aber oft ein kleineres Ökosystem an verwalteten Diensten als die großen Hyperscaler. Für Projekte mit besonders sensiblen Daten überwiegt meist der Sicherheitsgewinn, für weniger kritische interne Tools kann ein Hyperscaler mit EU-Region ein vertretbarer Kompromiss sein.

Muss ich auch Nebendienste wie E-Mail-Versand oder KI-APIs auf den Serverstandort prüfen?

Ja. Jeder Dienst, der personenbezogene Daten verarbeitet - auch Support-Tools, Fehler-Tracking oder KI-Schnittstellen - kann unabhängig von der Hauptdatenbank ein eigenes Drittlandrisiko mitbringen. Lass dir für jede Komponente der Architektur schriftlich bestätigen, in welchem Land sie betrieben wird.