EU-Datenresidenz für Agenturen: so garantierst du sie wirklich

EU-Datenresidenz bedeutet, dass deine Kundendaten physisch in einer EU-Region liegen und weiterhin dem EU-Recht unterstehen — und der einzige Weg, sie tatsächlich zu garantieren, ist zu kontrollieren, wo die Datenbank angelegt wird, auf einem Konto, das dir gehört, statt dem Versprechen eines Anbieters zu vertrauen, in deinem Namen “in der EU zu hosten”. Residenz und Souveränität sind zwei verschiedene Fragen, die meisten SaaS-Angebote beantworten nur die erste, und in der Lücke zwischen ihnen versteckt sich das Transferrisiko.

Dieser Beitrag erklärt, was Datenresidenz wirklich bedeutet, warum “in der EU gehostet” eine schwächere Aussage ist, als sie klingt, wie Schrems II und der US CLOUD Act das Risiko prägen, und wie die Wahl deiner eigenen Region auf deinem eigenen Konto Residenz von einem Versprechen in eine Ressource verwandelt, auf die du zeigen kannst. Es ist allgemeine Information, keine Rechtsberatung — kläre deine eigenen Pflichten mit einer Anwältin oder einem Anwalt.

Was bedeutet “EU-Datenresidenz” eigentlich?

Datenresidenz ist die Antwort auf eine physische Frage: In welchem Land oder welcher Region liegen diese Daten im Ruhezustand? Für eine Agentur, die EU-Kundendaten verarbeitet, lautet die angestrebte Antwort meist “in einer EU-Region”, damit personenbezogene Daten innerhalb des Europäischen Wirtschaftsraums bleiben, statt auf Server anderswo kopiert zu werden.

Aber Residenz allein ist nur die halbe Wahrheit. Die andere Hälfte ist Datensouveränität — wessen Gesetze die Daten regeln und wer den Zugriff darauf erzwingen kann. Daten können in Frankfurt ansässig sein und trotzdem unter ein Nicht-EU-Rechtssystem fallen, wenn das Unternehmen, das sie hält, fremdem Recht unterliegt. Die DSGVO selbst ist um diese Unterscheidung herum gebaut: Kapitel V (Artikel 44–50 der Verordnung (EU) 2016/679) beschränkt Übermittlungen personenbezogener Daten in “Drittländer” gerade deshalb, weil wohin die Daten gehen und wer sie erreichen kann andere Risiken sind als wo die Festplatte steht.

Eine vollständige Residenz-Aussage muss also drei Dinge beantworten, nicht eines:

1. Standort — in welcher Region die Daten physisch liegen.
2. Jurisdiktion — wessen Recht sie regelt und wer die Offenlegung erzwingen kann.
3. Kontrolle — wer die Region gewählt hat und wer sie später klammheimlich ändern kann.

Die meisten “in der EU gehostet”-Aussagen beantworten nur die erste.

Warum “in der EU gehostet” ein schwaches Residenz-Versprechen ist

“Wir hosten in der EU” klingt beruhigend, aber als Residenz-Garantie hat es drei weiche Stellen, die für eine Agentur zählen, die eine Auftragsverarbeitungsvereinbarung unterschreibt.

Es ist eine Richtlinie, keine Konstruktion. Ein Anbieter, der heute eine EU-Region wählt, kann morgen eine andere wählen, aus Resilienzgründen ein US-Failover hinzufügen oder Support-Tooling ins Ausland verlagern — meist ohne dich zu fragen. Die Aussage ist nur so beständig wie die aktuelle Konfiguration und das Wohlwollen des Anbieters.

Sie deckt selten die ganze Kette ab. Die primäre Datenbank mag in der EU liegen, während Backups, Logs, Fehler-Monitoring, E-Mail-Versand oder KI-Funktionen über Nicht-EU-Unterauftragsverarbeiter laufen. Jedes davon ist eine potenzielle Übermittlung personenbezogener Daten. “In der EU gehostet” beschreibt eine Komponente; deine Pflichten aus Artikel 28 zu Unterauftragsverarbeitern decken sie alle ab.

Sie klärt die Jurisdiktion nicht. Wenn der Anbieter — oder sein Mutterkonzern — fremden Zugriffsgesetzen unterliegt, bringen in der EU stehende Server die Daten nicht außer Reichweite dieser Gesetze. Das ist der Kern des Transferproblems, und genau hier kommen Schrems II und der US CLOUD Act ins Spiel.

Über die Mechanik der Kette der Unterauftragsverarbeiter haben wir ausführlicher in Datenresidenz und DSGVO für Agenturen geschrieben — die Kurzfassung ist, dass Konsolidierung ohne Eigentum das Risiko einfach in einem Anbieter zentralisiert, statt es auf drei zu verteilen.

Was ändern Schrems II und der US CLOUD Act an EU-Daten?

