Cloud Act, Schrems II und dein ISMS: Was du über Datenzugriff durch US-Behörden wissen musst

Der Cloud Act ist kein theoretisches Risiko

Im März 2018 hat der US-Kongress den Clarifying Lawful Overseas Use of Data Act verabschiedet, kurz Cloud Act. Das Gesetz regelt, was vorher rechtlich umstritten war: US-Behörden dürfen US-Unternehmen per Gerichtsbeschluss oder Subpoena zur Herausgabe von Daten verpflichten, die sich in ihrem Besitz, unter ihrer Kontrolle oder in ihrem Gewahrsam befinden. Wo die Daten physisch gespeichert sind, spielt keine Rolle.

Das bedeutet konkret: Wenn du Microsoft 365, Google Workspace, AWS, Salesforce oder einen anderen US-Dienst nutzt, können US-Behörden auf deine Daten zugreifen, selbst wenn die Server in Frankfurt, Amsterdam oder Dublin stehen. Der Serverstandort Deutschland, den viele Anbieter prominent bewerben, ändert an der Rechtslage nichts. Es zählt nicht, wo die Daten liegen. Es zählt, wer die Infrastruktur kontrolliert.

Was der Cloud Act genau erlaubt

Der Cloud Act unterscheidet zwei Wege:

Weg 1: Direkter Zugriff über US-Recht. US-Strafverfolgungsbehörden (FBI, DOJ, SEC und andere) können über einen Warrant, eine Subpoena oder einen Court Order die Herausgabe von Daten verlangen. Der US-Anbieter muss die Daten liefern, auch wenn sie auf einem Server in der EU gespeichert sind.

Weg 2: Executive Agreements. Der Cloud Act ermöglicht bilaterale Abkommen zwischen den USA und anderen Staaten, die einen direkten Datenzugriff ohne den Umweg über Rechtshilfeersuchen erlauben. Mit dem Vereinigten Königreich existiert ein solches Abkommen seit 2022. Mit der EU gibt es bislang kein Executive Agreement, die Verhandlungen laufen.

Was der Cloud Act nicht ist: Er ist kein Freifahrtschein für anlasslose Massenüberwachung. Jeder Zugriff braucht eine rechtliche Grundlage, typischerweise im Rahmen einer strafrechtlichen Ermittlung. Das Problem ist aber: Die betroffenen EU-Unternehmen erfahren in der Regel nichts davon. US-Anbieter sind unter bestimmten Umständen sogar verpflichtet, den Zugriff geheim zu halten (Gag Order). Du weißt also möglicherweise gar nicht, dass eine US-Behörde deine Daten eingesehen hat.

Warum „Rechenzentrum in Deutschland" nicht hilft

Viele US-Anbieter werben mit EU-Rechenzentren als Lösung für Datenschutzbedenken. Das klingt gut, löst das Problem aber nicht. Der Cloud Act knüpft an die Kontrolle über die Daten an, nicht an den physischen Standort. Solange ein US-Unternehmen die Schlüssel hat, die Infrastruktur betreibt oder die Daten verwaltet, greift der Cloud Act.

Einige Anbieter versuchen, dieses Problem durch „Datentreuhand"-Modelle zu umgehen: Ein europäischer Partner verwaltet die Schlüssel, der US-Anbieter hat technisch keinen Zugriff. In der Theorie elegante Modelle, in der Praxis selten vollständig umgesetzt und juristisch ungetestet.

Schrems II: Was der EuGH entschieden hat

Am 16. Juli 2020 hat der Europäische Gerichtshof in der Rechtssache C-311/18 (Schrems II) den EU-US Privacy Shield für ungültig erklärt. Das Urteil war kein Überraschungscoup: Max Schrems hatte bereits 2015 den Vorgänger Safe Harbor zu Fall gebracht (Schrems I).

Die Kernaussagen des Schrems-II-Urteils:

1. Das US-Überwachungsrecht bietet keinen gleichwertigen Schutz. Der EuGH stellte fest, dass die US-Überwachungsprogramme (insbesondere Section 702 FISA und Executive Order 12333) nicht auf das zwingend erforderliche Maß beschränkt sind und EU-Bürgern keinen wirksamen Rechtsschutz bieten.

2. Der Privacy Shield ist ungültig. Da der Privacy Shield das Defizit im US-Recht nicht kompensieren konnte, hat der EuGH ihn für nichtig erklärt. Sofort, ohne Übergangsfrist.

