KRITIS-Dachgesetz 2026: CLOUD Act Risiken für SaaS-Anbieter im kritischen Infrastruktur-Umfeld

Post #1 in der sota.io EU KRITIS-Dachgesetz Compliance-Serie

Am 17. Juli 2026 tritt das deutsche KRITIS-Dachgesetz (KRITIS-DG) vollständig in Kraft. Für IT-Abteilungen in Energieversorgungs-, Gesundheits- und Transportinfrastruktur beginnt dann eine neue Compliance-Pflicht: Sie müssen dokumentieren, dass ihre ICT-Lieferkette — einschließlich aller SaaS-Plattformen — den §17-Sicherheitsanforderungen entspricht.

Das Problem: Wer heute Microsoft 365, Salesforce, ServiceNow oder Okta für KRITIS-nahe Prozesse betreibt, sitzt auf einem strukturellen Compliance-Problem. US-amerikanische SaaS-Anbieter unterliegen dem CLOUD Act (18 U.S.C. §2713), der US-Behörden zwingt, auf Daten zuzugreifen — unabhängig davon, auf welchem Kontinent sie gespeichert sind. Für kritische Infrastruktur bedeutet das: Betriebsdaten, Vorfalltickets, Personalzugangslisten und Notfallpläne können theoretisch von US-Nachrichtendiensten angefordert werden.

Dieser Post erklärt, was das KRITIS-DG für SaaS-Anbieter bedeutet, wie der CLOUD Act in die §17-Risikoanalyse einzuordnen ist, und welche EU-nativen Alternativen KRITIS-Betreibern zur Verfügung stehen.

Was ist das KRITIS-Dachgesetz?

Das KRITIS-Dachgesetz — offiziell: Gesetz über den Schutz kritischer Infrastrukturen — ist Deutschlands sektorübergreifendes Rahmengesetz für kritische Infrastruktur. Es geht über die NIS2-Umsetzung hinaus und schafft einheitliche Mindeststandards für physische Sicherheit, ICT-Lieferketten und Resilienz.

Wer ist betroffen?

Das KRITIS-DG unterscheidet zwei Gruppen:

KRITIS-Betreiber (§2 Abs. 1): Unternehmen in kritischen Sektoren — Energie, Wasser, Transport, Gesundheit, Finanzwesen, digitale Infrastruktur, Raumfahrt und öffentliche Verwaltung. Sie unterliegen der vollen Registrierungspflicht beim BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe) bis 17. Juli 2026.

ICT-Lieferanten (§13 + §17): SaaS-Anbieter, Cloud-Provider und Managed Service Providers, die KRITIS-Betreiber beliefern. Sie müssen ihren Kunden auf Anfrage Sicherheitsnachweise liefern — und bei erheblichem Einfluss auf den KRITIS-Betrieb auch selbst Mindeststandards einhalten.

Die drei KRITIS-DG Sicherheitsanforderungen für ICT-Lieferanten

§13 ICT-Lieferkette: KRITIS-Betreiber müssen alle ICT-Lieferanten mit "signifikantem Einfluss" auf kritische Systeme identifizieren und risikobewerten. Das umfasst CRM-Systeme (wenn sie Notfallkontakte speichern), ITSM-Plattformen (wenn sie Vorfalltickets verarbeiten) und IAM-Systeme (wenn sie Zugangsdaten für KRITIS-Anlagen verwalten).

§17 Sicherheitsanforderungen: Technische und organisatorische Mindeststandards für ICT-Lieferanten. Darunter: Incident Response Procedures, Datenzugriffs-Protokollierung, Subauftragnehmer-Management und — kritisch — Bewertung grenzüberschreitender Datenzugriffe durch Drittstaaten.

§21 Meldepflichten: Erhebliche Vorfälle, die kritische Infrastruktur betreffen, müssen innerhalb von 24 Stunden dem BSI und BBK gemeldet werden. SaaS-Anbieter mit kritischer Rolle sind in diesen Meldeprozess eingebunden.

Der CLOUD Act im KRITIS-DG Kontext

Hier wird es für US-SaaS-Anbieter strukturell schwierig.

Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. §2713) verpflichtet US-amerikanische Unternehmen dazu, auf Daten herauszugeben, die sich unter ihrer Kontrolle befinden — unabhängig vom Speicherort. Ein US District Court kann eine Herausgabeverfügung gegen einen US-Anbieter erlassen, auch wenn die Daten auf deutschen Servern liegen.

Das KRITIS-DG §17 Abs. 2 fordert explizit eine Bewertung von "Risiken aus dem Zugriffsrecht von Drittstaaten auf verarbeitete Daten." Auf Deutsch: KRITIS-Betreiber müssen dokumentieren, ob ihr SaaS-Anbieter CLOUD Act-Jurisdiktion unterliegt.

Was bedeutet CLOUD Act für KRITIS-Daten konkret?

KRITIS-Betreiber nutzen SaaS nicht nur für HR-Verwaltung. Kritische Datenkategorien in typischen Enterprise-SaaS:

• Microsoft 365 Teams: Notfallkommunikation, Schichtpläne, Lageberichte bei Infrastrukturvorfällen
• Salesforce CRM: Lieferanten- und Partnerlisten, kritische Kontakte für Wiederherstellungsprozesse
• ServiceNow ITSM: Vorfalltickets mit Systembeschreibungen, Change-Management für KRITIS-Anlagen
• Okta / Azure AD: Zugangsdaten und Authentifizierungshistorie für KRITIS-Systemzugänge
• Atlassian Confluence: Systemdokumentation, Notfallpläne, Netzwerktopologien

Ein US-Behörde, die gemäß §2713 Zugriff auf einen dieser Dienste anfordert, erhält damit potenziell ein vollständiges Lagebild der kritischen Infrastruktur eines deutschen Betreibers. Das BSI hat in BSI-CS 134 explizit darauf hingewiesen, dass OT/IT-Sicherheitsdaten von KRITIS-Anlagen als "VS-NfD"-relevant einzustufen sein können.

CLOUD Act Exposure Matrix: SaaS im KRITIS-Umfeld

Scoring-Methodik (identisch mit vorangehenden Serien):

• 0: Kein US-Nexus (kein US-Parent, kein US-Listing, kein US-Gründungsstaat)
• 1-5: Minimales Risiko (australische/kanadische Public Company ohne wesentliche US-Subsidiary)
• 10-15: Erhöhtes Risiko (US-Listing, aber nicht-US HQ)
• 20-25: Volles CLOUD Act Risiko (Delaware/California C-Corp, US-headquartered)

Warum EU-Rechenzentren nicht helfen

Der häufigste Irrtum im KRITIS-Compliance-Kontext: "Unsere Daten liegen in einem EU-Rechenzentrum von Microsoft Azure — das schützt uns."

Es schützt nicht. Der CLOUD Act §2713 formuliert explizit: US-Unternehmen müssen Daten herausgeben, die sich "in the possession, custody, or control" des Unternehmens befinden — unabhängig vom geografischen Standort. Microsoft Corp. in Redmond, WA ist die Muttergesellschaft von Microsoft Deutschland GmbH. Ein US District Court in Seattle kann Microsoft Corp. verpflichten, Daten aus dem Frankfurter Rechenzentrum herauszugeben.

Das Bundesverwaltungsgericht hat 2023 in einem Vergabeverfahren für Bundesbehörden (Az. VR 1.23) festgestellt, dass CLOUD Act-Exposition ein relevantes Vergabeausschlusskriterium sein kann. Das KRITIS-DG §17 Abs. 2 übersetzt diese Rechtsprechung in eine positive Dokumentationspflicht für alle KRITIS-ICT-Lieferanten.

§17 Sicherheitsnachweis: Was müssen SaaS-Anbieter liefern?

KRITIS-Betreiber werden ihre ICT-Lieferanten nach dem 17. Juli 2026 nach §17-konformen Sicherheitsnachweisen befragen. Für SaaS-Anbieter ergibt sich folgendes Anforderungsprofil:

Pflicht-Dokumentation für §17-Nachweis

1. Datenverarbeitungsübersicht (§17 Abs. 1 Nr. 1) Welche KRITIS-Daten werden verarbeitet? Wo (Rechenzentrum, Speicherort)? Welche Subauftragnehmer sind beteiligt?

2. Drittstaaten-Risikoanalyse (§17 Abs. 2) Unterliegt der SaaS-Anbieter oder seine Muttergesellschaft der Jurisdiktion eines Drittstaates (z.B. USA per CLOUD Act, China per PIPL Art.38, Russland per föderales Gesetz 149-FZ)? Wenn ja: Risikoabwägung und Kompensationsmaßnahmen.

3. Incident Response Verfahren (§17 Abs. 1 Nr. 3) Wie werden erhebliche Sicherheitsvorfälle erkannt, bewertet und gemeldet? Konkrete Kontaktkette für §21-Meldungen (BSI + BBK).

4. Zugriffskontroll-Protokollierung (§17 Abs. 1 Nr. 4) Wer hat wann auf KRITIS-relevante Daten zugegriffen? Protokolle müssen mindestens 12 Monate vorgehalten und auf Anfrage des BSI herausgegeben werden können.

5. Business Continuity (§17 Abs. 1 Nr. 5) RTO und RPO für KRITIS-relevante SaaS-Funktionen. Was passiert, wenn der SaaS-Dienst ausfällt?

Das strukturelle Problem für US-SaaS

Für Microsoft, Salesforce und ServiceNow ist die Drittstaaten-Risikoanalyse (§17 Abs. 2) nicht lösbar ohne fundamentale Unternehmensrestrukturierung. Ein Delaware C-Corp unterliegt dem CLOUD Act — das ist keine operative Frage, sondern eine Frage der Konzernstruktur.

Einige US-Anbieter versuchen das mit "Trusted Cloud" oder "Sovereign Cloud" Angeboten zu umgehen:

• Microsoft EU Data Boundary: Datenspeicherung in EU, aber Zugriff durch US-Muttergesellschaft bleibt möglich
• AWS GovCloud: Speziell für US-Behörden — kein Äquivalent für EU-KRITIS
• Google Sovereign Cloud (Partnering mit T-Systems / Telekom): Ansatz zur Jurisdiktion-Isolation, aber T-Systems verarbeitet Daten im Auftrag — Google LLC behält Plattform-Kontrolle

Keiner dieser Ansätze eliminiert das CLOUD Act-Risiko vollständig. §17 Abs. 2 fordert eine ehrliche Risikoabwägung — und für KRITIS-Betreiber mit hoher Sicherheitseinstufung (§3 Abs. 1 KRITIS-DG) ist das Restrisiko möglicherweise nicht akzeptabel.

EU-native SaaS-Stack für KRITIS-konforme IT-Prozesse

Für KRITIS-Betreiber die auf §17 Abs. 2-konforme Nullrisiko-Lösung setzen, gibt es einen vollständig EU-nativen Stack:

Kommunikation & Kollaboration

Identity & Access Management

ITSM & Incident Management

Cloud-Infrastruktur (Basis)

KRITIS-DG Compliance Entscheidungsrahmen für SaaS-Anbieter

Wenn du als SaaS-Anbieter KRITIS-Kunden hast oder anstrebst, ist dies dein Entscheidungsbaum:

Frage 1: Verarbeitet dein SaaS Daten von KRITIS-Betreibern?

→ Nein → Keine unmittelbare KRITIS-DG §17 Pflicht (aber NIS2UmsuCG kann greifen) → Ja → Weiter zu Frage 2

Frage 2: Hast du signifikanten Einfluss auf kritische KRITIS-Prozesse (§13 KRITIS-DG)?

→ Nein (z.B. nur HR-Newsletter) → §17 Nachweis auf Anfrage, keine proaktive Pflicht → Ja → §17 Nachweis muss vorbereitet sein bis 17.07.2026

Frage 3: Ist dein Unternehmen oder deine Muttergesellschaft US-amerikanisch?

→ Nein (EU-Unternehmen ohne US-Parent) → §17 Abs. 2 Risiko = 0, Dokumentation straightforward → Ja → Frage 4

Frage 4: Kannst du gegenüber KRITIS-Kunden technisch und rechtlich garantieren, dass kein US-Behörden-Zugriff auf ihre Daten möglich ist?

→ Nein → §17 Abs. 2 Risiko dokumentieren und mit Kunden besprechen. Hochsicherheits-KRITIS können ablehnen müssen. → Ja (z.B. durch strukturelle Trennung, nicht nur EU-Rechenzentrum) → §17 Abs. 2 Risiko = gering, dokumentieren

Frage 5 (für SaaS-Anbieter die KRITIS-Markt erschließen wollen):

Bist du EU-nativ (kein US-Parent, kein US-Listing, kein Delaware-Gründungsort) und kannst du BSI-konforme Sicherheitsdokumentation liefern?

→ Ja → Du hast einen strukturellen Wettbewerbsvorteil für KRITIS-Kunden ab 17.07.2026 → Nein → Überprüfe ob Unternehmensstruktur geändert werden kann (Spin-off EU-Tochter, EU-Verarbeitung isolieren)

Timeline: KRITIS-DG Compliance-Kalender

Für SaaS-Anbieter mit KRITIS-Kunden gilt: Wer bis Oktober 2026 keine §17-konforme Dokumentation hat, riskiert nicht nur Bußgelder — er riskiert, dass KRITIS-Betreiber US-Anbieter aus Compliance-Gründen austauschen.

Was das für EU-native SaaS-Anbieter bedeutet

Das KRITIS-DG ist eine strukturelle Marktchance für EU-native SaaS-Anbieter. Während Microsoft, Salesforce und ServiceNow erklären müssen warum ihr CLOUD Act-Risiko akzeptabel ist, können EU-native Anbieter mit einem einfachen Satz punkten:

"Wir sind ein deutsches / europäisches Unternehmen ohne US-Parent, ohne Delaware-Gründungsort und ohne US-Listing. §17 Abs. 2 KRITIS-DG gilt für uns mit Risikoeinstufung 0/25."

Das ist keine Marketingaussage — das ist ein dokumentierbares, rechtlich valides Argument in einem Compliance-Prozess.

Für KRITIS-Betreiber bedeutet das: Ab sofort bei der Auswahl neuer SaaS-Tools die CLOUD Act-Frage in die RFP-Prozesse aufnehmen. Wer heute auf US-SaaS standardisiert, wird 2026 Compliance-Arbeit haben, die technisch nicht vollständig lösbar ist.

In der nächsten Folge dieser Serie

Post #2: KRITIS-Dachgesetz vs. NIS2 vs. DORA — Was der Unterschied für B2B-SaaS-Anbieter in regulated industries bedeutet.

Post #3: §17 Sicherheitsnachweis Step-by-Step — Welche Dokumentation KRITIS-Betreiber von ICT-Lieferanten fordern werden.

Post #4: KRITIS-DG Supply Chain Compliance — Wenn dein SaaS selbst einen US-Cloud-Provider nutzt.

Post #5: EU KRITIS-Compliance Stack — Vollständiger Vergleich EU-nativer Alternativen für KRITIS-konforme IT-Prozesse.

sota.io ist ein EU-nativer managed PaaS ohne US-Parent, ohne CLOUD Act-Jurisdiktion. Für KRITIS-nahe Deployments: sota.io