Data Residency und grenzüberschreitende Datentransfers in Multi-Tenant-Apps

# Data Residency und grenzüberschreitende Datentransfers in Multi-Tenant-Apps

An einem Dienstag trifft eine Mail aus dem Einkauf ein: „Unsere Daten müssen jederzeit innerhalb der EU bleiben, Backups eingeschlossen.“ Die Architektur des SaaS-Anbieters, ein einzelner in den USA gehosteter Postgres-Cluster für alle Tenants, mit nächtlichem Backup nach Virginia, kann diesen Satz so nicht erfüllen. Sales will den Deal abschließen. Engineering muss herausfinden, was „in der EU“ konkret für Sharding, Backups, Logs und jeden Subprozessor bedeutet, der diese Daten berührt. Das ist das Residency-Problem, und es trifft jedes Multi-Tenant-SaaS-Unternehmen in dem Moment, in dem es sein erstes ernstzunehmendes europäisches (oder indisches, saudisches, brasilianisches) Enterprise-Logo gewinnt.

Was „Data Residency“ tatsächlich bedeutet

Data Residency ist eine Anforderung (vertraglich, manchmal auch gesetzlich), dass Daten eines Kunden innerhalb einer bestimmten geografischen oder jurisdiktionellen Grenze gespeichert bleiben.

Datensouveränität ist der stärkere, verwandte Gedanke: Daten unterliegen den Gesetzen des Landes, in dem sie liegen, unabhängig davon, wo das Unternehmen, dem sie gehören, seinen Hauptsitz hat. Die Daten eines französischen Krankenhauses, gespeichert auf einem Cloud-Server in US-Besitz, selbst wenn dieser physisch in Frankfurt steht, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen theoretisch für US-Strafverfolgungsbehörden zugänglich sein, und zwar über den CLOUD Act (2018), der US-Behörden erlaubt, in den USA ansässige Provider zur Herausgabe von Daten zu verpflichten, die sie kontrollieren, wo auch immer diese gespeichert sind. Genau deshalb treiben EU-Regulierer „Sovereign Cloud“-Angebote voran.

Grenzüberschreitender Datentransfer ist der Vorgang, personenbezogene Daten von einer Jurisdiktion in eine andere zu bewegen, unterschiedlich von Residency, aber eng damit verbunden, denn ein Residency-Versprechen ist im Kern ein Versprechen, Transfers zu kontrollieren.

Diese drei Begriffe werden in Sales-Gesprächen synonym verwendet. Sie sind nicht dasselbe, und ihre Vermischung ist der Grund, warum Engineering-Teams zu viel oder zu wenig bauen.

Die regulatorischen Ankerpunkte

Die DSGVO (Datenschutz-Grundverordnung, EU, anwendbar seit 2018) ist der Referenzpunkt. Sie verlangt nicht, dass EU-Daten physisch in der EU bleiben. Stattdessen beschränkt Kapitel V *Übermittlungen* personenbezogener Daten in Länder außerhalb der EU/des EWR, sofern nicht eines der Folgenden zutrifft:

• Ein Angemessenheitsbeschluss: Die Europäische Kommission hat festgestellt, dass die Gesetze des Ziellandes ein vergleichbares Schutzniveau bieten (Beispiele: UK, Japan, Südkorea und, seit 2023, die USA unter dem EU-US Data Privacy Framework).
• Standardvertragsklauseln (SCCs): vorab genehmigte Vertragsvorlagen zwischen Exporteur und Importeur, der häufigste Mechanismus für US-basierte SaaS-Anbieter.
• Binding Corporate Rules (BCRs): konzerninterne Regeln für Übermittlungen innerhalb multinationaler Gruppen.

Das EU-US-Framework ist relevant, weil es zwei frühere Konstruktionen ersetzte, die der Gerichtshof der EU gekippt hat: Safe Harbor (2015 für ungültig erklärt) und Privacy Shield (2020 für ungültig erklärt, das „Schrems II“-Urteil, nachdem der österreichische Datenschutzaktivist Max Schrems den Übermittlungsmechanismus von Facebook angegriffen hatte). Jede dieser Ungültigerklärungen zwang tausende SaaS-Anbieter, praktisch über Nacht eine neue rechtliche Grundlage zu finden. Diese Geschichte ist der Grund, warum Enterprise-Einkäufer heute in Security-Fragebögen explizit nach Transfermechanismen fragen und nicht nur eine Checkbox setzen.

