NIS2 und Datensouveränität: Was die Richtlinie über die Kontrolle deiner Daten sagt

TL;DR

NIS2 Art. 21 Abs. 2 lit. d fordert explizit die Sicherheit der Lieferkette, einschließlich der Sicherheit zwischen der Einrichtung und ihren Dienstleistern.
Deine ISMS-Software ist ein kritischer Dienstleister. Wird der SaaS-Anbieter gehackt, bist du meldepflichtig, wenn der Vorfall erhebliche Auswirkungen auf deine Dienste hat.
Das BSI empfiehlt, bei der Auswahl von Cloud-Diensten die Datensouveränität und die Rechtsordnung des Anbieters in die Risikobewertung einzubeziehen.
Self-Hosted-Lösungen reduzieren die Angriffsfläche in der Lieferkette und vereinfachen die NIS2-Nachweispflichten zur Datenhaltung.
Datenhaltung ist kein reines Datenschutzthema. NIS2 macht sie zu einem Bestandteil der Risikobewertung für die Cybersicherheit.

Was NIS2 mit der Kontrolle über deine Daten zu tun hat

Die NIS2-Richtlinie wird in den meisten Artikeln als Cybersicherheits-Regulierung beschrieben, und das ist sie auch. Aber wer nur an Firewalls, Patch-Management und Incident Response denkt, übersieht einen wesentlichen Aspekt: NIS2 stellt indirekte, aber weitreichende Anforderungen an die Kontrolle über deine Daten und die Sicherheit deiner Lieferkette, also auch an die Frage, wo und bei wem deine Compliance-Daten liegen.

Dieser Artikel zeigt dir, wo NIS2 die Datensouveränität berührt, was die Richtlinie konkret für die Auswahl deiner Tools bedeutet und warum die Datenhaltung deines ISMS selbst Teil deiner Risikobewertung sein sollte.

Art. 21: Das Fundament der NIS2-Sicherheitsanforderungen

Artikel 21 der NIS2-Richtlinie definiert die Risikomanagementmaßnahmen, die betroffene Einrichtungen umsetzen müssen. Die Liste in Absatz 2 liest sich wie ein Best-of der Informationssicherheit:

Risikoanalyse und Sicherheitskonzepte
Bewältigung von Sicherheitsvorfällen
Aufrechterhaltung des Betriebs und Krisenmanagement
Sicherheit der Lieferkette (lit. d)
Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen
Bewertung der Wirksamkeit der Maßnahmen
Cyberhygiene und Schulungen
Kryptografie und Verschlüsselung
Personalsicherheit und Zugangskontrollen
Multi-Faktor-Authentifizierung

Für die Datensouveränität ist besonders lit. d relevant: die Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern.

Was "Lieferkette" im Kontext von ISMS-Software bedeutet

Wenn du eine Cloud-basierte ISMS-Lösung nutzt, ist dieser Anbieter Teil deiner Lieferkette. Er verarbeitet und speichert Daten, die direkt mit deiner Cybersicherheit zusammenhängen. Aus NIS2-Perspektive ist das nicht irgendein Dienstleister, sondern einer, dessen Kompromittierung unmittelbare Auswirkungen auf dein Sicherheitsniveau haben kann.

Art. 21 Abs. 2 lit. d verlangt, dass du die Risiken in deiner Lieferkette berücksichtigst. Das bedeutet konkret:

Du musst bewerten, welche Risiken von deinen Dienstleistern ausgehen.
Du musst Sicherheitsanforderungen an deine Dienstleister stellen und deren Einhaltung überwachen.
Du musst die Auswirkungen einer Kompromittierung des Dienstleisters auf deine eigene Sicherheit einschätzen.

Für einen SaaS-Anbieter, der dein Risikoregister, deinen Maßnahmenstatus und deine Incident-Daten hostet, sind diese Anforderungen besonders relevant. Die Lieferantenbewertung dieses Anbieters sollte deutlich gründlicher ausfallen als bei einem normalen Cloud-Dienst.

Datenhaltung als Teil der Risikobewertung

NIS2 fordert in Art. 21 Abs. 1 einen "gefahrenübergreifenden Ansatz" für die Risikoanalyse. Das heißt: Du musst nicht nur technische Bedrohungen betrachten (Malware, DDoS, Phishing), sondern alle Faktoren, die die Sicherheit deiner Netz- und Informationssysteme beeinträchtigen können.

Die Datenhaltung ist ein solcher Faktor. Wo deine Daten liegen, bestimmt:

Welcher Rechtsordnung sie unterliegen: Daten auf Servern eines US-Unternehmens können dem CLOUD Act unterliegen, unabhängig vom physischen Standort des Servers.
Wer technisch Zugriff hat: Der Hosting-Provider, der SaaS-Anbieter und deren Subauftragnehmer haben potenziell Zugang zu deinen Daten.
Wie schnell du bei einem Vorfall reagieren kannst: Wenn der SaaS-Anbieter kompromittiert wird, hängt deine Reaktionsfähigkeit davon ab, wie transparent und schnell der Anbieter kommuniziert.
Ob du die Daten im Notfall migrieren kannst: Vendor Lock-in bei einer ISMS-Lösung ist ein operatives Risiko, das in die Risikobewertung gehört.

Praktische Risikobewertung der Datenhaltung

Für die Risikobewertung deiner ISMS-Datenhaltung kannst du folgende Fragen als Ausgangspunkt verwenden:

Risikofaktor	Frage	Relevanz
Rechtsordnung	Unter welchem Recht werden meine Daten gespeichert?	Hoch
Zugriffskontrolle	Wer hat beim Anbieter technisch Zugriff auf meine Daten?	Hoch
Transparenz	Werde ich bei Sicherheitsvorfällen des Anbieters zeitnah informiert?	Hoch
Datenportabilität	Kann ich meine Daten jederzeit vollständig exportieren?	Mittel
Subauftragnehmer	Nutzt der Anbieter Subauftragnehmer für Hosting oder Betrieb?	Mittel
Verschlüsselung	Sind meine Daten at rest und in transit verschlüsselt?	Hoch
Schlüsselmanagement	Wer kontrolliert die Verschlüsselungsschlüssel?	Mittel
Insolvenzrisiko	Was passiert mit meinen Daten, wenn der Anbieter insolvent wird?	Niedrig

Diese Bewertung gehört ins Risikoregister und sollte regelmäßig aktualisiert werden, insbesondere wenn der Anbieter seine Infrastruktur, AGB oder Subauftragnehmer ändert.

Meldepflichten: Was wenn der SaaS-Anbieter gehackt wird?

Einer der am meisten unterschätzten Aspekte von NIS2 ist die Meldepflicht bei Vorfällen, die über Dienstleister eintreten. Die NIS2-Meldefristen gelten nicht nur für direkte Angriffe auf deine eigenen Systeme, sondern auch für Vorfälle, die erhebliche Auswirkungen auf die Erbringung deiner Dienste haben.

Das Szenario: Dein ISMS-Anbieter wird kompromittiert

Nehmen wir an, der Cloud-Anbieter deiner ISMS-Software wird gehackt. Angreifer erbeuten Daten mehrerer Kunden, darunter deine Risikoregister, Maßnahmenpläne und Incident-Berichte. Was passiert jetzt?

Schritt 1: Der Anbieter muss dich informieren. Je nach vertraglicher Vereinbarung und den geltenden Datenschutzgesetzen muss der Anbieter seine Kunden über den Vorfall informieren. Aber wie schnell? In vielen AGB gibt es keine konkreten Fristen. Erfahrungsgemäß vergehen zwischen Entdeckung und Kundenbenachrichtigung oft Tage bis Wochen.

Schritt 2: Du musst bewerten, ob der Vorfall meldepflichtig ist. Nach NIS2 musst du innerhalb von 24 Stunden eine Frühwarnung und innerhalb von 72 Stunden eine ausführlichere Meldung an die zuständige Behörde abgeben, wenn der Vorfall "erhebliche Auswirkungen" auf die Erbringung deiner Dienste hat.

Und hier wird es kompliziert: Die 24-Stunden-Frist läuft ab dem Zeitpunkt, an dem du von dem Vorfall Kenntnis erlangst. Wenn der Anbieter dich erst nach drei Tagen informiert, hast du ab diesem Zeitpunkt 24 Stunden. Aber du hast keine Kontrolle darüber, wann du informiert wirst.

