NIS2 für Rechenzentren und Cloud-Anbieter

Warum Rechenzentren und Cloud-Anbieter unter NIS2 fallen

Rechenzentren sind die physische Grundlage der digitalen Wirtschaft. Wenn ein Rechenzentrum ausfällt, sind die Auswirkungen nicht auf ein einzelnes Unternehmen beschränkt, sondern betreffen potenziell Hunderte oder Tausende von Kunden, deren Anwendungen, Daten und Geschäftsprozesse in diesem Rechenzentrum laufen. Ein einziger Brand in einem Rechenzentrum von OVHcloud in Straßburg im März 2021 legte 3,6 Millionen Websites lahm und vernichtete Daten von Tausenden Kunden, die kein Offsite-Backup hatten.

Der europäische Gesetzgeber hat Rechenzentren und Cloud-Computing-Dienste deshalb in Anhang I der NIS2-Richtlinie als Teil des Sektors "Digitale Infrastruktur" aufgenommen. Das bedeutet: Betroffene Unternehmen gelten als wesentliche Einrichtungen und unterliegen den strengsten Anforderungen, die NIS2 vorsieht.

Konkret betroffen sind:

• Rechenzentrumsbetreiber: Unternehmen, die Rechenzentren betreiben und Colocation-Dienste anbieten (Serverhousing, Cage, Suite)
• Cloud-Computing-Anbieter: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS), soweit sie die Schwellenwerte überschreiten
• Managed-Hosting-Anbieter: Unternehmen, die dedizierte Server oder Managed-Server-Umgebungen bereitstellen
• Content-Delivery-Network-Anbieter (CDN): Werden in Anhang I separat aufgeführt

Die NIS2-Richtlinie definiert den Anwendungsbereich über den Unternehmenssitz in der EU: Wer seinen Hauptsitz oder eine relevante Niederlassung in einem EU-Mitgliedstaat hat und die Schwellenwerte überschreitet (50 Mitarbeiter oder 10 Mio. Euro Umsatz), ist betroffen. Für Cloud-Anbieter, die grenzüberschreitend tätig sind, gilt das Prinzip des Hauptsitzes: Die Aufsichtsbehörde am Hauptsitz ist zuständig.

Wesentliche Einrichtung: Die strengsten Auflagen

Als wesentliche Einrichtungen unterliegen Rechenzentren und Cloud-Anbieter der schärfsten Regulierungsstufe unter NIS2:

Die proaktive Aufsicht bedeutet in der Praxis: Das BSI kann ohne konkreten Anlass Nachweise über die Umsetzung der Sicherheitsmaßnahmen anfordern, Audits durchführen lassen und bei Mängeln Anordnungen erlassen. Für Rechenzentrumsbetreiber, die es gewohnt sind, ihre Sicherheitsmaßnahmen gegenüber Kunden nachzuweisen (ISO 27001, SOC 2), ist das kein völlig neues Konzept, aber die Verbindlichkeit und die Sanktionsmöglichkeiten gehen über das hinaus, was private Zertifizierungen verlangen.

Die besondere Rolle der Rechenzentren: Multiplikator-Risiko

Rechenzentren unterscheiden sich von den meisten anderen NIS2-regulierten Sektoren durch ein fundamentales Merkmal: Ihre Sicherheitslücken wirken sich nicht nur auf das eigene Unternehmen aus, sondern potenziell auf alle Kunden, deren Infrastruktur im Rechenzentrum betrieben wird.

Die Doppelverantwortung

Rechenzentrumsbetreiber und Cloud-Anbieter tragen eine Doppelverantwortung:

1. Eigene NIS2-Compliance: Sie müssen als regulierte Einrichtung selbst alle NIS2-Anforderungen erfüllen.
2. Kundenbefähigung: Viele ihrer Kunden sind ebenfalls NIS2-pflichtig und benötigen nachweisbare Sicherheitsgarantien, um ihre eigene Compliance zu gewährleisten. Wenn der Cloud-Anbieter eines NIS2-pflichtigen Unternehmens keine ausreichenden Sicherheitsnachweise liefern kann, hat der Kunde ein Problem bei seiner Supply-Chain-Bewertung.