3. Standardvertragsklauseln bleiben gültig, aber... Der EuGH hat Standardvertragsklauseln (SCC) als Transfermechanismus nicht grundsätzlich beanstandet. Aber er verlangt, dass der Datenexporteur für jeden einzelnen Transfer prüft, ob das Recht des Drittstaats den Schutz durch die SCC untergräbt. Ist das der Fall, muss der Exporteur ergänzende Maßnahmen ergreifen oder den Transfer einstellen.

4. Transfer Impact Assessment ist Pflicht. Aus dem Urteil folgt die Pflicht, für jeden SCC-basierten Transfer ein Transfer Impact Assessment (TIA) durchzuführen: eine dokumentierte Bewertung der Rechtslage im Zielland.

Das EU-US Data Privacy Framework: Schrems III am Horizont

Seit Juli 2023 gibt es mit dem EU-US Data Privacy Framework (DPF) einen neuen Angemessenheitsbeschluss für die USA. US-Unternehmen, die sich beim Department of Commerce zertifizieren lassen, gelten als Empfänger mit angemessenem Datenschutzniveau.

Die Grundlage des DPF ist die Executive Order 14086 von Präsident Biden, die die US-Überwachungsbefugnisse einschränkt und einen neuen Rechtsbehelfsmechanismus (Data Protection Review Court) für EU-Bürger schafft.

Ob das reicht, ist umstritten. Max Schrems und seine Organisation noyb haben angekündigt, auch diesen Beschluss vor dem EuGH anzufechten. Die Kritikpunkte:

• Die Executive Order ist kein Gesetz, sondern ein Erlass des Präsidenten. Ein zukünftiger Präsident kann sie jederzeit widerrufen oder ändern.
• Der Data Protection Review Court ist kein unabhängiges Gericht im europäischen Sinne, sondern ein Gremium innerhalb der Exekutive.
• Section 702 FISA, die zentrale Rechtsgrundlage für die Massenüberwachung, wurde Ende 2023 verlängert, nicht reformiert.

Für deine Compliance-Strategie bedeutet das: Das DPF ist ein Fortschritt gegenüber dem Nichts, das nach Schrems II herrschte. Aber es auf Dauer als einzige Grundlage für Datentransfers in die USA zu betrachten, ist ein Glücksspiel.

Warum gerade ISMS-Daten besonders sensibel sind

Nicht alle Daten, die du in der Cloud speicherst, sind gleich sensibel. Kundenadressen in einem CRM sind eine Sache. ISMS-Daten sind eine ganz andere.

Dein ISMS enthält:

• Risikoanalysen mit konkreten Eintrittswahrscheinlichkeiten und Schadenspotenzialen für dein Unternehmen
• Schwachstellenberichte die zeigen, wo deine IT-Sicherheit Lücken hat
• Audit-Feststellungen mit dokumentierten Abweichungen und offenen Maßnahmen
• Netzwerkpläne und Sicherheitsarchitekturen die den Aufbau deiner IT-Infrastruktur offenlegen
• Maßnahmen-Status der zeigt, welche Controls umgesetzt sind und welche nicht
• Vorfallsberichte mit Details zu vergangenen Sicherheitsvorfällen
• Lieferantenbewertungen mit Sicherheitsfragebögen und Ratings
• Management-Review-Protokolle die strategische Sicherheitsentscheidungen dokumentieren

Diese Daten sind in ihrer Gesamtheit eine Blaupause deiner gesamten IT-Sicherheit. Wer sie liest, kennt deine Schwächen, deine Verteidigungsstrategie und deine Prioritäten. In den Händen eines Angreifers sind sie ein Angriffshandbuch. In den Händen eines Konkurrenten sind sie Wettbewerbsintelligenz. In den Händen einer ausländischen Behörde sind sie ein detaillierter Einblick in dein Unternehmen, den du nie freiwillig geben würdest.

Wenn ein US-Staatsanwalt per Cloud Act auf die Daten deines ISMS-Cloud-Anbieters zugreift, bekommt er nicht ein paar E-Mail-Adressen. Er bekommt die vollständige Dokumentation deiner Sicherheitslage, inklusive aller bekannten Schwachstellen. Das ist ein qualitativ anderes Risiko als bei den meisten anderen Cloud-Diensten.

Standardvertragsklauseln als Lösung? Nur bedingt

Nach Schrems II greifen viele Unternehmen zu Standardvertragsklauseln (SCC) als Transfermechanismus. Die SCC sind ein Vertrag zwischen dir und dem US-Anbieter, in dem sich der Anbieter verpflichtet, ein europäisches Datenschutzniveau einzuhalten. Das Problem: Der Cloud Act verpflichtet den US-Anbieter zur Datenherausgabe, unabhängig davon, was in den SCC steht.