Schritt 3: Du musst den Vorfall intern bewerten. Welche deiner Daten sind betroffen? Welche Auswirkungen hat die Offenlegung deines Risikoregisters? Musst du zusätzlich eine DSGVO-Datenpanne melden, weil personenbezogene Daten betroffen sind? Enthielten die Incident-Berichte Informationen über Dritte?

Schritt 4: Du musst Maßnahmen ergreifen. Passwörter ändern, Zugänge prüfen, gegebenenfalls die ISMS-Software wechseln. Und du musst dokumentieren, was du getan hast.

Das fundamentale Problem

Bei einem SaaS-Vorfall bist du auf die Kommunikation und Kooperation des Anbieters angewiesen. Du kannst nicht selbst forensisch untersuchen, was passiert ist. Du kannst nicht selbst feststellen, welche Daten betroffen sind. Du musst dem Anbieter vertrauen, und zwar genau in dem Moment, in dem sein Vertrauenskapital am niedrigsten ist.

Bei einem Self-Hosted-ISMS entfällt diese Abhängigkeit. Du hast die vollständige Kontrolle über die Forensik, die Bewertung und die Kommunikation. Natürlich kann auch deine eigene Infrastruktur angegriffen werden, aber dann steuerst du den Prozess selbst, statt auf die E-Mail eines Drittanbieters zu warten.

In ISMS Lite ist der Meldeprozess für Sicherheitsvorfälle als Workflow abgebildet, von der Erstbewertung über die Frühwarnung bis zum Abschlussbericht. Weil die Daten lokal liegen, kannst du im Ernstfall sofort handeln, ohne auf externe Benachrichtigungen angewiesen zu sein.

BSI-Empfehlungen zur Datensouveränität

Das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat sich in mehreren Publikationen zur Datensouveränität geäußert, auch wenn es den Begriff nicht immer explizit verwendet.

BSI C5: Cloud Computing Compliance Criteria Catalogue

Der BSI C5-Kriterienkatalog definiert Anforderungen an Cloud-Anbieter in Bezug auf:

Transparenz über den Datenstandort: Der Anbieter muss offenlegen, in welchen Ländern und Rechenzentren Kundendaten verarbeitet und gespeichert werden.
Kontrolle über Subdienstleister: Der Anbieter muss dokumentieren, welche Subdienstleister eingesetzt werden und wo diese sitzen.
Datenportabilität: Kunden müssen ihre Daten in einem standardisierten Format exportieren können.
Löschung nach Vertragsende: Daten müssen nach Vertragsende nachweisbar gelöscht werden.

Wenn du einen Cloud-ISMS-Anbieter evaluierst, sollte eine C5-Attestierung oder zumindest die Beantwortung der C5-Kriterien Teil deiner Anforderungen sein.

BSI IT-Grundschutz und Datensouveränität

Im BSI IT-Grundschutz-Kompendium finden sich relevante Bausteine:

OPS.1.2.4 Telearbeit und OPS.1.2.5 Fernwartung: Regelungen zum Datenzugriff von außerhalb des Unternehmensnetzes.
OPS.2.2 Cloud-Nutzung: Anforderungen an die Auswahl und Nutzung von Cloud-Diensten, einschließlich Aspekte der Datensouveränität.
CON.1 Kryptokonzept: Anforderungen an die Verschlüsselung, die direkt die Frage beantworten, wer die Schlüssel kontrolliert.

Das BSI empfiehlt ausdrücklich, bei der Auswahl von Cloud-Diensten die "digitale Souveränität" als Kriterium zu berücksichtigen. Das bedeutet nicht, dass Cloud-Dienste grundsätzlich abzulehnen sind, aber dass die Risiken bewusst bewertet und gesteuert werden müssen.

Gaia-X und die europäische Perspektive

Auf europäischer Ebene verfolgt die Gaia-X-Initiative das Ziel, eine souveräne Dateninfrastruktur in Europa aufzubauen. Für die Praxis im Mittelstand ist Gaia-X noch wenig relevant, aber die politische Richtung ist klar: Europa will die Abhängigkeit von außereuropäischen Cloud-Anbietern reduzieren. NIS2 ist ein Baustein dieser Strategie.

Self-Hosted als Risikominimierung unter NIS2

Self-Hosted-Lösungen lösen nicht alle Probleme, aber sie vereinfachen die Einhaltung mehrerer NIS2-Anforderungen erheblich.

Lieferketten-Risiko minimieren

