NIS2 für Cloud-Teams, Teil 1: Anforderungen und Checkliste für AWS, Azure und Google Cloud

Schlagen Sie die NIS2-Richtlinie bei Artikel 21 auf, finden Sie zehn Sicherheitsmaßnahmen, (a) bis (j). Keine davon erwähnt AWS, Azure, Google Cloud, Kubernetes oder Terraform. Und trotzdem landet das Ticket in Ihrem Backlog: „Macht unsere Cloud NIS2-konform.“ Ohne Definition of Done, ohne Verantwortlichen auf der Fachseite, mit einem Audit irgendwo in der Zukunft.

Ich arbeite im Bereich Cloud Security in einem großen, regulierten deutschen Unternehmen, und das hier ist die Übersetzung, die ich mir am ersten Tag gewünscht hätte: was NIS2 wirklich verlangt, was Ihr Cloud-Anbieter schon abdeckt, was bei Ihnen bleibt und wie sich jede der zehn Maßnahmen auf echte Dienste in AWS, Azure und Google Cloud abbilden lässt. Sie bekommen eine Tabelle für Ihr Ticket, eine CSV-Datei für Excel und einen 30-Tage-Plan.

Das ist Teil 1 der Serie NIS2 für Cloud-Teams. Er klärt, was NIS2 von einem Cloud-Team verlangt. Der Rest der Serie zeigt das Wie, mit echter Konfiguration.

Was verlangt NIS2? Die Zusammenfassung in 60 Sekunden

NIS2 (Richtlinie (EU) 2022/2555) ersetzt die erste NIS-Richtlinie und wird in jedem EU-Mitgliedstaat durch nationales Recht umgesetzt. In Deutschland ist das das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), das das BSI-Gesetz (BSIG) neu gefasst hat und seit Dezember 2025 gilt. Für ein Cloud-Team zählen vier Teile:

Alles Weitere dreht sich um Artikel 21, denn dort lebt Ihre Cloud-Konfiguration.

Für wen gilt NIS2?

Die Nutzung einer Cloud macht Sie nicht betroffen. Entscheidend sind Sektor und Größe. NIS2 gilt für Einrichtungen in den Sektoren aus Anhang I (Energie, Verkehr, Bankwesen, Gesundheit, digitale Infrastruktur, Verwaltung von IKT-Diensten und weitere) und Anhang II (Post, Abfall, Chemie, Lebensmittel, verarbeitendes Gewerbe, Anbieter digitaler Dienste und weitere), die mindestens mittelgroß sind. In der Praxis heißt das: 50 oder mehr Beschäftigte oder mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme. In Deutschland betrifft das laut BSI rund 29.500 Einrichtungen.

Manche Einrichtungen sind unabhängig von ihrer Größe erfasst: Anbieter öffentlicher elektronischer Kommunikationsnetze oder -dienste, Vertrauensdiensteanbieter, TLD-Namenregister und DNS-Diensteanbieter sowie Einrichtungen, die ein Mitgliedstaat als kritisch einstuft.

Betroffene Einrichtungen sind entweder besonders wichtig oder wichtig. Die Pflichten aus Artikel 21 sind dieselben, der Unterschied liegt in der Aufsicht: Besonders wichtige Einrichtungen können proaktiv geprüft werden, wichtige vor allem dann, wenn es Hinweise auf ein Problem gibt. Auch die Bußgelder unterscheiden sich (siehe Tabelle oben).

Vier Details überraschen Cloud-Teams regelmäßig:

• Wenn Sie Cloud-, Managed- oder Security-Services verkaufen, sind Sie wahrscheinlich selbst betroffen. Anbieter von Cloud-Computing-Diensten, Rechenzentrumsdiensten, verwalteten Diensten und verwalteten Sicherheitsdiensten stehen in Anhang I.
• Ein Sitz außerhalb der EU schützt nicht. NIS2 folgt den Diensten, die Sie in der EU erbringen. Cloud-, Rechenzentrums-, Managed- und Managed-Security-Anbieter ohne EU-Niederlassung müssen einen Vertreter in einem Mitgliedstaat benennen, in dem sie Dienste anbieten (Artikel 26).
• Banken und Versicherungen folgen meist DORA. Wo ein sektorspezifischer EU-Rechtsakt mindestens gleichwertige Sicherheits- und Meldepflichten festlegt, hat er Vorrang (Artikel 4). Für Finanzunternehmen ist das DORA; das BSI erklärt das Zusammenspiel auf seiner Seite DORA und NIS-2.
• In Deutschland ist die Registrierung Ihre Aufgabe. Einrichtungen registrieren sich selbst beim BSI; niemand schickt Ihnen einen Brief. Wenn Sie unsicher sind, ob Sie betroffen sind, nutzen Sie die NIS-2-Betroffenheitsprüfung des BSI. Sind Sie betroffen und noch nicht registriert, sind Sie bereits spät dran.

„Ist AWS NIS2-konform?“ ist die falsche Frage

Es ist eine der meistgesuchten Fragen zu NIS2 und Cloud, und sie beruht auf einem Missverständnis. NIS2-Pflichten treffen Einrichtungen, nicht Produkte. Eine Cloud kann nicht für Sie konform sein, so wie ein Fitnessstudio nicht für Sie fit sein kann.

Tatsächlich passiert Folgendes: AWS, Microsoft und Google fallen selbst als Anbieter von Cloud-Computing-Diensten unter NIS2. Für sie hat die Kommission die Durchführungsverordnung (EU) 2024/2690 erlassen, die die technischen Anforderungen ausbuchstabiert und festlegt, wann ein Vorfall als erheblich gilt. Das betrifft deren Rechenzentren, Hypervisoren und globales Netz.

Was Sie von den Anbietern bekommen, sind Nachweise und Werkzeuge. Alle drei veröffentlichen unabhängige Testate, darunter ISO 27001 und den Cloud-Kriterienkatalog C5 des BSI (siehe die C5-Seiten von AWS, Microsoft und Google Cloud). Die Berichte laden Sie aus AWS Artifact, dem Microsoft Service Trust Portal oder dem Google Compliance Reports Manager herunter. Genau diese Berichte verlangt Maßnahme (d), die Sicherheit der Lieferkette. Sie belegen, dass der Lieferant solide ist. Über Ihre IAM-Policy sagen sie nichts.

Die NIS2-Konformität Ihres Anbieters deckt sein Rechenzentrum ab, nicht Ihre IAM-Policy. Das Testat wandert in Ihre Lieferantenakte, die Fehlkonfiguration bleibt in Ihrem Backlog.

NIS2-Anforderungen nach Artikel 21: die zehn Maßnahmen verständlich erklärt

Artikel 21 Absatz 2 ist kurz. Hier ist jede Maßnahme, was sie für ein Cloud-Team bedeutet und welche Nachweise ein Prüfer vernünftigerweise sehen will. „Verhältnismäßig“ (Art. 21 Abs. 1) heißt: Die Tiefe skaliert mit Risiko und Größe. Es heißt nicht, dass Sie einen Buchstaben auslassen dürfen.

Zu fast jeder dieser Maßnahmen hat das BSI ein eigenes #nis2know-Infopaket veröffentlicht, von der Risikoanalyse über die Lieferkette bis zu MFA. Wer schon ein ISMS nach ISO/IEC 27001 betreibt, findet dort auch, wie es sich zu NIS2 verhält.

Die zehn Buchstaben wirken wie eine zufällige Liste, bündeln sich aber in vier Aufgaben, die Ihre Cloud-Plattform ohnehin erledigt: steuern, schützen, reagieren und wiederherstellen.

NIS2-Checkliste: Artikel 21 auf AWS, Azure und Google Cloud abgebildet

Das ist die Tabelle für Ihr Ticket. Jede Zeile nennt die nativen Dienste, die die Kontrolle oder den Nachweis liefern. Keiner davon macht Sie durch bloßes Einschalten konform; sie machen die Maßnahme umsetzbar und nachweisbar.

Die vollständige NIS2-Checkliste als CSV herunterladen: alle zehn Maßnahmen mit Erklärung, Nachweisen, den drei Anbietern und leeren Spalten für verantwortlich und status. Sie öffnet sich in Excel, Numbers und Google Sheets.

Azure-NIS2-Policy-Initiative und was AWS und Google Cloud stattdessen bieten

Azure ist der einzige der drei Anbieter, der NIS2 als fertiges Policy-Set liefert. Azure Policy enthält integrierte Regulatory-Compliance-Initiativen für NIS2, die nach der Zuweisung im Regulatory-Compliance-Dashboard von Defender for Cloud erscheinen. Sie zu finden, ist ein Befehl:

# Integrierte NIS2-Initiativen im Tenant auflisten
az policy set-definition list \
  --query "[?contains(displayName, 'NIS2')].{id:name, name:displayName}" \
  --output table

Weisen Sie eine Initiative zuerst im Audit-Modus auf Management-Group-Ebene zu. Wer am ersten Tag deny-Effekte über eine laufende Umgebung legt, legt Produktion lahm und verspielt das Vertrauen des Teams am selben Nachmittag.

AWS und Google Cloud haben zum Zeitpunkt des Schreibens kein NIS2-Framework. Ihre integrierten Listen enden bei CIS, ISO 27001, NIST, PCI DSS und SOC 2:

• AWS Security Hub CSPM (der Posture-Management-Teil von Security Hub, inzwischen unter eigenem Namen) prüft gegen AWS Foundational Security Best Practices, CIS, NIST und PCI DSS. AWS Audit Manager nimmt keine Neukunden mehr an; bauen Sie darauf also keinen neuen NIS2-Nachweisprozess.
• Compliance Manager im Security Command Center bringt Frameworks wie CIS, ISO 27001:2022, NIST SP 800-53 und SOC 2 mit und erlaubt eigene Frameworks. Das ISO-27001-Framework zu kopieren und seine Kontrollen nach den Buchstaben aus Artikel 21 neu zu ordnen, ist ein schneller Start.

Das ist weniger schlimm, als es klingt. Die meisten technischen NIS2-Prüfungen sind dieselben, die diese Frameworks ohnehin ausführen. Sie starten damit und ergänzen das Mapping selbst:

# AWS: welche Standards Security Hub CSPM für Sie prüfen kann
aws securityhub describe-standards \
  --query 'Standards[].Name' --output table

# Google Cloud: welche Organization Policies auf Org-Ebene gesetzt sind
gcloud org-policies list --organization=ORG_ID

Auf Google Cloud gruppiert das Security Command Center Findings bereits nach Compliance-Standard. Wenn Sie es zum ersten Mal öffnen, lesen Sie vorher, wie die ersten 24 Stunden mit dem Security Command Center aussehen, bevor die roten Zahlen jemanden erschrecken.

Ihre ersten 30 Tage

Starten Sie nicht mit einer Gap-Analyse über 200 Zeilen. Starten Sie mit den Maßnahmen, die sich billig beheben, leicht nachweisen und schmerzhaft verpassen lassen:

In Woche 2 gewinnen Cloud-Teams am meisten mit dem wenigsten Aufwand, und die Anbieter haben einen Teil davon schon für Sie erledigt:

Die Lücke, die die Anbieter lassen, sind Maschinenidentitäten. Auf Google Cloud beseitigt Service-Account-Schlüssel abschaffen mit Workload Identity Federation eine ganze Klasse langlebiger Zugangsdaten. Woche 3 entscheidet, ob Sie überhaupt rechtzeitig melden können; wenn ein SIEM Teil des Plans ist, prüfen Sie vorher, was Wazuh, Sentinel und Google SecOps wirklich kosten.

Fünf Fehler, die Cloud-Teams bei NIS2 machen

1. Das Zertifikat des Anbieters für die eigene Konformität halten. C5 und ISO 27001 decken den Anbieter ab. Sie gehören in Ihre Lieferantenakte für Maßnahme (d), nicht in Ihre Antwort auf Maßnahme (i).
2. Ein Dashboard kaufen und fertig. Ein grüner Compliance-Score misst konfigurierbare Kontrollen. Er sieht nicht, ob die Geschäftsleitung die Richtlinie gebilligt hat oder ob jemand geschult wurde.
3. Logging ohne Menschen am Ende. Die 24-Stunden-Frist beginnt mit der Kenntniserlangung eines erheblichen Sicherheitsvorfalls. Logs, die niemand liest, helfen Ihnen nicht, rechtzeitig zu melden, und sind später ein unangenehmes Beweisstück.
4. Backups, die nie wiederhergestellt wurden. Bei Maßnahme (c) geht es um Betriebskontinuität, und Kontinuität heißt: eine Wiederherstellung, deren Dauer Sie kennen. Ein ungetestetes Backup ist eine Hypothese.
5. Die Software-Lieferkette vergessen. Maßnahme (d) umfasst mehr als Ihren Cloud-Vertrag. Jede Paket-Registry und jedes Base-Image ist ebenfalls ein Lieferant, deshalb gehört Schutz vor npm-Lieferkettenangriffen in dasselbe Backlog.

NIS2-Meldepflicht: die 24-Stunden-Uhr

Mit Artikel 23 hört NIS2 auf, eine Dokumentenübung zu sein. Sobald Sie Kenntnis von einem erheblichen Sicherheitsvorfall erlangen, laufen die Fristen, auch am Wochenende:

In Deutschland gehen die Meldungen über das BSI-Portal an das BSI. Als Kenntniserlangung gilt laut BSI der Zeitpunkt, an dem eine Mitarbeiterin oder ein Mitarbeiter der Einrichtung innerhalb der Arbeitszeit von dem Vorfall erfährt. Die Leitlinie des BSI ist unmissverständlich: Schnelligkeit vor Vollständigkeit. Eine Meldung lässt sich später korrigieren und ergänzen, aber nicht zurückziehen. Details stehen im #nis2know-Paket zur Meldepflicht.

Und jetzt der unbequeme Teil: Auf allen drei Clouds werden einige der Logs, die Sie für diese Meldung brauchen, standardmäßig nicht erfasst. Google Cloud lässt die meisten Data-Access-Audit-Logs ausgeschaltet. AWS CloudTrail zeichnet S3-Datenereignisse auf Objektebene nur auf, wenn Sie das ausdrücklich konfigurieren. Azure behält Ressourcenprotokolle nur, wenn Sie Diagnoseeinstellungen anlegen. Viele Teams entdecken diese Lücken bei ihrem ersten Vorfall, wenn die 24-Stunden-Uhr schon läuft.

Genau an dieser Lücke setzt der nächste Teil der Serie an. Abonnieren Sie unten, dann landet er am Tag der Veröffentlichung in Ihrem Postfach.

Fazit

NIS2 ist egal, auf welcher Cloud Sie laufen. Entscheidend ist, ob Sie für jede der zehn Maßnahmen aus Artikel 21 zeigen können, dass jemand verantwortlich ist, dass eine Kontrolle existiert und dass sie funktioniert. AWS, Azure und Google Cloud liefern Ihnen die meisten Kontrollen und einen Stapel Nachweise über sich selbst. Die Konfiguration, die Logs, die Wiederherstellungstests, die Meldungen und die Unterschriften bleiben Ihre.

Starten Sie mit der Tabelle, benennen Sie pro Buchstabe eine verantwortliche Person und beheben Sie zuerst Identitäten und Logging. Allein damit sind Sie weiter als viele Organisationen, die noch auf die Gap-Analyse eines Beraters warten.

Dann kommt der Moment, in dem eine Checkliste nicht mehr reicht: der erste erhebliche Sicherheitsvorfall. Genau dorthin geht diese Serie als Nächstes.