Es gibt also einen direkten Konflikt: Die SCC sagen „schütze die Daten nach EU-Standard", der Cloud Act sagt „gib die Daten an US-Behörden heraus". Wer gewinnt diesen Konflikt? In der Praxis der US-Anbieter. Kein US-Unternehmen wird eine Contempt-of-Court-Verurteilung riskieren, um einen europäischen Kunden zu schützen.

Was ergänzende Maßnahmen leisten können (und was nicht)

Das Europäische Datenschutzausschuss (EDSA) empfiehlt ergänzende technische Maßnahmen, um den Schutz der SCC zu stärken:

Die Krux bei ISMS-Software: Damit die Anwendung funktioniert, muss sie die Daten verarbeiten können. Eine verschlüsselte Risikobewertung, die der Server nicht lesen kann, kann er auch nicht anzeigen, filtern oder durchsuchen. Ende-zu-Ende-Verschlüsselung ist bei E-Mail oder Dateispeicher möglich, bei einer SaaS-Anwendung mit Suchfunktion, Dashboards und Reports praktisch nicht.

Praxisbeispiel: Der Auditor fragt, wo deine ISMS-Daten liegen

Stell dir folgende Situation vor: Dein Unternehmen wird nach ISO 27001 zertifiziert. Der externe Auditor prüft Control A.5.23 (Cloud-Dienste) und stellt fest, dass du eine US-amerikanische ISMS-Software als SaaS nutzt.

Auditor: „Wo werden Ihre ISMS-Daten gespeichert?"

Du: „In der Cloud. Rechenzentrum in Frankfurt."

Auditor: „Wer ist der Anbieter?"

Du: „Ein US-Unternehmen mit EU-Rechenzentrum."

Auditor: „Wie bewerten Sie das Risiko eines Datenzugriffs durch US-Behörden auf Ihre Risikobewertungen und Schwachstellenberichte?"

Du: „..."

Auditor: „Haben Sie ein Transfer Impact Assessment durchgeführt? Welche ergänzenden Maßnahmen haben Sie implementiert? Wie stellen Sie sicher, dass der Cloud Act die Vertraulichkeit Ihrer ISMS-Daten nicht kompromittiert?"

Diese Fragen sind keine Schikane. Sie sind die logische Konsequenz aus Schrems II und dem Cloud Act. Und sie treffen auf ein Kernproblem: ISMS-Daten gehören zu den sensibelsten Informationen deines Unternehmens, und du speicherst sie bei einem Anbieter, der per Gesetz gezwungen werden kann, sie an eine ausländische Behörde herauszugeben.

Ein sauberes Transfer Impact Assessment für diese Konstellation zu schreiben, das zum Ergebnis kommt „alles okay", ist juristisch ambitioniert. Du müsstest argumentieren, dass die ergänzenden Maßnahmen den Cloud-Act-Zugriff technisch verhindern. Bei einer SaaS-Anwendung, die deine Daten im Klartext verarbeitet, ist dieses Argument schwer zu halten.

Die drei Optionen für dein ISMS

Wenn du die Datentransfer-Problematik ernst nimmst, hast du drei Optionen:

Option 1: EU-Anbieter ohne US-Verbindung

Du wählst einen ISMS-Anbieter, der seinen Sitz in der EU hat, keine US-Muttergesellschaft hat und keine Daten in die USA transferiert. Damit fällt der Cloud Act komplett weg. Kein Drittstaatentransfer, kein TIA nötig, keine Schrems-II-Problematik.

Vorteil: Sauber aus Compliance-Sicht, kein zusätzlicher Dokumentationsaufwand. Nachteil: Die Auswahl an rein europäischen ISMS-SaaS-Anbietern ist überschaubar. Und du tauscht die Cloud-Act-Problematik gegen eine andere Abhängigkeit: Du vertraust einem Drittanbieter deine sensibelsten Daten an, mit allen Risiken die das mit sich bringt, von Insolvenz über Datenlecks bis zu Preiserhöhungen.

Option 2: US-Anbieter mit Kompensationsmaßnahmen

Du bleibst bei deinem US-Anbieter, dokumentierst das Risiko im Rahmen deiner Risikobewertung und implementierst ergänzende Maßnahmen: SCC mit TIA, soweit möglich technische Verschlüsselung, vertragliche Zusagen.