Jeder externe Dienstleister ist ein potenzielles Risiko in der Lieferkette. Bei einer Self-Hosted-ISMS-Lösung reduzierst du dieses Risiko auf den Software-Hersteller selbst (der die Software liefert, aber keinen Zugriff auf deine Daten hat) und deinen eigenen Hosting-Provider (den du selbst auswählst und kontrollierst).

Das ist ein wesentlicher Unterschied zu einer SaaS-Lösung, bei der der Anbieter gleichzeitig Softwarehersteller, Betreiber und Datenverarbeiter ist. Bei einer Self-Hosted-Lösung sind diese Rollen getrennt, was die Risikosteuerung erleichtert.

Konkret bedeutet das für die NIS2-Dokumentation: Statt einen komplexen Dienstleister mit mehreren Rollen zu bewerten, hast du zwei klar abgrenzbare Lieferantenbeziehungen. Der Software-Hersteller liefert Updates und Support, hat aber keinen Zugriff auf deine Produktivdaten. Der Hosting-Provider stellt Infrastruktur bereit, kennt aber die Anwendung nicht. Diese Trennung macht die Risikobewertung nach Art. 21 präziser und die Dokumentation für den Auditor nachvollziehbarer.

Und wenn du das ISMS auf eigener Hardware im eigenen Serverraum betreibst, entfällt der Hosting-Provider als Lieferant komplett. Die gesamte Kette liegt in deiner Hand.

Meldepflichten vereinfachen

Wenn dein ISMS auf deiner eigenen Infrastruktur läuft, hast du bei einem Vorfall die volle Kontrolle über die Bewertung und Meldung. Du musst nicht auf die Benachrichtigung eines Drittanbieters warten, sondern kannst sofort mit der Erstmeldung ans BSI beginnen. Die Forensik liegt in deiner Hand, die Datenauswertung ebenso.

Nachweispflichten erfüllen

NIS2 fordert, dass du die Wirksamkeit deiner Maßnahmen nachweisen kannst. Bei der Datenhaltung bedeutet das: Du musst dokumentieren können, wo deine Daten liegen, wer Zugriff hat und welche Schutzmaßnahmen greifen.

Bei einer Self-Hosted-Lösung kannst du diese Nachweise selbst erbringen. Du zeigst dem Auditor deinen Server, deine Firewall-Regeln, dein Backup-Konzept und deine Zugriffsprotokolle. Bei einer SaaS-Lösung verweist du auf die Zertifizierungen und Zusicherungen des Anbieters, was der Auditor je nach Prüfungstiefe akzeptiert oder auch nicht.

Ein konkretes Beispiel: Der Auditor fragt, wie die Verschlüsselung der ISMS-Daten umgesetzt ist. Bei Self-Hosted zeigst du die Festplattenverschlüsselung (LUKS), die TLS-Konfiguration des Webservers und die Backup-Verschlüsselung (AES-256). Du kontrollierst jeden Schlüssel. Bei einer SaaS-Lösung verweist du auf die Kryptografie-Richtlinie des Anbieters und hoffst, dass sie aktuell ist und der Realität entspricht. Der Unterschied in der Nachweistiefe ist erheblich.

Praktische Umsetzung

Die Entscheidung für Self-Hosted bedeutet nicht, dass du alles selbst bauen musst. Fertige Self-Hosted-ISMS-Lösungen wie ISMS Lite bieten dieselbe Funktionalität wie Cloud-Lösungen, laufen aber auf deiner Infrastruktur. Der Installationsaufwand liegt typischerweise bei wenigen Stunden, der laufende Betrieb erfordert die üblichen Administrationsaufgaben: Updates einspielen, Backups konfigurieren, Monitoring einrichten.

Für ein Unternehmen mit einer funktionierenden IT-Abteilung ist das kein wesentlicher Mehraufwand gegenüber der Verwaltung eines weiteren internen Systems. Der Gewinn an Datensouveränität und die Vereinfachung der NIS2-Nachweispflichten überwiegen in den meisten Fällen.

Checkliste: Datensouveränität unter NIS2

Anforderung	NIS2-Bezug	Maßnahme
Lieferketten-Bewertung der ISMS-Software	Art. 21 Abs. 2 lit. d	Anbieter als kritischen Dienstleister bewerten
Datenstandort dokumentieren	Art. 21 Abs. 1 (Risikoanalyse)	Physischen Standort und Rechtsordnung erfassen
Zugriffskontrolle beim Anbieter prüfen	Art. 21 Abs. 2 lit. i	Technische und organisatorische Zugriffskontrollen dokumentieren
Meldeprozess für SaaS-Vorfälle definieren	Art. 23 (Meldepflichten)	Vertragliche Benachrichtigungsfristen vereinbaren
Datenportabilität sicherstellen	Art. 21 Abs. 1 (Betriebskontinuität)	Export-Funktionalität testen, Migrationsszenario durchspielen
Verschlüsselung prüfen	Art. 21 Abs. 2 lit. h	At-rest und in-transit Verschlüsselung dokumentieren
Subdienstleister erfassen	Art. 21 Abs. 2 lit. d	Alle Subdienstleister des Anbieters identifizieren
Exit-Strategie erstellen	Art. 21 Abs. 2 lit. c (BCM)	Plan für Anbieterwechsel oder Umstieg auf Self-Hosted

Häufige Fehler bei der NIS2-Umsetzung zur Datensouveränität

Fehler 1: Datensouveränität nur als Datenschutzthema behandeln. NIS2 und DSGVO sind unterschiedliche Regulierungen mit unterschiedlichen Anforderungen. Selbst wenn dein Cloud-Anbieter DSGVO-konform ist, erfüllt das nicht automatisch die NIS2-Anforderungen an die Lieferkettensicherheit und die Risikobewertung der Datenhaltung.

Fehler 2: "EU-Rechenzentrum" mit Datensouveränität gleichsetzen. Ein Rechenzentrum in Frankfurt betrieben von einem US-Unternehmen unterliegt weiterhin dem US CLOUD Act. Der physische Standort allein sagt wenig über die tatsächliche Datensouveränität aus. Entscheidend sind der Hauptsitz des Betreibers, die anwendbare Rechtsordnung und die technische Zugriffsmöglichkeit.

Fehler 3: Den ISMS-Anbieter nicht als kritischen Dienstleister einstufen. Viele Unternehmen bewerten ihre IT-Dienstleister sorgfältig, vergessen aber die Compliance-Software. Dabei enthält das ISMS die sensibelsten Sicherheitsinformationen des Unternehmens. Der ISMS-Anbieter gehört in die höchste Kritikalitätsstufe der Lieferantenbewertung.

Fehler 4: Keine vertraglichen Meldepflichten vereinbaren. Wenn dein SaaS-ISMS-Anbieter kompromittiert wird, brauchst du eine vertragliche Zusicherung, innerhalb welcher Frist du informiert wirst. Ohne eine solche Klausel riskierst du, die NIS2-Meldefristen zu reißen, weil du zu spät vom Vorfall erfährst.

Fehler 5: Die eigene Infrastruktur unterschätzen. Self-Hosted ist kein Selbstläufer. Wenn du dein ISMS auf einem ungepatchten Server betreibst, hast du das Lieferketten-Risiko gegen ein Betriebsrisiko getauscht. Self-Hosted funktioniert nur, wenn du die grundlegenden Sicherheitsmaßnahmen für den Betrieb eigener Systeme beherrschst: Patch-Management, Backup, Monitoring, Zugriffskontrolle.

Was das für deine NIS2-Umsetzung bedeutet

Datensouveränität ist kein Modewort und kein Marketing-Argument. NIS2 macht die Kontrolle über deine Daten zu einem konkreten Compliance-Thema. Wenn du die Richtlinie umsetzt, prüfe nicht nur deine Firewalls und Passwort-Richtlinien, sondern auch, wo deine Compliance-Daten liegen und wer darauf zugreifen kann.

Die Entscheidung zwischen Cloud und Self-Hosted ist dabei kein Schwarz-Weiß-Thema. Es gibt Cloud-Anbieter mit hoher Transparenz und starken Sicherheitszusagen, und es gibt Self-Hosted-Installationen auf schlecht gewarteten Servern. Der Schlüssel liegt in der bewussten, dokumentierten Entscheidung auf Basis einer Risikobewertung, nicht im blinden Vertrauen auf das Marketingversprechen eines Anbieters. NIS2 erwartet genau das: dass du die Risiken kennst, bewertest und steuerst. Für deine ISMS-Daten gilt das ganz besonders.

Weiterführende Artikel