Weitere Regime, die man namentlich kennen sollte:

• Chinas PIPL (Personal Information Protection Law, 2021) verlangt Sicherheitsbewertungen für grenzüberschreitende Übermittlungen „wichtiger Daten“ und schreibt für bestimmte Betreiber lokale Speicherung vor.
• Indiens DPDP Act (Digital Personal Data Protection Act, 2023) erlaubt der Regierung, Transfers in bestimmte Länder über einen Blocklist-Ansatz zu beschränken.
• Schrems II selbst hat Transfers nicht verboten, verlangt aber von Exporteuren, im Einzelfall zu prüfen, ob die Überwachungsgesetze des Ziellandes den Schutz der SCCs untergraben, ein Schritt, der als Transfer Impact Assessment (TIA) bekannt ist.

Als Primärquelle ist die Guidance des EDSA (Europäischer Datenschutzausschuss) zu Transfer-Tools die kostenlose, mamaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßgebliche Quelle, nicht irgendein Anbieter-Blog.

Wie das das Produkt verändert, nicht nur den Vertrag

Sales kann Residency versprechen; liefern kann es nur die Architektur. Vier konkrete Änderungen ziehen sich durch den Stack.

1. Sharding nach Region. Multi-Tenant-SaaS-Apps speichern aus Kostengründen üblicherweise alle Tenants in gemeinsam genutzter Infrastruktur. Residency verlangt Shards pro Region: einen EU-Shard (etwa AWS eu-central-1, Frankfurt), der nur EU-Tenant-Daten hält, mit Anwendungslogik, die Reads und Writes jedes Tenants auf den richtigen Shard routet. Das ist ein echtes Engineering-Projekt, kein Config-Flag, besonders bei Apps, die von Tag eins auf einer einzigen globalen Datenbank aufgebaut wurden.

2. Backups und Disaster Recovery. Ein Backup, das aus Resilienzgründen regionsübergreifend repliziert wird, wird zum Compliance-Verstoß, wenn es außerhalb der versprochenen Grenze landet. Anbieter müssen entweder die Backup-Replikation auf Einrichtungen in der Region beschränken (und geringere Disaster-Recovery-Robustheit akzeptieren) oder Verschlüsselungsverfahren nutzen, bei denen nur Schlüssel in der Region entschlüsseln kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen, was Prüfern zeigt, dass die Daten außerhalb *effektiv* unzugänglich sind, selbst wenn Bytes vorübergehend eine Grenze überschreiten.

3. Logs, Metriken und Support-Tooling. Hier fliegen Teams auf. Application Logs, Error Traces (z. B. Sentry), Support-Tickets (z. B. Zendesk) und Analytics-Pipelines schicken Kundendaten oft unbemerkt an US-basierte SaaS-Tools. Eine Residency-Zusage, die diese sekundären Flows nicht prüft, ist keine echte Zusage.

4. Subprozessor-Verträge. Nach DSGVO ist ein Subprozessor jeder Dritte, den der Anbieter (der „Auftragsverarbeiter“) einsetzt, um personenbezogene Daten im Auftrag des Kunden (des „Verantwortlichen“) zu verarbeiten. Cloud-Hosting-Provider, E-Mail-Versanddienste, Support-Plattformen, selbst APIs von KI-Modellen sind Subprozessoren. Artikel 28 DSGVO verlangt, dass Auftragsverarbeiter gleichwertige Datenschutzpflichten an jeden Subprozessor weitergeben und die Subprozessor-Liste gegenüber Kunden offenlegen. Enterprise-Verträge enthalten heute üblicherweise ein Widerspruchsrecht gegen neue Subprozessoren und eine vorgeschriebene Ankündigungsfrist (typischerweise 30 Tage, als Schätzung gängiger Marktpraxis), bevor einer hinzukommt.