Vorteil: Kein Anbieterwechsel nötig. Nachteil: Wie oben dargestellt ist die technische Kompensation bei SaaS-ISMS-Tools begrenzt. Du dokumentierst ein Restrisiko, das du nicht eliminieren kannst. Manche Aufsichtsbehörden und Auditoren akzeptieren das, andere nicht.

Option 3: Self-Hosting

Du hostest deine ISMS-Software auf eigener Infrastruktur oder bei einem EU-Hosting-Provider deiner Wahl. Deine Daten verlassen nie die EU, kein US-Unternehmen hat Zugriff, kein Drittstaatentransfer findet statt.

Vorteil: Maximale Kontrolle, keine Datentransfer-Problematik, kein TIA nötig, keine Abhängigkeit vom DPF. Der Auditor bekommt eine klare Antwort: „Unsere ISMS-Daten liegen auf unserem eigenen Server in Deutschland. Kein Drittanbieter hat Zugriff." Nachteil: Du brauchst Infrastruktur und jemanden der sie betreibt. Bei einem Unternehmen mit 50 bis 500 Mitarbeitern ist das aber in der Regel vorhanden, ein Standard-Linux-Server mit PHP reicht.

Warum Self-Hosting die sauberste Lösung ist

Self-Hosting ist nicht für jede Anwendung die richtige Wahl. Für ISMS-Software ist es die beste.

Grund 1: Du eliminierst das Problem statt es zu kompensieren. Kein Transfer Impact Assessment, keine Standardvertragsklauseln, keine Diskussion über ergänzende Maßnahmen. Wenn die Daten dein Rechenzentrum nie verlassen, gibt es kein Datentransfer-Problem. Diese Klarheit spart dir Hunderte Seiten Dokumentation und stundenlange Diskussionen mit Auditoren und Datenschutzbeauftragten.

Grund 2: Du bist unabhängig von politischen Entscheidungen. Das DPF kann morgen kippen. Ein neues Executive Agreement kann kommen oder nicht. Deine Self-Hosted-Lösung ist davon nicht betroffen. Du musst keine Strategie umbauen, wenn sich die politische Lage zwischen der EU und den USA ändert.

Grund 3: ISMS-Daten sind strukturell für Self-Hosting geeignet. Ein ISMS ist kein Echtzeit-Kollaborationstool mit tausenden gleichzeitigen Nutzern. Es wird von einem kleinen Team gepflegt (ISB, IT-Leitung, ein paar Risikoeigner), braucht keine horizontale Skalierung und keine 99,999 % Verfügbarkeit. Ein gut konfigurierter Server reicht.

Grund 4: Total Cost of Ownership. Die meisten ISMS-SaaS-Lösungen kosten zwischen 3.000 und 15.000 Euro pro Jahr, je nach Nutzeranzahl und Funktionsumfang. ISMS Lite kostet 500 Euro pro Jahr als Self-Hosted-Lizenz, inklusive unbegrenzter Nutzer, läuft auf jedem PHP-8.3-Server und speichert alles als Flat Files, ohne Datenbank. Die Infrastrukturkosten für einen kleinen Linux-Server liegen bei 10 bis 30 Euro pro Monat.

Grund 5: Git-Versionierung statt Vendor Lock-in. Da ISMS Lite alle Daten als Markdown und YAML im Dateisystem speichert, kannst du dein gesamtes ISMS in Git versionieren. Jede Änderung ist nachvollziehbar, du hast ein vollständiges Audit-Log, und wenn du den Anbieter wechseln willst, nimmst du einfach deine Dateien mit. Kein Datenexport, kein Migrationsprojekt, kein Vendor Lock-in.

Checkliste: ISMS-Daten und Datensouveränität

Prüfe diese Punkte für deine aktuelle ISMS-Lösung:

• Anbieter-Sitz: Wo hat der Anbieter seinen Firmensitz? Hat er eine US-Muttergesellschaft?
• Unternehmensstruktur: Unterliegt der Anbieter oder eine seiner Konzerngesellschaften dem US Cloud Act?
• Serverstandort: Wo werden die Daten gespeichert? Werden Backups in die USA repliziert?
• Verschlüsselung: Wer hält die Schlüssel? Hat der Anbieter technisch Zugriff auf die unverschlüsselten Daten?
• Transfermechanismus: Auf welcher Grundlage findet der Datentransfer statt (DPF, SCC, keiner)?
• TIA vorhanden: Hast du ein Transfer Impact Assessment durchgeführt und dokumentiert?
• Ergänzende Maßnahmen: Welche technischen, organisatorischen und vertraglichen Maßnahmen hast du implementiert?
• AVV geprüft: Enthält der Auftragsverarbeitungsvertrag Regelungen zum Umgang mit behördlichen Datenanfragen?
• Exit-Strategie: Kannst du den Anbieter wechseln ohne deine ISMS-Daten zu verlieren?
• Auditor-ready: Kannst du dem Auditor in zwei Sätzen erklären, wo deine ISMS-Daten liegen und warum das sicher ist?