Zwei Entwicklungen machten aus “wo steht der Server” die Frage “wessen Recht erreicht die Daten”, und jedes ehrliche Residenz-Gespräch muss beide berücksichtigen.

Schrems II (2020). In der Rechtssache C-311/18 erklärte der Gerichtshof der Europäischen Union den EU-US-Datenschutzschild (Privacy Shield) für ungültig und entschied, dass Standardvertragsklauseln nur dann ein gültiger Transfermechanismus sind, wenn die Daten im Zielland weiterhin einen Schutz erhalten, der dem EU-Recht im Wesentlichen gleichwertig ist. Der praktische Effekt: Du kannst personenbezogene Daten nicht allein auf dem Papier außerhalb der EU übertragen — du musst das tatsächliche Rechtssystem bewerten, dem die Daten ausgesetzt wären. (Ein Nachfolge-Angemessenheitsbeschluss, das EU-US Data Privacy Framework, wurde im Juli 2023 verabschiedet, hat aber bereits rechtliche Anfechtungen ausgelöst, sich dauerhaft darauf zu verlassen ist also optimistisch.)

Der US CLOUD Act (2018). Der Clarifying Lawful Overseas Use of Data Act erlaubt US-Behörden, Unternehmen, die der US-Jurisdiktion unterliegen, zur Herausgabe von Daten zu zwingen, die sie kontrollieren — unabhängig davon, wo diese Daten physisch gespeichert sind. Ein US-Unternehmen (oder eine EU-Tochter davon) kann daher erreichbar sein, selbst wenn die Server in der EU stehen. Das ist der konkrete Grund, warum “in der EU gehostet” und “unter EU-Jurisdiktion” nicht derselbe Satz sind.

Keines von beiden bedeutet, dass EU-Agenturen keine Technologie mit irgendeiner US-Verbindung nutzen können — es gibt reichlich konforme Setups. Es bedeutet, dass die Fragen nach Jurisdiktion und Kontrolle tragend sind, und dass eine Residenz-Aussage, die nur über Geografie spricht, sie klammheimlich unbeantwortet lässt.

“In der EU gehostet” vs. Residenz auf deinem eigenen Konto

Der Unterschied ist am leichtesten nebeneinander zu sehen. Die folgenden Spalten vergleichen ein typisches Anbieter-Versprechen “in der EU gehostet” mit einer Datenbank, die auf deinem eigenen Cloud-Konto angelegt wird, in einer Region, die du gewählt hast.

Frage	“In der EU gehostet” (Anbieter-Versprechen)	Residenz auf deinem eigenen Konto
Wer wählt die Region	Der Anbieter, als Richtlinie	Du, beim Anlegen
Wer kann sie später ändern	Der Anbieter, oft ohne Vorwarnung	Du — es ist deine Ressource
Auf wessen Konto liegen die Daten	Dem des Anbieters	Deinem
Jurisdiktions-Risiko	Hängt vom Rechtssitz des Anbieters / Mutterkonzerns ab	Begrenzt durch deine Konto- und Regionswahl
Kette der Unterauftragsverarbeiter	Die volle Liste des Anbieters, die wachsen kann	Kürzer — Infrastruktur, mit der du bereits vertraglich verbunden bist
Beweis für einen Prüfer	Eine Klausel in einer Richtlinie	Eine Ressource, sichtbar in deinem eigenen Dashboard
Was beim Ausstieg passiert	Exportieren, dann auf Löschung vertrauen	Die Datenbank bleibt dein; der Anbieter verliert den Zugriff

Der Punkt ist nicht, dass “in der EU gehostet” unehrlich wäre — viele Anbieter meinen es aufrichtig. Es ist, dass jede Zeile auf der linken Seite ein Versprechen ist, dem du vertrauen musst, und jede Zeile auf der rechten Seite eine Tatsache, die du prüfen kannst. Für eine Frage der Datensouveränität in Agenturgröße schlägt prüfbar vertrauenswürdig.

Wie die Wahl deiner eigenen Region auf deinem eigenen Konto Residenz garantiert

Das ist die Designentscheidung hinter sSystm und, breiter, dem BYOC-Modell (Bring Your Own Cloud): Es gibt keine zentrale Anbieter-Datenbank, die deine CRM-Daten hält. Wenn sich deine Organisation mit ihrem eigenen Cloudflare-Konto anmeldet, legt sSystm eine dedizierte Cloudflare-D1-Datenbank auf deinem Konto an, in der Region, die du wählst, mit einer optionalen harten EU-Jurisdiktions-Garantie.

Warum das eine stärkere Residenz-Aussage ist als “in der EU gehostet”:

• Du wählst die Region, und es ist deine Ressource. Die Datenbank erscheint in deinem eigenen Cloudflare-Dashboard. Residenz ist keine Einstellung, die der Anbieter für dich verwaltet — es ist eine Wahl, die du auf Infrastruktur getroffen hast, die du kontrollierst.
• Die EU-Jurisdiktions-Garantie ist hart, keine Präferenz. Mit ihr aktiviert ist die Datenbank an die EU-Jurisdiktion gebunden, statt dort voreingestellt und potenziell verschoben zu werden. Das adressiert direkt die Souveränitäts-Hälfte der Frage, nicht nur die Geografie-Hälfte.
• Die Kette ist kürzer und näher an dir. Die Daten sitzen auf Infrastruktur, mit der du bereits eine direkte Beziehung hast, was die Liste der Parteien mit technischem Zugriff verkürzt — genau das, was dein Verzeichnis nach Artikel 30 nachhalten muss.
• Der Ausstieg verschiebt die Daten nicht. Weil die Datenbank immer auf deinem Konto war, widerruft das Verlassen der Plattform den Zugriff des Anbieters, statt eine Migration auszulösen. Es gibt nichts zu exportieren, weil es nichts zurückzulassen gibt.

Nichts davon nimmt dir deine Verantwortung als Verantwortlicher (Data Controller). sSystm betreibt weiterhin die Software und zählt unter der DSGVO weiterhin als Auftragsverarbeiter, du brauchst also weiterhin deine eigene Auftragsverarbeitungsvereinbarung, deine eigene Dokumentation der Unterauftragsverarbeiter und — wenn dies eine akute Compliance-Frage ist — deine eigene rechtliche Prüfung. Was sich ändert, ist die Stärke der zugrundeliegenden Aussage: Du kannst die Datenbank, das Konto und die Region zeigen, statt eine Richtlinie zu zitieren. Mehr Details zum Sicherheits- und Datenmodell findest du auf der Sicherheitsseite.

Wie du EU-Datenresidenz wirklich garantierst: eine Checkliste

Bevor du eine Residenz-Aussage in eine Kunden-Auftragsverarbeitungsvereinbarung schreibst, prüfe bei jedem Werkzeug, das du nutzt — sSystm eingeschlossen — das Folgende:

1. Liegt die Datenbank auf meinem Konto oder dem des Anbieters? Dediziert-aber-Anbieter-eigen ist Isolation, keine Residenz, die du kontrollierst.
2. Kann ich die Region wählen — und ist das eine echte Wahl beim Anlegen oder eine Marketing-Zeile? Bitte darum, sie in deiner eigenen Konsole zu sehen.
3. Ist die EU-Jurisdiktion garantiert oder nur voreingestellt? Eine Voreinstellung kann driften; eine Garantie ist eine Verpflichtung.
4. Wie sieht die vollständige Liste der Unterauftragsverarbeiter aus, inklusive Backups, Logs, E-Mail und KI-Funktionen? Die weichen Stellen liegen meist außerhalb der primären Datenbank.
5. Unterliegt der Anbieter (oder sein Mutterkonzern) fremden Zugriffsgesetzen? Das ist die Schrems-II- / CLOUD-Act-Frage — und sie überlebt eine EU-Region.
6. Was passiert beim Ausstieg? Die richtige Antwort lautet: Der Anbieter verliert den Zugriff, du behältst die Daten, ohne Export-Schritt.

Wenn ein Anbieter die ersten drei mit “auf deinem Konto, deiner gewählten Region, garantierter EU-Jurisdiktion” beantwortet, hast du eine Residenz-Aussage, die du beweisen kannst. Wenn die Antworten alle “vertrau unserer Richtlinie” lauten, hast du ein Versprechen — das durchaus gehalten werden mag, aber nicht dasselbe ist.

Wo dich das lässt

EU-Datenresidenz ist kein Häkchen; sie besteht aus drei Fragen — Standort, Jurisdiktion und Kontrolle — und “in der EU gehostet” beantwortet nur eine davon. Schrems II und der US CLOUD Act sind der Grund, warum die anderen beiden zählen, denn sie zeigen, dass wo eine Festplatte steht und wessen Recht sie erreicht auseinanderfallen können. Die robusteste Antwort, die einer Agentur heute zur Verfügung steht, ist, die Datenbank auf deinem eigenen Konto zu halten, in einer Region, die du wählst, unter einer harten EU-Jurisdiktions-Garantie — sodass Residenz zu einer Ressource wird, auf die du zeigen kannst, statt zu einem Versprechen, dem du glauben musst.

Fang mit was ein BYOC Agency OS ist für das zugrundeliegende Modell an, lies die tiefere Aufschlüsselung zu DSGVO und Unterauftragsverarbeitern, und sieh dir das Sicherheits- und Datenmodell an, wie die Verbindung in der Praxis funktioniert. Dieser Artikel ist allgemeine Information über Datenresidenz, keine Rechtsberatung; für deine konkreten Pflichten sprich mit einer Anwältin oder einem Anwalt.