Ein praktisches Beispiel für die Kette: Ein SaaS-Anbieter integriert die APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → von OpenAI für ein KI-Feature. OpenAI wird damit zum Subprozessor. Läuft die Datenverarbeitung bei OpenAI auf US-Infrastruktur, ist jeder EU-Kundenvertrag, der EU-only-Residency verspricht, technisch gebrochen, es sei denn, der Anbieter nutzt die EU-Data-Residency-Optionen von OpenAI oder ein in der EU gehostetes Alternativmodell.

Eine minimale technische Illustration

Regionsbewusstes Routing beginnt meist mit einer Tenant-zu-Region-Lookup-Tabelle, die abgefragt wird, bevor irgendeine Query Kundendaten berührt:

-- tenant_region_map: one row per tenant, set at signup
SELECT region_endpoint
FROM tenant_region_map
WHERE tenant_id = :current_tenant;

-- application layer then connects to the
-- region-specific database cluster, e.g.:
-- eu-central-1.db.internal  OR  us-east-1.db.internal

Der schwierige Teil ist nie dieser Lookup. Es ist sicherzustellen, dass *jeder* Service (Suchindex, Cache, Message Queue, Log Shipper) dieselbe Routing-Entscheidung respektiert.

Praktische Prüfungen und Audits

Für ein Governance-Team, das Residency-Aussagen bewertet (die eigenen oder die eines Anbieters), eine belastbare Checkliste:

• Data Flow Mapping: jedes System dokumentieren, das personenbezogene Daten speichert oder durchleitet, einschließlich Logging, Analytics und KI-Tooling, nicht nur die Primärdatenbank. Das ist Standardpraxis nach der Verzeichnispflicht aus Artikel 30 DSGVO.
• Review des Subprozessor-Registers: die veröffentlichte Subprozessor-Liste des Anbieters prüfen (die meisten SaaS-Anbieter veröffentlichen eine, z. B. über ihr Trust Center), und zwar auf Hosting-Region und Transfermechanismus.
• Transfer Impact Assessment liegt vor: Gibt es für jeden SCC-basierten Transfer ein dokumentiertes TIA, das das Überwachungsrisiko im Zielland adressiert?
• Verifizierung von Backup- und DR-Region: gezielt fragen, nicht nur „sind die Daten verschlüsselt“, sondern „wo liegen die Backups und wer hält die Entschlüsselungsschlüssel“.
• Zertifizierungen als Signal, nicht als Beweis: SOC 2 Type II (ein US-Prüfungsstandard für Sicherheitskontrollen) und ISO 27001 (ein internationaler Standard für Informationssicherheits-Managementsysteme) zeigen Prozessreife, sagen aber nichts Spezifisches über Residency. Akzeptieren Sie sie nicht als Ersatz für die Antwort Region für Region.
• Vertragliche Auditrechte: sicherstellen, dass der Kundenvertrag das Recht enthält, Nachweise anzufordern (Auditberichte, Subprozessor-Listen), statt sich auf Marketingaussagen zu verlassen.

🎬 [VIDEO: „GDPR Data Transfers Explained“ - youtube.com - ein Durchgang zu SCCs, Angemessenheitsbeschlüssen und den Folgen von Schrems II, gerichtet an Praktiker, nicht an Juristen]

Key Takeaways

• Data Residency, Souveränität und grenzüberschreitender Transfer sind verwandte, aber unterschiedliche Konzepte; Verträge vermischen sie oft, Architekturentscheidungen brauchen Präzision.
• Die DSGVO verbietet internationale Transfers nicht pauschal, sie verlangt einen gültigen Mechanismus (Angemessenheitsbeschluss, SCCs oder BCRs), und Schrems II hat die Pflicht ergänzt, das Überwachungsrisiko im Zielland im Einzelfall zu bewerten.
• Ein Residency-Versprechen einzuhalten betrifft Sharding, Backups, Logs, Analytics und Support-Tooling, nicht nur die Primärdatenbank; das schwächste Glied ist meist ein vergessenes Sekundärsystem.
• Jeder Drittanbieterdienst, der Kundendaten berührt, KI-APIs eingeschlossen, ist ein Subprozessor nach DSGVO und muss offengelegt und vertraglich gebunden werden.
• SOC 2 und ISO 27001 sind nützliche Signale für Sicherheitsreife, beantworten aber die Residency-Frage nicht; fragen Sie immer nach der konkreten Region und dem Transfermechanismus.