Ihr Risiko sitzt nicht nur am Zaun, an der Schleuse oder im Brandschutzabschnitt. Es sitzt in der logischen Trennung Ihrer Kundenumgebungen. In Hypervisoren. In Containern. In Admin-Tenants. In der Frage, ob ein kompromittierter Kunde zum Plattformrisiko wird.
RZ-Betreiber und Cloud-Provider stehen unter NIS2 nicht mehr mit schönen Architekturfolien im Audit. Sie müssen nachweisen, dass physische und logische Sicherheitsperimeter funktionieren. Unter Last. Im Incident. Bei Dienstleisterausfall. Im Exit-under-stress-Szenario.
Wer hier nur ISO-Templates ausfüllt, baut einen Papier-Tiger. Und Papier-Tiger schützen nicht vor Meldepflichten, Kundenkündigungen oder Geschäftsführerhaftung.
Anforderungen an Rechenzentren und Cloud-Betreiber unter NIS2
NIS2 verschiebt die Erwartung von „wir haben Sicherheitsmaßnahmen“ zu „wir können ihre Wirksamkeit belegen“. Für Betreiber von Rechenzentren, Cloud-Plattformen und Managed-Infrastrukturen heißt das: Ihr Sicherheitskonzept muss technische, organisatorische und vertragliche Abhängigkeiten abdecken.
Der kritische Punkt ist nicht die Richtlinie auf dem SharePoint. Der kritische Punkt ist der Nachweis im Ernstfall.
Das BSI beschreibt die Erwartung in der Sache: „Der Betreiber muss eine Exit-Strategie nachweisen und Verfahren implementieren, die geeignet sind, den teilweisen oder vollständigen Ausfall der Dienste eines Dritten unverzüglich [...] zu kompensieren.“
Juristen-Jargon. Harte Praxis.
Das bedeutet für Sie:
- Sie müssen zeigen, wie Sie aus einem Provider-, Carrier-, SaaS-, IaaS- oder Subdienstleister-Ausfall herauskommen.
- Sie müssen definieren, welche Workloads, Daten, Schlüssel, Images, Backups und Konfigurationen in welcher Reihenfolge migriert oder wiederhergestellt werden.
- Sie müssen belegen, dass Multi-Tenant-Isolation nicht nur konzipiert, sondern technisch kontrolliert wird.
- Sie müssen dokumentieren, wie Container, VMs, Orchestrierung, Management-Plane und Storage-Schichten nach Stand der Technik geschützt sind.
- Sie müssen Exit- und Wiederanlaufprozesse testen. Nicht irgendwann. Regelmäßig. Nachweisbar.
NIS2 Cloud ist damit kein reines Compliance-Thema. Es ist ein Betriebsfähigkeits-Thema. Wenn Ihr Plattformbetrieb unter Stress nicht kontrollierbar ist, ist Ihr Audit-Risiko nur das kleinere Problem.
Warum generische Richtlinien und Templates nicht ausreichen
Eine neue Firewall löst keine Tenant-Isolation. Ein ISO-27001-Template löst keine Exit-Strategie. Und ein hübsches Notfallhandbuch löst keinen Vendor-Lock-in.
Gerade diese Nachweisfragen werden in Standardvorlagen oft nur unzureichend abgebildet.
Viele Anbieter verkaufen Ihnen generische Policies:
- „Access Control Policy“
- „Incident Response Plan“
- „Business Continuity Template“
- „Supplier Risk Register“
Das sieht sauber aus. Erst wenn der Prüfer konkrete Fragen stellt, wird sichtbar:
- Welche logischen Sicherheitsperimeter trennen Tenant A von Tenant B?
- Wie verhindern Sie Side-Channel-, Escape- und Privilege-Escalation-Risiken in VMs und Containern?
- Welche Admin-Rollen können Mandantengrenzen überschreiten?
- Wie schnell können Sie kritische Kundendaten aus einem Drittanbieter-Dienst herausziehen?
- Wo liegen die Schlüssel?
- Wer kontrolliert die Orchestrierungs- und Management-Plane?
- Wann wurde der Exit zuletzt unter realistischen Bedingungen getestet?
Dann kippt das Template.
Der eigentliche Wettbewerbsnachteil liegt im Flickenteppich: historisch gewachsene RZ-Strukturen, Legacy-Altlasten, mehrere Virtualisierungsschichten, verschiedene Backup-Systeme, uneinheitliche Kundenverträge, Subdienstleister ohne belastbare Exit-Zusagen. Dazu Ressourcenmangel im Betrieb.
Das Ergebnis: Sie haben Dokumentation. Aber keinen belastbaren Nachweis.
Für NIS2 Cloud brauchen Sie keine Enterprise-Show. Sie brauchen eine prüfbare, technische und rechtliche Beweiskette:
- Risiko → Maßnahme → Verantwortlicher → technischer Nachweis → Test → Management-Freigabe.
Ohne diese Klarheit entstehen zusätzliche technische und organisatorische Risiken.
Schritte zu einer prüffähigen Sicherheits- und Exit-Strategie
Ziehen Sie eine harte Perimeter-Landkarte für physisch und logisch: Erfassen Sie nicht nur Gebäude, Räume, Racks und Zutrittszonen. Erfassen Sie auch Management-Netze, Hypervisor-Cluster, Kubernetes-Namespaces, Storage-Tenants, Backup-Domänen, IAM-Rollen, Secrets, Schlüsselverwaltung und Admin-Jump-Hosts. Markieren Sie jede Stelle, an der ein Mandant, Dienstleister oder Administrator Tenant-Grenzen überschreiten kann. Genau dort sitzt Ihr NIS2-Risiko.
Bauen Sie Ihre Exit-Strategie als operatives Runbook, nicht als PDF-Friedhof: Definieren Sie pro kritischem Drittanbieter den Exit-Auslöser, die maximale Toleranzzeit, die Datenexporte, Zielplattformen, Verantwortlichen, Kommunikationswege, Vertragsrechte und technischen Abhängigkeiten. Prüfen Sie insbesondere Cloud-Backups, Identity Provider, DNS, Monitoring, Ticketing, Key Management, Object Storage und Container Registries. Wenn Sie nicht wissen, wie Sie diese Dienste bei Ausfall kompensieren, haben Sie keine Exit-Strategie. Sie haben Hoffnung.
Härten Sie die Ausführungsumgebung nachweisbar: Dokumentieren und prüfen Sie Hypervisor-Härtung, VM-Isolation, Container-Runtime-Security, Image-Scanning, Patch-Zyklen, Secrets-Handling, Netzwerksegmentierung, Admission Controls, Logging und privilegierte Zugriffe. Legen Sie technische Evidenzen ab: Konfigurationsexporte, Scan-Ergebnisse, Testprotokolle, SIEM-Regeln, Change-Tickets, Notfallübungen. Der Prüfer will keine Absichtserklärung. Er will Belege.
Checkliste: NIS2 für Rechenzentren und Cloud-Anbieter
Die Checkliste gibt einen strukturierten Überblick, welche Prüfpunkte für RZ-Betreiber und Cloud-Provider im NIS2-Kontext relevant sind – von Tenant-Isolation und Exit-Strategie über Ausführungsumgebungs-Härtung bis zur Nachweisführung gegenüber Audit und Kundschaft. Sie dient der internen Orientierung und ersetzt keine technische oder rechtliche Fachberatung.