¶ Rollen und Verantwortlichkeiten
Beispielorganisation: Diese Seite benennt keine realen Rolleninhaber, Stellvertretungen, Befugnisse oder Erreichbarkeiten. Jede Organisation muss das Modell an Rechtsform, Größe, relevante Dienste, Risiken und bestehende Führungsstrukturen anpassen und formal freigeben.
Verantwortungsgrenze: Operative Aufgaben dürfen qualifizierten Rollen übertragen werden. Die gesetzliche Pflicht der Geschäftsleitung, die Risikomanagementmaßnahmen umzusetzen und ihre Umsetzung zu überwachen, wird dadurch nicht auf IT, CISO, NIS2-Koordination oder externe Dienstleister verlagert.
Ein wirksames Rollenmodell beantwortet mehr als die Frage, wer eine Funktionsbezeichnung trägt. Es legt fest, wer entscheiden darf, wer ausführt, wer fachlich prüft, wer unabhängig kontrolliert, wer informiert wird und wer bei Abwesenheit übernimmt. Dazu gehören ausreichende Befugnisse, Ressourcen, Kompetenz, Zugänge, Berichtswege und Eskalationsrechte. Erst diese Verbindung macht aus einem Organigramm eine belastbare NIS2-Governance.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-ORG-01-03 |
| Dokumentenart | Rollen- und Verantwortlichkeitsmodell |
| Wiki.js-Pfad | /NIS2/01-Governance-und-Geschaeftsleitung/Rollen-und-Verantwortlichkeiten |
| Prozesseigner | Geschäftsleitung / NIS2-Koordination |
| Mitwirkende Rollen | Informationssicherheit, Diensteigner, IT/OT, BCM, Einkauf, Personal, Recht, Datenschutz und Audit |
| Status | Entwurf – Rollen, Befugnisse und Stellvertretungen nicht organisationsbezogen bestätigt |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Intern; persönliche Kontaktdaten und Bereitschaftspläne geschützt |
| Rechtsbezug | Insbesondere § 2 Nummer 13 sowie §§ 30, 32, 33 und 38 BSIG |
| Prüfanlass | mindestens jährlich sowie bei Reorganisation, Rollenwechsel, neuem Dienst, Vorfall oder Kontrollfeststellung |
Verantwortung, Ausführung, Prüfung, Freigabe und Vertretung eindeutig zuordnen. Eigene redaktionelle SVG-Grafik; zum Vergrößern öffnen.
¶ 1. Ziel und erwartete Arbeitsergebnisse
Das Rollenmodell soll sicherstellen, dass
- jede NIS2-relevante Pflicht und jeder wesentliche Prozess einen verantwortlichen Owner besitzt,
- Entscheidungen und operative Ausführung nicht miteinander verwechselt werden,
- Geschäftsleitung, Fachbereiche und Kontrollfunktionen dieselben Zuständigkeitsgrenzen kennen,
- zeitkritische Aufgaben auch außerhalb der Regelarbeitszeit handlungsfähig bleiben,
- Vertretung und Übergabe bei Abwesenheit oder Rollenwechsel funktionieren,
- Rollenkonflikte erkannt und durch Funktionstrennung oder kompensierende Kontrollen behandelt werden,
- Kompetenz- und Ressourcenlücken eskaliert statt stillschweigend akzeptiert werden und
- Benennung, Wahrnehmung und Wirksamkeit der Rollen nachweisbar sind.
Arbeitsergebnisse sind ein Rollenregister, genehmigte Rollenaufträge, prozessbezogene RACI-Matrizen, Kompetenzprofile, Stellvertretungs- und Eskalationsregeln sowie Nachweise regelmäßiger Rollenreviews.
¶ 2. Wer ist Geschäftsleitung im Sinne des BSIG?
§ 2 Nummer 13 BSIG definiert Geschäftsleitung als eine natürliche Person, die nach Gesetz, Satzung oder Gesellschaftsvertrag zur Führung der Geschäfte und zur Vertretung einer besonders wichtigen oder wichtigen Einrichtung berufen ist. Die konkrete Zuordnung richtet sich somit nach Rechtsform und Organisationsverfassung – nicht nach einer frei gewählten Projektbezeichnung.
Mögliche Geschäftsleitungsfunktionen können je nach Rechtsform beispielsweise Vorstand, Geschäftsführung oder eine vergleichbare gesetzlich beziehungsweise satzungsmäßig berufene Leitung sein. Nicht jede Bereichsleitung, jeder Prokurist und nicht automatisch CISO, CIO oder IT-Leitung ist dadurch Geschäftsleitung im Sinne des BSIG.
Die organisationsbezogene Prüfung dokumentiert:
- betroffenen Rechtsträger,
- Rechtsform und maßgebliche Vertretungsregel,
- Mitglieder des zuständigen Leitungsorgans,
- Ressort- und Gesamtverantwortung,
- Vertretungs- und Beschlussregeln,
- Verbindung zu Aufsichts- oder Kontrollorganen, soweit einschlägig.
¶ 3. Was kann delegiert werden – und was bleibt bei der Leitung?
Die Geschäftsleitung kann fachliche Vorbereitung und operative Durchführung organisieren. Dazu gehören beispielsweise Risikoanalysen, Maßnahmenumsetzung, Registerpflege, technische Bewertungen, Berichtserstellung und Vorfallkoordination. Die Beauftragung muss eindeutig sein und der beauftragten Rolle Befugnisse, Informationen, Kompetenz und Ressourcen geben.
Bei der Geschäftsleitung verbleiben insbesondere:
- Einrichtung und Freigabe einer angemessenen NIS2-Governance,
- Entscheidung über wesentliche Ressourcen und Prioritäten,
- Überwachung der Umsetzung der Risikomanagementmaßnahmen,
- Behandlung wesentlicher Abweichungen und Restrisiken,
- Sicherstellung eigener regelmäßiger Schulung,
- Nachsteuerung, wenn Berichte, Kontrollen oder Maßnahmen nicht ausreichen.
Delegation ist daher keine Entlastung durch bloße Benennung. Die Leitung muss Berichte verstehen, kritische Annahmen hinterfragen, Entscheidungen treffen und deren Umsetzung bis zur Wirksamkeitsprüfung verfolgen.
¶ 4. Rollenarchitektur
Das Modell unterscheidet vier Ebenen:
| Ebene | Zweck | Typische Rollen |
|---|---|---|
| Leitung und Entscheidung | Ziele, Ressourcen, Risiko- und Eskalationsentscheidungen | Geschäftsleitung, gegebenenfalls zuständiges Leitungsgremium |
| Koordination und Steuerung | Pflichten, Termine, Berichte und Schnittstellen zusammenführen | NIS2-Koordination, Informationssicherheitsmanagement |
| Eigentum und Ausführung | Dienste, Risiken, Maßnahmen, Systeme und Prozesse verantwortlich betreiben | Diensteigner, Risk Owner, Control Owner, IT/OT und Fachbereiche |
| Prüfung und unabhängige Beurteilung | Kriterien, Nachweise, Wirksamkeit und Governance bewerten | Kontrollfunktion, Compliance, interne Revision oder unabhängige Prüfung |
Recht, Datenschutz, Kommunikation und Personal können je nach Fragestellung beratende, prüfende, freigebende oder ausführende Aufgaben haben. Diese Rollen werden nicht pauschal einer Ebene zugeordnet, sondern pro Prozess eindeutig beschrieben.
¶ 5. Geschäftsleitung
Die Geschäftsleitung
- genehmigt das Rollen- und Governance-Modell,
- stellt angemessene personelle, technische und finanzielle Ressourcen bereit,
- entscheidet wesentliche Risiken, Prioritäten, Ausnahmen und Eskalationen,
- überwacht Umsetzung, Wirksamkeit und überfällige Maßnahmen,
- verlangt belastbare Daten und Korrekturen bei unzureichender Berichtsqualität,
- sorgt für regelmäßige eigene Schulung,
- stellt sicher, dass NIS2 in Unternehmensentscheidungen, Investitionen und Änderungen berücksichtigt wird.
Bei mehrgliedrigen Leitungsorganen werden Ressortzuständigkeiten dokumentiert. Eine Ressortzuordnung darf weder Informationslücken im Gesamtorgan erzeugen noch die erforderliche gemeinsame Beschlussfassung umgehen. Welche Punkte das Gesamtorgan behandeln muss, richtet sich nach Rechtsform, Geschäftsordnung, Risikowirkung und gesellschaftsrechtlichen Vorgaben.
¶ 6. NIS2-Koordination
Die NIS2-Koordination ist die zentrale Steuerungs- und Konsistenzfunktion. Sie
- führt Pflichten-, Fristen- und Statusübersichten,
- koordiniert Betroffenheitsprüfung, Registrierung und Behördenkontakte,
- bereitet Geschäftsleitungsberichte und Entscheidungsvorlagen vor,
- verfolgt Maßnahmen, Abweichungen und Nachweise,
- verbindet NIS2-Prozesse mit ISMS, Datenschutz, BCM und Lieferantensteuerung,
- überwacht Änderungen von Rechtsträgern, Diensten, Zuständigkeiten und gesetzlichen Vorgaben,
- eskaliert unklare Verantwortlichkeiten, fehlende Daten und drohende Fristverletzungen.
Die Koordination ist nicht automatisch fachlicher Owner jedes Risikos oder jeder Maßnahme. Sie darf den operativen Verantwortlichen nicht deren Bestätigungspflichten abnehmen und besitzt keine pauschale Vollmacht zur Risikoakzeptanz oder Behördenmeldung.
¶ 7. Informationssicherheitsfunktion
Die Informationssicherheitsfunktion entwickelt und pflegt Methoden für Risikoanalyse, Maßnahmensteuerung, Nachweisführung und Wirksamkeitsbewertung. Sie unterstützt bei Sicherheitsanforderungen, analysiert Querschnittsrisiken und berichtet wesentliche Abweichungen.
Abzugrenzen sind:
- methodische Steuerung versus operative Systemverantwortung,
- fachliche Beratung versus formale Managemententscheidung,
- Kontrollaufgabe versus unabhängige interne Revision,
- Informationssicherheit versus Datenschutzrechtsbewertung.
Wenn die Informationssicherheitsfunktion zugleich operative Maßnahmen umsetzt, wird die spätere Wirksamkeitsprüfung durch eine ausreichend unabhängige Rolle oder eine kompensierende Kontrolle abgesichert.
¶ 8. Diensteigner
Der Diensteigner verantwortet die fachliche Leistung eines relevanten Dienstes. Er bestätigt insbesondere:
- Zweck, Nutzer und Leistungsumfang,
- Kritikalität und tolerierbare Unterbrechung,
- fachliche Auswirkungen von Sicherheitsvorfällen,
- abhängige Prozesse, Systeme, Standorte und Lieferanten,
- Mindestanforderungen an Verfügbarkeit, Integrität und Vertraulichkeit,
- fachliche Akzeptanz von Not- und Ersatzverfahren,
- Änderungen, die Scope oder Risikolage beeinflussen.
Der Diensteigner ist nicht automatisch technischer Systemowner. Bei gemeinsam genutzten Plattformen müssen Dienst- und Systemverantwortung über dokumentierte Leistungs-, Schutz- und Eskalationsanforderungen verbunden werden.
¶ 9. Risk Owner, Control Owner und Maßnahmenverantwortung
Diese Rollen werden getrennt geführt:
| Rolle | Verantwortungsgegenstand | Typische Entscheidung oder Bestätigung |
|---|---|---|
| Risk Owner | konkretes Risiko und dessen Behandlung | Bewertung, Behandlungsoption, Restrisiko und Eskalation vorbereiten |
| Control Owner | dauerhafte organisatorische oder technische Kontrolle | Design, Betrieb, Nachweise und Kontrollverbesserung bestätigen |
| Maßnahmenverantwortlicher | zeitlich begrenzte Veränderungsmaßnahme | Umsetzung, Termin, Ressourcen und Abschlussnachweis steuern |
| Wirksamkeitsprüfer | definierte Wirkung unabhängig oder ausreichend objektiv beurteilen | Prüfergebnis, Abweichung und Aussagegrenze dokumentieren |
Ein Projektabschluss bedeutet nicht automatisch, dass die zugrunde liegende Kontrolle dauerhaft betrieben wird. Deshalb werden Maßnahmenverantwortung und Control Ownership bei Übergabe ausdrücklich verbunden.
¶ 10. Asset-, System- sowie IT-/OT-Verantwortung
Technische Verantwortliche sorgen innerhalb ihres Auftrags für:
- aktuelle Inventar-, Konfigurations- und Abhängigkeitsdaten,
- sicheren Betrieb und genehmigte Änderungen,
- Schwachstellen-, Patch- und Ausnahmebehandlung,
- Protokollierung, Überwachung und Alarmübergabe,
- Zugriffs- und Berechtigungssteuerung,
- Backup, Wiederherstellung und technische Notverfahren,
- belastbare technische Nachweise.
Bei IT-/OT-Schnittstellen wird geklärt, wer Anlagenverfügbarkeit, Produktionsrisiko, Wartungsfenster, Fernzugriff, Sicherheitsfreigabe und Notfallentscheidung verantwortet. Dienstleisterzugänge werden nicht als rein vertragliche Frage behandelt.
¶ 11. Incident Response, Meldekoordination und Krise
Zeitkritische Ereignisse benötigen ein vorab abgestimmtes Rollenmodell:
| Rolle | Aufgabe im Ereignis |
|---|---|
| Incident Lead | technische und organisatorische Bearbeitung koordinieren, Zeitlinie führen |
| Diensteigner | Dienstwirkung, Kritikalität und betriebliche Folgen beurteilen |
| NIS2-Meldekoordination | Erheblichkeitsprüfung, gesetzliche Fristen, Portalweg und Meldungsfassungen steuern |
| Recht / Datenschutz | parallele Rechtsfragen und getrennte Meldepflichten prüfen |
| Kommunikation | interne, Kunden-, Partner- und Öffentlichkeitskommunikation vorbereiten |
| Krisenleitung | bei festgelegtem Auslöser Prioritäten, Notbetrieb und Ressourcen entscheiden |
| Geschäftsleitung | wesentliche Entscheidungen treffen und angemessene Überwachung sicherstellen |
Das Rollenmodell darf die Fristen nach § 32 BSIG nicht durch unnötige Freigabestufen blockieren. Vorab definierte Befugnisse, Stellvertretungen und Eskalationswege stellen sicher, dass eine erforderliche Meldung auch nachts, am Wochenende oder bei Nichterreichbarkeit einzelner Personen bearbeitet werden kann.
¶ 12. BCM-, Notfall- und Krisenrollen
BCM- und Krisenrollen verantworten Business-Impact-Analyse, Notfallvorsorge, Wiederanlauf, Übungen und Krisenkommunikation innerhalb des genehmigten Rahmens. Sie stimmen fachliche Wiederanlaufziele mit Diensteignern und technische Möglichkeiten mit IT/OT ab.
Ein Wechsel vom Sicherheitsvorfall zur Krise wird durch definierte Kriterien ausgelöst. Dokumentiert werden Auslöser, Entscheidungsbefugnis, Führungswechsel, Informationsübergabe, Protokollierung und Rückkehr in den Normalbetrieb. Rollenübungen prüfen nicht nur Erreichbarkeit, sondern Entscheidungs- und Übergabefähigkeit.
¶ 13. Einkauf und Lieferantenmanagement
Einkauf und Lieferantenmanagement
- klassifizieren Lieferanten gemeinsam mit Diensteigner und Informationssicherheit,
- verankern Sicherheits-, Melde-, Audit-, Unterauftragnehmer- und Exit-Anforderungen,
- steuern Nachweise, Abweichungen, Vertragsänderungen und Eskalationen,
- sorgen für frühzeitige Einbindung vor Beschaffung oder wesentlicher Änderung.
Der Einkauf allein kann das technische oder fachliche Risiko eines Dienstes nicht bewerten. Der Diensteigner bestätigt die geschäftliche Abhängigkeit, Informationssicherheit die Sicherheitsanforderungen und Recht die vertragliche Gestaltung. Die Geschäftsleitung entscheidet wesentliche Konzentrations-, Rest- oder Exitrisiken.
¶ 14. Personal, Schulung und Joiner-Mover-Leaver
Die Personalorganisation unterstützt Rollenbesetzung, Kompetenzentwicklung und geregelte Veränderungen. Sie verbindet Eintritt, Wechsel, längere Abwesenheit und Austritt mit den zuständigen Fachrollen.
Der Rollenwechsel umfasst:
- Änderungsereignis und Wirksamkeitsdatum melden,
- neue Zuständigkeit und Stellvertretung bestätigen,
- Berechtigungen und Portalrollen anpassen,
- offene Risiken, Maßnahmen, Fristen und Vorfälle übergeben,
- Kontakt- und Bereitschaftslisten aktualisieren,
- nicht mehr erforderliche Zugänge entziehen,
- Abschluss und Übernahme dokumentieren.
Eine neue Rollenbezeichnung ohne verfügbare Zeit, Kompetenz oder Zugriffsmöglichkeiten gilt nicht als wirksame Besetzung.
¶ 15. Recht, Compliance und Datenschutz
Recht und Compliance unterstützen insbesondere bei Betroffenheit, Rechtsauslegung, Registrierung, Behördenkommunikation, Verträgen, Haftungs- und Aufsichtsfragen. Sie ersetzen nicht die technische oder dienstbezogene Sachverhaltsaufklärung.
Datenschutz und NIS2 können bei einem Sicherheitsvorfall parallel betroffen sein. Die Datenschutzfunktion führt die Bewertung nach DSGVO eigenständig und koordiniert Fakten und Zeitlinien mit dem Incident-Team. Eine NIS2-Meldung ersetzt keine Datenschutzmeldung – und umgekehrt. Gesetzliche Unabhängigkeits- und Verschwiegenheitsanforderungen der jeweiligen Funktion bleiben bestehen.
¶ 16. Kommunikation
Die Kommunikationsrolle bereitet abgestimmte Informationen für Beschäftigte, Kunden, Partner, Behörden und Öffentlichkeit vor. Sie erhält bestätigte Fakten, Aussagegrenzen und Freigaberegeln. Technische Spekulationen, personenbezogene Daten, Geschäftsgeheimnisse und Ermittlungsinformationen werden geschützt.
Vordefinierte Textbausteine dürfen den konkreten Sachverhalt nicht vorwegnehmen. Im Vorfall ist geregelt, wer Inhalte liefert, wer rechtlich prüft, wer freigibt und wer tatsächlich kommuniziert.
¶ 17. Prüfung, Compliance-Kontrolle und interne Revision
Prüfrollen beurteilen Kriterien, Nachweise, Umsetzung und Wirksamkeit mit angemessener Objektivität. Je nach Organisation können operative Kontrolle, Compliance-Prüfung und interne Revision unterschiedliche Ebenen bilden.
Grundregeln sind:
- niemand bestätigt allein die Wirksamkeit der eigenen kritischen Maßnahme,
- Prüfauftrag, Scope, Kriterien und Befugnisse sind dokumentiert,
- Feststellungen erhalten Owner, Termin und Eskalation,
- Prüfergebnisse werden nicht durch den geprüften Bereich still geändert,
- die Geschäftsleitung erhält wesentliche Abweichungen und unabhängige Beurteilungen.
Kleine Organisationen dürfen Rollen kombinieren, müssen Interessenkonflikte aber sichtbar machen und durch Vier-Augen-Prüfung, externe Stichprobe oder unabhängigen Leitungsreview kompensieren.
¶ 18. Wiki-, Dokumenten- und Systemadministration
Technische Administratoren betreiben Plattform, Berechtigungen, Datensicherung und Verfügbarkeit. Diese technische Rolle verleiht keine fachliche Freigabebefugnis. Umgekehrt darf eine fachlich verantwortliche Person nicht allein wegen ihrer Rolle administrative Vollrechte erhalten.
Für kritische Systeme gelten genehmigte Rollen, protokollierte Änderungen, regelmäßige Berechtigungsreviews, Notfallzugänge und Trennung zwischen Inhaltseigentum und Systembetrieb. Das Wiki veröffentlicht nur freigegebene Methodik; geschützte Originalnachweise bleiben außerhalb der öffentlichen Seite.
¶ 19. Verbindlicher Rollenauftrag
Jede wesentliche Rolle erhält einen dokumentierten Auftrag mit mindestens:
Rollen-ID · Bezeichnung · Zweck · Aufgaben · Entscheidungen · Befugnisse · Informationszugang · Berichtslinie · Eskalationsrecht · erforderliche Kompetenz · Kapazität · Stellvertretung · Unvereinbarkeiten · Nachweise · Reviewtermin · Annahme durch Rolleninhaber
Der Rolleninhaber bestätigt den Auftrag und offene Einschränkungen. Fehlen Budget, Zeit, Datenzugang oder Weisungsbefugnis, wird dies als Governance-Lücke behandelt und an die entscheidende Stelle eskaliert.
¶ 20. Rollenregister
| Feld | Mindestinhalt |
|---|---|
| Rollen-ID | eindeutige Referenz |
| Rolle / Prozess | Funktionsbezeichnung und betroffener Prozess |
| Organisationseinheit | Rechtsträger, Bereich und Berichtslinie |
| Rolleninhaber | geschützte Referenz auf benannte Person oder Funktion |
| Stellvertretung | primäre und gegebenenfalls weitere Vertretung |
| Befugnisse | Entscheidungen, Freigaben, Weisungs- und Eskalationsrechte |
| Kompetenz | Sollprofil, Iststand, Lücke und Qualifizierungsmaßnahme |
| Kapazität | vorgesehene Zeit, Bereitschaft und bekannte Einschränkung |
| Zugänge | erforderliche Systeme, Portale und Notfallinformationen |
| Unvereinbarkeiten | Rollenkonflikte und kompensierende Kontrollen |
| Nachweise | Auftrag, Schulung, Übung, Review und Übergabe |
| Lebenszyklus | Beginn, letzter Review, nächste Prüfung und Ende |
Persönliche Telefonnummern, private Kontaktdaten und Bereitschaftspläne werden nicht auf der öffentlichen Wiki-Seite gespeichert.
¶ 21. RACI-Regeln
Das RACI-Modell wird einheitlich verwendet:
A – Accountable: trägt die Ergebnis- und Entscheidungsverantwortung; je Aktivität grundsätzlich genau eine eindeutig führende Rolle,R – Responsible: führt die Aktivität aus; mehrere ausführende Rollen sind möglich,C – Consulted: wird rechtzeitig fachlich einbezogen,I – Informed: erhält die erforderliche Information.
RACI ersetzt keine Prozessbeschreibung. Für zeitkritische Schritte werden zusätzlich Frist, Auslöser, Übergabepunkt, Befugnis und Stellvertretung dokumentiert. Ist „A“ überall die Geschäftsleitung, ohne operative Owner und Entscheidungsgrenzen zu benennen, ist die Matrix nicht handlungsfähig.
¶ 22. RACI-Muster für Governance und Risikomanagement
| Aktivität | Geschäftsleitung | NIS2-Koordination | Fach-/Diensteigner | Prüfung |
|---|---|---|---|---|
| Betroffenheitsentscheidung | A | R | C | Recht C |
| NIS2-Geltungsbereich | A | R | R/C | Informationssicherheit C |
| Risikomethodik freigeben | A | R | C | Kontrollfunktion C |
| Risiko bewerten | I/A bei wesentlichem Risiko | C | R | Informationssicherheit C |
| Risikobehandlung entscheiden | A | C | R für Vorlage | Recht/Finanzen C |
| Maßnahme umsetzen | I | C | R | Control Owner C |
| Wirksamkeit beurteilen | I/A für Ergebnis | C | C | unabhängige Prüffunktion R |
| Leitungsbericht | A für Behandlung | R | C | Daten-/Kontrollowner C |
Die konkrete Matrix wird an Rechtsform und Prozesse angepasst. „A“ beschreibt keine automatische Einzelzeichnungsbefugnis; Satzung, Geschäftsordnung und Vertretungsregeln bleiben maßgeblich.
¶ 23. RACI-Muster für Registrierung und Vorfälle
| Aktivität | Geschäftsleitung | NIS2-Koordination | Fachrolle | Prüfung/Beratung |
|---|---|---|---|---|
| Registrierungsdatensatz erstellen | I/A nach interner Regel | R | IT/Dienst R/C | Recht C |
| Registrierung aktualisieren | I | R | Datenowner R/C | Recht C |
| Vorfall technisch behandeln | I | C | Incident/IT R | Forensik C |
| Dienstwirkung beurteilen | I | C | Diensteigner R | BCM C |
| Erheblichkeit prüfen | I/A nach Regel | R | Incident/Dienst C | Recht/Datenschutz C |
| NIS2-Meldung übermitteln | I/A nach vorab definierter Befugnis | Meldekoordination R | Incident C | Recht C |
| Krise ausrufen | A | C | Krisenleitung R/C | Recht/Kommunikation C |
| Abschluss und Lessons Learned | A für wesentliche Maßnahmen | R | beteiligte Owner R/C | Prüfung C |
Die Matrix darf keine zusätzliche Freigabehürde erzeugen, die gesetzliche Meldefristen gefährdet. Die reale Organisation legt vorab fest, wer bei Zeitdruck verbindlich handeln darf.
¶ 24. Schnittstellen und Übergaben
| Schnittstelle | Erforderliche Übergabe |
|---|---|
| Geschäftsleitung – NIS2-Koordination | Risiken, Entscheidungen, Ressourcen, Termine und Eskalationen |
| Diensteigner – IT/OT | Schutzanforderungen, Abhängigkeiten, Änderungen und Dienstwirkung |
| Informationssicherheit – Datenschutz | gemeinsame Fakten, getrennte Rechtsbewertungen und Meldewege |
| Einkauf – Diensteigner – Sicherheit | Kritikalität, Vertragsanforderungen, Nachweise, Änderungen und Exit |
| SOC/IT – Incident Lead | Alarm, Zeitlinie, technische Befunde, Eindämmung und Beweise |
| Incident Lead – Meldekoordination | Kenntniszeitpunkt, Erheblichkeit, Auswirkungen und Meldedaten |
| BCM – Krisenleitung | Aktivierung, Notbetrieb, Wiederanlauf und Kommunikationslage |
| Maßnahmenverantwortlicher – Control Owner | Projektabschluss, Betriebsübergabe, Nachweis und Wirksamkeitskriterium |
Für jede Übergabe werden Format, Frist, führende Quelle, Empfänger und Bestätigung definiert. Eindeutige IDs verbinden Register; unkontrollierte Kopien sollen vermieden werden.
¶ 25. Stellvertretung und Bereitschaft
Eine Stellvertretung ist erst wirksam, wenn sie
- den Rollenauftrag kennt,
- fachlich ausreichend befähigt ist,
- erforderliche Systeme und Informationen erreichen kann,
- Entscheidungs- und Eskalationsbefugnisse besitzt,
- in Kontakt- und Bereitschaftsplänen korrekt eingetragen ist,
- durch Test oder Übung praktisch bestätigt wurde.
Für zeitkritische Rollen werden mehrere Eskalationsstufen, sichere Kontaktwege und ein Vorgehen bei Nichterreichbarkeit festgelegt. Gemeinsame Abwesenheiten von Primärrolle und Vertretung werden in der Planung berücksichtigt.
¶ 26. Funktionstrennung und Interessenkonflikte
Besonders kritisch sind:
- Beantragung und eigene Genehmigung privilegierter Berechtigungen,
- Umsetzung und alleinige Wirksamkeitsbestätigung derselben Maßnahme,
- Lieferantenauswahl und unabhängige Lieferantenbewertung,
- Risikoerstellung und endgültige Risikoakzeptanz,
- Vorfallbearbeitung und alleinige Bewertung der eigenen Verfahrensleistung,
- Systemadministration und unkontrollierte Änderung von Nachweisen.
Wenn organisatorische Trennung nicht möglich ist, werden kompensierende Kontrollen festgelegt: dokumentierte Zweitprüfung, unabhängige Stichprobe, Vier-Augen-Freigabe, externe Prüfung, verstärkte Protokollierung oder Managementreview.
¶ 27. Kompetenz, Kapazität und Befähigung
Jede Rolle besitzt ein Sollprofil aus Fachwissen, Methodenkompetenz, Entscheidungskompetenz und praktischer Erfahrung. Die Befähigung kann durch Schulung, Einweisung, Übungen, betreute Anwendung und nachgewiesene Erfahrung aufgebaut werden.
Kapazität wird separat geprüft. Eine fachkundige Person ohne verfügbare Zeit oder ohne Vertretung ist keine ausreichende Rollenabdeckung. Kompetenzlücken erhalten Maßnahme, Owner, Termin und befristete Zwischenregelung.
¶ 28. Rollenlebenszyklus
| Phase | Mindestkontrolle |
|---|---|
| Bedarf | Rolle aus Pflicht, Prozess, Risiko oder Dienst ableiten |
| Design | Aufgaben, Befugnisse, RACI, Kompetenz und Unvereinbarkeiten festlegen |
| Benennung | Person oder Funktion formal beauftragen und Annahme dokumentieren |
| Befähigung | Zugänge, Informationen, Schulung, Zeit und Stellvertretung bereitstellen |
| Betrieb | Aufgaben, Berichte, Entscheidungen und Eskalationen wahrnehmen |
| Review | Wirksamkeit, Konflikte, Kapazität und Aktualität prüfen |
| Änderung | Übergabe, Zugangsänderung und Kommunikation steuern |
| Beendigung | Berechtigungen entziehen, offene Aufgaben übergeben, Nachweise archivieren |
Auslöser für einen außerplanmäßigen Review sind Reorganisation, neuer relevanter Dienst, wesentlicher Vorfall, wiederholte Fristverletzung, Auditfeststellung oder Ausfall einer Schlüsselrolle.
¶ 29. Nachweise der Rollenwirksamkeit
Eine Benennungsurkunde allein belegt keine wirksame Rollenwahrnehmung. Geeignete Nachweise sind beispielsweise:
- genehmigter Rollenauftrag und bestätigte Stellvertretung,
- aktuelle RACI- und Prozesszuordnung,
- Kompetenz- und Schulungsnachweise,
- überprüfte Portal- und Systemberechtigungen,
- Berichte, Entscheidungen und dokumentierte Eskalationen,
- Erreichbarkeits- oder Übergabetests,
- Vorfall- und Notfallübungen,
- Rollenreviews, Auditfeststellungen und Korrekturmaßnahmen.
Nachweise enthalten Scope, Zeitraum, Owner, Prüfer und Ergebnis. Persönliche Daten und sicherheitskritische Informationen bleiben in einer geschützten Ablage.
¶ 30. Kennzahlen und Managementinformation
Mögliche Kennzahlen sind:
- Anteil der wesentlichen Prozesse mit eindeutigem
Aund mindestens einemR, - Anteil kritischer Rollen mit bestätigter Stellvertretung,
- offene Rollen ohne ausreichende Befugnis oder Kapazität,
- überfällige Rollen- und Berechtigungsreviews,
- nicht geschlossene Kompetenzlücken,
- fehlgeschlagene Erreichbarkeits- und Übergabetests,
- Rollenkonflikte ohne genehmigte kompensierende Kontrolle,
- Fristverletzungen aufgrund unklarer Übergaben oder Zuständigkeiten.
Kennzahlen besitzen Definition, Datenquelle, Stichtag, Owner, Zielwert, Eskalationsschwelle und Aussagegrenze. Eine formal besetzte, aber nicht verfügbare Rolle wird nicht als wirksam gezählt.
¶ 31. Muster eines Rollenregistereintrags
| Feld | Musterwert |
|---|---|
| Rollen-ID | NIS2-ROLE-MUSTER-01 |
| Rolle | NIS2-Meldekoordination – Mustereintrag |
| Rolleninhaber | nicht benannt |
| Stellvertretung | nicht benannt |
| Befugnis | organisationsbezogen festzulegen |
| Kompetenzstatus | nicht bewertet |
| Kapazität / Bereitschaft | nicht bestätigt |
| erforderliche Zugänge | BSI-Portal und geschützte Vorfallakte – nur als Muster |
| Rollenkonflikt | noch zu prüfen |
| nächster Schritt | Auftrag, Vertretung und Meldebefugnis freigeben |
Der Mustereintrag bestätigt weder eine benannte Person noch die tatsächliche Meldebereitschaft.
¶ 32. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| CISO wird pauschal als „NIS2-verantwortlich“ benannt | Leitungspflicht und operative Aufgaben vermischt | Geschäftsleitungs-, Koordinations- und Owner-Rollen getrennt beschreiben |
RACI enthält mehrere unklare A |
niemand entscheidet verbindlich | je Aktivität eindeutige führende Ergebnisverantwortung festlegen |
| Rolle ohne Zeit oder Befugnis | Auftrag kann nicht erfüllt werden | Ressourcen und Eskalationsrecht mitbenennen |
| Stellvertretung nur namentlich eingetragen | bei Abwesenheit keine Handlungsfähigkeit | Zugang, Kompetenz und Übung bestätigen |
| externe Leistung ersetzt internen Owner | Verantwortung und Kontrolle fehlen | internen Leistungs- und Risikoverantwortlichen benennen |
| Prüfer kontrolliert ausschließlich eigene Arbeit | Wirksamkeitsaussage nicht objektiv | unabhängige oder kompensierende Prüfung einsetzen |
| Rollenwechsel ohne Übergabe | Fristen, Risiken und Zugänge gehen verloren | Joiner-Mover-Leaver- und Übergabecheckliste anwenden |
| Kontaktliste im öffentlichen Wiki | personenbezogene und operative Informationen offengelegt | geschützte Kontakt- und Bereitschaftsakte verwenden |
¶ 33. Qualitätscheck vor Freigabe
- Ist die Geschäftsleitung je betroffenem Rechtsträger rechtlich und organisatorisch bestimmt?
- Sind Leitungspflicht, Koordination, Ausführung und Prüfung klar getrennt?
- Besitzt jede wesentliche Pflicht und Aktivität eine eindeutige führende Verantwortung?
- Sind Diensteigner, Risk Owner, Control Owner und Maßnahmenverantwortliche unterschieden?
- Sind Vorfall-, Melde-, Krisen- und Kommunikationsrollen fristgerecht handlungsfähig?
- Sind Aufgaben, Befugnisse, Informationszugang und Eskalationsrecht dokumentiert?
- Sind Stellvertretungen befähigt, berechtigt, erreichbar und getestet?
- Sind Rollenkonflikte und kompensierende Kontrollen dokumentiert?
- Stimmen Rollenregister, RACI, Prozessseiten, Kontaktlisten und Berechtigungen überein?
- Werden Rollenwechsel, Übergaben und Zugriffsänderungen kontrolliert durchgeführt?
- Sind Kompetenz und verfügbare Kapazität getrennt bewertet?
- Belegen Berichte, Entscheidungen, Übungen und Reviews die tatsächliche Rollenwahrnehmung?
- Enthält die öffentliche Seite keine persönlichen Kontakt- oder Bereitschaftsdaten?
¶ 34. Offene Punkte vor organisationsbezogener Freigabe
- Geschäftsleitung je relevantem Rechtsträger bestimmen,
- Rollenarchitektur und Prozesseigner genehmigen,
- Rolleninhaber und qualifizierte Stellvertretungen benennen,
- Rollenaufträge einschließlich Befugnis und Eskalationsrecht freigeben,
- Diensteigner, Risk Owner, Control Owner und Maßnahmenverantwortliche zuordnen,
- RACI-Matrizen für Governance, Registrierung und Vorfälle abstimmen,
- Incident-, Melde-, Krisen- und Kommunikationsbefugnisse festlegen,
- Funktionstrennungen und kompensierende Kontrollen genehmigen,
- Kompetenzprofile, Kapazität und Schulungsmaßnahmen bestätigen,
- Rollenregister mit Kontakt-, Berechtigungs- und Organisationsdaten abgleichen,
- Rollenreview und Wirksamkeitsprüfung terminieren.
¶ 35. Verknüpfte Seiten im Wiki
- Pflichten der Geschäftsleitung
- Ressourcen und Berichtswesen
- Schulung der Geschäftsleitung
- Behörden und Kontaktstellen
- Registrierung und Aktualisierung
- Schnittstellen zu ISMS und DSGVO
- NIS2-Risikomethodik
- Maßnahmenkatalog nach BSIG
- NIS2-Nachweisregister
- Melderegister und Fristenkontrolle
- Relevante Dienste und Prozesse
- ISMS Rollen und Verantwortlichkeiten
- Kontakt- und Eskalationslisten
¶ 36. Amtliche Grundlagen
Die externen Links öffnen in einem neuen Tab. Vor einer organisationsbezogenen Anwendung sind Rechtsstand, Betroffenheit und gesellschaftsrechtliche Zuständigkeiten zu prüfen.
- § 2 BSIG – Begriffsbestimmungen, insbesondere Geschäftsleitung
- § 30 BSIG – Risikomanagementmaßnahmen
- § 32 BSIG – Meldepflichten
- § 33 BSIG – Registrierungspflicht
- § 38 BSIG – Umsetzungs-, Überwachungs- und Schulungspflicht der Geschäftsleitung
¶ 37. Weiterführende Unterstützung durch SMCT-Management
SMCT-Management unterstützt bei Rollenarchitektur, RACI, Geschäftsleitungssteuerung, Schnittstellen, Kompetenzprofilen und der Verbindung zu bestehenden ISMS- und Datenschutzrollen. Informationen zur NIS2-Beratung öffnen.
¶ 38. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Geschäftsleitungsdefinition, Delegationsgrenzen, Rollenarchitektur, Fach- und Kontrollrollen, Rollenauftrag, Register, RACI, Stellvertretung, Funktionstrennung, Rollenlebenszyklus, Nachweise und Kennzahlen umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Benennung, Funktionstrennung, Schnittstellen, Bereitschaft, Kompetenz, Kennzahlen und Freigabekriterien vertieft | Ausstehend |
| 0.1 | 08.08.2026 | NIS2-Rollen- und Verantwortlichkeitsmodell erstellt | Ausstehend |