Diese Doppelverantwortung macht Sicherheitsnachweise zum Wettbewerbsfaktor. Rechenzentrumsbetreiber, die ISO 27001, BSI C5 oder SOC 2 vorweisen können, haben einen klaren Vorteil gegenüber Wettbewerbern, die keine Zertifizierung haben.

BSI C5: Der deutsche Cloud-Sicherheitsstandard

Der Cloud Computing Compliance Criteria Catalogue (C5) des BSI ist der maßgebliche Sicherheitsstandard für Cloud-Dienste in Deutschland. Er wurde 2016 eingeführt und 2020 umfassend überarbeitet. C5 definiert Mindestanforderungen an die Informationssicherheit von Cloud-Diensten und basiert auf international anerkannten Standards (ISO 27001, SOC 2, CSA CCM).

Für Cloud-Anbieter, die Kunden im öffentlichen Sektor oder in regulierten Branchen bedienen, ist ein C5-Testat faktisch verpflichtend. Die Bundesverwaltung darf Cloud-Dienste nur nutzen, wenn ein C5-Testat vorliegt. Und mit NIS2 wird die Bedeutung von C5 weiter steigen, weil NIS2-pflichtige Unternehmen von ihren Cloud-Anbietern nachweisbare Sicherheitsmaßnahmen verlangen werden.

C5 unterscheidet zwei Testat-Stufen:

• Typ 1: Bestätigung, dass die Sicherheitsmaßnahmen zum Prüfungszeitpunkt angemessen gestaltet sind
• Typ 2: Bestätigung, dass die Maßnahmen über einen Prüfungszeitraum (typischerweise 6-12 Monate) wirksam umgesetzt waren

Ein Typ-2-Testat ist der Goldstandard. Es zeigt nicht nur, dass du ein Sicherheitskonzept hast, sondern dass du es tatsächlich lebst.

Branchenspezifische Anforderungen

Physische Sicherheit: Der Grundpfeiler

Für Rechenzentren beginnt IT-Sicherheit mit physischer Sicherheit. Ein Angreifer, der physischen Zugang zur Hardware hat, kann alle logischen Sicherheitsmaßnahmen umgehen. Die physische Sicherheit umfasst:

Zutrittskontrolle:

• Mehrzonenkonzept: Außenbereich, Empfang, Technikbereich, Rechnerraum, Cage/Suite
• Zutrittskontrollsystem mit individuellen Berechtigungen pro Zone
• Mehrstufige Authentifizierung für kritische Bereiche (Chipkarte + PIN, biometrisch)
• Besucherbegleitung: Kein unbegleiteter Zugang für Externe
• Lückenlose Protokollierung aller Zutritte
• Vereinzelungsanlagen (Schleusen, Drehkreuze) zur Verhinderung von Tailgating

Videoüberwachung:

• Lückenlose Kameraerfassung aller Zugangspunkte und Technikbereiche
• Aufzeichnung mit ausreichender Vorhaltezeit (mindestens 30 Tage)
• Alarmierung bei ungewöhnlichen Aktivitäten (Bewegung in gesperrten Bereichen)

Perimeterschutz:

• Zaun, Beleuchtung, Bewegungsmelder
• Zufahrtskontrolle für Lieferfahrzeuge und Besucher
• Schutz gegen Fahrzeugangriffe (Poller, Barrieren) bei hochsicheren Standorten

Energieversorgung und Klimatisierung

Ein Rechenzentrum ist so verfügbar wie seine Energieversorgung und Kühlung. Die NIS2-Risikoanalyse muss diese Infrastruktur vollständig erfassen.

Redundante Energieversorgung:

• Zwei unabhängige Stromzuführungen (A/B-Versorgung) von verschiedenen Umspannwerken
• USV-Anlagen (Unterbrechungsfreie Stromversorgung) für die Überbrückung von Sekunden bis Minuten
• Netzersatzanlage (Dieselgeneratoren) für Ausfälle von Stunden bis Tagen
• Brennstoffvorrat für mindestens 48 Stunden Volllastbetrieb
• Automatische Umschaltung zwischen den Versorgungspfaden

Klimatisierung:

• Redundante Klimaanlagen (N+1 oder 2N)
• Monitoring der Raumtemperatur und Luftfeuchtigkeit in allen Rechnerräumen
• Automatische Alarmierung bei Überschreitung von Grenzwerten
• Notfallprozedur bei Totalausfall der Klimatisierung (kontrolliertes Herunterfahren)

Brandschutz:

• Brandfrühesterkennung (VESDA oder vergleichbar)
• Gaslöschanlage (typischerweise Novec oder Inergen) statt Wasser
• Brandabschnitte: Rechnerräume als eigene Brandabschnitte mit entsprechender Bauweise
• Integration ins Gebäudeleitsystem: Automatische Alarmierung und Notabschaltung

Mandantentrennung: Isolation ist kein Feature, sondern Pflicht

In Colocation-Rechenzentren und Cloud-Umgebungen teilen sich mehrere Kunden die physische Infrastruktur. Die Mandantentrennung stellt sicher, dass ein Kunde nicht auf Daten oder Systeme eines anderen Kunden zugreifen kann und dass ein Sicherheitsvorfall bei einem Kunden die anderen Kunden nicht beeinträchtigt.

Physische Mandantentrennung (Colocation):

• Cages (abgeschlossene Gitterbereiche) oder Suites (eigene Räume) für Kunden
• Eigene Zutrittskontrolle pro Cage/Suite
• Getrennte Stromkreise (auf Wunsch)
• Klare Kennzeichnung und Dokumentation, welche Hardware zu welchem Kunden gehört

Logische Mandantentrennung (Cloud/Managed Hosting):

• Netzwerksegmentierung: VLANs, VRFs oder SDN-basierte Isolation
• Hypervisor-Isolation: Kein Zugriff zwischen virtuellen Maschinen verschiedener Kunden
• Storage-Isolation: Getrennte Storage-Pools oder verschlüsselte Volumes mit kundenindividuellen Schlüsseln
• Management-Isolation: Getrennte Administrationszugänge, kein Zugriff des Providers auf Kundendaten ohne explizite Genehmigung

SLA-Management: Sicherheit vertraglich verankern

Rechenzentren und Cloud-Anbieter definieren ihre Leistungen über Service Level Agreements (SLAs). Unter NIS2 müssen diese SLAs auch Sicherheitsaspekte abdecken, und zwar in beide Richtungen: gegenüber den eigenen Kunden und gegenüber den eigenen Lieferanten.

SLA-Anforderungen gegenüber Kunden:

• Verfügbarkeitsgarantien (typischerweise 99,9 % bis 99,999 %)
• Reaktionszeiten bei Sicherheitsvorfällen: Wann wird der Kunde informiert?
• Transparenz über Sicherheitsmaßnahmen: Welche Informationen erhält der Kunde über die implementierten Maßnahmen?
• Unterstützung bei Audits: Kann der Kunde eigene Audits durchführen oder Testate einsehen?
• Datenherausgabe und -löschung: Wie werden Kundendaten am Ende des Vertrags übergeben und sicher gelöscht?

SLA-Anforderungen gegenüber Lieferanten:

• Energieversorger: Verfügbarkeitsgarantien, Wartungsvorankündigung
• Netzwerkanbieter (Carrier): Redundante Anbindung, Reaktionszeiten bei Störungen
• Hardware-Lieferanten: Ersatzteilversorgung, Reaktionszeiten bei Defekten
• Wartungsdienstleister: Sicherheitsanforderungen für Personal, das Zutritt zum Rechenzentrum hat

