NIS2 trifft CLOUD Act: Wer haftet für die Drittstaaten-Lücke
8 Min. Lesezeit
NIS2 zwingt deutsche Betreiber zu einer Lieferketten-Prüfung, die der US CLOUD Act zur gleichen Zeit unterläuft. Wer einen US-Hyperscaler mit deutschen Daten betreibt, hat zwei Behörden, die widersprüchlich Zugriff verlangen. Die Haftung dafür sitzt 2026 nicht mehr im Einkauf, sondern beim Geschäftsführer.
Das Wichtigste in Kürze
- Geschäftsleitung haftet persönlich. NIS2 macht die Lieferketten-Sicherheit zu einer dokumentationspflichtigen Geschäftsführerentscheidung. Delegation an den CISO entlastet nicht.
- US CLOUD Act bricht Schrems II nicht heimlich. Wer Standardvertragsklauseln mit AWS, Azure oder GCP unterschreibt, hat die Konflikt-Klauseln in den eigenen Vertragsunterlagen stehen. Sie sind dokumentiert, sie sind ignoriert.
- Drittstaaten-Risiko ist nicht nur USA. Cloud-Dienste mit Sub-Operatoren in Indien, Israel oder den Philippinen sind in der gleichen Lage. NIS2 verlangt eine Risiko-Sicht, die Sub-Lieferanten mit einbezieht.
Verwandt:NIS2-Compliance im Mittelstand: machbare Schritte / DORA und NIS2: Warum Banken-Audits jetzt kollidieren
Was die NIS2-Lieferkettenpflicht wirklich verlangt
Was ist Supply Chain Security nach NIS2? Supply Chain Security im Sinne der NIS2-Richtlinie verpflichtet betroffene Einrichtungen, die Sicherheit ihrer Lieferanten und Dienstleister systematisch zu bewerten, zu dokumentieren und vertraglich zu sichern. Das umfasst Cloud-Dienstleister, Managed-Service-Provider und Software-Lieferanten. Die Verantwortung liegt bei der Geschäftsleitung und ist nicht delegierbar.
Artikel 21 Absatz 2 lit. d der NIS2-Richtlinie und seine Umsetzung im NIS2UmsuCG verlangen explizit, dass die Sicherheit der Lieferkette in das Risikomanagement aufgenommen wird. Das Gesetz nennt vier Punkte beim Namen: Schwachstellen direkter Anbieter, Sicherheitspraktiken der Lieferanten, Reaktion auf Sicherheitsvorfälle in der Kette, und die Verlässlichkeit dieser Lieferantenbeziehung über die Vertragslaufzeit.
Wer das in der Praxis abbildet, kommt um eine Frage nicht herum: Welche Cloud-Anbieter sind Bestandteil der eigenen Lieferkette, und welche Sub-Lieferanten haben sie wiederum eingebunden. Im Datenraum eines Audits ist die Antwort „wir nutzen Azure“ zu wenig. Verlangt wird die Sicht zwei Schichten tiefer.
Wo der US CLOUD Act den europäischen Schutz aushebelt
Der US Clarifying Lawful Overseas Use of Data Act von 2018 erlaubt US-Strafverfolgungsbehörden, von US-Anbietern Daten zu verlangen, unabhängig davon, wo diese Daten gespeichert sind. AWS, Microsoft und Google sind US-Anbieter. Eine deutsche Region ändert daran nichts. Der Anbieter ist verpflichtet zu kooperieren, der deutsche Auftraggeber wird in vielen Fällen nicht informiert.
Das ist kein Geheimnis. Es steht in den Datenverarbeitungsverträgen der Hyperscaler, in der Regel unter „Government Access Requests“ oder „Law Enforcement Demands“. Wer es nicht gelesen hat, hat seine Lieferanten-Sorgfalt nicht erfüllt. Wer es gelesen und übergangen hat, hat ein anderes Problem: Er weiß, dass seine Schrems-II-konforme Standardvertragsklausel im Konfliktfall nachgibt, und hat trotzdem unterschrieben.
Der EuGH hat in der Schrems-II-Entscheidung 2020 festgehalten, dass Standardvertragsklauseln nur dann ausreichen, wenn das Schutzniveau im Drittland tatsächlich gleichwertig ist. Der CLOUD Act macht es nicht gleichwertig. Das EU-US Data Privacy Framework von 2023 federt das auf der Anwendungsebene ab, aber es löst den strukturellen Konflikt nicht. Datenschutzbehörden und Aufsichtsbehörden bewerten das unterschiedlich, was den Compliance-Pfad nicht entspannt.
Wer einen US-Hyperscaler nutzt, akzeptiert vertraglich eine Behörden-Zugriffsklausel, die im Konflikt mit europäischem Datenschutz steht. Das ist eine bewusste Risikoübernahme, keine technische Restschwäche.
Drittstaaten sind nicht nur USA
Die öffentliche Diskussion fokussiert auf US-Anbieter. Die Lieferketten-Realität ist breiter. Ein managed SOC eines deutschen MSSP arbeitet häufig mit Analysten in Indien, ein Cloud-Backup-Anbieter lagert Storage in Polen und Sicherungskopien in Israel, ein SaaS-Anbieter für HR-Software hat Entwicklungs-Hubs in Vietnam. Jeder dieser Standorte hat seine eigene Behörden-Zugriffslogik und seine eigene Auslegung von Datenexport.
| Region | Behörden-Zugriff (Kurz) | NIS2-Bewertung im Datenraum |
|---|---|---|
| USA | CLOUD Act, FISA 702 | Hoch, mit Restkonflikt zu Schrems II |
| UK | Investigatory Powers Act, EU-Angemessenheitsbeschluss | Mittel, Angemessenheit unter Beobachtung |
| Indien | IT Act Section 69, DPDP Act 2023 | Hoch, kein Angemessenheitsbeschluss |
| Israel | Privacy Protection Law, EU-Angemessenheitsbeschluss | Mittel, Sektor-spezifische Restrisiken |
| Philippinen | Data Privacy Act, Behörden-Zugriff über AML-Rahmen | Hoch, häufig Sub-Lieferant ohne Vertrag |
Quelle: Eigene Auswertung NIS2UmsuCG plus EU-Kommissions-Angemessenheitsbeschlüsse, Stand Mai 2026.
Ein Risikoregister, das diese Sicht nicht abbildet, ist im NIS2-Audit angreifbar. Die Aufsichtsbehörde fragt nicht nach Lieblings-Anbietern, sie fragt nach der Bewertungs-Methodik. Wer fünf Sub-Lieferanten in drei Drittstaaten hat und keine schriftliche Bewertung des Behörden-Zugriffsrisikos, hat die NIS2-Sorgfalt formal nicht eingehalten.
Wo die Haftungsfallen wirklich greifen
Es gibt drei Stellen, an denen die persönliche Haftung der Geschäftsleitung in der Praxis sichtbar wird. Erstens beim Sicherheitsvorfall mit Datenabfluss: Wenn die Untersuchung zeigt, dass die Lieferkette nicht bewertet war, ist das eine Verletzung der Sorgfaltspflicht. Zweitens beim Audit ohne Vorfall: Eine Aufsichtsbehörde kann auch ohne Schadensfall die fehlende Dokumentation sanktionieren. Drittens im Zivilverfahren: Wenn Kundendaten durch eine Drittstaaten-Übermittlung kompromittiert werden, kommen Schadensersatzklagen, deren Streitwert direkt am Datenumfang hängt.
Die Hyperscaler werden in diesen Verfahren nicht die Hauptbeklagten sein. Sie haben in ihren AGB sauber definiert, was sie liefern und was nicht. Die Hauptbeklagten sind die Auftraggeber, die unterschrieben haben, ohne die Implikationen vertraglich abzufangen. Das ist die Konstruktion, die NIS2 jetzt ausdrücklich adressiert.
Vier konkrete Schritte, die jetzt im Risikoregister stehen müssen
Schritt eins: Lieferanten-Inventar mit Drittstaatenbezug. Welcher Anbieter, welcher Vertrag, welcher tatsächliche Verarbeitungsort, welche Sub-Auftragsverarbeiter. Wer das auf eine Excel-Tabelle reduzieren kann, muss es einer Aufsichtsbehörde vorlegen können.
Schritt zwei: Schriftliche Risikobewertung pro Anbieter. Nicht „wir vertrauen AWS“, sondern: Welche Behörden-Zugriffsrechte existieren, welche Datenkategorien sind betroffen, welche Maßnahmen mindern das Risiko. Verschlüsselung mit Kundenschlüsseln ist eine Maßnahme, geografische Beschränkung eine andere. Beide gehören dokumentiert.
Schritt drei: Vertragliche Nachschärfung. Standardvertragsklauseln plus zusätzliche Schutzmaßnahmen sind Pflicht, keine Empfehlung. Das bedeutet konkret: Verschlüsselungs-Kontrolle, Audit-Rechte, Meldepflichten bei Behörden-Zugriffen, Exit-Klauseln mit Daten-Übergabe-Pfad.
Schritt vier: Geschäftsführungs-Beschluss. Die Auswahl des Anbieters und die Bewertung des Restrisikos muss in einem Beschluss der Geschäftsleitung dokumentiert sein. Nicht in einer Cloud-Strategie-Folie. In einem Protokoll, das die Aufsichtsbehörde nachvollziehen kann.
Wann ein Wechsel zu europäischen Anbietern realistisch ist
Die ehrliche Antwort ist: nicht für alle Workloads, nicht sofort. Die European Open Cloud Initiative und souveräne Angebote wie OVHcloud, Open Telekom Cloud oder Stackit decken eine wachsende Bandbreite ab, sie schließen aber nicht jede technische Funktion eines Hyperscalers ab. Wer Bedrock-äquivalente Inferenz, Aurora Serverless oder spezifische Microsoft-Identity-Funktionen benötigt, hat heute keinen 1:1-Ersatz.
Das ist kein Grund, den Status quo zu belassen. Es ist ein Grund für eine differenzierte Architektur. Sensible Datenkategorien wandern auf europäische Anbieter oder bleiben on-premises. Generische Workloads bleiben auf dem Hyperscaler, mit dokumentierten Schutzmaßnahmen. Die Plattform-Architektur 2026 ist polyglott, nicht entweder-oder.
Häufige Fragen
Ist die EU-US Data Privacy Framework eine ausreichende Grundlage für US-Cloud-Nutzung?
Das Framework von 2023 hat den Angemessenheitsbeschluss neu hergestellt und ist die aktuelle Rechtsgrundlage. Mehrere Datenschutzbehörden und juristische Gutachten erwarten allerdings ein neues EuGH-Verfahren, das die Tragfähigkeit erneut prüft. Wer auf das Framework allein setzt, akzeptiert das Risiko einer Schrems-III-Entscheidung. Belastbar ist das Framework plus zusätzliche technische Maßnahmen, insbesondere Verschlüsselung mit Kundenschlüsseln.
Reicht eine Verschlüsselung auf dem Hyperscaler als Schutz gegen den CLOUD Act?
Eine Server-seitige Verschlüsselung des Anbieters reicht nicht, weil der Anbieter die Schlüssel verwaltet und im Behörden-Verfahren zur Herausgabe verpflichtet werden kann. Bring-Your-Own-Key oder Hold-Your-Own-Key-Lösungen mit externer Schlüsselverwaltung schließen die Lücke technisch, sofern der Schlüssel-Verwalter selbst nicht US-rechtlich greifbar ist. Beachten ist außerdem, dass nicht alle Anbieter HYOK für alle Services anbieten.
Was passiert, wenn ein Hyperscaler einen CLOUD-Act-Bescheid erhält?
Der Anbieter ist verpflichtet, die angeforderten Daten herauszugeben. Er kann Widerspruch einlegen, was in der Praxis selten zum Erfolg führt. Eine Benachrichtigung des Kunden findet oft nicht statt, weil der Bescheid eine Schweigeverpflichtung enthalten kann. Der Auftraggeber erfährt im Zweifel erst aus dem späteren Verfahren, dass Daten übermittelt wurden.
Müssen kleine Unternehmen NIS2-Lieferkettenprüfungen durchführen?
Die NIS2-Pflichten greifen ab einer bestimmten Größenklasse oder bei Tätigkeit in geregelten Sektoren. Kleinere Unternehmen sind in der Regel nicht direkt verpflichtet, werden aber von ihren NIS2-pflichtigen Auftraggebern vertraglich in die Prüfung eingebunden. Das verschiebt die Pflicht faktisch in die Lieferkette. Wer als KMU einen NIS2-pflichtigen Kunden hat, muss Auskunft geben können.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt
