Cloud Anbieter ausgefallen unter NIS 2
Der Ausfall Ihres Anbieters ist der Praxistest Ihres Notfallplans, keine Befreiung davon.
Worum es auf dieser Seite geht
Ein großer Cloud Anbieter fällt aus. Die Produktion steht. Die Frage im Raum: Liegen die NIS 2 Pflichten beim Anbieter oder bei Ihrer Einrichtung. Die Antwort der Richtlinie: Beide Ebenen tragen ihre eigenen Pflichten, und eine Ebene entlastet die andere nicht. Ihre Pflichten nach Artikel 21(2)(c) NIS 2 zu Betriebskontinuität, Backup und Wiederherstellung sowie nach Artikel 23 zur Meldung erheblicher Sicherheitsvorfälle gelten für Ihre Einrichtung unabhängig davon, was Ihr Anbieter auf seiner eigenen Uhr tut.
Diese Seite richtet sich an eine IT Leitung oder eine Geschäftsführung in einem Unternehmen mit 50 bis 250 Beschäftigten, das den Großteil seiner Produktion bei einem Hyperscaler oder regionalen Cloud Anbieter betreibt. Dies ist keine Rechtsberatung. Es ist die Mechanik dahinter, welche Klausel auf wen anwendbar ist, wenn die Statusseite des Anbieters rot wird.
Der wichtigste Satz: Ein Cloud Ausfall ist der Live Test Ihres Wiederanlaufplans nach Artikel 21(2)(c). Funktioniert der Plan, liegt kein erheblicher Sicherheitsvorfall bei Ihrer Einrichtung vor. Funktioniert der Plan nicht, beginnt Artikel 23 auf Ihrer Uhr zu laufen, nicht auf der Uhr des Anbieters.
Richtlinie (EU) 2022/2555 (NIS 2)
Artikel 21(2)(c): Konzepte und Verfahren für die Aufrechterhaltung des Betriebs wie Sicherungsmanagement und Wiederherstellung nach einem Notfall sowie Krisenmanagement. Artikel 21(2)(d): Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen jeder Einrichtung und ihren unmittelbaren Anbietern oder Diensteanbietern.
Artikel 21(2)(c) legt die Pflicht zu Kontinuität, Backup und Wiederherstellung auf die Einrichtung. Die Richtlinie lässt nicht zu, dass diese Pflicht über einen Vertrag an einen Cloud Anbieter übertragen wird. Artikel 21(2)(d) ist der Lieferantenarm: Sie müssen die Sicherheit Ihrer unmittelbaren Anbieter bewerten und steuern, einschließlich vertraglicher Meldepflichten bei Ausfällen und Sicherheitsvorfällen beim Anbieter. Artikel 23 setzt die Meldekaskade: 24 Stunden Frühwarnung, 72 Stunden Meldung des Sicherheitsvorfalls, Zwischenbericht auf Anforderung, Abschlussbericht binnen eines Monats.
Durchführungsverordnung (EU) 2024/2690
Artikel 23(3) NIS 2: Ein Sicherheitsvorfall gilt als erheblich, wenn er schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die betreffende Einrichtung verursacht hat oder verursachen kann oder wenn er andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann.
Die CIR konkretisiert für die elf Kategorien digitaler Infrastruktur und digitaler Dienste, was als erheblich gilt. Dazu gehören Anbieter von Cloud Computing Diensten nach Anhang I Sektor 8 NIS 2. Abschnitt 11 des Anhangs der CIR listet Szenarien, die auf Anbieterebene als erheblicher Sicherheitsvorfall gelten. Für Einrichtungen außerhalb des CIR Anwendungsbereichs gilt der Erheblichkeitstest nach Artikel 23(3), und ein kaskadierender Ausfall, der die Produktion stoppt, erfüllt diesen Test fast immer.
BSIG (Deutschland)
§30 BSIG: dem Risiko angemessene technische und organisatorische Maßnahmen. §32 BSIG: Meldung erheblicher Sicherheitsvorfälle an das BSI über das Meldeportal unter bsi.bund.de. §31 BSIG: Pflichten zur Sicherheit der Lieferkette für die Einrichtung.
Das BSIG ist die deutsche Umsetzung als Beispiel. Die Niederlande (Cyberbeveiligingswet) und Österreich (NISG 2024) haben eigene Umsetzungen. Die Kaskade aus 24 / 72 Stunden, Zwischenbericht und einem Monat steht in der Richtlinie selbst und ist in allen Mitgliedstaaten identisch. Ein Cloud Anbieter, der selbst eine NIS 2 Einrichtung in der EU ist, hat seine eigene Meldepflicht nach §32 BSIG oder dem nationalen Pendant. Diese Pflicht hebt Ihre nicht auf.
Gegen den Plan nach Artikel 21(2)(c) prüfen
Den Plan zur Aufrechterhaltung des Betriebs und zur Wiederherstellung öffnen und ausführen. Die Frage lautet nicht, ob der Anbieter ausgefallen ist. Die Frage lautet, ob Ihre Dienste nach dem Plan, den Sie geschrieben haben, weiterlaufen können. Failover in eine zweite Region, Umstieg auf einen dokumentierten Offline Ablauf oder Wiederherstellung aus einem Backup außerhalb des betroffenen Anbieters. Artikel 21(2)(c) NIS 2 legt die Kontinuitätspflicht auf Ihre Einrichtung. Zeigt der Ausfall, dass kein Plan existierte, ist das der erste Befund, nicht der Ausfall selbst.
Den Lieferantenprozess nach Artikel 21(2)(d) auslösen
Artikel 21(2)(d) NIS 2 verlangt, dass Sie die Sicherheit Ihrer unmittelbaren Anbieter steuern. In einem Ausfall heißt das drei Dinge: Vertrag öffnen und Melde sowie SLA Klauseln lesen, die Vorgangsnummer des Anbieters und seinen veröffentlichten Zeitverlauf protokollieren, und die Belege in Ihrem Audit Trail erfassen. Verlangt der Vertrag keine Anbieter Meldung bei Sicherheitsvorfällen, die Sie betreffen, ist das der zweite Befund, getrennt vom Ausfall selbst.
Melden, wenn Ihre Einrichtung einen erheblichen Sicherheitsvorfall hat
Der Erheblichkeitstest nach Artikel 23(3) wird auf Ihre Einrichtung angewendet, nicht auf den Anbieter. Verursacht der Ausfall schwerwiegende Betriebsstörungen Ihrer Dienste, finanzielle Verluste bei Ihnen oder erhebliche Schäden bei anderen, die von Ihnen abhängen, beginnt Artikel 23 NIS 2 auf Ihrer Uhr zu laufen. Frühwarnung an das nationale CSIRT oder die zuständige Behörde binnen 24 Stunden nach Kenntnisnahme, Meldung des Sicherheitsvorfalls binnen 72 Stunden, Zwischenbericht auf Anforderung, Abschlussbericht binnen eines Monats. In Deutschland läuft das über das BSI Meldeportal nach §32 BSIG. Die eigene Meldung des Anbieters nach seinem eigenen NIS 2 Status ist getrennt und ersetzt Ihre nicht.
Kontinuität ist Pflicht der Einrichtung, nicht des Anbieters
Artikel 21(2)(c) NIS 2 legt die Pflicht zu Kontinuität, Backup und Wiederherstellung auf die Einrichtung. Ein Vertrag mit einem Hyperscaler, der eine Verfügbarkeit von 99,99 Prozent zusagt, ist kein Notfallplan im Sinne der Richtlinie. Der Plan muss beschreiben, was Ihre Einrichtung tut, wenn der Anbieter nicht verfügbar ist. Der Prüfer im nächsten Jahr testet, ob dieser Plan existiert und geübt wurde, nicht ob die SLA eingehalten wurde.
Backups müssen wiederherstellbar sein, nicht nur vorhanden
Die BSI Position lautet: Die Existenz eines Backups ist nicht der Test. Die Wiederherstellbarkeit unter den Bedingungen eines tatsächlichen Vorfalls ist es. Ein Backup, das in derselben Cloud Region wie das Produktionssystem und gegen denselben Identitätsanbieter abgelegt ist, ist im Sinne von Artikel 21(2)(c) kein Backup, wenn genau die Region oder die Identitätsebene ausfällt. Die Pflicht zum wiederherstellbaren Backup verlangt Trennung über die Fehlerebene hinweg, die Sie überstehen wollen.
BSI Meldeportal (Deutschland), nationales CSIRT (andere Mitgliedstaaten)
Verursacht der Ausfall einen erheblichen Sicherheitsvorfall bei Ihrer Einrichtung nach Artikel 23(3), läuft die Meldung über Ihren nationalen Kanal. In Deutschland ist das das BSI Meldeportal nach §32 BSIG. In den Niederlanden das National Cyber Security Centre, in Österreich das GovCERT. Die Meldung ist Ihre Pflicht, auch wenn die Ursache beim Anbieter sitzt. Eine Statusseite des Anbieters ist keine Meldung.
Cloud Anbieter als NIS 2 Einrichtung, Anhang I Sektor 8
Ein in der EU niedergelassener Anbieter von Cloud Computing Diensten ist eine wesentliche oder wichtige Einrichtung nach Anhang I Sektor 8 NIS 2 (digitale Infrastruktur). Er hat seine eigene Meldepflicht nach Artikel 23 auf seiner eigenen Uhr gegenüber seiner eigenen zuständigen Behörde oder seinem CSIRT. Die CIR 2024/2690 legt die Erheblichkeitsschwellen für Anbieter digitaler Infrastruktur fest. Die Meldung des Anbieters ist nicht Ihre Meldung. Ein Anbieter außerhalb der EU fällt außerhalb des Geltungsbereichs der Richtlinie, in diesem Fall ist Artikel 21(2)(d) zur Lieferkettensicherheit Ihr einziger Hebel.
ENISA und das CSIRTs Netzwerk
Grenzüberschreitende Ausfälle großer Cloud Anbieter werden über das CSIRTs Netzwerk unter Koordinierung der ENISA nach Artikel 15 NIS 2 koordiniert. ENISA veröffentlicht Lageinformationen über die Mitgliedstaaten hinweg. Für eine einzelne Einrichtung ist das Referenzmaterial, kein Meldekanal. Der Meldekanal ist national. ENISA ist die Stelle, an der Sie nachlesen, was auf EU Ebene passiert, wenn der Anbieter in mehreren Ländern ausgefallen ist.
Die Cloud ist Sache des Anbieters. NIS 2 liegt bei denen.
Artikel 21(2)(c) NIS 2 legt die Pflicht zu Kontinuität, Backup und Wiederherstellung auf Ihre Einrichtung. Artikel 21(2)(d) legt die Pflicht zur Lieferkettensicherheit auf Ihre Einrichtung. Der Anbieter hat seine eigenen Pflichten nach der Richtlinie, wenn er ein in der EU niedergelassener Cloud Anbieter nach Anhang I Sektor 8 ist. Diese Pflichten laufen parallel zu Ihren und heben sie nicht auf. Die Prüfung im nächsten Jahr testet Ihren Plan, nicht die SLA des Anbieters.
Auf den SLA Bericht des Anbieters warten, bevor wir melden oder nachbessern.
Artikel 23(4) NIS 2 verlangt die Frühwarnung binnen 24 Stunden nach Kenntnisnahme eines erheblichen Sicherheitsvorfalls bei Ihrer Einrichtung. Der Anbieterbericht kann Wochen dauern. Hat der Ausfall schwerwiegende Betriebsstörungen bei Ihrer Einrichtung verursacht, läuft die 24 Stunden Uhr gegen Sie, unabhängig davon, ob der Anbieter etwas veröffentlicht hat. Das Warten auf den SLA Bericht ist in Cloud Ausfällen der häufigste Grund, warum Einrichtungen die Frist verpassen.
Der Anbieter ist wieder da, alles läuft, der Vorfall ist geschlossen.
Artikel 21(2)(c) NIS 2 erwartet, dass der Kontinuitäts und Wiederanlaufplan geübt und verbessert wird. Ein Cloud Ausfall ist eine Live Übung dieses Plans, und die Nachbereitung speist die nächste Iteration. Der Prüfer wird fragen, was sich am Wiederanlaufplan nach dem letzten Ausfall geändert hat. Hat sich nichts geändert und die gleiche Lücke besteht weiter, ist das ein Befund. Eine Rückkehr zum Normalbetrieb ist im Sinne der Richtlinie noch kein abgeschlossener Vorfall.
Ein Logistikunternehmen mit 110 Beschäftigten in Nordrhein Westfalen, eingestuft als wichtige Einrichtung nach NIS 2, weil Sektor und Beschäftigtenzahl im Anwendungsbereich liegen. Dienstag 09:14 Uhr: Die zentrale EU Region des Hyperscalers degradiert, das Transportmanagementsystem, der Identitätsanbieter und der gemeinsame Dateispeicher sind nicht mehr erreichbar. 09:20 Uhr: Die IT Leitung öffnet den Notfallplan, schaltet die Disposition auf den dokumentierten Offline Ablauf auf lokalen Laptops um und informiert die Geschäftsführung. 09:35 Uhr: Geschäftsleitung gebrieft, Entscheidung im Audit Trail festgehalten: Behandlung als Kontinuitätsereignis nach Artikel 21(2)(c) und Beobachtung gegen den Erheblichkeitstest nach Artikel 23(3). Die Statusseite des Anbieters wird gespeichert und an den Vorfallsdatensatz angehängt.
11:50 Uhr: Der Ausfall dauert über zwei Stunden und beeinträchtigt jetzt Liefertermine gegenüber Kunden. Der Test nach Artikel 23(3) wird erneut bewertet: Schwerwiegende Betriebsstörung der Dienste ist erfüllt. Die 24 Stunden Frühwarnung wird über das BSI Meldeportal nach §32 BSIG gemeldet, unter Angabe der Vorgangsnummer des Anbieters und der eigenen Auswirkungen. 14:30 Uhr: Der Anbieter stellt die Region wieder her. Das Unternehmen führt am Folgemorgen die Nachbereitung durch. Befund: Der zweite Identitätsanbieter war auf dem Papier vorhanden, aber nie geübt, daher dauerte der Failover 40 Minuten länger als geplant. Zwei schriftliche Änderungen gehen in den Plan: monatliche Übung des zweiten Identitätsanbieters und eine Vertragsanpassung mit dem Cloud Anbieter zur Meldung regionaler Sicherheitsvorfälle binnen 30 Minuten. Zwischenbericht und Abschlussbericht binnen eines Monats nach Artikel 23 werden aus dem Audit Trail erstellt, nicht aus dem Gedächtnis.
Die Plattform hält die vier schriftlichen Dinge vor, die Sie vor dem nächsten Anbieterausfall brauchen: den Kontinuitätsplan gegen Artikel 21(2)(c), die Konfiguration des wiederherstellbaren Backups mit Belegen seiner Trennung von der primären Fehlerebene, das Lieferantenverzeichnis mit Melde und SLA Klauseln gegen Artikel 21(2)(d) sowie die Meldetemplates und die Kontaktliste für die Kaskade nach Artikel 23. Jede Änderung und jede Übung wird mit Zeitstempel im Audit Trail festgehalten, sodass der Prüfer im nächsten Jahr einen Plan sieht, der tatsächlich gelaufen ist, nicht ein Dokument, das einmal geschrieben wurde.
Die Plattform ist kostenlos und Open Source. Es gibt keine Bezahlebene und keinen Lock-in. Diese Seite verkauft nichts. Sie sorgt dafür, dass beim nächsten roten Statusbalken Ihre Geschäftsführung weiß, ob die Uhr der Richtlinie gegen Sie läuft und was der nächste schriftliche Schritt ist.
- Richtlinie (EU) 2022/2555 (NIS 2): Artikel 21(2)(c) (Betriebskontinuität, Backup, Wiederherstellung, Krisenmanagement), Artikel 21(2)(d) (Lieferkettensicherheit), Artikel 23 (Meldekaskade) und Artikel 23(3) (Erheblichkeitstest). Anhang I Sektor 8 (digitale Infrastruktur, einschließlich Anbieter von Cloud Computing Diensten). EUR-Lex.
- Durchführungsverordnung (EU) 2024/2690: technische und methodische Anforderungen sowie Erheblichkeitsschwellen für Anbieter digitaler Infrastruktur und digitaler Dienste, einschließlich Cloud Anbieter. Anhang Abschnitt 11. EUR-Lex.
- BSIG (Deutschland): §30 (Risikomanagementmaßnahmen), §31 (Lieferkettensicherheit), §32 (BSI Meldeportal). Gesetze im Internet.
- BSI: NIS 2 Informationspakete zu Betriebskontinuität, wiederherstellbaren Backups und der Position, dass die Existenz eines Backups nicht der Test ist. bsi.bund.de.
- ENISA: Koordinierung des CSIRTs Netzwerks nach Artikel 15 NIS 2 für grenzüberschreitende Sicherheitsvorfälle. enisa.europa.eu.