Trust Center und Datensouveränität: EU-Hosting vs. EU-Souveränität
Ihr Trust Center enthält Pentest-Berichte, Sicherheitsarchitektur-Details und Compliance-Evidenz. „EU-gehostet“ bedeutet nicht, was Sie denken.
Die meisten US-Trust-Center-Plattformen bieten mittlerweile EU-Hosting an. Die Checkbox existiert. Das Rechenzentrum steht in Frankfurt oder Dublin. Ihr Beschaffungsteam sieht „EU-gehostet" und hakt den Punkt ab.
Aber Datenresidenz und Datensouveränität sind nicht dasselbe. Und für ein Trust Center spezifisch — eine Plattform, die Ihre sensibelste Sicherheitsdokumentation speichert und teilt — ist die Unterscheidung kommerziell und rechtlich folgenreich.
Die Unterscheidung
Datenresidenz bedeutet, dass Ihre Daten physisch in der EU gespeichert sind. Die Server stehen in europäischen Rechenzentren. Die Bits liegen auf europäischem Boden.
Datensouveränität bedeutet, dass Ihre Daten der europäischen Rechtsordnung unterliegen — und nur der europäischen Rechtsordnung. Keine ausländische Regierung kann den Anbieter zwingen, Ihre Daten nach ihrem eigenen nationalen Recht herauszugeben.
Sie können Residenz ohne Souveränität haben. Ein US-inkorporiertes Unternehmen mit EU-Rechenzentren bietet Residenz. Aber als US-juristische Person unterliegt es weiterhin US-Recht — einschließlich des CLOUD Act.
Sie können keine Souveränität ohne Residenz haben. Aber Residenz allein reicht nicht.
Warum das für Trust Center besonders wichtig ist
Jedes SaaS-Tool steht vor der Residenz-vs.-Souveränität-Frage. Aber bei den meisten Kategorien — Projektmanagement, CRM, Kommunikation — ist die Datensensitivität moderat. Das praktische Risiko einer CLOUD-Act-Anfrage nach Ihren Jira-Tickets ist gering.
Trust Center sind anders. Sie enthalten designbedingt die sensibelste Dokumentation über Ihre Sicherheitslage:
- Pentest-Berichte mit Details zu Schwachstellen und Behebungsstatus
- Sicherheitsarchitektur-Dokumentation, die Ihre Infrastruktur beschreibt
- Compliance-Evidenz einschließlich Auditberichte, Kontrollbewertungen und Zertifizierungsscopes
- Subprozessor-Listen mit Datenflüssen und Verarbeitungsstandorten
- Incident-Response-Dokumentation einschließlich Post-Incident-Analysen
- Interne Richtlinienzusammenfassungen, die die Struktur Ihres Sicherheitsprogramms offenlegen
Genau diese Art von Informationen macht die Souveränitätsfrage operativ relevant, nicht theoretisch. Wenn eine ausländische Regierung legal Zugang zu Ihren Trust-Center-Daten erzwingen kann, erhält sie eine strukturierte, aktuelle, umfassende Ansicht Ihrer Sicherheitslage — etwas, das normalerweise erheblichen Aufwand erfordern würde.
Das CLOUD-Act-Problem
Der Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) gibt US-Strafverfolgungsbehörden die Befugnis, von US-inkorporierten Unternehmen die Herausgabe von Daten zu verlangen, die sich in ihrem Besitz, ihrer Verwahrung oder Kontrolle befinden — unabhängig davon, wo die Daten physisch gespeichert sind.
Das erzeugt einen direkten Konflikt mit der DSGVO. Artikel 48 besagt, dass jede Übermittlung personenbezogener Daten an eine Drittlandsbehörde auf Grundlage einer ausländischen gerichtlichen oder behördlichen Anordnung nur anerkannt oder vollstreckbar ist, wenn sie auf einem internationalen Abkommen beruht. Der CLOUD Act beruht nicht auf einem solchen Abkommen.
Der Anbieter steckt zwischen zwei Rechtssystemen:
- US-Recht sagt: Daten herausgeben bei gültiger Rechtsanordnung.
- EU-Recht sagt: Daten nicht herausgeben, es sei denn, die Anfrage geht durch ordnungsgemäße Rechtshilfekanäle.
Für Ihr Trust Center erzeugt das ein praktisches Problem: Ihre sensibelste Sicherheitsdokumentation liegt auf einer Plattform, bei der eine ausländische Regierung einen legalen Mechanismus hat, Zugang zu verlangen — unabhängig davon, wo die Daten physisch liegen.
„Aber das ist noch nie bei einem Trust Center passiert"
Das stimmt wahrscheinlich. CLOUD-Act-Anfragen haben auf Kommunikation, Finanzdaten und Beweismittel gezielt — nicht auf Trust-Center-Plattformen. Aber der legale Mechanismus existiert, und die Compliance-Exposition ist real.
Wichtiger: Das ist bereits ein Beschaffungsfaktor. Europäische Enterprise-Käufer — besonders in regulierten Sektoren — berücksichtigen CLOUD-Act-Exposition in ihren Vendor-Risk-Assessments. Wenn Ihre Trust-Center-Plattform CLOUD-Act-Risiko erzeugt, fließt dieses Risiko zu jedem Kunden, der auf Ihr Trust Center für seine eigene Lieferketten-Compliance angewiesen ist.
Es geht nicht darum, ob eine Anfrage passieren wird. Es geht darum, ob das strukturelle Risiko existiert und ob die Compliance-Teams Ihrer Kunden es flaggen werden.
Was „EU-gehostet" bei US-Anbietern wirklich bedeutet
US-Trust-Center-Plattformen bieten EU-Hosting typischerweise in einer dieser Konfigurationen an:
EU-Rechenzentrumsregion
Der Anbieter betreibt (oder mietet) Server in EU-Rechenzentren. Ihre Daten im Ruhezustand liegen in der EU. Das ist echte Datenresidenz.
Aber die Unternehmenseinheit des Anbieters — die juristische Person, die die Infrastruktur kontrolliert, die Ingenieure beschäftigt und auf Rechtsanordnungen reagiert — sitzt in den USA. Der CLOUD Act folgt der Unternehmenseinheit, nicht den Daten.
EU-spezifische Instanz
Einige Anbieter bieten eine separate EU-Instanz — manchmal mit separater Domain, separatem Support-Team oder separaten operativen Grenzen. Das ist eine stärkere Positionierung als eine einfache Regionauswahl.
Aber wenn die EU-Instanz von einer Tochtergesellschaft einer US-Muttergesellschaft betrieben wird, kann der CLOUD Act die Mutter erreichen. Und wenn Support-, Engineering- oder Betriebsteams über US- und EU-Instanzen geteilt werden, ist die praktische Trennung möglicherweise weniger robust als das Marketing suggeriert.
Enterprise-Tier-EU-Hosting
Viele US-Anbieter bieten EU-Hosting nur auf Enterprise-Preisniveau. Das bedeutet:
- Start-ups und Mittelstand werden standardmäßig in den USA gehostet
- EU-Hosting ist ein Upsell, kein Standard
- Die Architektur des Unternehmens wurde nicht EU-first konzipiert; EU-Hosting wurde nachträglich hinzugefügt
Für den Trust-Center-Markt erzeugt das eine ironische Dynamik: Die Unternehmen, die am stärksten von NIS2 betroffen sind (die breite Masse der wichtigen Einrichtungen, viele davon Mittelstand), sind diejenigen, die am unwahrscheinlichsten Zugang zu EU-Hosting-Features erhalten.
Was echte Datensouveränität erfordert
Damit ein Trust Center echte Datensouveränität bietet, braucht es mehr als ein Rechenzentrum in der EU.
EU-Unternehmensstruktur
Der Anbieter muss in einem EU-Mitgliedstaat inkorporiert sein — nicht als Tochtergesellschaft einer US-Mutter, sondern als Einheit, deren ultimative rechtliche Verpflichtungen gegenüber europäischen Behörden bestehen. Das ist die einzige strukturelle Verteidigung gegen extraterritoriale Datenzugriffsgesetze.
EU-Infrastruktur als Standard
EU-Hosting sollte die Standardkonfiguration sein, kein Enterprise-Upsell. Wenn Sie für EU-Hosting verhandeln oder extra zahlen müssen, wurde die Plattform nicht für EU-Souveränität konzipiert — sie wurde für US-Betrieb konzipiert, mit EU als Sekundärmarkt.
Operationelle Souveränität
Support-Interaktionen, Log-Verarbeitung, Analytics und operative Daten sollten alle innerhalb der EU-Jurisdiktion verbleiben. Eine Plattform, die Ihren Trust-Center-Inhalt in der EU speichert, aber operative Daten in den USA verarbeitet, hat eine Souveränitätslücke.
Subprozessor-Ketten-Souveränität
Auch die Subprozessoren des Anbieters zählen. Wenn die Trust-Center-Plattform US-basierte Analytics-, Monitoring- oder Infrastrukturdienste nutzt, können diese Subprozessoren CLOUD-Act-Exposition erzeugen — selbst wenn der primäre Anbieter EU-basiert ist. Ein wirklich souveränes Trust Center arbeitet mit einer EU-Subprozessor-Kette.
Souveränität in der Praxis bewerten
Wenn Sie die Souveränitätsposition einer Trust-Center-Plattform bewerten, stellen Sie diese Fragen:
Unternehmensstruktur: Wo ist der Anbieter inkorporiert? Gibt es eine US-Mutter, Holdinggesellschaft oder Mehrheitsinvestor, der US-Rechtsexposition erzeugt?
Hosting-Standard: Ist EU-Hosting der Standard für alle Kunden, oder ein Enterprise-Tier-Feature? Was passiert, wenn Sie auf einem niedrigeren Tier starten — defaultet Ihre Datenverarbeitung auf US-Hosting?
Operative Daten: Wo werden Logs, Analytics, Support-Tickets und operative Metadaten verarbeitet? Ist das durch dieselbe EU-Hosting-Zusage abgedeckt wie der Trust-Center-Inhalt selbst?
Subprozessoren: Wer sind die Subprozessoren des Anbieters? Wo sind sie inkorporiert und wo verarbeiten sie Daten? Ist die Subprozessor-Liste öffentlich, oder müssen Sie eine NDA unterschreiben?
Incident Response: Wenn eine ausländische Regierung eine Datenzugriffsanfrage stellt — was ist der dokumentierte Prozess des Anbieters? Hat er einen Transparenzbericht veröffentlicht?
Vertragsbedingungen: Adressiert der AV-Vertrag explizit CLOUD-Act-Risiko? Verpflichtet sich der Anbieter, extraterritoriale Anfragen anzufechten?
Die Beschaffungsrealität
Das ist keine abstrakte Rechtsdebatte. Es ist ein Beschaffungsfaktor, der jedes Jahr folgenreicher wird.
Unter NIS2 müssen wesentliche und wichtige Einrichtungen Lieferkettensicherheit adressieren. Ihre Vendor-Risk-Assessments beinhalten zunehmend Datensouveränitätsbewertung — nicht nur „wo liegen die Daten", sondern „wer kann legal darauf zugreifen."
Unter DORA müssen Finanzunternehmen IKT-Drittparteien-Risiken bewerten, einschließlich des rechtlichen und regulatorischen Umfelds der Jurisdiktion des Anbieters. Ein Trust Center auf US-kontrollierter Infrastruktur erzeugt einen Risikofaktor, den Finanzunternehmen dokumentieren und rechtfertigen müssen.
Europäische DPOs, CISOs und Beschaffungsteams stellen diese Fragen. Sie nehmen Souveränitätskriterien in Ausschreibungen auf. Sie flaggen CLOUD-Act-Exposition in Vendor-Risk-Registern.
Wenn Ihr Trust Center diese Exposition für Ihre Kunden erzeugt, wird es deren Compliance-Problem. Und Compliance-Probleme beschleunigen keine Deals — sie blockieren sie.
Quellen
- US CLOUD Act (H.R. 4943) — Extraterritoriale Datenzugriffsbestimmungen.
- DSGVO Artikel 48 — Nach dem Unionsrecht nicht zulässige Übermittlungen.
- DSGVO Artikel 28 — Auftragsverarbeiterpflichten und Subprozessor-Transparenz.
- Richtlinie (EU) 2022/2555 (NIS2) — Lieferkettensicherheitspflichten.
- Verordnung (EU) 2022/2554 (DORA) — IKT-Drittparteien-Risikomanagement einschließlich Jurisdiktionsbewertung.
- Schrems II (Rechtssache C-311/18) — EuGH-Urteil zur Ungültigerklärung des Privacy Shield.