NIS2-Maßnahmen für Rechenzentren

Risikoanalyse: IT, physische Infrastruktur und Kundenverantwortung

Die Risikoanalyse eines Rechenzentrums ist umfassender als die eines Unternehmens, das nur seine eigene IT schützen muss. Sie muss drei Ebenen abdecken:

1. IT-Infrastruktur: Server, Netzwerk, Storage, Virtualisierung, Management-Systeme
2. Physische Infrastruktur: Gebäude, Energieversorgung, Klimatisierung, Zutrittskontrolle, Brandschutz
3. Service-Ebene: Auswirkungen eines Vorfalls auf die Kunden, vertragliche Verpflichtungen, Reputationsrisiko

Netzwerksicherheit: Mehrschichtige Verteidigung

Die Netzwerksicherheit in einem Rechenzentrum muss mehrere Schutzschichten umfassen:

• Perimeter-Sicherheit: DDoS-Mitigation (on-premise oder als Service), Border-Firewalls, IDS/IPS
• Kundennetz-Isolation: Strikte Trennung der Kundennetze untereinander, kein Cross-Connect ohne explizite Genehmigung
• Management-Netz: Physisch oder logisch getrenntes Netzwerk für die Verwaltung der Infrastruktur (IPMI, iLO, iDRAC, Switch-Management). Dieses Netz darf niemals über das Internet erreichbar sein.
• Backbone-Sicherheit: Redundante Uplinks zu verschiedenen Carriern, verschlüsselte Inter-Site-Verbindungen

Incident Response: Kundenkommunikation als Kernprozess

Der Incident-Response-Plan eines Rechenzentrums unterscheidet sich von dem anderer Unternehmen dadurch, dass die Kundenkommunikation ein zentraler Bestandteil ist. Wenn ein Sicherheitsvorfall die Infrastruktur betrifft, auf der Hunderte Kunden laufen, muss die Kommunikation schnell, transparent und koordiniert erfolgen.

Elemente des Incident-Response-Plans:

• Klassifikation nach Kundenauswirkung: Ein Vorfall, der nur interne Systeme betrifft, wird anders behandelt als ein Vorfall, der Kundensysteme beeinträchtigt.
• Kundenkommunikation: Vordefinierte Kommunikationswege und -vorlagen. Wer informiert die Kunden? Über welchen Kanal (Status-Seite, E-Mail, Telefon)? Welche Informationen werden geteilt und welche nicht (Forensik-Schutz)?
• Parallele Meldepflichten: BSI-Meldung (24h für NIS2) und gleichzeitig Kundenbenachrichtigung. Die NIS2-Meldung und die Kundeninformation haben unterschiedliche Inhalte und Zielgruppen.
• Post-Incident-Report: Ein detaillierter Bericht nach Abschluss des Vorfalls, den Kunden auf Anfrage erhalten können. Transparenz stärkt das Vertrauen.

Change Management: Jede Änderung ist ein Risiko

In einem Rechenzentrum, das Hunderte Kunden bedient, kann jede Konfigurationsänderung unbeabsichtigte Auswirkungen haben. Ein Change-Management-Prozess ist nicht nur eine NIS2-Anforderung, sondern eine betriebliche Notwendigkeit.

• Klassifikation: Standard-Changes (vorgeprüft, geringes Risiko), Normal-Changes (individuelle Prüfung), Emergency-Changes (beschleunigtes Verfahren bei Sicherheitsvorfällen)
• Genehmigung: Jeder Normal-Change wird vor der Umsetzung geprüft und genehmigt. Wer darf Changes genehmigen? Welche Informationen müssen vorliegen?
• Wartungsfenster: Geplante Changes werden in definierten Wartungsfenstern durchgeführt. Kunden werden vorab informiert.
• Rollback-Plan: Für jeden Change muss ein dokumentierter Rollback-Plan existieren, um bei Problemen schnell zum Ausgangszustand zurückkehren zu können.

Praxisbeispiel: Colocation-Anbieter mit 75 Mitarbeitern

Ausgangslage:

Die DataCenter Süd GmbH (fiktives Beispiel) ist ein Colocation-Anbieter mit Sitz in Bayern. 75 Mitarbeiter, 22 Millionen Euro Jahresumsatz. Das Unternehmen betreibt zwei Rechenzentren (Tier III Design) in der Region und bietet Colocation (Rack, Cage, Suite), Managed Hosting, Connectivity und Cloud-Dienste (IaaS) an. 180 Kunden aus verschiedenen Branchen nutzen die Infrastruktur, darunter Finanzdienstleister, Gesundheitsunternehmen und Industriebetriebe.

DataCenter Süd ist bereits nach ISO 27001 zertifiziert. Der Geltungsbereich umfasst den Betrieb der Rechenzentren und die Managed-Hosting-Dienste. Ein BSI-C5-Testat liegt nicht vor. SOC 2 Typ 1 wurde im Vorjahr erstmals erstellt.

Die Infrastruktur:

• Rechenzentrum 1: 800 Racks, 3 MW IT-Last, 2N-Energieversorgung, redundante Klimatisierung, Gaslöschanlage
• Rechenzentrum 2: 400 Racks, 1,5 MW IT-Last, N+1-Energieversorgung, redundante Klimatisierung
• Netzwerk: Carrier-neutral, 6 Carrier angebunden, redundante Dark-Fiber-Verbindung zwischen den Standorten, eigenes AS (Autonomous System) mit BGP-Peerings
• Cloud-Plattform: VMware-basierte IaaS-Plattform (120 Hosts, 3 vSAN-Cluster), Self-Service-Portal für Kunden
• Management-Systeme: DCIM (Data Center Infrastructure Management), Monitoring (Zabbix), Ticketsystem (JIRA Service Management), Zutrittskontrollsystem, Videoüberwachung
• Personal: 8 Personen im Rechenzentrumsbetrieb (24/7-Bereitschaft), 12 Personen im Netzwerk- und Systembetrieb, 6 Personen im Cloud-Team, 3 Personen im Security-Team, Rest Verwaltung und Vertrieb

Phase 1: Lückenanalyse (Monat 1-2)

DataCenter Süd hat durch die ISO-27001-Zertifizierung bereits ein funktionierendes ISMS. Die Aufgabe ist keine Neueinführung, sondern eine Lückenanalyse: Wo erfüllt das bestehende ISMS die NIS2-Anforderungen, und wo gibt es Handlungsbedarf?

NIS2-Einstufung: Digitale Infrastruktur, Anhang I. Einstufung: wesentliche Einrichtung. Das bedeutet proaktive BSI-Aufsicht und die höchste Bußgeldstufe.

Identifizierte Lücken:

1. Meldeprozess: Das bestehende ISMS hat einen Incident-Response-Plan, aber keinen formalen BSI-Meldeprozess mit 24-Stunden-Frist. Die bisherige Praxis war die freiwillige Meldung schwerer Vorfälle, nicht die verpflichtende Meldung mit definierten Fristen.

2. Geschäftsführungsverantwortung: Die Geschäftsführung unterstützt das ISMS, ist aber nicht formal in die Risikogenehmigung und Schulungspflichten eingebunden, wie NIS2 es fordert.

3. Supply-Chain-Bewertung: Die Lieferantenbewertung im bestehenden ISMS konzentriert sich auf Verfügbarkeit (Carrier, Energieversorger, Hardware). Eine systematische Bewertung der Cybersicherheit aller kritischen Lieferanten fehlt.

4. Cloud-Plattform-Sicherheit: Die ISO-27001-Zertifizierung umfasst den Colocation- und Managed-Hosting-Betrieb, aber die Cloud-Plattform (IaaS) ist nicht vollständig im Scope. Mandantentrennung, Hypervisor-Sicherheit und Self-Service-Portal-Härtung müssen formalisiert werden.

5. BSI C5: Viele NIS2-pflichtige Kunden werden ein C5-Testat verlangen. Der Aufwand für ein C5-Testat Typ 2 muss eingeplant werden, auch wenn es nicht direkt eine NIS2-Pflicht ist.

Phase 2: Umsetzung der Lücken (Monat 3-8)

Meldeprozess implementieren (Monat 3):

• Meldeprozess mit klaren Zuständigkeiten definiert gemäß den NIS2-Meldefristen: Der Security-Team-Leiter ist primärer Melder, der CTO ist Vertreter
• Vorlagen für alle drei Meldestufen (24h, 72h, 1 Monat) erstellt
• 24/7-Erreichbarkeit sichergestellt: Der Bereitschaftsdienst des Rechenzentrums kann die Erstmeldung auslösen, wenn der Security-Team-Leiter nicht erreichbar ist
• Kriterien für meldepflichtige Vorfälle definiert (mit Unterscheidung: Vorfall betrifft nur interne Systeme vs. Vorfall betrifft Kundeninfrastruktur)

Geschäftsführungseinbindung (Monat 3-4):

• Cybersicherheitsschulung für die Geschäftsführung durchgeführt
• Formaler Genehmigungsprozess für die Risikoakzeptanz implementiert
• Quartalsweise Berichterstattung an die Geschäftsführung über den Stand der Informationssicherheit etabliert

Cloud-Plattform in den ISMS-Scope aufnehmen (Monat 4-6):

• Risikoanalyse für die VMware-basierte IaaS-Plattform durchgeführt – ISMS Lite ermöglicht dabei die systematische Erfassung aller Cloud-Assets mit ihrer jeweiligen Mandantentrennung und den zugehörigen Risikobewertungen
• Mandantentrennung formalisiert und dokumentiert:
  • Netzwerk-Isolation über NSX-basierte Microsegmentation
  • Storage-Isolation über vSAN-Policies
  • Management-Zugriff: Kein Provider-Mitarbeiter hat Zugriff auf Kunden-VMs ohne explizites Ticket und vier-Augen-Prinzip
• Self-Service-Portal gehärtet: MFA für alle Kunden-Accounts, API-Rate-Limiting, Audit-Logging

Supply-Chain-Bewertung (Monat 5-7):

Systematische Bewertung der 15 kritischsten Lieferanten:

Technische Härtung (Monat 6-8):

• Management-Netzwerk-Segmentierung verschärft: Eigenes physisches Netz für IPMI/iLO/iDRAC, kein Routing zum Kunden- oder Internet-Netz
• DDoS-Mitigation: Erweiterung des bestehenden Schutzes um automatische Erkennung und Mitigation auf Layer 3/4 und Layer 7
• Monitoring-Erweiterung: Anomalieerkennung für Netzwerkverkehr zwischen Kunden-Segmenten (Erkennung von lateraler Bewegung)
• Backup der Management-Systeme: DCIM, Zutrittskontrolle und Videoüberwachung erhalten ein Offsite-Backup

Phase 3: Audit, Dokumentation, BSI-Registrierung (Monat 9-12)

Internes Audit (Monat 9-10):

Das interne Audit prüft sowohl die bestehenden ISO-27001-Kontrollen als auch die neu implementierten NIS2-Maßnahmen.

Feststellungen:

1. Die Zutrittsprotokolle von Rechenzentrum 2 werden nur 14 Tage aufbewahrt. Korrekturmaßnahme: Retention auf 90 Tage erhöhen (Empfehlung C5).
2. Drei Kunden-Cages in Rechenzentrum 1 haben keine eigene Zutrittskontrolle, sondern werden über einen gemeinsamen Raumzugang betreten. Korrekturmaßnahme: Nachträgliche Installation von Cage-Zutrittskontrollsystemen.
3. Der Rollback-Plan für VMware-Updates ist nicht dokumentiert. Korrekturmaßnahme: Rollback-Prozedur für alle kritischen Infrastruktur-Komponenten formalisieren.

BSI-Registrierung (Monat 11):

DataCenter Süd registriert sich beim BSI als wesentliche Einrichtung im Sektor Digitale Infrastruktur. Die Registrierung umfasst Unternehmensdaten, Kontaktstelle für Sicherheitsvorfälle und eine Beschreibung der erbrachten Dienste.

C5-Vorbereitung (Monat 10-12):

Parallel zur NIS2-Umsetzung beginnt die Vorbereitung auf das BSI-C5-Testat. Viele NIS2-Maßnahmen decken sich mit C5-Anforderungen, sodass der Zusatzaufwand beherrschbar ist. Die C5-Prüfung (Typ 1) wird für das erste Quartal des Folgejahres angesetzt.

Management-Review: Die Geschäftsführung genehmigt den Restrisiko-Katalog, das Budget für das Folgejahr (Schwerpunkt: C5-Testat, Ausbau DDoS-Protection) und den Audit-Plan.

Budget-Übersicht

Das Budget liegt höher als bei vielen anderen Sektoren, weil Rechenzentren als wesentliche Einrichtungen den höchsten Anforderungen unterliegen und weil das BSI-C5-Testat einen erheblichen Prüfungsaufwand verursacht. Der Großteil der laufenden Kosten entfällt auf das jährliche C5-Testat, das allerdings auch einen direkten geschäftlichen Nutzen hat, weil es die Kundenbindung stärkt und in Ausschreibungen zunehmend gefordert wird. Bei den ISMS-Tool-Kosten lässt sich dagegen sparen: ISMS Lite deckt alle Module 500 Euro pro Jahr ab, ohne Seat-Lizenzen oder versteckte Kosten.

Was du jetzt tun solltest

Wenn du ein Rechenzentrum oder einen Cloud-Dienst betreibst und NIS2 umsetzen musst, sind folgende Schritte sinnvoll:

1. Bestehende Zertifizierungen als Grundlage nutzen. Wenn du bereits ISO 27001, SOC 2 oder andere Zertifizierungen hast, bist du in einer guten Ausgangsposition. Führe eine Lückenanalyse durch, statt von vorne zu beginnen.

2. BSI-C5-Testat prüfen. Auch wenn C5 keine direkte NIS2-Pflicht ist, wird es für viele Kunden zum Entscheidungskriterium. Plane die C5-Vorbereitung parallel zur NIS2-Umsetzung.

3. Kundenkommunikation für Sicherheitsvorfälle vorbereiten. Dein Incident-Response-Plan muss die Kundenkommunikation als Kernprozess enthalten. Vordefinierte Vorlagen, klare Kommunikationswege und Transparenz sind entscheidend.

4. Cloud-Plattform in den ISMS-Scope aufnehmen. Wenn dein ISMS bislang nur den Colocation-Betrieb abdeckt, muss die Cloud-Plattform vollständig integriert werden: Mandantentrennung, Hypervisor-Sicherheit, Self-Service-Portal.

Rechenzentren und Cloud-Anbieter tragen unter NIS2 eine besondere Verantwortung, weil sie die Infrastruktur bereitstellen, auf der die digitale Wirtschaft läuft. Die proaktive BSI-Aufsicht und die hohen Bußgelder spiegeln diese Verantwortung wider. Gleichzeitig bietet NIS2 die Chance, Sicherheit noch stärker als Wettbewerbsvorteil zu positionieren: Wer nachweisbar sicher ist, gewinnt das Vertrauen der Kunden, die selbst unter Compliance-Druck stehen.

Weiterführende Artikel

• NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist
• NIS2 für IT-Dienstleister und MSPs: Doppelrolle als Betroffener und Berater
• Self-hosted vs. Cloud: Was bedeutet das für deine Compliance?
• NIS2-Meldefristen im Überblick: 24h, 72h, 1 Monat - was wann fällig ist
• Netzwerksegmentierung im Mittelstand: Praxisleitfaden für KMU