NIS2-Anforderungen: Die 10 Cybersicherheits-Risikomanagementmaßnahmen erklärt

NIS2-Anforderungen: Die 10 Cybersicherheits-Risikomanagementmaßnahmen erklärt

Zuletzt verifiziert: März 2026. Dieser Leitfaden behandelt Article 21 der Richtlinie (EU) 2022/2555 (NIS2) und die Durchführungsverordnung der Kommission (EU) 2024/2690 (CIR), die verbindliche technische Anforderungen für wichtige und wesentliche Einrichtungen festlegt.

Wenn Sie festgestellt haben, dass Ihre Organisation in den Anwendungsbereich von NIS2 fällt, stellt sich unmittelbar die nächste Frage: Was genau müssen Sie tun?

Article 21 der Richtlinie (EU) 2022/2555 legt zehn verbindliche Maßnahmen zum Cybersicherheits-Risikomanagement fest. Jede in den Anwendungsbereich fallende Einrichtung — ob Energieunternehmen, Cloud-Anbieter, mittelständischer Hersteller oder digitaler Marktplatz — muss alle zehn Maßnahmen umsetzen. Die einzige Variable ist wie verhältnismäßig Ihre Umsetzung sein muss, abhängig von Ihrer Größe, Ihrem Risikoexposure sowie der Wahrscheinlichkeit und Schwere von Sicherheitsvorfällen.

Dieser Leitfaden erläutert jede Maßnahme in verständlicher Sprache: Was die Rechtsvorschrift vorschreibt, wie die Durchführungsverordnung der Kommission 2024/2690 (CIR) dies in technische Anforderungen überführt, welche Dokumente Sie als Konformitätsnachweis benötigen, und praktische Hinweise für Organisationen mit begrenzten Sicherheitsressourcen.

Article 21 im Überblick: Der rechtliche Rahmen

Article 21(1) von NIS2 etabliert das grundlegende Prinzip: “Die Mitgliedstaaten stellen sicher, dass wesentliche und wichtige Einrichtungen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen ergreifen, um die Risiken für die Sicherheit der Netz- und Informationssysteme zu beherrschen.”

Zwei Grundsätze bestimmen die praktische Umsetzung:

  • Verhältnismäßigkeit — Der Umfang und die Ausgereiftheit Ihrer Umsetzung sollten Ihrer Größe, Ihrem Risikoexposure sowie den potenziellen gesellschaftlichen und wirtschaftlichen Auswirkungen von Sicherheitsvorfällen Rechnung tragen. Ein Fertigungsunternehmen mit 200 Mitarbeitenden und ein paneuropäischer Cloud-Anbieter unterliegen denselben zehn Pflichten, jedoch unterscheiden sich der erforderliche Dokumentationsumfang und die Komplexität der Kontrollen erheblich.
  • Gefahrenübergreifender Ansatz — Sie müssen Bedrohungen aus jeder Quelle begegnen: Cyberangriffe, Hardwareausfälle, Naturkatastrophen, Insider-Bedrohungen und Lieferkettenkompromittierungen gleichermaßen. NIS2 befasst sich nicht nur mit Hacking — es umfasst alles, was Ihre Dienste stören oder die Vertraulichkeit und Integrität der von Ihnen verarbeiteten Informationen gefährden könnte.

Für DNS-Anbieter, TLD-Registries, Cloud-Computing-Dienste, Rechenzentren, CDN-Anbieter, Managed Service Provider (MSPs), Managed Security Service Provider (MSSPs), Online-Marktplätze, Online-Suchmaschinen und soziale Netzwerkplattformen geht die Durchführungsverordnung der Kommission 2024/2690 weiter. Im Dezember 2024 veröffentlicht und ab dem 18. Januar 2025 anwendbar, legt die CIR in ihrem Annex präzise, verbindliche technische und methodische Anforderungen fest — das Dokument, das NIS2 einem ISO-Standard in Rechtsform am nächsten bringt.

Die 10 Maßnahmen des Article 21 im Überblick

#MaßnahmeArticle 21(2)CIR Annex
1Risikoanalyse und Informationssicherheitspolitik(a)1.1–1.2, 2.1
2Behandlung von Sicherheitsvorfällen(b)3.1–3.6
3Business Continuity und Krisenmanagement(c)4.1–4.3
4Sicherheit der Lieferkette(d)5.1–5.2
5Sicherheit bei Erwerb, Entwicklung und Wartung(e)6.1–6.2
6Bewertung der Wirksamkeit von Cybersicherheitsmaßnahmen(f)7
7Grundlegende Cybersicherheitspraktiken und Schulungen(g)8, 10
8Kryptografie und Verschlüsselung(h)9
9Personalsicherheit, Zugriffskontrolle und Asset-Management(i)11, 12
10Multi-Faktor-Authentifizierung und sichere Kommunikation(j)11.5–11.7

Maßnahme 1: Risikoanalyse und Informationssicherheitspolitik

Article 21(2)(a) verpflichtet Einrichtungen zur Vorhaltung einer Risikoanalyse und einer Sicherheitspolitik für Informationssysteme. Dies ist das Fundament, auf dem alle übrigen Maßnahmen aufbauen — wenn Sie nicht nachweisen können, dass Sie Ihre Risiken systematisch identifiziert haben, lässt sich für keine Ihrer Kontrollen belegen, dass sie diesen Risiken angemessen ist.

Was die Rechtsvorschrift verlangt

Sie benötigen zwei Dinge: eine dokumentierte Methodik zur Bewertung von Cybersicherheitsrisiken sowie eine übergeordnete Informationssicherheitspolitik, die von der Unternehmensleitung genehmigt wurde. Die Politik muss den Anwendungsbereich Ihres Informationssicherheits-Managementsystems (ISMS) definieren, Verantwortlichkeiten namentlich genannten Rollen zuweisen und die Organisation zur kontinuierlichen Verbesserung verpflichten.

Gemäß CIR Annex Abschnitte 1.1 und 1.2 müssen Einrichtungen eine Risikobewertungsmethodik aufstellen und dokumentieren, die Kriterien zur Risikobewertung definiert — Wahrscheinlichkeitsskalen, Auswirkungsskalen und Risikoakzeptanzschwellen — und alle netz- und informationstechnischen Systeme im Anwendungsbereich identifiziert. Abschnitt 2.1 verlangt, dass die Informationssicherheitspolitik formal auf Vorstandsebene oder gleichwertiger Ebene genehmigt wird. Dies ist eine bewusste Entscheidung der Kommission: Die Genehmigung durch das Leitungsorgan schafft direkte Managementverantwortung und begründet die in Article 20 beschriebene persönliche Haftungsexposition.

Die technische Umsetzungsleitlinie von ENISA (Abschnitte 1.1, 1.2 und 2.1.1) empfiehlt die Übernahme eines anerkannten Rahmenwerks wie ISO 27005, NIST SP 800-30 oder OCTAVE als Grundlage für Ihre Methodik und schreibt vor, dass die Risikobewertung mindestens jährlich sowie nach wesentlichen Änderungen der Betriebsumgebung oder der Bedrohungslage überprüft wird.

Erforderliche Dokumente

  • Informationssicherheitspolitik — vorstandsgenehmigt, unterzeichnet, datiert, mit Definition des ISMS-Anwendungsbereichs, Sicherheitszielen und zugewiesenen Verantwortlichkeiten
  • Risikobewertungsmethodik — dokumentierte Kriterien für Wahrscheinlichkeit, Auswirkung, Risikobewertungsskalen und Risikoakzeptanzschwellen
  • Risikoregister — laufendes Inventar identifizierter Bedrohungen mit zugewiesenen Wahrscheinlichkeits- und Auswirkungsbewertungen, Behandlungsentscheidungen und Status des Restrisikos

Hinweis für KMU: Eine verhältnismäßige Risikobewertung für eine Organisation mit 100 Mitarbeitenden erfordert keine dedizierte GRC-Plattform. Ein strukturiertes Tabellenkalkulationsregister in Verbindung mit einer zweiseitigen Methodikbeschreibung und einer vorstandsgenehmigten Politik erfüllt Article 21(2)(a), sofern es jährlich überprüft und nachweislich zur Steuerung von Kontrollentscheidungen verwendet wird. Siehe unsere Vorlagen für Risikobewertungsmethodik und Risikoregister.

Maßnahme 2: Behandlung von Sicherheitsvorfällen

Article 21(2)(b) verpflichtet Einrichtungen zur Vorhaltung von Richtlinien und Verfahren für die Behandlung von Sicherheitsvorfällen. Es geht dabei nicht nur darum, auf Vorfälle zu reagieren, wenn sie eintreten — sondern darum, vordefinierte Arbeitsabläufe, Eskalationswege und Benachrichtigungsprozesse bereitzuhalten, die unter Zeitdruck sofort aktiviert werden können.

Was die Rechtsvorschrift verlangt

Sie müssen in der Lage sein, Vorfälle zu erkennen, zu klassifizieren, darauf zu reagieren und sich davon zu erholen. Entscheidend ist, dass Sie die operative Kapazität besitzen, die Meldefristen für Sicherheitsvorfälle von NIS2 einzuhalten: eine 24-stündige Frühwarnung an Ihr nationales CSIRT oder die zuständige Behörde, eine 72-stündige Vorfallmeldung mit einer vorläufigen Bewertung sowie einen Abschlussbericht innerhalb eines Monats nach Bekanntwerden des Vorfalls.

CIR Annex Abschnitt 3 ist der detaillierteste der gesamten Verordnung. Er umfasst sechs Teilbereiche:

  • 3.1 — Fähigkeiten zur Vorfallserkennung: zentralisiertes Protokollmanagement, Monitoring-Tools (SIEM oder gleichwertig) und Alarmschwellen für bedeutende Ereignisse
  • 3.2 — Vorfallsklassifikationskriterien: dokumentierte Schwellenwerte für das, was gemäß Article 23(3) einen „erheblichen Sicherheitsvorfall“ darstellt, einschließlich Kriterien für die Anzahl betroffener Nutzer, Schätzungen finanzieller Schäden, Dauer von Dienstunterbrechungen und grenzüberschreitende Auswirkungen
  • 3.3 — Verfahren zur Vorfallsreaktion: dokumentierte Handlungsanweisungen für Eindämmung, Beseitigung, Beweissicherung und Wiederherstellungsreihenfolge
  • 3.4 — Interne Eskalation und Kommunikation: wer in welcher Reihenfolge, innerhalb welcher Frist und über welche Kanäle während eines aktiven Vorfalls benachrichtigt wird
  • 3.5 — Externe Meldepflichten: Verfahren zur Benachrichtigung des CSIRT, der zuständigen Behörde sowie — soweit Article 23(4) Anwendung findet — betroffener Nutzer und nachgelagerte Dienstleistungsempfänger
  • 3.6 — Nachbereitung von Vorfällen und Lessons Learned: dokumentierte Ursachenanalyse und Empfehlungen zur Verbesserung von Kontrollen, abzuschließen innerhalb des einmonatigen Abschlussberichtsfensters

Erforderliche Dokumente

  • Richtlinie zur Behandlung von Sicherheitsvorfällen — definiert Anwendungsbereich, Vorfallsklassifikationskriterien, Rollen und Verantwortlichkeiten, Eskalationsweg und Aufbewahrungsanforderungen für Vorfallsaufzeichnungen
  • Vorfallsprotokoll — laufende Aufzeichnung aller Sicherheitsereignisse, ihrer Klassifizierung, ergriffenen Reaktionsmaßnahmen und des Lösungsstatus
  • Meldeformulare — vorstrukturierte Vorlagen für die 24-Stunden-Frühwarnung, die 72-Stunden-Meldung und den Abschlussbericht, ausgerichtet an den Berichtsformatvorgaben von ENISA

Wesentliches Risiko: Die 24-Stunden-Frühwarnfrist überrascht die meisten Organisationen unvorbereitet. Ihre Fähigkeit zur Vorfallserkennung — auch eine einfache zentralisierte Protokollerfassung und Alarmierung — muss vor dem Eintreten eines Vorfalls einsatzbereit sein, nicht erst als Reaktion darauf zusammengestellt werden. Unser Vorlagenpaket für Vorfallsmeldungen enthält alle drei regulatorischen Meldeformulare mit Ausfüllanleitungen.

Maßnahme 3: Business Continuity und Krisenmanagement

Article 21(2)(c) behandelt Business Continuity, Backup-Management, Notfallwiederherstellung und Krisenmanagement. Ziel ist es, sicherzustellen, dass wesentliche Dienste nach einem störenden Ereignis wiederhergestellt werden können und dass Ihre Organisation vorab weiß, wie ein größerer Vorfall zu bewältigen ist, der die normale operative Kapazität übersteigt.

