Wie deutsche Unternehmen personenbezogene Daten gemäß BfDI-Anforderungen vor dem Zugriff der US-Regierung schützen können
Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) hat die Überprüfung von Unternehmen, die US-Cloud-Anbieter zur Verarbeitung deutscher personenbezogener Daten nutzen, verschärft. Der US CLOUD Act ermöglicht es amerikanischen Strafverfolgungsbehörden, US-Unternehmen zur Herausgabe von Daten zu verpflichten – unabhängig vom physischen Speicherort. Dies führt zu einem grundlegenden Konflikt zwischen US-Überwachungsgesetzen und deutschen Datenschutzanforderungen nach DSGVO.
Deutsche Unternehmen stehen vor einer entscheidenden Frage: Können Sie dem BfDI nachweisen, dass personenbezogene Daten vor dem Zugriff ausländischer Behörden geschützt bleiben? Der BfDI fordert technische Maßnahmen – architektonische Kontrollen, die einen unbefugten Zugriff technisch unmöglich machen – und akzeptiert keine rein vertraglichen Zusicherungen.
Dieser Leitfaden erklärt, wie deutsche Unternehmen die BfDI-Anforderungen durch Datensouveränität erfüllen: kundengesteuerte Verschlüsselungsschlüssel, Single-Tenant-Bereitstellung in Europa und durch Richtlinien erzwungene Datenresidenz.
Executive Summary
Kernaussage: Deutsche Unternehmen müssen Compliance zur Datensouveränität umsetzen – kundengesteuerte Verschlüsselungsschlüssel und Single-Tenant-Bereitstellung in Europa –, um personenbezogene Daten vor dem Zugriff der US-Regierung gemäß CLOUD Act zu schützen. Vertragliche Maßnahmen wie Standardvertragsklauseln verhindern die gesetzlich erzwungene Herausgabe an ausländische Behörden nicht.
Warum das relevant ist: Der BfDI verlangt nachweisbare technische Kontrollen, die einen Zugriff ausländischer Behörden unmöglich machen – nicht nur vertragliche Zusagen. Unternehmen, die keine technische Souveränität nachweisen können, riskieren aufsichtsrechtliche Maßnahmen, DSGVO-Bußgelder von bis zu 4 % des weltweiten Umsatzes, Vertragsverletzungen gegenüber Kunden und Wettbewerbsnachteile, da Datensouveränität zum Markterfordernis wird.
wichtige Erkenntnisse
1. Der CLOUD Act gilt für US-Unternehmen unabhängig vom Speicherort der Daten. Der Clarifying Lawful Overseas Use of Data Act verpflichtet amerikanische Unternehmen, US-Behörden Zugriff auf Daten zu gewähren – egal, wo diese weltweit gespeichert sind, auch in Rechenzentren in Frankfurt oder Amsterdam. Der physische Speicherort bestimmt nicht die rechtliche Zuständigkeit.
2. Vertragliche Schutzmechanismen können gesetzliche Verpflichtungen nicht aushebeln. Standardvertragsklauseln und das EU-US Data Privacy Framework sind rechtliche Übermittlungsmechanismen, verhindern aber nicht, dass Anbieter US-Gesetzesanforderungen nachkommen. Wenn US-Recht die Herausgabe verlangt, müssen Anbieter dies auch bei vertraglichen Zusagen gegenüber Kunden tun.
3. Kundengesteuerte Verschlüsselungsschlüssel verhindern die Erfüllung ausländischer Anforderungen durch den Anbieter. Wenn Kunden Verschlüsselungsschlüssel in eigenen Hardware Security Modules generieren und speichern, können Anbieter Daten auch bei gesetzlicher Verpflichtung nicht entschlüsseln. Die technische Unmöglichkeit der Entschlüsselung bietet Schutz, den Verträge nicht leisten können.
4. Der BfDI verlangt technische Nachweise, keine vertraglichen Behauptungen. Die deutschen Datenschutzbehörden erwarten architektonische Dokumentation, die belegt, dass Daten Deutschland nie verlassen, Verschlüsselungsschlüssel unter Kundensouveränität bleiben und Anbieter keinen Zugriff auf entschlüsselte personenbezogene Daten haben. Compliance erfordert nachweisbare technische Maßnahmen.
5. Single-Tenant-Bereitstellung in Europa beseitigt komplexe Mehrmandanten-Szenarien. Dedizierte Infrastruktur in festgelegten deutschen Rechenzentren schafft klare Zuständigkeit, vollständige Isolation von anderen Unternehmen und dokumentierte Datenresidenz, die die BfDI-Anforderungen für Transfer Impact Assessments und Audit-Anfragen erfüllt.
Das CLOUD-Act-Problem für deutsche Unternehmen verstehen
Der Clarifying Lawful Overseas Use of Data Act (US CLOUD Act) hat 2018 den internationalen Datenschutz grundlegend verändert. Deutsche Unternehmen müssen verstehen, wie dieses Gesetz ihre Datenverarbeitungsmodelle beeinflusst.
Eine vollständige Checkliste für DSGVO-Compliance
Jetzt lesen
Was der CLOUD Act für deutsche Daten bedeutet
Der CLOUD Act verpflichtet US-Unternehmen, US-Behörden Zugriff auf Daten zu gewähren – unabhängig vom physischen Speicherort. Das Gesetz gilt für Unternehmen mit US-Geschäft, US-Mitarbeitern oder US-Investoren – und damit für alle großen Cloud-Anbieter.
Wenn US-Behörden Microsoft, Google oder Amazon zur Herausgabe von Daten aus Frankfurter Rechenzentren auffordern, müssen diese Unternehmen dem nachkommen. Der physische Speicherort in Deutschland schützt nicht vor US-Rechtsansprüchen.
Zentrale Auswirkungen:
- Daten in deutschen Rechenzentren von US-Anbietern bleiben für US-Behörden zugänglich
- US-Behörden benötigen keine Kontrolle durch deutsche Gerichte
- Anbieter dürfen Kunden über behördliche Anfragen oft nicht informieren
- Deutsches Datenschutzrecht kann die Herausgabe durch Anbieter nicht verhindern
Warum der Standort des deutschen Rechenzentrums nicht ausreicht
Der physische Standort bestimmt, wo Daten geografisch gespeichert werden. Die rechtliche Zuständigkeit regelt, welches Land den Datenzugriff kontrolliert. Wenn US-Unternehmen deutsche Rechenzentren betreiben, gilt US-Recht – unabhängig vom Serverstandort.
Die Position des BfDI: Ein Rechenzentrum in Deutschland ist notwendig, aber nicht ausreichend. Unternehmen müssen technische Kontrollen implementieren, die den Zugriff durch Anbieter auch bei gesetzlicher Verpflichtung verhindern.
Die Grenzen von Standardvertragsklauseln
Standardvertragsklauseln sind von der Europäischen Kommission genehmigte Vertragsbedingungen für Datenübermittlungen. Sie sind jedoch vertragliche Mechanismen und bieten keinen technischen Schutz.
Was Standardvertragsklauseln nicht leisten können:
- US-Gesetze zur Datenherausgabe aushebeln
- Verhindern, dass Anbieter gesetzlichen Verpflichtungen nachkommen
- Die Erfüllung gesetzlicher Anforderungen technisch unmöglich machen
- Daten schützen, wenn US-Recht mit Verträgen kollidiert
Die rechtliche Hierarchie: US-Bundesrecht steht über Anbieter-Verträgen, die wiederum über Standardvertragsklauseln stehen. Wenn US-Recht die Herausgabe verlangt, können vertragliche Verpflichtungen die Compliance nicht verhindern.
BfDI-Anforderungen an Datensouveränität
Die deutschen Datenschutzbehörden legen die DSGVO streng aus, insbesondere beim Schutz vor ausländischer Überwachung.
Kritische DSGVO-Artikel für deutsche Datensouveränität
Drei DSGVO-Artikel bilden die Grundlage der BfDI-Anforderungen an die Datensouveränität.
| DSGVO-Artikel | Anforderung | BfDI-Interpretation |
|---|---|---|
| Artikel 25 | Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen | Kundengesteuerte Verschlüsselung für sensible personenbezogene Daten bei Drittanbietern erforderlich |
| Artikel 32 | Sicherheit der Verarbeitung einschließlich Verschlüsselung | Verschlüsselung, bei der Anbieter die Schlüssel halten, reicht nicht aus – Kundenschlüsselkontrolle ist notwendig |
| Artikel 44-49 | Internationale Übermittlungen und Transfer Impact Assessments | Architektonische Maßnahmen erforderlich, da Verträge den gesetzlich erzwungenen Zugriff nicht verhindern können |
Was nachweisbare technische Kontrollen bedeuten
Der BfDI fordert technische Kontrollen, die einen unbefugten Zugriff technisch unmöglich machen – nicht nur vertraglich untersagen.
| Unzureichende Maßnahmen | Nachweisbare technische Kontrollen |
|---|---|
| Anbieter verspricht, nicht auf Daten zuzugreifen | Kunde kontrolliert Verschlüsselungsschlüssel im Hardware Security Module |
| Nur Standardvertragsklauseln | Anbieter kann Daten ohne Kundenschlüssel nicht entschlüsseln |
| Verschlüsselung, bei der der Anbieter die Schlüssel hält | Single-Tenant-Bereitstellung an festgelegtem deutschen Standort |
| Deutsches Rechenzentrum, betrieben von US-Unternehmen | Geofencing-Richtlinien, die verhindern, dass Daten Deutschland verlassen |
| Umfassende Audit-Trails, die Zugriff und Standort dokumentieren |
Anforderungen an Transfer Impact Assessments
Der BfDI erwartet, dass Transfer Impact Assessments Risiken ehrlich bewerten und wirksame technische Gegenmaßnahmen nachweisen.
Erforderliche TIA-Bestandteile:
Ehrliche Risikobewertung mit Antworten auf:
- Gilt der US CLOUD Act? (Ja, bei US-Unternehmen)
- Kann Ihr Anbieter US-Anforderungen widerstehen? (Nein)
- Verhindern Verträge die Compliance? (Nein)
- Funktionieren ergänzende Maßnahmen? (Muss technisch nachgewiesen werden)
Dokumentation technischer Maßnahmen:
- Architekturdiagramme mit Datenflüssen
- Verschlüsselung mit Details zur Schlüsselverwaltung
- Durchsetzung von Zugriffskontrollen
- Geografische Einschränkungen und deren Durchsetzung
Nachweis der Wirksamkeit:
- Warum Maßnahmen den Zugriff ausländischer Behörden verhindern
- Wie Kundenschlüsselkontrolle Entschlüsselung unmöglich macht
- Was bei behördlichen Anfragen passiert
- Wie dies dem BfDI nachgewiesen werden kann
Unternehmen sollten umfassende Dokumentation proaktiv vorbereiten. Auf BfDI-Anfragen muss innerhalb von vier Wochen reagiert werden. Der BfDI fragt gezielt: Wo werden Daten gespeichert (präzise Standorte, nicht „Cloud“), wer kontrolliert die Verschlüsselungsschlüssel (Kunden-HSM, nicht nur „verschlüsselt“), und ob Anbieter auf ausländische Anforderungen reagieren können (nein, da sie keine Schlüssel besitzen).
Mitbestimmungsrechte des Betriebsrats
Deutsche Betriebsräte haben Mitbestimmungsrechte bei der Verarbeitung von Beschäftigtendaten. Unternehmen müssen ihre Regelungen für den Betriebsrat dokumentieren, technische Souveränitätsmaßnahmen verständlich erklären und die Zustimmung des Betriebsrats einholen, bevor Änderungen an Systemen zur Verarbeitung von Beschäftigtendaten umgesetzt werden.
Architektonische Lösungen für BfDI-konforme Datensouveränität
Die technische Architektur bildet die Grundlage für Datensouveränität, die die BfDI-Anforderungen erfüllt. Drei architektonische Säulen greifen ineinander und schaffen nachweisbare technische Kontrollen.
Der Ansatz der kundengesteuerten Verschlüsselungsschlüssel
Kundengesteuerte Verschlüsselungsschlüssel schaffen kryptografische Souveränität und verhindern den Zugriff durch Anbieter – auch bei gesetzlicher Verpflichtung.
Wie Kundenschlüsselkontrolle funktioniert
Kunden generieren Verschlüsselungsschlüssel in ihrer eigenen sicheren Umgebung und speichern sie im eigenen Hardware Security Module oder Schlüsselmanagementsystem. Die Schlüssel verlassen nie die Kontrolle oder den geografischen Geltungsbereich des Kunden.
Anbieter greifen nur für autorisierte Vorgänge über einen sicheren Key Access Service auf die Schlüssel zu. Der Service prüft jede Anfrage anhand der Kundenrichtlinien, bevor temporärer Zugriff gewährt wird. Anbieter können Daten ohne Kundengenehmigung nicht entschlüsseln.
Warum dies die BfDI-Anforderungen erfüllt
Wenn US-Behörden CLOUD-Act-Anfragen stellen, verfügen Anbieter zwar über verschlüsselte Daten, aber nicht über die Entschlüsselungsschlüssel. Die faktische Antwort des Anbieters: „Wir können keine entschlüsselten Daten liefern, da wir die Schlüssel nicht besitzen. Der Kunde kontrolliert die Schlüssel in seinem deutschen HSM.“
Rechtliche Anforderungen können nicht zur Herausgabe von etwas zwingen, das nicht im Besitz der angefragten Partei ist. Kundenschlüsselkontrolle bedeutet, dass Anbieter keine Entschlüsselungsmöglichkeit haben und gesetzliche Anforderungen nicht erfüllen können.
Dies erfüllt die Verschlüsselungsanforderungen nach DSGVO Artikel 32, Datenschutz durch Technikgestaltung nach Artikel 25 und belegt angemessene technische Maßnahmen, die den Zugriff durch Anbieter verhindern.
Technische Architektur der Schlüsselverwaltung
Kundeneigene Hardware Security Modules in Deutschland speichern AES-256-Verschlüsselungsschlüssel unter Kontrolle der Kundenadministratoren. Diese HSMs sind über sichere Key Access Services mit den Systemen des Anbieters verbunden, die jede Anfrage validieren.
Ablauf der Schlüsselverwaltung:
- Kunde generiert Schlüssel im eigenen HSM
- Schlüssel bleiben unter Kontrolle des Kundenadministrators
- System fordert temporären Zugriff für Vorgänge an
- Key Access Service prüft Anfrage anhand der Richtlinien
- Bei Freigabe wird temporärer Zugriff gewährt
- System verschlüsselt Daten mit dem Kundenschlüssel
- Verschlüsselte Daten werden gespeichert; Schlüssel gehen zurück ins HSM
- Entschlüsselung erfolgt nach demselben Validierungsprozess
Erhält der Anbieter eine behördliche Anfrage, besitzt er nur verschlüsselte Daten, aber keine Entschlüsselungsschlüssel. Die Anfrage kann nicht erfüllt werden, da die kryptografische Fähigkeit fehlt.
Single-Tenant-Bereitstellung in Europa
Single-Tenant-Bereitstellung bedeutet dedizierte Infrastruktur, die ausschließlich einem Kunden dient – ohne geteilte Ressourcen.
Warum Single-Tenant-Architektur entscheidend ist
Multi-Tenant-Plattformen bedienen Tausende Kunden auf gemeinsamer Infrastruktur. Kundendaten teilen sich Server, Speicher und Netzwerk mit anderen Unternehmen – das schafft Risiken und komplexe Zuständigkeiten.
Single-Tenant-Bereitstellung beseitigt diese Risiken. Unternehmen erhalten dedizierte Infrastruktur in ausgewählten deutschen Rechenzentren mit vollständiger Isolation. Es findet keine Datenvermischung statt.
Bereitstellungsoptionen für deutsche Unternehmen
| Bereitstellungsoption | Infrastrukturkontrolle | Zeitrahmen | Optimal für |
|---|---|---|---|
| Kundeneigenes Rechenzentrum | Vollständig | 3–6 Monate | Großunternehmen mit hohen Sicherheitsanforderungen |
| Deutscher Cloud Service Provider | Hoch | 1–3 Monate | Mittelständische Unternehmen mit Flexibilitätsbedarf |
| Anbieter-gehostete dedizierte Instanz | Gemäß SLA | 4–8 Wochen | Unternehmen mit Fokus auf schnelle Umsetzung |
Klare Zuständigkeit durch Isolation
Single-Tenant-Bereitstellung schafft klare rechtliche Zuständigkeit. Die Infrastruktur befindet sich physisch in Deutschland und kann auf Wunsch von deutschen Administratoren betrieben werden.
Unternehmen legen präzise deutsche Rechenzentrumsstandorte fest, statt sich mit „EU-Regionen“ zufrieden zu geben. Die vollständige Infrastrukturisolation beseitigt Zuständigkeitsunklarheiten und ermöglicht eine einfache BfDI-Dokumentation.
Richtlinienbasierte Kontrolle der Datenresidenz
Technische Richtliniendurchsetzung stellt sicher, dass Daten die festgelegte geografische Region nicht verlassen – unabhängig von Benutzeraktionen.
Geofencing und Durchsetzungsmechanismen
Unternehmen definieren Grenzen wie „nur Deutschland“ oder „nur EU/EWR“. Richtlinien-Engines erzwingen diese Grenzen bei allen Datenoperationen – Speicherung, Verarbeitung, Übertragung und Backup.
Speicherortkontrolle stellt sicher, dass Daten ausschließlich in festgelegten deutschen Rechenzentren gespeichert werden – ohne Replikation in nicht-deutsche Standorte ohne explizite Freigabe. Zugriffsortkontrolle kann Remote-Zugriffe aus dem Ausland einschränken, falls erforderlich, z. B. mit administrativem Zugriff nur von deutschen IP-Adressen und Blockierung unautorisierter Zugriffsversuche.
Übertragungsverhinderung gilt für alle Datenbewegungen: E-Mail-Anhänge werden durch Richtlinien geprüft, Filesharing erzwingt geografische Einschränkungen, API-Zugriffe unterliegen Geofencing, und Sync-Clients beschränken die Datensynchronisation nach Geografie.
Umfassende Audit-Trails
Jeder Vorgang wird protokolliert – mit Benutzeridentität, Aktion, betroffenen Daten, geografischem Speicher- und Zugriffsort, Ergebnis der Richtlinienprüfung und kryptografisch signierten Zeitstempeln.
Für BfDI-Anfragen liefern diese Audit-Trails vollständige Nachweise, wo Daten gespeichert wurden, wer Zugriff hatte und dass Daten Deutschland nie verlassen haben.
Vorgehen zur Umsetzung für deutsche Unternehmen
Die Umsetzung architektonischer Datensouveränität erfordert systematische Planung in Technik, Betrieb und Compliance.
Ist-Analyse und Migrationsplanung
Unternehmen sollten bestehende Regelungen dokumentieren und Lücken identifizieren. Anbieterinventar erfasst, welche US-Anbieter personenbezogene Daten deutscher Kunden speichern, welche Kategorien verarbeitet werden, wo Rechenzentren liegen und wer die Verschlüsselungsschlüssel kontrolliert. Transfer Impact Assessment Review prüft, ob aktuelle TIAs das CLOUD-Act-Risiko ehrlich bewerten und wirksame Gegenmaßnahmen dokumentieren. BfDI-Readiness-Assessment klärt, ob Unternehmen auf Anfragen innerhalb von vier Wochen reagieren können.
Datenklassifizierung und Priorisierung
Priorität-1-Daten erfordern sofortige Maßnahmen: Beschäftigtendaten, Kundendaten mit strengen Verträgen, besondere Kategorien nach DSGVO Artikel 9, Daten öffentlicher Auftraggeber und Daten mit laufender BfDI-Anfrage.
Priorität-2-Daten erfordern geplante Migration: Kundendaten, bei denen Wettbewerber Souveränität bieten, vertrauliche Partnerdaten, regulierte Finanzdaten und gesundheitsbezogene Daten außerhalb der DSGVO-Sonderkategorien.
Priorität-3-Daten können sukzessive bewertet werden: Interne Kollaborationsdaten, nicht-personenbezogene Daten und Daten mit geringerer Sensitivität.
Technischer Implementierungszeitplan
Die Umsetzungsdauer variiert je nach Bereitstellungsoption. Anbieter-gehostete Bereitstellung benötigt typischerweise 12–16 Wochen. Deutsche Cloud-Bereitstellung erfordert 2–4 Wochen zusätzlich. Kundeneigenes Rechenzentrum benötigt 4–12 Wochen mehr.
Wochen 1–4: Grundlagen: HSM-Einrichtung, Schlüsselerzeugung, Key Access Service, Auswahl des Rechenzentrums, Instanzkonfiguration, Netzwerkanbindung und Geofencing.
Wochen 5–8: Integration: SSO-Integration, Zugriffskontrollen, Einrichtung deutscher Administratoren, SIEM-Anbindung, Audit-Konfiguration und Sicherheitsprozesse.
Wochen 9–12: Migration: Pilotbetrieb mit Priorität-1-Daten, Test von Verschlüsselung und Schlüsselmanagement, Validierung von Geofencing, Sicherheitstests, Produktivmigration und Residenzvalidierung.
Wochen 13–16: Validierung: Compliance-Validierung, Prüfung der Schlüsselverwaltung, Geofencing-Tests, TIA-Updates, Vorbereitung des BfDI-Response-Pakets und Betriebsratsdokumentation.
Typischer Ressourcenbedarf: Projektmanager (50 % für vier Monate), Security Architect (Vollzeit zwei Monate), Infrastructure Engineer (Vollzeit ein Monat), IAM-Spezialist (Teilzeit), Datenschutzbeauftragter (Teilzeit).
Compliance-Dokumentation und Nachweiserbringung
Datenschutzbeauftragte sollten während der Umsetzung BfDI-Response-Pakete erstellen: Architekturdiagramme, Verschlüsselungsdokumentation, Zugriffskontrollmatrizen, Geofencing-Konfigurationen, Audit-Trails, aktualisierte TIAs, DSGVO-Artikel-30-Verzeichnisse und Betriebsratsdokumentation.
Compliance-Nachweis gegenüber dem BfDI
Der BfDI erwartet evidenzbasierte Compliance-Nachweise mit architektonischem Beleg.
Nachweisanforderungen für Datenschutzbehörden
Nachweis des Speicherorts: Genaue Adresse und Betreiber des Rechenzentrums, Netzwerkarchitektur, die zeigt, dass Daten Deutschland nie verlassen, Backup- und DR-Standorte innerhalb Deutschlands/EU, Protokolle ohne Transfers außerhalb der festgelegten Geografie.
Nachweis der Schlüsselverwaltung: HSM-Dokumentation zum Kundeneigentum, Nachweis der Schlüsselerzeugung durch den Kunden, Schlüsselzugriffsprotokolle, Nachweis, dass Anbieter ohne Autorisierung keinen Zugriff auf Schlüssel haben.
Nachweis der Zugriffskontrolle: Benutzer- und Authentifizierungskontrollen, Administratoren mit geografischen Einschränkungen, Audit-Logs aller Zugriffsversuche, Protokolle fehlgeschlagener Zugriffe aus nicht autorisierten Standorten.
Nachweis der Richtliniendurchsetzung: Geofencing-Konfigurationen, Protokolle zur Durchsetzung (inkl. blockierter Transfers), Beispiele verhinderter unautorisierter Bewegungen, Override-Prozesse mit Audit-Trail.
Der BfDI-Anfrageprozess
Der Erstkontakt erfolgt per offiziellem Schreiben oder E-Mail, meist mit vier Wochen Frist zur Antwort. Der BfDI fordert Beschreibungen der Datenverarbeitung, Datenkategorien, Speicher- und Verarbeitungsorte, Schutzmaßnahmen, Transfer Impact Assessments und Nachweise an.
Unternehmen sollten strukturiert antworten: In Woche eins Empfang bestätigen und vorhandene Dokumentation zusammenstellen. In Woche zwei und drei Architekturdiagramme, Compliance-Berichte, TIAs und schriftliche Antworten erstellen. In Woche vier rechtliche und betriebsrätliche Prüfung, Freigabe durch die Geschäftsleitung und Einreichung mit vollständigen Nachweisen.
Proaktive Zusammenarbeit mit der Aufsicht
Einige Unternehmen suchen proaktiv den Kontakt zum BfDI, um Compliance zu demonstrieren, informelle Hinweise zu erhalten, die Beziehung zur Aufsicht zu stärken und ihr Datenschutz-Engagement zu zeigen. Dies ist sinnvoll bei neuen Verarbeitungsvorhaben, Migration von US-Anbietern, Kundenanfragen oder in stark regulierten Branchen.
BfDI-Compliance durch architektonische Datensouveränität erreichen
Deutsche Unternehmen stehen vor klaren BfDI-Anforderungen zum Schutz personenbezogener Daten vor US-Zugriffen nach dem CLOUD Act. Vertragliche Maßnahmen reichen nicht aus – der BfDI verlangt nachweisbare technische Kontrollen, die den Zugriff ausländischer Behörden technisch unmöglich machen.
Wie Kiteworks BfDI-konforme Datensouveränität liefert
Kiteworks bietet architektonische Datensouveränität für Unternehmen, die garantieren müssen, dass personenbezogene Daten unter europäischer Zuständigkeit bleiben. Im Gegensatz zu US-basierten Cloud-Anbietern, die dem CLOUD Act unterliegen und deren vertragliche Zusagen keine gesetzliche Herausgabe verhindern, ermöglicht Kiteworks echte europäische Datensouveränität durch drei Kernfunktionen.
Single-Tenant-Bereitstellung in Europa: Ihre Kiteworks-Instanz läuft als dedizierte Infrastruktur in Ihrem gewählten deutschen Rechenzentrum – im eigenen Haus, bei einem europäischen Cloud-Anbieter oder in Kiteworks-gehosteten EU-Standorten. Vollständige Isolation ohne Multi-Tenant-Sharing schafft klare deutsche Zuständigkeit.
Kundengesteuerte Verschlüsselung: Sie generieren, speichern und verwalten Verschlüsselungsschlüssel im eigenen Hardware Security Module unter Ihrer Kontrolle. Kiteworks verschlüsselt Daten mit Schlüsseln, die wir niemals besitzen. Wir können Daten nicht entschlüsseln oder herausgeben – unabhängig von gesetzlichen Anforderungen. Technische Unmöglichkeit ersetzt vertragliche Zusagen.
Richtlinienbasierte Datenresidenz: Geofencing-Kontrollen verhindern technisch, dass Daten deutsche Grenzen verlassen. Umfassende Audit-Trails dokumentieren jeden Zugriffsversuch und jede Richtliniendurchsetzung – als Nachweis für den BfDI.
Mit Kiteworks demonstrieren deutsche Unternehmen Souveränität gegenüber Aufsichtsbehörden durch architektonische Nachweise – nicht durch vertragliche Zusicherungen. Datenschutzbehörden erhalten dokumentierte Belege für deutsche Zuständigkeit. Rechtsteams bestätigen, dass ausländische Anforderungen nicht erfüllt werden können, da Kiteworks keine Schlüssel besitzt. Während der BfDI die Durchsetzung verschärft und Souveränität zum Wettbewerbsfaktor wird, verschafft frühe Umsetzung sowohl regulatorische Compliance als auch Marktvorteile.
Erfahren Sie mehr über den Schutz sensibler Inhalte gemäß BfDI- und Datensouveränitätsanforderungen – vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Häufig gestellte Fragen
Ihr aktualisiertes Transfer Impact Assessment sollte dokumentieren, dass Sie nicht mehr auf Standardvertragsklauseln oder das EU-US Data Privacy Framework angewiesen sind, da kein US-Transfer stattfindet. Dokumentieren Sie konkret, dass Daten ausschließlich in Ihrem festgelegten deutschen Rechenzentrum gespeichert werden, Kunden die Verschlüsselungsschlüssel in deutschen Hardware Security Modules kontrollieren, Anbieter CLOUD-Act-Anfragen nicht erfüllen können, da sie keine Daten entschlüsseln können, und die technische Architektur US-Zugriffe unmöglich macht. Fügen Sie Architekturdiagramme, Nachweise zur Schlüsselverwaltung und Audit-Log-Belege bei. Ihr TIA sollte das Fazit enthalten, dass weder Angemessenheitsbeschluss noch Übermittlungsmechanismus erforderlich sind, da die Daten unter deutscher Zuständigkeit mit kundengesteuerten technischen Schutzmaßnahmen verbleiben.
Kundengesteuertes Schlüsselmanagement integriert sich über KMIP (Key Management Interoperability Protocol) oder herstellerspezifische APIs mit Enterprise Hardware Security Modules. Ihr HSM generiert und speichert Verschlüsselungsschlüssel, die nie Ihre Kontrolle verlassen. Ein Key Access Service fungiert als sichere Schnittstelle zwischen Systemen und Ihrem HSM, wobei eine Richtlinien-Engine jede Schlüsselanforderung anhand Ihrer Vorgaben prüft. Temporärer Zugriff wird nur für autorisierte Vorgänge gewährt, und Audit-Trails dokumentieren jede Schlüsselanforderung und deren Ergebnis. Unterstützte HSMs sind u. a. Thales, Utimaco, AWS CloudHSM (bei Bereitstellung in Ihrer VPC) und andere Enterprise-Key-Management-Systeme. Ihr Sicherheitsteam behält die vollständige Kontrolle über den Schlüssel-Lebenszyklus; ein Key Escrow außerhalb Ihres Unternehmens existiert nicht. Dieses Vorgehen gewährleistet AES-256-Verschlüsselung mit Kundensouveränität.
Architektonische Souveränität verändert Ihre DSGVO-Übermittlungsanalyse grundlegend. Wenn Daten Deutschland oder die EU nie verlassen und unter kundengesteuerter Verschlüsselung bleiben, liegt in der Regel keine „Übermittlung in ein Drittland“ nach Artikel 44 DSGVO vor – Angemessenheitsbeschlüsse, Standardvertragsklauseln oder Ausnahmen sind dann nicht erforderlich. Sie benötigen jedoch weiterhin einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO mit Ihrem Anbieter, müssen Sicherheitsmaßnahmen nach Artikel 32 umsetzen und Ihre rechtliche Analyse dokumentieren, warum keine Übermittlung stattfindet. Ihre DSGVO-Artikel-30-Verzeichnisse sollten für diese Verarbeitung „keine internationale Übermittlung“ dokumentieren. Die Rechtsabteilung sollte begründen, warum Datenspeicherung in Deutschland mit kundengesteuerten Schlüsseln keine Übermittlung darstellt, Sie auf architektonische Maßnahmen statt rechtliche Übermittlungsmechanismen setzen und dies mit Nachweisen untermauern. Dieses Vorgehen entspricht den Prinzipien von Datenschutz durch Technikgestaltung.
Der Zeitplan hängt von der gewählten Option ab. Anbieter-gehostete dedizierte Bereitstellung benötigt typischerweise 12–16 Wochen von Planung bis Produktivbetrieb – inklusive Anforderungsaufnahme, Instanzbereitstellung, HSM-Einrichtung, Sicherheitsintegration, Pilotbetrieb und Produktivsetzung. Deutsche Cloud-Bereitstellung erfordert 2–4 Wochen zusätzlich für Infrastrukturprovisionierung (insgesamt 14–20 Wochen). Kundeneigenes Rechenzentrum benötigt 4–12 Wochen mehr für Infrastrukturanschaffung und -aufbau (insgesamt 16–28 Wochen). Die Kosten umfassen Softwarelizenzen, deutsches Hosting (bei Anbieterbetrieb), HSM-Beschaffung (falls erforderlich), Implementierungsdienstleistungen und internen Ressourcenaufwand. Unternehmen sollten Projektmanagement, Security Architecture, Infrastructure Engineering, IAM-Integration und Datenschutzbeauftragten einplanen. Laufende Kosten entstehen für jährliche Lizenzen, Hosting oder Infrastrukturwartung, Sicherheitsmonitoring und Compliance-Aktivitäten.
Disaster Recovery mit kundengesteuerten Schlüsseln erfordert sorgfältige Planung, bietet aber hohe Ausfallsicherheit. Unternehmen setzen meist auf Dual-Rechenzentrumsarchitektur mit aktiver/passiver Konfiguration – Primärinstanz in einer deutschen Stadt, Disaster-Recovery-Instanz in einer anderen. Die Replikation der HSM-Schlüssel zwischen den Standorten stellt sicher, dass Schlüssel bei Ausfällen verfügbar bleiben. Alternativen sind Backup und Restore auf deutschen oder EU-Speicher mit Backup-Verschlüsselung durch kundengesteuerte Schlüssel oder cloudbasierte Disaster Recovery mit Primärbetrieb im eigenen Rechenzentrum und DR beim deutschen Cloud-Anbieter. Das Schlüsselmanagement in DR-Szenarien erfordert Schlüsselzugriff aus DR-Standorten über HSM-Cluster oder Schlüsselreplikation, regelmäßige Tests des DR-Zugriffs und dokumentierte DR-Prozesse. Recovery Time Objectives liegen typischerweise bei 4–24 Stunden, Recovery Point Objectives bei 15 Minuten bis 1 Stunde. Unternehmen sollten DR-Prozesse quartalsweise testen und die DR-Architektur in der BfDI-Compliance-Dokumentation nachweisen. So bleibt der sichere Betrieb gewährleistet.
Weitere Ressourcen
- Blog-Beitrag
Datensouveränität: Best Practice oder regulatorische Pflicht? - eBook
Datensouveränität und DSGVO - Blog-Beitrag
Vermeiden Sie diese Fallstricke bei der Datensouveränität - Blog-Beitrag
Best Practices für Datensouveränität - Blog-Beitrag
Datensouveränität und DSGVO [Datensicherheit verstehen]