¶ Maßnahmenkatalog nach BSIG
Muster und Entwurf: Diese Seite ist ein Arbeitsmodell für die organisationsbezogene Ausgestaltung der Risikomanagementmaßnahmen. Sie bestätigt weder die Betroffenheit einer bestimmten Organisation noch die Umsetzung, Angemessenheit oder Wirksamkeit einzelner Kontrollen.
Wichtige Abgrenzung: § 30 Absatz 2 BSIG verlangt, dass die Maßnahmen zumindest alle zehn Mindestbereiche umfassen. Jeder Bereich muss deshalb nachvollziehbar betrachtet werden. Das ist keine Statement-of-Applicability-Logik, bei der ganze gesetzliche Mindestbereiche ohne Prüfung abgewählt werden dürfen. Nur auf Ebene konkreter Detailanforderungen, Technologien oder Ausprägungen kann sich nach Rechtsgrundlage, Scope, Risiko und Verhältnismäßigkeit eine begründete andere Umsetzung oder Nichtanwendbarkeit ergeben.
Der Maßnahmenkatalog übersetzt gesetzliche Mindestbereiche in steuerbare Kontrollen. Eine bloße Verlinkung auf eine Richtlinie oder ISO-27001-Kontrolle reicht nicht aus. Für jeden relevanten Dienst muss erkennbar sein, welches Risiko begrenzt wird, welche Kontrolle tatsächlich angewendet wird, wer verantwortlich ist, wie die Wirksamkeit geprüft wird und welche Lücke noch besteht.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-02-05 |
| Dokumentenart | Anforderungs-, Kontroll- und Maßnahmenregister nach § 30 BSIG |
| Wiki.js-Pfad | /NIS2/02-Risikomanagement-und-Nachweise/Massnahmenkatalog-nach-BSIG |
| Prozesseigner | Geschäftsleitung / NIS2-Koordination / Informationssicherheitsmanagement |
| Fachverantwortliche | Control Owner der zehn Mindestbereiche |
| Status | Entwurf – keine organisationsbezogene Umsetzung oder Wirksamkeit bestätigt |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Intern; technische Nachweise und Schwachstelleninformationen geschützt |
| Rechtsbezug | § 30 BSIG; ergänzend §§ 31 und 39 BSIG sowie Artikel 21 NIS2-Richtlinie |
| Regelprüfung | mindestens jährlich und anlassbezogen; Kontrollfrequenzen risikobasiert |
Gesetzliche Mindestbereiche in prüfbare Kontrollen, Nachweise und Verbesserungen überführen. Eigene redaktionelle SVG-Grafik; zum Vergrößern öffnen.
¶ 1. Zweck und Arbeitsergebnisse
Der Katalog soll die Organisation in die Lage versetzen,
- die zehn Mindestbereiche vollständig und dienstbezogen zu bearbeiten,
- Anforderungen aus Gesetz, Durchführungsrecht, Aufsicht und Verträgen zu unterscheiden,
- bestehende ISMS-, BCM-, Datenschutz- oder TISAX-Kontrollen auf tatsächliche Eignung zu prüfen,
- Lücken und unzureichende Nachweise sichtbar zu machen,
- technische und organisatorische Maßnahmen risikobasiert zu priorisieren,
- Umsetzung und Wirksamkeit getrennt zu bewerten,
- Entscheidungen, Abweichungen und Verbesserungen nachvollziehbar zu steuern,
- der Geschäftsleitung eine belastbare Entscheidungsgrundlage bereitzustellen.
Arbeitsergebnisse sind ein freigegebener Scope, eine Anforderungsmatrix, Kontrollsteckbriefe, eine Gap-Analyse, ein Risikobehandlungsplan, ein Prüfplan, ein Nachweisregister sowie regelmäßige Managementberichte. Die geschützten Originalnachweise verbleiben außerhalb des öffentlichen Wikis.
¶ 2. Gesetzlicher Pflichtenkern
Besonders wichtige und wichtige Einrichtungen müssen nach § 30 Absatz 1 BSIG geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen ergreifen. Ziel ist, Störungen der Verfügbarkeit, Integrität und Vertraulichkeit der für die Dienste genutzten informationstechnischen Systeme, Komponenten und Prozesse zu vermeiden und die Auswirkungen von Sicherheitsvorfällen möglichst gering zu halten.
Bei der Verhältnismäßigkeit sind insbesondere zu berücksichtigen:
- Ausmaß der Risikoexposition,
- Größe der Einrichtung,
- Umsetzungskosten,
- Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen,
- gesellschaftliche und wirtschaftliche Auswirkungen.
Die Einhaltung ist zu dokumentieren. Die Maßnahmen sollen den Stand der Technik einhalten, einschlägige europäische und internationale Normen berücksichtigen und auf einem gefahrenübergreifenden Ansatz beruhen. Der Katalog darf deshalb weder auf reine IT-Angriffe noch auf Dokumentenbesitz reduziert werden.
¶ 3. Normenhierarchie und Vorrangprüfung
Vor dem Aufbau einzelner Kontrollen wird geklärt, welche Rechts- und Detailanforderungen für die Einrichtung gelten.
| Prüfebene | Leitfrage | Ergebnis im Katalog |
|---|---|---|
| Betroffenheit | Ist die Organisation besonders wichtige oder wichtige Einrichtung? | dokumentierte Einstufung und betroffene Dienste |
| Einrichtungsart | Gehört sie zu einer in § 30 Absatz 3 genannten digitalen Einrichtungsart? | Vorrangprüfung der EU-Durchführungsverordnung |
| Sektor | Gelten besondere sektorale Rechtsakte oder Aufsichtsvorgaben? | zusätzliche oder vorrangige Anforderungen |
| Kritische Anlage | Wird eine kritische Anlage betrieben? | Zusatzanforderungen aus §§ 31 und 39 BSIG |
| Verträge und Kunden | Bestehen weitergehende Sicherheitsanforderungen? | getrennte Vertragsreferenz, keine Vermischung mit Gesetz |
| Normen | Werden ISO 27001, TISAX oder andere Standards genutzt? | unterstützendes Mapping mit dokumentierter Deckungsprüfung |
Für DNS-Diensteanbieter, TLD-Namenregister, Cloud-Computing-Dienstleister, Anbieter von Rechenzentrumsdiensten, Betreiber von Content Delivery Networks, Managed Service Provider, Managed Security Service Provider, Online-Marktplätze, Online-Suchmaschinen, Plattformen sozialer Netzwerke und Vertrauensdiensteanbieter ist insbesondere die Durchführungsverordnung (EU) 2024/2690 zu prüfen. Eine Zuordnung allein zu den zehn Überschriften des § 30 Absatz 2 genügt für diese Einrichtungsarten nicht.
¶ 4. Geltungsbereich des Maßnahmenkatalogs
Der Katalog wird nicht pauschal für „die IT“ geführt. Jede Kontrolle wird auf die Erbringung der relevanten Dienste bezogen. Zum Scope gehören je nach Sachverhalt:
- relevante Dienste und Geschäftsprozesse,
- Netz- und Informationssysteme, Komponenten und Anwendungen,
- Daten, Schnittstellen und Kommunikationswege,
- Standorte, Rechenzentren und unterstützende Versorgung,
- Beschäftigte, privilegierte Rollen und externe Personen,
- unmittelbare Anbieter und Diensteanbieter,
- Cloud-, Plattform- und Managed-Service-Leistungen,
- Abhängigkeiten, Single Points of Failure und Notbetriebsressourcen.
Scope-Grenzen, Ausschlüsse und Schnittstellen werden begründet. Ein System außerhalb des formalen ISMS-Geltungsbereichs kann dennoch für einen NIS2-relevanten Dienst wesentlich sein und muss dann in der NIS2-Betrachtung berücksichtigt werden.
¶ 5. Katalogstruktur und eindeutige Kennzeichnung
Jede Anforderung und Kontrolle erhält eine eindeutige Referenz. Ein mögliches Schema ist:
NIS2-30-[Mindestbereich]-[Kontrollnummer]
Beispiel: NIS2-30-03-04 bezeichnet die vierte Kontrolle im Bereich Aufrechterhaltung des Betriebs. Detailanforderungen aus der Durchführungsverordnung erhalten eine separate Referenz, beispielsweise EU-2024-2690-07.2. Dadurch bleiben Rechtsquelle, interne Kontrolle und Nachweis voneinander unterscheidbar.
Der Katalog besteht mindestens aus:
- Anforderungsreferenz und verbindlichem Soll,
- betroffenen Diensten und Assets,
- internem Kontrollziel,
- konkreter Kontrollbeschreibung,
- Control Owner und ausführenden Rollen,
- Frequenz oder Auslöser,
- Umsetzungs- und Wirksamkeitsstatus,
- Prüfverfahren und Akzeptanzkriterium,
- Nachweisreferenzen,
- Lücke, Risiko und Behandlungsmaßnahme,
- Termin, Eskalation und Freigabe,
- letzter und nächster Review.
¶ 6. Die zehn Mindestbereiche im Überblick
| Nr. | Mindestbereich nach § 30 Absatz 2 BSIG | Primäres Steuerungsziel | Beispielhafte führende Wiki-Seiten |
|---|---|---|---|
| 1 | Risikoanalyse und Sicherheit in der Informationstechnik | Risiken der relevanten Dienste vollständig erkennen und behandeln | NIS2-Risikomethodik, NIS2-Risikoregister |
| 2 | Bewältigung von Sicherheitsvorfällen | Vorfälle erkennen, begrenzen, bearbeiten und auswerten | Incident Response, Meldeweg Sicherheitsvorfälle |
| 3 | Aufrechterhaltung des Betriebs, Backup, Wiederherstellung und Krisenmanagement | relevante Dienste in Störungen fortführen oder geordnet wiederanlaufen lassen | Notfallvorsorge und BCM, Wiederanlaufplanung |
| 4 | Sicherheit der Lieferkette | Abhängigkeiten und Risiken unmittelbarer Anbieter beherrschen | Lieferanten und Dienstleister |
| 5 | Sicherheit bei Erwerb, Entwicklung und Wartung einschließlich Schwachstellenmanagement und -offenlegung | Sicherheitsanforderungen über den Lebenszyklus durchsetzen | Sichere Entwicklung, Schwachstellen- und Patchmanagement |
| 6 | Bewertung der Wirksamkeit | feststellen, ob Kontrollen tatsächlich funktionieren | Wirksamkeitsprüfung, Wirksamkeitsmessungen |
| 7 | grundlegende Schulungen und Sensibilisierung | sicheres Verhalten und rollenbezogene Fähigkeiten stärken | Personal und Schulungen, Schulung der Geschäftsleitung |
| 8 | kryptografische Verfahren | Informationen und Kommunikation angemessen kryptografisch schützen | Kryptografie und Schlüssel |
| 9 | Personalsicherheit, Zugriffskontrolle und Verwaltung von IKT-Systemen, -Produkten und -Prozessen | vertrauenswürdige Personen, minimale Berechtigungen und kontrollierte Assets sicherstellen | Zugriff und Berechtigungen, Asset-Inventar |
| 10 | MFA oder kontinuierliche Authentifizierung sowie gesicherte Kommunikation und gegebenenfalls Notfallkommunikation | Identitäten und Kommunikationskanäle gegen Missbrauch schützen | Netzwerke und Kommunikation, Kontakt- und Eskalationslisten |
¶ 7. Mindestbereich 1 – Risikoanalyse und Informationssicherheit
¶ Kontrollziel
Risiken für die Erbringung der relevanten Dienste werden systematisch, wiederholbar und entscheidungsorientiert identifiziert, bewertet, behandelt und überwacht.
¶ Prüffragen
- Sind relevante Dienste, Prozesse, Systeme, Daten, Standorte und Anbieter vollständig einbezogen?
- Berücksichtigt die Methode Cyberangriffe, Fehlbedienung, Ausfälle, physische Ereignisse und Lieferkettenrisiken?
- Werden Eintrittswahrscheinlichkeit, Auswirkungen auf Dienste und gesellschaftliche oder wirtschaftliche Folgen bewertet?
- Sind Risikoeigner, Akzeptanzgrenzen und Eskalationswege festgelegt?
- Werden wesentliche Änderungen, Vorfälle und neue Bedrohungen als Auslöser genutzt?
¶ Mögliche Kontrollen und Nachweise
Risikomethodik, Dienst- und Assetinventar, Bedrohungsszenarien, Risikoregister, dokumentierte Risikobehandlung, Freigaben von Restrisiken, Review-Protokolle und nachvollziehbare Verknüpfungen zwischen Risiko, Kontrolle und Nachweis. Die Existenz eines Risikoregisters belegt noch nicht, dass die Bewertung vollständig oder aktuell ist.
¶ 8. Mindestbereich 2 – Bewältigung von Sicherheitsvorfällen
¶ Kontrollziel
Sicherheitsvorfälle werden rechtzeitig erkannt, klassifiziert, eingedämmt, untersucht, gemeldet, behoben und nachbereitet.
¶ Prüffragen
- Sind Kriterien für Ereignis, Sicherheitsvorfall und erheblichen Sicherheitsvorfall definiert?
- Funktionieren Meldewege rund um die Uhr für kritische Situationen?
- Sind Rollen für Triage, Technik, Recht, Datenschutz, Kommunikation und Geschäftsleitung geklärt?
- Werden Beweise geschützt und Entscheidungen zeitgestempelt dokumentiert?
- Sind gesetzliche, datenschutzrechtliche, vertragliche und TISAX-Meldewege getrennt bewertbar?
- Werden Erkenntnisse in Risiken, Kontrollen und Schulungen zurückgeführt?
¶ Mögliche Kontrollen und Nachweise
Incident-Response-Plan, Alarmierungsregeln, Bereitschaftslisten, Fallakten, Zeitlinien, technische Protokolle, Kommunikationsfreigaben, Melderegister, Nachbesprechungen und Maßnahmenverfolgung. Übungen müssen realistische Entscheidungs- und Eskalationssituationen enthalten; eine reine Lesebestätigung genügt nicht als Funktionsnachweis.
¶ 9. Mindestbereich 3 – Betriebskontinuität, Backup und Krise
¶ Kontrollziel
Kritische Leistungen können bei Störungen in einem festgelegten Mindestumfang fortgeführt und innerhalb akzeptierter Zeiten wiederhergestellt werden.
¶ Prüffragen
- Sind maximale Ausfallzeiten, Wiederanlaufzeiten und tolerierbare Datenverluste dienstbezogen festgelegt?
- Sind Abhängigkeiten von Personal, Gebäuden, Energie, Telekommunikation, Cloud und Lieferanten berücksichtigt?
- Sind Backups gegen Manipulation, Verschlüsselung und gleichzeitigen Ausfall geschützt?
- Werden Wiederherstellung und Wiederanlauf praktisch getestet?
- Bestehen Notbetriebsverfahren und ein entscheidungsfähiger Krisenstab?
- Werden Testergebnisse und nicht erreichte Ziele nachverfolgt?
¶ Mögliche Kontrollen und Nachweise
Business-Impact-Analyse, Notfallkonzept, Wiederanlaufpläne, Backup-Architektur, Restore-Protokolle, Notfallübungen, Krisenstabsprotokolle, alternative Kommunikationswege und Maßnahmen aus Tests. Eine erfolgreiche Backup-Meldung ersetzt keinen Wiederherstellungstest des relevanten Dienstes.
¶ 10. Mindestbereich 4 – Sicherheit der Lieferkette
¶ Kontrollziel
Cyberrisiken aus unmittelbaren Anbietern und Diensteanbietern werden über Auswahl, Vertrag, Betrieb, Überwachung und Beendigung hinweg beherrscht.
¶ Prüffragen
- Gibt es ein aktuelles Verzeichnis unmittelbarer Anbieter und der bereitgestellten IKT-Produkte, Dienste und Prozesse?
- Werden Kritikalität, Konzentrationsrisiken, Unterauftragnehmer und geografische Abhängigkeiten bewertet?
- Sind Sicherheits-, Melde-, Audit-, Kontinuitäts-, Rückgabe- und Löschanforderungen vereinbart?
- Werden Leistungs- und Sicherheitsnachweise risikobasiert überprüft?
- Existieren Exit-, Wechsel- oder Ersatzszenarien für kritische Anbieter?
- Fließen Schwachstellen und Vorfälle von Lieferanten in die eigene Risikobewertung ein?
¶ Mögliche Kontrollen und Nachweise
Lieferanteninventar, Kritikalitätsbewertung, Due-Diligence-Unterlagen, Vertragsklauseln, Sicherheitsanlagen, Zertifikatsprüfungen, Serviceberichte, Auditberichte, Vorfallmeldungen, Exit-Pläne und Lieferantenreviews. Ein Zertifikat des Anbieters ist ein möglicher Nachweisbaustein, ersetzt aber nicht die Prüfung des tatsächlich bezogenen Dienstes und seines Scopes.
¶ 11. Mindestbereich 5 – Erwerb, Entwicklung, Wartung und Schwachstellen
¶ Kontrollziel
Sicherheitsanforderungen werden über Beschaffung, Entwicklung, Änderung, Wartung und Außerbetriebnahme von IKT-Systemen, Komponenten und Prozessen gesteuert; Schwachstellen werden rechtzeitig behandelt und gegebenenfalls verantwortungsvoll offengelegt.
¶ Prüffragen
- Sind Sicherheitsanforderungen Bestandteil von Beschaffung und Projektfreigabe?
- Werden Architektur, Code, Konfiguration und Abhängigkeiten risikobasiert geprüft?
- Sind Entwicklungs-, Test- und Produktionsumgebungen angemessen getrennt?
- Werden Schwachstelleninformationen aus Herstellern, CERTs und eigenen Tests bewertet?
- Sind Patchfristen nach Kritikalität und Exposition festgelegt?
- Gibt es Verfahren für Ausnahmen, nicht patchbare Systeme und kompensierende Maßnahmen?
- Besteht ein koordinierter Prozess für Entgegennahme und Offenlegung von Schwachstellen?
¶ Mögliche Kontrollen und Nachweise
Security-by-Design-Vorgaben, Beschaffungschecklisten, Architekturfreigaben, Code- und Abhängigkeitsscans, Penetrationstests, Änderungsprotokolle, Schwachstellenregister, Patchberichte, Ausnahmegenehmigungen, End-of-Life-Pläne und Veröffentlichungsprozesse. Scannerabdeckung und Datenqualität müssen bekannt sein; eine grüne Oberfläche allein ist kein Wirksamkeitsnachweis.
¶ 12. Mindestbereich 6 – Bewertung der Wirksamkeit
¶ Kontrollziel
Die Organisation kann nachweisen, dass ausgewählte Maßnahmen nicht nur dokumentiert oder technisch eingerichtet, sondern im relevanten Scope wirksam umgesetzt und aufrechterhalten werden.
¶ Prüffragen
- Ist für jede wesentliche Kontrolle ein überprüfbares Ziel definiert?
- Sind Methode, Stichprobe, Frequenz, Prüfer und Akzeptanzkriterium festgelegt?
- Werden Design, Umsetzung und tatsächliche Wirkung unterschieden?
- Sind negative Ergebnisse, Ausnahmen und Wiederholungsprüfungen sichtbar?
- Berücksichtigen Prüfungen relevante Vorfälle und wesentliche Änderungen?
- Wird die Unabhängigkeit der Bewertung risikogerecht organisiert?
¶ Mögliche Kontrollen und Nachweise
Kontrolltests, technische Stichproben, Wiederherstellungstests, Berechtigungsreviews, Angriffssimulationen, Red-/Purple-Team-Ergebnisse, interne Audits, Kennzahlen und dokumentierte Wiederholungsprüfungen. Der Katalog verweist auf den Nachweis, enthält aber keine vertraulichen technischen Rohdaten.
¶ 13. Mindestbereich 7 – Schulung und Sensibilisierung
¶ Kontrollziel
Beschäftigte, Fachrollen, Administratoren, Incident-Rollen und Geschäftsleitung verfügen über die für ihre Aufgaben erforderlichen Kenntnisse und können diese anwenden.
¶ Prüffragen
- Sind Zielgruppen und rollenbezogene Lernbedarfe bestimmt?
- Werden neue Personen zeitnah qualifiziert und Änderungen anlassbezogen vermittelt?
- Behandeln Inhalte reale Risiken, Meldewege und sichere Arbeitsweisen?
- Werden Abwesenheit, Nachholung und Kompetenzlücken verfolgt?
- Wird neben Teilnahme auch Verständnis oder praktische Anwendung bewertet?
- Ist die gesonderte Schulungspflicht der Geschäftsleitung berücksichtigt?
¶ Mögliche Kontrollen und Nachweise
Schulungskonzept, Zielgruppenmatrix, Lehrpläne, versionierte Lerninhalte, Einladungen, geschützte Teilnahme- und Testergebnisse, Phishing- oder Szenarioübungen, Nachholtermine und Wirksamkeitsauswertung. Personenbezogene Lerndaten werden nur zweckgebunden und geschützt verarbeitet.
¶ 14. Mindestbereich 8 – Kryptografische Verfahren
¶ Kontrollziel
Kryptografie schützt Daten und Kommunikation entsprechend Informationswert, Risiko, Lebenszyklus und regulatorischen Anforderungen; Schlüssel und Zertifikate werden kontrolliert verwaltet.
¶ Prüffragen
- Bestehen verbindliche Regeln für Verschlüsselung, Signatur und Hashverfahren?
- Sind zulässige Algorithmen, Schlüssellängen und Protokolle festgelegt und aktuell?
- Werden Schlüssel sicher erzeugt, verteilt, gespeichert, rotiert, gesperrt und vernichtet?
- Sind Zertifikatsabläufe, HSMs, Geheimnisse und Wiederherstellungsschlüssel überwacht?
- Werden Daten in Übertragung, Speicherung und Backup angemessen geschützt?
- Existiert eine Migrationsplanung für veraltete oder künftig unsichere Verfahren?
¶ Mögliche Kontrollen und Nachweise
Kryptografierichtlinie, Schlüssel- und Zertifikatsinventar, Konfigurationsstandards, Ablaufüberwachung, HSM-Protokolle, Schlüsselwechsel, TLS-Prüfungen, Ausnahmeentscheidungen und Migrationspläne. Sensible Schlüsselmaterialien und technische Details gehören nicht in das öffentliche Wiki.
¶ 15. Mindestbereich 9 – Personal, Zugriff und IKT-Verwaltung
¶ Kontrollziel
Nur geeignete und autorisierte Personen erhalten aufgabenbezogenen Zugriff; IKT-Systeme, Produkte und Prozesse werden über ihren Lebenszyklus kontrolliert verwaltet.
¶ Prüffragen
- Sind Sicherheitsanforderungen vor, während und nach Beschäftigung geregelt?
- Werden Identitäten eindeutig verwaltet und Berechtigungen nach Minimalprinzip vergeben?
- Sind privilegierte Konten besonders geschützt, getrennt und überwacht?
- Funktionieren Joiner-, Mover- und Leaver-Prozesse fristgerecht?
- Werden Berechtigungen regelmäßig und durch verantwortliche Stellen überprüft?
- Sind Assets, Konfigurationen, Änderungen und Außerbetriebnahmen nachvollziehbar?
- Werden Funktionstrennung und Interessenkonflikte angemessen berücksichtigt?
¶ Mögliche Kontrollen und Nachweise
Rollen- und Berechtigungskonzepte, Identitätsregister, Genehmigungsworkflows, Rezertifizierungen, privilegierte Sitzungsprotokolle, Offboarding-Checks, Asset- und Konfigurationsinventare, Änderungsnachweise sowie Ausnahmen mit kompensierenden Kontrollen.
¶ 16. Mindestbereich 10 – Authentifizierung und sichere Kommunikation
¶ Kontrollziel
Identitäten werden mit angemessener Sicherheit authentifiziert; sensible Regel- und Notfallkommunikation bleibt verfügbar, vertraulich und manipulationsgeschützt.
¶ Prüffragen
- Für welche Zugriffe ist MFA oder kontinuierliche Authentifizierung erforderlich?
- Sind Remotezugriffe, privilegierte Zugriffe, Cloudzugänge und externe Portale vollständig erfasst?
- Werden starke, phishing-resistente Verfahren risikobasiert bevorzugt?
- Sind Registrierung, Gerätewechsel, Recovery und Sperrung gegen Missbrauch geschützt?
- Sind Sprach-, Video- und Textkommunikation angemessen abgesichert?
- Gibt es vom Primärsystem unabhängige und regelmäßig getestete Notfallkommunikation?
- Werden Ausnahmen zeitlich befristet und mit kompensierenden Maßnahmen gesteuert?
¶ Mögliche Kontrollen und Nachweise
Authentifizierungsrichtlinie, MFA-Abdeckungsbericht, Conditional-Access-Regeln, privilegierte Zugriffskontrollen, sichere Kommunikationsplattformen, Recovery-Prozesse, Notfallkontakte, Kommunikationsübungen und dokumentierte Ausnahmebehandlungen. Eine MFA-Lizenz belegt keine vollständige oder wirksame Nutzung.
¶ 17. Zusätzliche Prüfung für Betreiber kritischer Anlagen
Für Betreiber kritischer Anlagen reicht die allgemeine Betrachtung nicht aus. Nach § 31 BSIG können für maßgebliche Systeme, Komponenten und Prozesse über das Schutzniveau besonders wichtiger Einrichtungen hinausgehende Maßnahmen verhältnismäßig sein. Zusätzlich sind Systeme zur Angriffserkennung einzusetzen, die geeignete Parameter und Merkmale kontinuierlich und automatisch erfassen und auswerten.
Der Katalog ergänzt daher mindestens:
- Abgrenzung der für die kritische Anlage maßgeblichen Systeme, Komponenten und Prozesse,
- besondere Ausfall- und Beeinträchtigungsfolgen,
- Architektur und Abdeckung der Angriffserkennung,
- Betriebs-, Auswertungs- und Reaktionsprozesse,
- Behandlung von Blind Spots und Ausnahmen,
- Nachweisplanung nach § 39 BSIG,
- Mängelbeseitigungspläne und deren Fortschritt.
Die KRITIS-Einstufung und die konkreten Nachweisfristen werden nicht aus diesem Muster abgeleitet, sondern organisationsbezogen bestätigt.
¶ 18. Umgang mit ISO 27001, TISAX und bestehenden Kontrollen
Bestehende Kontrollen können mehrfach genutzt werden, wenn ihre Eignung geprüft ist. Das Mapping beantwortet mindestens:
- Deckt die Kontrolle dieselbe gesetzliche Zielsetzung ab?
- Umfasst ihr Scope sämtliche betroffenen Dienste und Abhängigkeiten?
- Ist der Control Owner für diesen Scope verantwortlich?
- Wird die Kontrolle in der erforderlichen Frequenz angewendet?
- Ist der Nachweis aktuell und ausreichend belastbar?
- Belegt er Umsetzung oder auch Wirksamkeit?
- Bestehen NIS2-spezifische Ergänzungen oder Lücken?
Eine ISO-27001-Zertifizierung oder TISAX-Prüfung kann wertvolle Nachweise liefern. Sie stellt für sich allein aber keine automatische Bestätigung aller gesetzlichen Anforderungen, aller relevanten Dienste oder der organisationsbezogenen Verhältnismäßigkeit dar.
¶ 19. Kontrollsteckbrief
| Feld | Erwartete Aussage |
|---|---|
| Kontroll-ID | eindeutige und versionierte Referenz |
| Rechts-/Anforderungsreferenz | § 30-Bereich, EU-Detailanforderung, sektorale oder vertragliche Quelle |
| Kontrollziel | welches Risiko oder welche Dienstwirkung begrenzt werden soll |
| Scope | Dienste, Systeme, Standorte, Daten, Personen und Anbieter |
| Beschreibung | wer führt was wann womit und nach welchen Kriterien durch |
| Frequenz/Auslöser | kontinuierlich, periodisch oder ereignisbezogen |
| Control Owner | für Gestaltung und Betrieb verantwortliche Rolle |
| Ausführende Rolle | tatsächliche Durchführung der Kontrolle |
| Prüfer | Bewertung von Umsetzung und Wirksamkeit |
| Akzeptanzkriterium | messbarer Sollwert oder nachvollziehbare qualitative Bedingung |
| Nachweisreferenz | Metadaten und geschützter Ablageort des Originals |
| Status | Bewertung nach der freigegebenen Statuslogik |
| Lücke und Risiko | Abweichung, Ursache, Auswirkung und Priorität |
| Behandlung | Maßnahme, Zwischenkontrolle, Owner, Termin und Eskalation |
| Review | letzte Prüfung, Ergebnis und nächster Termin |
¶ 20. Statusmodell – Anforderung, Umsetzung und Wirkung trennen
| Status | Zulässige Aussage | Nicht zulässige Schlussfolgerung |
|---|---|---|
| nicht bewertet | Scope oder Sollanforderung noch offen | keine Lücke vorhanden |
| zugeordnet | mögliche interne Referenz gefunden | Kontrolle deckt Anforderung ab |
| fachlich geprüft | Deckung und Scope wurden verglichen | Kontrolle ist umgesetzt |
| Lücke erkannt | Sollzustand fehlt oder reicht nicht aus | Risiko ist bereits behandelt |
| geplant | Behandlung ist beschlossen oder vorbereitet | Maßnahme ist produktiv |
| umgesetzt | Kontrolle wird im Scope angewendet | Kontrolle ist wirksam |
| geprüft | Test oder Bewertung wurde durchgeführt | Akzeptanzkriterien wurden erfüllt |
| wirksam | definierte Kriterien wurden mit aktuellem Nachweis erfüllt | Wirkung bleibt ohne weitere Prüfung dauerhaft bestehen |
| teilweise wirksam | Teile erfüllen die Kriterien; Restlücke besteht | Bereich ist abgeschlossen |
| Abweichung akzeptiert | befristete Entscheidung mit Risiko, Auflagen und Termin | dauerhafte Befreiung von der gesetzlichen Pflicht |
Status werden je Kontrolle und Scope vergeben. Ein zusammengefasster Prozentwert darf Unterschiede zwischen kritischen und weniger kritischen Kontrollen nicht verdecken.
¶ 21. Umgang mit „nicht anwendbar“
Die zehn gesetzlichen Mindestbereiche werden nicht pauschal als „nicht anwendbar“ markiert. Für jeden Bereich ist zu dokumentieren, wie er im konkreten Geltungsbereich berücksichtigt wird.
Bei einzelnen Detailanforderungen kann eine begründete Bewertung erforderlich sein. Sie enthält mindestens:
- genaue Anforderungsreferenz,
- betroffenen oder nicht betroffenen Scope,
- tatsächliche und rechtliche Begründung,
- zugrunde liegende Risikobewertung,
- gegebenenfalls alternative oder kompensierende Maßnahme,
- verantwortliche fachliche Prüfung,
- Freigabe und Befristung,
- Auslöser für erneute Bewertung.
Für Einrichtungen im Anwendungsbereich der Durchführungsverordnung (EU) 2024/2690 sind deren Formulierungen zu „angemessen“, „anwendbar“ oder „durchführbar“ und die Pflicht zur verständlichen Dokumentation der Begründung auf Ebene der konkreten Anforderung zu beachten. Diese Möglichkeit ist kein pauschaler Verzicht auf einen der zehn Mindestbereiche.
¶ 22. Verhältnismäßigkeitsentscheidung
Verhältnismäßigkeit bedeutet nicht automatisch die kostengünstigste Lösung. Die Entscheidung vergleicht mindestens:
- Risikoexposition und Bedrohungslage,
- Bedeutung und Kritikalität des Dienstes,
- Größe und Struktur der Einrichtung,
- technische und organisatorische Abhängigkeiten,
- Eintrittswahrscheinlichkeit und mögliche Schwere,
- gesellschaftliche und wirtschaftliche Auswirkungen,
- Stand der Technik und verfügbare Alternativen,
- Umsetzungs- und Betriebskosten,
- mögliche kompensierende Maßnahmen,
- verbleibendes Restrisiko.
Die Entscheidung enthält Annahmen, Alternativen, Verantwortliche, Gültigkeitsdauer und Review-Auslöser. Wesentliche Restrisiken oder Ressourcenentscheidungen werden der Geschäftsleitung vorgelegt.
¶ 23. Nachweisführung
Ein Nachweisregister hält Metadaten und Referenzen, nicht zwingend vertrauliche Originalinhalte. Geeignete Nachweise können sein:
- freigegebene Richtlinien und Verfahrensanweisungen,
- technische Konfigurations- oder Abdeckungsberichte,
- Protokolle automatisierter Kontrollen,
- Stichproben und Prüfberichte,
- Wiederherstellungs-, Notfall- oder Angriffssimulationen,
- Berechtigungs- und Lieferantenreviews,
- Schulungs- und Kompetenznachweise,
- Vorfallakten und Lessons Learned,
- Managemententscheidungen und Maßnahmenfreigaben.
Jeder Nachweis erhält Owner, Schutzklasse, Zeitraum, betroffenen Scope, Anforderungs- und Kontrollreferenz, Ergebnis, geschützten Ablageort, Aufbewahrungsregel und nächsten Prüftermin. Screenshots ohne System-, Zeit-, Scope- und Ergebnisbezug sind regelmäßig zu schwach.
¶ 24. Wirksamkeitsprüfung
Wirksamkeit wird vor Durchführung einer Prüfung operationalisiert. Für jede wesentliche Kontrolle werden festgelegt:
- Prüfziel und zu prüfende Annahme,
- Population und Stichprobe,
- Methode und Werkzeuge,
- erforderliche Kompetenz und Unabhängigkeit,
- Sollkriterium und Toleranz,
- Umgang mit Abweichungen,
- Wiederholungsprüfung und Frist.
Beispiele sind der vollständige Entzug ausgeschiedener Zugänge innerhalb der Sollfrist, die Wiederherstellung eines relevanten Dienstes innerhalb der genehmigten Zeit, die tatsächliche MFA-Abdeckung privilegierter Zugänge oder die fristgerechte Behandlung kritischer Schwachstellen. Ergebnisse werden in Katalog, Risikoregister und Maßnahmenplan zurückgeführt.
¶ 25. Gap-Analyse
Die Gap-Analyse vergleicht je Anforderung:
- verbindliches Soll,
- betroffenen Scope,
- vorhandene Kontrolle,
- belegte Umsetzung,
- belegte Wirksamkeit,
- verbleibende Lücke,
- daraus entstehendes Risiko.
Lücken werden nicht nur nach Dokumentenbestand bewertet. Typische Befunde sind fehlender Scope, unklare Verantwortung, nicht angewendete Prozesse, unzureichende technische Abdeckung, veraltete Nachweise, nicht bestandene Tests oder fehlende Eskalation.
¶ 26. Maßnahmenplanung und Priorisierung
Jede Behandlung erhält Zielzustand, Arbeitspakete, Owner, Ressourcen, Termin, Abhängigkeiten, Zwischenkontrolle und Erfolgsprüfung. Die Priorisierung berücksichtigt:
- Bedeutung für relevante Dienste,
- Höhe und Dringlichkeit des Risikos,
- gesetzliche oder aufsichtsrechtliche Verbindlichkeit,
- Schutzwirkung und Reichweite,
- notwendige Voraussetzungen,
- Umsetzungsdauer und verfügbare Ressourcen,
- Möglichkeit vorläufiger kompensierender Kontrollen.
Die Roadmap bildet sachliche Reihenfolgen ab. Ein belastbares Asset- und Dienstinventar ist beispielsweise Voraussetzung für vollständiges Schwachstellenmanagement; definierte Wiederanlaufziele sind Voraussetzung für aussagekräftige Restore- und Wiederanlauftests.
¶ 27. Abweichungen und Risikoakzeptanz
Eine Abweichung ist eine kontrollierte, befristete Differenz zum festgelegten Soll. Sie dokumentiert:
- betroffene Anforderung, Kontrolle und Dienste,
- Ursache und erwartete Dauer,
- Risiko und mögliche Folgewirkungen,
- vorhandene oder geplante Kompensationsmaßnahmen,
- verantwortlichen Owner,
- Entscheidungskompetenz und Genehmigung,
- Ablaufdatum und Überwachung,
- Rückführungs- oder Behandlungsplan.
Eine interne Risikoakzeptanz hebt eine gesetzliche Verpflichtung nicht auf. Unvertretbare oder nicht ausreichend kompensierte Risiken werden eskaliert; wiederholte Verlängerungen lösen eine erneute Grundsatzentscheidung aus.
¶ 28. Rollen und Verantwortlichkeiten
| Rolle | Kernaufgabe im Maßnahmenkatalog |
|---|---|
| Geschäftsleitung | Umsetzung überwachen, Ressourcen bereitstellen, wesentliche Risiken und Abweichungen entscheiden |
| NIS2-Koordination | Katalogmethodik, Vollständigkeit, Rechtsreferenzen, Berichtswesen und Eskalation koordinieren |
| Informationssicherheitsbeauftragte | fachlich beraten, Konsistenz mit ISMS und Sicherheitsarchitektur prüfen |
| Dienst-/Prozessverantwortliche | Scope, Kritikalität, Auswirkungen und betriebliche Anforderungen bestätigen |
| Control Owner | Kontrolle gestalten, betreiben, dokumentieren und verbessern |
| Ausführende Rollen | Kontrollhandlungen fristgerecht durchführen und belegen |
| Risikoeigner | Risiko bewerten, Behandlung verfolgen und Restrisiko vorlegen |
| Prüfer/Audit | Design, Umsetzung und Wirksamkeit mit angemessener Unabhängigkeit bewerten |
| Recht/Compliance/Datenschutz | Rechtsquellen, Meldewege, Verträge und personenbezogene Nachweise prüfen |
| Einkauf/Lieferantenmanagement | Sicherheitsanforderungen und Anbieterüberwachung steuern |
Verantwortung bleibt auch bei ausgelagerten Tätigkeiten in der Einrichtung. Die Rolle des Dienstleisters wird vertraglich und operativ präzisiert.
¶ 29. Katalogpflege und Änderungssteuerung
Der Katalog wird mindestens jährlich sowie bei relevanten Ereignissen überprüft. Auslöser sind insbesondere:
- neue oder wesentlich geänderte Dienste,
- neue Standorte, Systeme, Cloud- oder Managed Services,
- Vorfälle und Beinahevorfälle,
- neue Schwachstellen oder Bedrohungsinformationen,
- Änderungen an Recht, Durchführungsakten oder Aufsichtsvorgaben,
- neue oder geänderte Lieferanten,
- nicht bestandene Kontrollen und Übungen,
- Änderungen des Stands der Technik,
- Audits, Prüfungen und Zertifizierungen.
Änderungen werden versioniert. Geänderte Anforderungen lösen eine Auswirkungsanalyse auf Kontrollen, Risiken, Nachweise, Schulungen und Verträge aus.
¶ 30. Managementinformation
Ein Managementbericht zeigt nicht nur einen pauschalen Erfüllungsgrad. Sinnvolle Aussagen sind:
- Abdeckung der zehn Mindestbereiche nach relevanten Diensten,
- Anforderungen ohne fachlich geprüfte Kontrollzuordnung,
- Kontrollen ohne Owner oder aktuellen Nachweis,
- umgesetzte, aber noch nicht wirksam geprüfte Kontrollen,
- offene hohe und kritische Lücken,
- überfällige Maßnahmen und wiederholte Terminverschiebungen,
- befristete Abweichungen vor Ablauf,
- Ergebnisse wesentlicher Tests und Übungen,
- Veränderungen der Risikoexposition,
- Ressourcen- oder Entscheidungsbedarf.
Jede Kennzahl nennt Scope, Stichtag, Datenquelle und Aussagegrenze. Eine hohe Dokumentenabdeckung darf nicht als hohe technische Wirksamkeit dargestellt werden.
¶ 31. Muster eines Katalogeintrags
| Feld | Musterwert – nicht real umgesetzt |
|---|---|
| Kontroll-ID | NIS2-30-10-01 |
| Anforderung | MFA für risikorelevante Zugriffe |
| Scope | privilegierte Administration eines relevanten Dienstes – organisationsbezogen zu bestätigen |
| Kontrollziel | missbräuchliche Nutzung kompromittierter Zugangsdaten erschweren |
| Control Owner | IAM-/IT-Betriebsverantwortung – zu benennen |
| Kontrollbeschreibung | privilegierte Zugriffe erfordern ein freigegebenes Mehrfaktorverfahren; Ausnahmen werden befristet und kompensiert |
| Frequenz | kontinuierlich; Abdeckungsreview quartalsweise und anlassbezogen |
| Akzeptanzkriterium | vollständige Abdeckung des bestätigten Scopes; genehmigte Ausnahmen separat |
| Umsetzungsstatus | nicht bewertet |
| Wirksamkeitsstatus | nicht geprüft |
| Nachweis | IAM-Auswertung und Stichprobe – geschützter Ablageort offen |
| Lücke/Maßnahme | nach organisationsbezogener Erhebung einzutragen |
| Freigabe | ausstehend |
Der Musterwert darf nicht unverändert als Nachweis einer realen Organisation übernommen werden.
¶ 32. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| zehn Überschriften ohne Detailkontrollen | keine prüfbare Umsetzung | Kontrollziele, Tätigkeiten, Owner und Kriterien ergänzen |
| vorhandene ISO-Seite gilt automatisch als erfüllt | Scope- und Deckungslücken bleiben verborgen | fachliche Mappingprüfung dokumentieren |
| „umgesetzt“ wird mit „wirksam“ gleichgesetzt | Scheinsicherheit | getrennte Status und Tests verwenden |
| ganze Mindestbereiche werden „nicht anwendbar“ gesetzt | unvollständige gesetzliche Betrachtung | jeden Mindestbereich behandeln; Detailabweichung begründen |
| nur technische Cyberangriffe werden betrachtet | gefahrenübergreifender Ansatz fehlt | physische, menschliche, Versorgungs- und Lieferkettenereignisse ergänzen |
| Screenshots ohne Kontext | Nachweis nicht reproduzierbar | System, Scope, Zeitpunkt, Prüfer und Ergebnis erfassen |
| Lieferantenzertifikat ersetzt eigene Bewertung | tatsächlicher Dienst bleibt ungeprüft | Zertifikatsscope und bezogenen Service vergleichen |
| pauschaler Erfüllungsprozentsatz | kritische Lücken werden verdeckt | risikobezogene Detail- und Trendinformation bereitstellen |
¶ 33. Qualitätscheck vor Freigabe
- Sind Betroffenheit, relevante Dienste und Rechtsquellen bestätigt?
- Wurde der Vorrang der Durchführungsverordnung oder sektoraler Vorgaben geprüft?
- Sind alle zehn Mindestbereiche vollständig betrachtet?
- Ist jede wesentliche Anforderung einer konkreten Kontrolle zugeordnet?
- Sind Scope, Owner, Frequenz und Akzeptanzkriterium festgelegt?
- Werden Zuordnung, Umsetzung, Prüfung und Wirksamkeit getrennt ausgewiesen?
- Besitzen Lücken Risiko, Zwischenkontrolle, Owner, Ressourcen und Termin?
- Sind Abweichungen befristet und auf angemessener Ebene genehmigt?
- Sind Nachweise geschützt, aktuell, auffindbar und dem richtigen Scope zugeordnet?
- Zeigt der Managementbericht auch Unsicherheiten und offene Entscheidungen?
- Enthält die öffentliche Wiki-Seite keine vertraulichen technischen Details oder realen Schwachstellen?
¶ 34. Offene Punkte vor organisationsbezogener Freigabe
- NIS2-Betroffenheit und Einrichtungsart formal bestätigen,
- relevante Dienste, Systeme, Standorte und Anbieter freigeben,
- anwendbare EU-, sektorale und KRITIS-Zusatzanforderungen bestimmen,
- Kontroll-ID-, Status- und Nachweismodell genehmigen,
- Control Owner und Prüfer benennen,
- vorhandene ISMS-/TISAX-Kontrollen fachlich auf Deckung prüfen,
- vollständige Gap-Analyse durchführen,
- Risikobehandlungs- und Ressourcenplan beschließen,
- Wirksamkeits- und Prüfplan freigeben,
- geschützte Nachweisablage und Aufbewahrungsregeln einrichten,
- Managementrhythmus und Eskalationsschwellen festlegen.
¶ 35. Verknüpfte Seiten im Wiki
- Betroffenheits- und Einstufungsprüfung
- Geltungsbereich und relevante Dienste
- NIS2–ISO-27001–TISAX-Mapping
- NIS2-Risikomethodik
- NIS2-Risikoregister
- Risikobehandlungsplan
- Verhältnismäßigkeit und Stand der Technik
- Wirksamkeitsprüfung
- Nachweisregister
- Pflichten der Geschäftsleitung
- Ressourcen und Berichtswesen
¶ 36. Amtliche Grundlagen
Die externen Quellen öffnen in einem neuen Tab. Maßgeblich ist der jeweils aktuelle Rechtsstand; Betroffenheit und konkrete Anforderungen sind organisationsbezogen zu prüfen.
- § 30 BSIG – Risikomanagementmaßnahmen besonders wichtiger und wichtiger Einrichtungen
- § 31 BSIG – besondere Anforderungen für Betreiber kritischer Anlagen
- § 39 BSIG – Nachweispflichten für Betreiber kritischer Anlagen
- EUR-Lex – Richtlinie (EU) 2022/2555, insbesondere Artikel 21
- EUR-Lex – Durchführungsverordnung (EU) 2024/2690 für bestimmte digitale Einrichtungsarten
¶ 37. Weiterführende Unterstützung durch SMCT-Management
SMCT-Management unterstützt bei Scope, Gap-Analyse, Kontrollkatalog, Risikobehandlung, Nachweisführung, Wirksamkeitsprüfung und Integration in bestehende ISO-27001- oder TISAX-Strukturen. Informationen zur NIS2-Beratung öffnen.
¶ 38. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Rechtsrahmen, Normenhierarchie, Scope, zehn Mindestbereiche mit Prüffragen und Nachweisen, KRITIS-Ergänzungen, Kontrollsteckbrief, Statusmodell, Nichtanwendbarkeit, Verhältnismäßigkeit, Gap-Analyse, Maßnahmen-, Abweichungs- und Managementsteuerung umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Katalogführung, Kontrollsteckbrief, Mapping, Reifestatus, Gap-Analyse, Prüfzyklus und Freigabekriterien vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Zehn Mindestbereiche strukturiert und mit bestehenden Wiki-Seiten verknüpft | Ausstehend |