Was die Rechtsvorschrift verlangt

Sie benötigen ein dokumentiertes Verständnis, welche Systeme und Dienste kritisch sind — eine Business Impact Analysis —, eine Strategie zur Aufrechterhaltung oder Wiederherstellung dieser Systeme unter definierten Wiederherstellungszeit- und Wiederherstellungspunktzielen, einen umsetzbaren Business Continuity Plan sowie einen Krisenmanagementplan für Szenarien, die normale Kapazitäten der Vorfallsreaktion übersteigen.

CIR Annex Abschnitt 4 korrespondiert mit diesen Anforderungen:

  • 4.1 — Business Impact Analysis: Identifizierung kritischer Funktionen und der sie unterstützenden Systeme, Erfassung interner und externer Abhängigkeiten, Definition der maximal tolerierbaren Ausfallzeit für jeden kritischen Dienst sowie Quantifizierung der finanziellen und betrieblichen Auswirkungen von Nichtverfügbarkeit
  • 4.2 — Business-Continuity-Strategie und -Pläne: Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) für jedes kritische System, Backup-Architekturanforderungen (die 3-2-1-Regel — drei Kopien, zwei Medientypen, eine Kopie außerhalb des Standorts — als Mindeststandard) sowie alternative Verarbeitungsarrangements oder Cloud-Failover-Lösungen
  • 4.3 — Krisenmanagementpläne: Führungs- und Kontrollstruktur während eines größeren Vorfalls, interne und externe Kommunikationsprotokolle, Verfahren zur Stakeholder- und Medienkommunikation sowie Koordinierungsmechanismen mit nationalen Behörden gemäß Article 23

Erforderliche Dokumente

  • Business Impact Analysis (BIA) — Inventar kritischer Dienste, Abhängigkeitskartierung, RTO- und RPO-Ziele je Dienst sowie Auswirkungsquantifizierung
  • Business-Continuity-Strategie — Backup-Architekturentscheidungen, Redundanzoptionen sowie Cloud-Failover- oder Alternativstandortarrangements
  • Business Continuity Plan (BCP) — schrittweise Wiederherstellungsverfahren für prioritäre Ausfallszenarien
  • Krisenmanagementplan — Befehlshierarchie, Kommunikationsbaum, Verfahren zur Behördenbenachrichtigung und Eskalationsauslöser

Testanforderung: Pläne, die niemals getestet werden, sind keine glaubwürdigen Konformitätsnachweise. Etablieren Sie ein BC-Testprogramm — mindestens eine Tischübung jährlich und einen technischen Backup-Wiederherstellungstest vierteljährlich. Dokumentieren Sie die Ergebnisse und aktualisieren Sie die Pläne auf Basis der Erkenntnisse. Testnachweise gehören zu den ersten Dingen, die eine Aufsichtsbehörde anfordern wird.

Maßnahme 4: Sicherheit der Lieferkette

Article 21(2)(d) befasst sich mit der Sicherheit der Lieferkette, einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zwischen jeder Einrichtung und ihren unmittelbaren Lieferanten oder Dienstleistern. Dies ist eine der operativ komplexesten Maßnahmen, da sie die Anforderungen von NIS2 über Ihren eigenen Perimeter hinaus auf Ihr gesamtes Lieferantenökosystem ausdehnt.

Was die Rechtsvorschrift verlangt

Sie müssen die Cybersicherheitslage Ihrer kritischen Lieferanten bewerten, verbindliche Sicherheitsanforderungen in Lieferantenverträge aufnehmen und die Lieferantensicherheit fortlaufend überwachen. Der Fokus liegt auf IKT-Produkt- und Dienstleistungsanbietern, deren Kompromittierung sich auf Ihre eigenen Dienste auswirken könnte — Softwareanbieter, Cloud-Plattformen, Managed Service Provider und IT-Hardwarelieferanten sind die Prioritätskategorien.

CIR Annex Abschnitt 5 legt fest:

  • 5.1 — Lieferantenklassifizierung und -bewertung: eine dokumentierte Methodik zur Kategorisierung von Lieferanten nach Kritikalität und Risiko, einschließlich einer Sicherheitsbewertung vor der Aufnahme für Lieferanten der kritischen und wichtigen Kategorie, die deren Sicherheitsrichtlinien, Kapazitäten zur Vorfallsreaktion, Datenzugriffskontrollen und Unterlieferantenmanagement abdeckt
  • 5.2 — Vertragliche Sicherheitsanforderungen: Mindestsicherheitsklauseln, die Datenschutzpflichten, Meldefristen für Sicherheitsvorfälle gegenüber Ihrer Organisation, Audit-Rechte, Anforderungen an Sicherheitszertifizierungen (wo verhältnismäßig) sowie Verantwortlichkeiten für Patch-Management und Offenlegung von Schwachstellen umfassen

Erforderliche Dokumente

  • Lieferantensicherheitsrichtlinie — Stufenmethodik, Bewertungsanforderungen je Stufe und Mindestsicherheitserwartungen nach Lieferantenkategorie
  • Lieferantensicherheitsklauseln — vertragliche Anlage mit NIS2-relevanten Pflichten, einschließlich Vorfallsmeldung an Ihre Organisation, Audit-Recht, Anforderungen an Zugriffskontrollen und Standards zur Datenverarbeitung
  • Lieferantenverzeichnis — Register aller im Anwendungsbereich befindlichen IKT-Lieferanten mit Kritikalitätsstufe, letztem Bewertungsdatum, Status der Vertragsklauseln und gehaltenen Sicherheitszertifizierungen

Praktische Realität: Vollständige Sicherheitsaudits bei jedem Lieferanten sind nicht durchführbar. Stufen Sie Ihre Lieferanten in kritische, wichtige und standardmäßige Kategorien ein und wenden Sie entsprechend verhältnismäßige Sorgfaltspflichten an. Eine Sicherheitsfragebogenbewertung ist für die meisten Lieferanten der wichtigen Kategorie ausreichend; bei Lieferanten der kritischen Kategorie kann eine unabhängige Auditverifizierung oder eine verpflichtende Zertifizierung (z.B. ISO 27001) angemessen sein. Siehe unseren Leitfaden zur Lieferkettensicherheit für eine ausgearbeitete Stufenmethodik und eine Fragebogenvorlage.

Maßnahme 5: Sicherheit bei Erwerb, Entwicklung und Wartung

Article 21(2)(e) verpflichtet Einrichtungen, Sicherheit beim Erwerb, bei der Entwicklung und der Wartung von Netz- und Informationssystemen zu berücksichtigen, einschließlich des Umgangs mit Schwachstellen und deren Offenlegung. Dies gilt unabhängig davon, ob Sie handelsübliche Software kaufen, maßgeschneiderte Entwicklungen beauftragen oder Kapazitäten intern aufbauen.

Was die Rechtsvorschrift verlangt

Sicherheit muss in die Art und Weise eingebettet sein, wie Sie IKT-Systeme auswählen, beschaffen, entwickeln und pflegen — nicht nachträglich hinzugefügt werden. Für entwickelnde Organisationen bedeutet dies die Integration von Sicherheitsanforderungen in den Software-Entwicklungslebenszyklus (SDLC), einschließlich sicherer Programmierpraktiken, Schwachstellenscans und Änderungsmanagementkontrollen. Für Organisationen, die primär kommerzielle Systeme kaufen und betreiben, liegt der Fokus auf Sicherheitsanforderungen bei der Beschaffung und einem disziplinierten Patch-Management.

CIR Annex Abschnitt 6 umfasst zwei Dimensionen:

  • 6.1 — Sicherheit bei der Beschaffung von IKT-Produkten und -Dienstleistungen: Mindestsicherheitsanforderungen in Beschaffungsspezifikationen, Bewertung der Sicherheitspraktiken von Anbietern bei der Lieferantenauswahl, Patch-Management-SLA-Anforderungen in Verträgen sowie ausdrückliche Verbote für den Erwerb oder den Weiterbetrieb nicht mehr unterstützter (end-of-life) Software oder Hardware
  • 6.2 — Sicherheit bei Entwicklung und Tests: sichere Entwicklungsprinzipien (OWASP Top 10 als angemessener Ausgangspunkt), statische und dynamische Anwendungssicherheitstests (SAST/DAST) für sicherheitsrelevante Anwendungen, erzwungene Trennung von Entwicklungs-, Test- und Produktionsumgebungen sowie ein formaler Änderungsmanagementprozess mit Sicherheitsfolgenabschätzung für wesentliche Systemänderungen

Erforderliche Dokumente

  • Sicherheitsrichtlinie für IKT-Beschaffung und -Entwicklung — Sicherheitsanforderungen bei der Beschaffung, SDLC-Sicherheitskontrollen, Änderungsmanagementprozess mit Sicherheits-Gates sowie Patch-Management-Pflichten und SLAs
  • Anhang Sicherheitsanforderungen — eine Vertragsanlage-Vorlage für IKT-Beschaffungen, die Mindestsicherheitsstandards festlegt: Patch-Reaktions-SLAs, Pflichten zur Benachrichtigung über Schwachstellen sowie Anforderungen an sichere Konfigurationsbaselines

Maßnahme 6: Bewertung der Wirksamkeit von Cybersicherheits-Risikomanagementmaßnahmen

Article 21(2)(f) verpflichtet Einrichtungen zur Vorhaltung von Richtlinien und Verfahren zur Bewertung der Wirksamkeit von Cybersicherheits-Risikomanagementmaßnahmen. Dies schließt den Plan-Do-Check-Act-Zyklus: Sie müssen nicht nur Kontrollen implementieren, sondern auch nachweisen, dass Sie messen, ob diese tatsächlich wirksam sind.

Was die Rechtsvorschrift verlangt

Sie benötigen ein definiertes Messprogramm — Key Performance Indicators (KPIs) und Key Risk Indicators (KRIs), die dem Management einen echten Einblick in Ihre Sicherheitslage verschaffen. Dies steht in direktem Zusammenhang mit der Anforderung an die Vorstandsaufsicht gemäß Article 20: Leitungsorgane können ihre NIS2-Governance-Verantwortung nicht wahrnehmen, ohne zuverlässige, regelmäßige Sicherheitskennzahlen zu erhalten.

CIR Annex Abschnitt 7 verpflichtet Einrichtungen:

  • Messbare Kriterien zur Bewertung der Wirksamkeit jeder implementierten Kontrollkategorie zu definieren
  • Regelmäßige Überprüfungen des gesamten Risikomanagementprogramms durchzuführen — mindestens jährlich sowie nach erheblichen Vorfällen oder wesentlichen betrieblichen Änderungen
  • Dokumentierte Bewertungsberichte für die Managementüberprüfung zu erstellen, einschließlich Trendanalysen und emp

    Häufig gestellte Fragen

    Sind alle 10 Maßnahmen gemäß Artikel 21 für jede NIS2-Einrichtung verpflichtend?

    Ja. Alle zehn in Artikel 21(2) aufgeführten Maßnahmen sind für jede betroffene Einrichtung verpflichtend. Der Verhältnismäßigkeitsgrundsatz regelt den Umfang der Umsetzung jeder einzelnen Maßnahme – nicht jedoch, ob sie umgesetzt wird. Eine Einrichtung, die eine der zehn Maßnahmen ausgelassen hat, ist nicht NIS2-konform, unabhängig davon, wie gründlich sie die übrigen Maßnahmen umgesetzt hat. Im Rahmen der Aufsichtsprüfung wird das Fehlen einer erforderlichen Maßnahme als Compliance-Lücke erfasst.

    Gilt die CIR 2024/2690 für meine Organisation?

    Die CIR ist unmittelbar verbindlich für eine bestimmte Teilgruppe von NIS2-Einrichtungen: DNS-Dienstanbieter, TLD-Namenregistrierungsstellen, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Anbieter von Inhaltszustellnetzen, Managed Service Provider (MSPs), Managed Security Service Provider (MSSPs), Betreiber von Online-Marktplätzen, Betreiber von Online-Suchmaschinen, Anbieter sozialer Netzwerkdienste sowie Vertrauensdiensteanbieter. Außerhalb dieser Kategorien ist der Anhang der CIR nicht unmittelbar verbindlich – er stellt jedoch die maßgeblichste verfügbare Auslegung von „angemessen und verhältnismäßig“ im Sinne von Artikel 21 dar, und Aufsichtsbehörden in den EU-Mitgliedstaaten verwenden ihn als Referenzmaßstab bei der Bewertung anderer Einrichtungstypen.

    Was ist der Unterschied zwischen Artikel 21 und Artikel 23?

    Artikel 21 regelt die laufenden präventiven Sicherheitsmaßnahmen, die Ihr Programm zum Cybersicherheits-Risikomanagement bilden. Artikel 23 regelt die Vorfallsmeldung – die reaktive Verpflichtung, erhebliche Sicherheitsvorfälle innerhalb festgelegter Fristen an das nationale CSIRT oder die zuständige Behörde zu melden: innerhalb von 24 Stunden für eine Frühwarnung, innerhalb von 72 Stunden für eine vorläufige Vorfallsmeldung und innerhalb eines Monats für einen Abschlussbericht. Maßnahme 2 (Vorfallsbehandlung) bildet die operative Verbindung zwischen beiden: Die im Rahmen von Artikel 21 erstellten Reaktionsverfahren und Meldeworkflows ermöglichen es Ihnen in der Praxis, die Fristen gemäß Artikel 23 einzuhalten.

    Schreibt NIS2 eine ISO 27001-Zertifizierung vor?

    Nein. Eine ISO 27001-Zertifizierung ist durch NIS2 nicht vorgeschrieben. Allerdings liefert eine Zertifizierung starke Nachweise durch Dritte für die Konformität mit mehreren Maßnahmen gemäß Artikel 21 – insbesondere den Maßnahmen 1, 6, 7, 9 und 10. Einige EU-Mitgliedstaaten und zuständige Behörden haben signalisiert, dass sie eine aktuelle ISO 27001-Zertifizierung als Teilnachweis der NIS2-Konformität akzeptieren werden. Weitere Informationen finden Sie in unserem Vergleich NIS2 vs. ISO 27001, der eine detaillierte Zuordnungstabelle enthält und zeigt, wo die Rahmenwerke übereinstimmen und wo NIS2 Anforderungen stellt, die ISO 27001 nicht vollständig abdeckt.

    Wie funktioniert der Verhältnismäßigkeitsgrundsatz in der Praxis?

    Verhältnismäßigkeit bedeutet, dass eine wichtige Einrichtung mit 60 Mitarbeitenden in einem risikoarmen Sektor nicht denselben Umfang an Dokumentation oder technischer Kontrollkomplexität benötigt wie eine große wesentliche Einrichtung, die kritische nationale Infrastrukturen betreibt. Aufsichtsbehörden beurteilen die Verhältnismäßigkeit anhand folgender Kriterien: Größe der Einrichtung und verfügbare Ressourcen, Sensitivität der verarbeiteten Daten, mögliche grenzüberschreitende Auswirkungen von Sicherheitsvorfällen sowie der Grad, in dem andere Organisationen von den Diensten der Einrichtung abhängig sind. Die Risikobewertung (Maßnahme 1) ist der Ort, an dem die Verhältnismäßigkeit formal begründet wird – eine dokumentierte Bewertung, die geringe Restrisiken identifiziert und entsprechend leichtere Maßnahmen anwendet, ist verteidigbar. Verhältnismäßigkeit ohne jegliche dokumentierte Risikobewertung geltend zu machen, ist es nicht.

    Wie viele Dokumente benötige ich, um alle 10 Maßnahmen zu erfüllen?

    Ein vollständig dokumentiertes NIS2-Programm erfordert ungefähr 15–20 grundlegende Richtliniendokumente und operative Register. Der wesentliche Dokumentensatz umfasst: Informationssicherheitsrichtlinie, Risikobewertungsmethodik, Risikoregister, Vorfallsbehandlungsrichtlinie, Vorfallsprotokoll, drei Meldeformularvorlagen (24h/72h/1 Monat), Business-Impact-Analyse, Business-Continuity-Strategie, Business-Continuity-Plan, Krisenmanagementplan, Lieferantensicherheitsrichtlinie, Lieferantensicherheitsklauseln, Lieferantenverzeichnis, IKT-Beschaffungsrichtlinie, Sicherheitsanforderungsanhang, Messmethodik, Vorlage für Messberichte, Cybersicherheits-Schulungsplan, Personalsicherheitsrichtlinie, Verschlüsselungsrichtlinie, Zugangskontrollrichtlinie, Authentifizierungsrichtlinie, Anlagenregister sowie Richtlinie für sichere Kommunikation. Unsere Vorlagenbibliothek deckt jedes Dokument dieses Satzes ab, vorstrukturiert für die NIS2-Konformität.

    Quellen

Ähnliche Beiträge