Häufige Fehler

Fehler 1: „Rechenzentrum in Frankfurt" als ausreichende Antwort. Der Serverstandort allein sagt nichts über die rechtliche Zugriffslage. Entscheidend ist, wer die Infrastruktur kontrolliert und welchem Recht der Anbieter unterliegt.

Fehler 2: Das DPF als dauerhafte Lösung behandeln. Das EU-US Data Privacy Framework ist ein politisches Abkommen, kein Naturgesetz. Es kann gekippt werden, wie seine beiden Vorgänger. Wer seine gesamte Compliance-Strategie darauf aufbaut, riskiert, bei einem Schrems-III-Urteil ohne Transfergrundlage dazustehen.

Fehler 3: ISMS-Daten wie andere Cloud-Daten behandeln. Nicht alle Daten haben dasselbe Schutzbedarf-Niveau. Ein CRM in der Cloud ist eine vertretbare Entscheidung. Deine vollständige Schutzbedarfsfeststellung mit allen identifizierten Schwachstellen bei einem US-Anbieter zu speichern, ist eine andere Risikoklasse.

Fehler 4: Kein TIA durchführen. Viele Unternehmen überspringen das Transfer Impact Assessment, weil es aufwändig ist. Das ist kein vergessener Formalismus. Es ist eine dokumentierte Pflichtverletzung, die bei einer Prüfung durch die Aufsichtsbehörde auffällt.

Fehler 5: Self-Hosting als zu aufwändig abtun. Ja, Self-Hosting erfordert Infrastruktur. Aber die Alternative ist nicht „kein Aufwand", sondern „Aufwand an anderer Stelle": TIA erstellen, SCC verwalten, ergänzende Maßnahmen implementieren, regelmäßig überprüfen, bei jedem Audit rechtfertigen. Verglichen damit ist ein Linux-Server mit ISMS Lite aufsetzen die pragmatischere Variante.

Was du jetzt konkret tun solltest

Schritt 1: Prüfe, welchem Recht dein aktueller ISMS-Anbieter unterliegt. US-Muttergesellschaft? Cloud Act Scope? Kläre das, bevor der Auditor fragt.

Schritt 2: Wenn dein Anbieter dem Cloud Act unterliegt, führe ein Transfer Impact Assessment durch. Dokumentiere die Rechtslage, die Risiken und die ergänzenden Maßnahmen. Nimm das Ergebnis in deine Risikobewertung auf.

Schritt 3: Bewerte die drei Optionen (EU-Anbieter, US-Anbieter mit Kompensation, Self-Hosting) anhand deiner konkreten Situation. Berücksichtige dabei nicht nur den Preis, sondern auch den Dokumentationsaufwand, die langfristige Planungssicherheit und die Frage, wie du dem Auditor gegenüber argumentierst.

Schritt 4: Wenn du dich für Self-Hosting entscheidest, rechne die Total Cost of Ownership durch. Ein ISMS Lite auf einem eigenen Server kostet dich ab 500 Euro pro Jahr oder als Einmalkauf für 2.500 Euro plus 120 bis 360 Euro Hosting pro Jahr. Vergleiche das mit deinem aktuellen SaaS-Preis plus dem jährlichen Aufwand für TIA-Aktualisierung, SCC-Verwaltung und Compliance-Dokumentation.

Datensouveränität bei ISMS-Daten ist kein abstraktes Compliance-Thema. Es ist eine praktische Entscheidung darüber, wer Zugriff auf die sensibelsten Informationen deines Unternehmens haben darf. Triff diese Entscheidung bewusst, nicht durch Unterlassung.

Weiterführende Artikel

• Internationaler Datentransfer: Standardvertragsklauseln und Angemessenheitsbeschlüsse
• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• ISO 27001 A.5.23: Cloud-Dienste sicher nutzen
• Cloud-Sicherheit für KMU: Die häufigsten Fehlkonfigurationen und wie du sie vermeidest
• Auftragsverarbeitung: AVV prüfen und Dienstleister bewerten