¶ Relevante Dienste und Prozesse
Leeres Musterregister: Diese Seite enthält keine realen Unternehmensdienste und keine bestätigte NIS2-Einstufung. Welche Dienste und Prozesse einzubeziehen sind, folgt aus der dokumentierten Betroffenheitsprüfung, dem organisationsbezogenen Geltungsbereich und einer fachlich freigegebenen Ende-zu-Ende-Analyse. Musterstatus und Beispielwerte belegen weder Umsetzung noch Wirksamkeit.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-03-01 |
| Dokumentenart | Dienstekatalog, Prozesszuordnung und Scope-Steuerung |
| Wiki.js-Pfad | /NIS2/03-Assets-Prozesse-und-Dienste/Relevante-Dienste-und-Prozesse |
| Verantwortlich | Dienst-/Prozess-Owner und NIS2-Koordination |
| Mitwirkende | Fachbereiche, IT/OT, Informationssicherheit, BCM, Einkauf, Datenschutz, Recht und Controlling |
| Status | Entwurf – keine realen Dienste, Prozesse oder Scopegrenzen freigegeben |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Methodik intern; detaillierte Dienstketten und operative Abhängigkeiten vertraulich |
| Review | mindestens jährlich sowie bei rechtlichen, organisatorischen, technischen oder leistungsbezogenen Änderungen |
Relevante Dienste Ende-zu-Ende beschreiben und mit erforderlichen Prozessen und Abhängigkeiten verbinden. Eigene redaktionelle SVG-Grafik. Zum Vergrößern in einem neuen Tab öffnen.
¶ 1. Steuerungscockpit
■ Dienste ohne bestätigten Owner
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
▲ Ungeklärte Scope-Entscheidungen
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
● Unvollständige Dienstketten
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
? Überfällige Reviews/Tests
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein fehlender Wert wird als „— / nicht ermittelt“ angezeigt und nicht als null offene Punkte interpretiert. Das Cockpit verwendet nur definierte Datenquellen und freigegebene Statusregeln.
¶ 2. Zweck der Seite
Der Dienstekatalog übersetzt die rechtliche Einordnung der Einrichtung in eine steuerbare betriebliche Sicht. Er beantwortet:
- welche konkrete Leistung aufgrund welcher Tätigkeit betrachtet wird,
- für wen, wo, wann und mit welchem Ergebnis sie erbracht wird,
- wo der Dienst fachlich und organisatorisch beginnt und endet,
- welche Kern-, Unterstützungs-, Sicherheits-, Incident-, Notfall- und Wiederanlaufprozesse erforderlich sind,
- welche Informationen, Systeme, Personen, Standorte und externen Leistungen die Prozesskette tragen,
- welche Ausfallfolgen und Mindestleistungen zu berücksichtigen sind und
- wer Entscheidungen, Änderungen, Risiken und Nachweise verantwortet.
Der Katalog ist damit das Bindeglied zwischen Betroffenheitsprüfung, NIS2-Geltungsbereich, Risikoanalyse, Assetmanagement, Lieferantensteuerung, Incident Response, BCM und Nachweisführung.
¶ 3. Rechtlicher Bezug und Abgrenzung
| Bezug | Bedeutung für diese Arbeitsseite |
|---|---|
| § 28 BSIG | ordnet Einrichtungen anhand Einrichtungsarten, Tätigkeiten, angebotener Waren/Dienstleistungen und Größenmerkmale zu; vernachlässigbare Tätigkeiten können unter den gesetzlichen Voraussetzungen gesondert betrachtet werden. |
| Anlagen 1 und 2 BSIG | bestimmen Sektoren, Teilsektoren und Einrichtungsarten, an die der Dienstekatalog fachlich anknüpft. |
| § 30 Abs. 1 BSIG | betrifft die informationstechnischen Systeme, Komponenten und Prozesse, die für die Erbringung der Dienste genutzt werden. |
| § 30 Abs. 2 BSIG | verlangt einen gefahrenübergreifenden Risikomanagementansatz einschließlich Betriebskontinuität, Lieferkette und Wirksamkeitsprüfung. |
| § 33 BSIG | erfordert Registrierungsangaben unter anderem zum relevanten Sektor und zu Mitgliedstaaten, in denen erfasste Dienste erbracht werden. |
Der Dienstekatalog entscheidet nicht allein über die rechtliche Betroffenheit. Er dokumentiert, wie eine freigegebene oder vorsorgliche Einrichtungszuordnung in konkrete Leistungen, Prozessketten und technische Ressourcen übersetzt wird. Spezialgesetze, Aufsichtsregime und mögliche Ausnahmen werden separat geprüft.
¶ 4. Von der Tätigkeit zum steuerbaren Dienst
1 · Einrichtungsart
Sektor, Teilsektor, rechtliche Zuordnung
Sektor, Teilsektor, rechtliche Zuordnung
2 · Tätigkeit
angebotene Leistung oder betriebliche Funktion
angebotene Leistung oder betriebliche Funktion
3 · Dienst
Empfänger, Ergebnis, Grenze, Region, Zeit
Empfänger, Ergebnis, Grenze, Region, Zeit
4 · Prozesse
Kern, Betrieb, Sicherheit, Notfall
Kern, Betrieb, Sicherheit, Notfall
5 · Ressourcen
Information, System, Mensch, Ort, Dritte
Information, System, Mensch, Ort, Dritte
Die Reihenfolge ist eine Nachvollziehbarkeitskette, keine automatische Rechtsentscheidung. Jede Stufe erhält Quelle, Begründung, verantwortliche Rolle, Status und Reviewdatum.
¶ 5. Dienst, Produkt, Prozess und System unterscheiden
| Begriff | Leitfrage | Beispielhafte Abgrenzung |
|---|---|---|
| Dienst | Welchen nutzbaren Wert oder welches Ergebnis erhält ein interner oder externer Empfänger? | Bereitstellung einer definierten Leistung |
| Produkt | Welche Ware, Plattform oder Lösung wird angeboten oder eingesetzt? | physisches Produkt, Software oder Paket |
| Geschäftsprozess | Welche fachlichen Schritte erzeugen das Ergebnis? | Auftrag bis Leistung/Abschluss |
| IT-/OT-Service | Welche technische Fähigkeit unterstützt den Dienst? | Identität, Plattform, Netzwerk, Steuerung |
| System/Asset | Welche konkrete Ressource verarbeitet, speichert oder überträgt? | Anwendung, Datenbank, Anlage, Endpunkt |
| Projekt | Welche zeitlich befristete Veränderung schafft oder ändert den Dienst? | Einführung, Migration oder Standortwechsel |
Ein System kann mehrere Dienste unterstützen; ein Dienst benötigt regelmäßig mehrere Prozesse und Systeme. Diese Beziehungen werden referenziert, nicht durch doppelte Stammdaten ersetzt.
¶ 6. Dienstgrenze bestimmen
| Abgrenzungsfrage | zu dokumentieren | Warnsignal |
|---|---|---|
| Wer empfängt die Leistung? | Kunden, Partner, Öffentlichkeit, interne Einheit oder anderer Dienst | nur Abteilungsname genannt |
| Was ist das Ergebnis? | messbarer Nutzen, Produkt, Entscheidung, Verfügbarkeit oder Übergabe | Tätigkeit statt Ergebnis beschrieben |
| Wann beginnt/endet der Dienst? | Auslöser, Eingabe, Übergabe, Abschluss und Restpflicht | Grenze nur aus Organigramm abgeleitet |
| Wo wird er erbracht? | Staaten, Regionen, Standorte, Cloud-/Providerregionen | rechtliche/technische Region fehlt |
| Wann muss er verfügbar sein? | Betriebszeit, Saison, Bereitschaft, Stichtage | „24/7“ ohne Leistungsinhalt |
| Welche Variante gilt? | Standard, Premium, Notbetrieb, manuell, regional | Varianten vermischt |
| Was ist bewusst ausgeschlossen? | begründete Komponente/Tätigkeit, Risiko und Entscheidung | Outsourcing pauschal ausgeschlossen |
| Welche Restpflicht bleibt? | Daten, Meldung, Aufbewahrung, Support, Exit | Dienstende mit Vertragsende gleichgesetzt |
Eine geeignete Dienstgrenze ist fachlich verständlich, technisch verknüpfbar und prüfbar. Sie darf weder so weit sein, dass Verantwortungen verschwimmen, noch so eng, dass wesentliche Unterstützungs- oder Notfallprozesse verschwinden.
¶ 7. Dienstesteckbrief – Pflichtfelder
| Feldgruppe | Mindestinhalt |
|---|---|
| Identität | Dienst-ID, Name, Kurzbeschreibung, Version, Status |
| Rechts-/Scopebezug | Einrichtungsart, Tätigkeit, Sektor, Entscheidung und Begründung |
| Leistung | Ergebnis, Empfänger, Qualitätsmerkmale, Varianten und Leistungsgrenze |
| Ort und Zeit | Staaten/Regionen, Standorte, Betriebs- und Bereitschaftszeiten, Spitzenfenster |
| Verantwortung | Dienst-Owner, Stellvertretung, Prozess-, Informations-, System- und Lieferanten-Owner |
| Prozesse | Kern-, Unterstützung-, Betrieb-, Sicherheits-, Incident-, Krisen- und Wiederanlaufprozesse |
| Ressourcen | Informationen, Systeme, Identitäten, Personal, Wissen, Standorte und Versorgung |
| Dritte | Anbieter, Cloud, Unterauftragnehmer, Partner, Verträge und Exit |
| Kritikalität | Auswirkungsdimensionen, MTPD/MAO, RTO, RPO und Mindestbetriebsniveau |
| Sicherheit | Risiken, Kontrollen, Ausnahmen, Vorfälle und Wirksamkeitsstatus |
| Nachweise | Register-, Test-, Review-, Freigabe- und Ablagereferenzen |
| Steuerung | Änderungsreferenz, Reviewdatum, offene Punkte und Entscheidung |
¶ 8. Leistungsversprechen und Mindestbetriebsniveau
| Ebene | Beschreibung | Beispielhafte Messgröße |
|---|---|---|
| Normalbetrieb | vollständige vereinbarte Leistung | Menge, Qualität, Verfügbarkeit, Durchlaufzeit |
| degradierter Betrieb | reduzierte Leistung bei Störung | Prioritätskunden, begrenzte Menge/Funktion |
| Mindestbetrieb | zwingend aufrechtzuerhaltendes Leistungsniveau | Mindestkapazität, maximale Wartezeit, Sicherheitsfunktion |
| Notverfahren | alternative manuelle oder technische Erbringung | Aktivierungszeit, Kapazität, Dauer, Fehlerquote |
| Wiederanlauf | schrittweiser Aufbau nach Unterbrechung | Reihenfolge, RTO, Abnahmezustand |
| Rückkehr | kontrollierter Übergang in den Normalbetrieb | Datenabgleich, Rückerfassung, Stabilitätskriterium |
Ein SLA oder eine technische Verfügbarkeit ist nicht automatisch das Mindestbetriebsniveau. Entscheidend ist, welche Leistung der Empfänger während einer Störung tatsächlich benötigt und welche Folgen ein Unterschreiten auslöst.
¶ 9. Empfänger- und Betroffenensicht
| Empfängergruppe | mögliche Auswirkung | erforderliche Information |
|---|---|---|
| externe Kunden | Leistungsausfall, Verzögerung, Fehlleistung | Vertrag, Kontakt, Priorität, Kommunikationsweg |
| Öffentlichkeit/Versorgung | Einschränkung einer gesellschaftlich relevanten Funktion | Reichweite, Region, Dauer, Ersatzversorgung |
| Geschäftspartner | unterbrochene Wertschöpfung oder Schnittstelle | Abhängigkeit, Eskalation, Datenaustausch |
| interne Einheiten | fehlende Vorleistung oder Entscheidung | Prozessabhängigkeit, interne Priorität |
| andere Dienste | Kaskade über Plattform, Information oder Personal | Dienst-zu-Dienst-Beziehung |
| betroffene Personen | materielle/immaterielle Auswirkungen und Datenschutzrisiken | Datenarten, Rechts-/Meldebezug, Schutzmaßnahmen |
| Behörden/Aufsicht | fehlende Meldung, Information oder Nachweis | Zuständigkeit, Frist und verantwortliche Rolle |
¶ 10. Prozesslandkarte je Dienst
| Prozessklasse | Zweck | Beispiele für Zuordnung |
|---|---|---|
| Kernprozess | erzeugt unmittelbar die Dienstleistung | Annahme, Bearbeitung, Bereitstellung, Auslieferung |
| Unterstützungsprozess | stellt Ressourcen und Vorleistungen bereit | Personal, Einkauf, Facility, Finanzen |
| Betriebsprozess | hält Systeme und Infrastruktur funktionsfähig | Betrieb, Wartung, Kapazität, Backup |
| Sicherheitsprozess | verhindert, erkennt oder begrenzt Sicherheitsereignisse | IAM, Patchen, Monitoring, Schwachstellenmanagement |
| Incidentprozess | analysiert und bewältigt Sicherheitsvorfälle | Triage, Eindämmung, Meldung, Kommunikation |
| BCM-/Krisenprozess | führt Leistung unter außergewöhnlichen Bedingungen fort | Notbetrieb, Krisenstab, Ersatzverfahren |
| Wiederanlaufprozess | stellt Ressourcen und Normalbetrieb wieder her | Restore, Abnahme, Rückkehr, Nacharbeiten |
| Governanceprozess | entscheidet, überwacht und verbessert | Risiko, Freigabe, Audit, Managementbewertung |
Ein Querschnittsprozess wird zentral gepflegt und mehreren Diensten über IDs zugeordnet. Eine Kopie pro Dienst würde schnell zu widersprüchlichen Versionen führen.
¶ 11. Prozesssteckbrief
| Feld | Inhalt |
|---|---|
| Prozess-ID/Version | eindeutige Kennung und Freigabestand |
| Dienstbeitrag | welches Leistungsmerkmal unterstützt wird |
| Start/Ende | Auslöser, Eingaben, Abschluss und Ausgaben |
| Owner/Beteiligte | verantwortliche Rolle, Mitwirkende, Vertretung, Dritte |
| Ablauf | Hauptschritte, Entscheidungen, Übergaben, Ausnahmen |
| Informationen | benötigte und erzeugte Daten mit Owner/Schutzbedarf |
| Ressourcen | Systeme, Standorte, Personal, Versorgung, Anbieter |
| Kontrollen | präventive, detektive, reaktive Maßnahmen und Control Owner |
| Mindestbetrieb | alternative Schritte, Grenzen, Aktivierung und Rückkehr |
| Zeitziele | Prozess-RTO, Ressourcenvorlauf und Abhängigkeiten |
| Risiken/Maßnahmen | Risiko- und Maßnahmen-IDs, Ausnahmen, Termine |
| Kennzahlen/Nachweise | Leistung, Sicherheit, Test, Review und Ablage |
¶ 12. Ende-zu-Ende-Dienstkette
Empfänger
Bedarf, Frist, Qualität
Bedarf, Frist, Qualität
Kernleistung
Ergebnis und Mindestbetrieb
Ergebnis und Mindestbetrieb
Prozesse
Ablauf, Übergabe, Kontrolle
Ablauf, Übergabe, Kontrolle
Ressourcen
Information, Technik, Mensch, Ort
Information, Technik, Mensch, Ort
Dritte
Anbieter, Partner, Unterauftragnehmer
Anbieter, Partner, Unterauftragnehmer
Nachweis
Test, Leistung, Entscheidung
Test, Leistung, Entscheidung
Eine Dienstkette ist erst belastbar, wenn jede Beziehung Owner, Ausfallmodus, Zeitwirkung, Alternative und Nachweis besitzt. Der bloße Verweis auf ein Organigramm oder einen Lieferantenvertrag reicht nicht.
¶ 13. Abhängigkeitsklassen
| Klasse | Beispiele | notwendige Steuerung |
|---|---|---|
| Personal/Wissen | Schlüsselrolle, Bereitschaft, Stellvertretung | Mindestbesetzung, Kompetenz, Übergabe, Ausfallvertretung |
| Information | Stamm-, Transaktions-, Konfigurations- und Entscheidungsdaten | Owner, Integrität, Aktualität, Zugriff, Backup |
| Technik | Anwendung, Netz, Identität, Endpunkt, OT, Sicherheitswerkzeug | Inventar, Architektur, Monitoring, Wiederanlauf |
| Standort/Versorgung | Raum, Energie, Kühlung, Kommunikation, Zutritt | Schutz, Kapazität, Redundanz, Ausweichfähigkeit |
| Lieferkette | Cloud, Provider, Hersteller, Support, Logistik | Vertrag, Unterauftragnehmer, Überwachung, Exit |
| Organisation | Entscheidung, Genehmigung, Kommunikation, Krisenrolle | Befugnis, Erreichbarkeit, Eskalation, Vertretung |
| Recht/Vertrag | Melde-, Aufbewahrungs-, Leistungs- und Informationspflicht | Frist, Owner, Nachweis, Änderungsmonitoring |
Gemeinsame Plattformen, Provider, Standorte, Identitäten oder Schlüsselpersonen werden als Konzentrations- und Kaskadenrisiken sichtbar gemacht.
¶ 14. Scope-Entscheidungsmatrix
| Kriterium | ✓ im Scope | ▲ vorsorglich | × ausgeschlossen | ○ ungeklärt |
|---|---|---|---|---|
| Tätigkeitsbezug | bestätigt | plausibel, Prüfung offen | nachweislich nicht gegeben | Information fehlt |
| Dienstbeitrag | direkt oder notwendige Vorleistung | mögliche Kaskade/Shared Service | keine relevante Beziehung | Grenze unklar |
| System/Prozess | für Dienst genutzt | vorsorglich zugeordnet | nicht genutzt und keine Abhängigkeit | Inventar widersprüchlich |
| externe Leistung | Bestandteil der Dienstkette | Unterauftragnehmer/Scope offen | ohne Dienstbezug | Vertrag/Leistung unklar |
| Entscheidung | freigegeben | befristete Einbeziehung | begründet und genehmigt | Owner/Entscheider fehlt |
| Review | regulär/triggerbasiert | kurzfristiger Klärtermin | bei Änderung erneut prüfen | sofortige Datenerhebung |
Ein Ausschluss benötigt mindestens Gegenstand, Begründung, Quelle, Prüfer, befugte Entscheidung, Auswirkungen, Restunsicherheit und Reviewauslöser. „Nicht im Scope“ ist kein Freitext ohne Nachweis.
¶ 15. Statusmodell
| Status | Kennzeichnung | Bedeutung |
|---|---|---|
| Erfasst | ○ ERFASST | Grundeintrag vorhanden; Prüfung offen |
| In Prüfung | ◆ IN PRÜFUNG | Rechts-/Scope-/Stammdaten werden geklärt |
| Vorläufig im Scope | ▲ VORLÄUFIG | vorsorglich einbezogen, Entscheidung befristet |
| Freigegeben | ✓ FREIGEGEBEN | Grenze bestätigt; keine Wirksamkeitsaussage |
| In Änderung | ↻ ÄNDERUNG | wesentliche Veränderung wird kontrolliert bewertet |
| Auslaufend | ◇ AUSLAUFEND | Exit, Übergang und Restpflichten aktiv |
| Historisch | ■ HISTORISCH | nicht operativ, als Entscheidungsstand archiviert |
¶ 16. Datenqualität der Dienstebeschreibung
✓ GRÜN · belastbar
Scope, Owner, Leistung, Kette, Quellen und Review bestätigt.
Scope, Owner, Leistung, Kette, Quellen und Review bestätigt.
! GELB · teilweise belegt
Einzelne Annahmen oder Lücken mit Owner und Termin.
Einzelne Annahmen oder Lücken mit Owner und Termin.
× ROT · hohe Unsicherheit
Wesentliche Grenze, Zuordnung oder Auswirkung nicht belastbar.
Wesentliche Grenze, Zuordnung oder Auswirkung nicht belastbar.
○ GRAU · ungeprüft
Noch keine Bewertung; nicht als „nicht relevant“ interpretieren.
Noch keine Bewertung; nicht als „nicht relevant“ interpretieren.
Scope-Status, Kritikalität und Datenqualität werden getrennt geführt. Ein freigegebener Dienst kann etwa eine gelbe Datenqualität besitzen, wenn eine neue Lieferantenkette noch nicht vollständig bestätigt ist.
¶ 17. Rollen und Verantwortlichkeiten
| Rolle | Verantwortlicher Beitrag | darf nicht allein entscheiden |
|---|---|---|
| Geschäftsleitung | Grundsätze, wesentliche Scopefragen, Ressourcen und Restrisiken | Detailzuordnung ohne fachliche Analyse |
| NIS2-Koordination | Katalog, Rechts-/Scopebezug, Konsistenz und Eskalation | rechtliche Einzelfallentscheidung ohne Fachprüfung |
| Dienst-Owner | Leistung, Empfänger, Grenze, Mindestbetrieb und Gesamtverantwortung | technische Machbarkeit ohne System-Owner |
| Prozess-Owner | Ablauf, Übergaben, Ressourcen, Kontrollen und Kennzahlen | Dienstekritikalität ohne Dienst-Owner |
| Information Owner | Informationsarten, Schutzbedarf, Empfänger und zulässige Nutzung | technische Systemfreigabe |
| System-/Service-Owner | Systeme, Betrieb, Änderung, Wiederherstellung und Nachweise | Geschäftsfolgen des Ausfalls |
| Einkauf/Lieferantenmanagement | externe Leistungen, Verträge, Unterauftragnehmer und Exit | Dienstgrenze ohne Fachbereich |
| BCM/Incident | Auswirkungen, Notbetrieb, Eskalation, Wiederanlauf und Übungen | allgemeine Scopefreigabe |
| Datenschutz/Recht | Personenbezug, Pflichten, Verträge und Meldebezug | operative Dienstpriorität |
| Audit/Compliance | Vollständigkeit, Quellen, Freigaben und Registerkonsistenz | operative Selbstfreigabe |
¶ 18. Technischer Baustein: aufklappbare Dienstprüfung
Die Prüffelder können in Workshops geöffnet werden. Sie ersetzen keine freigegebene Rechts-, Scope-, Risiko- oder Prozessprüfung.
Prüfpfad A · Tätigkeit, Dienst und Empfänger
- Welche Einrichtungsart und Tätigkeit begründet die Betrachtung?
- Welches konkrete Ergebnis erhält welcher interne oder externe Empfänger?
- Wo und wann wird die Leistung erbracht; welche Varianten bestehen?
- Sind Leistungsbeginn, -ende, Übergaben und Restpflichten eindeutig?
- Sind Annahmen, Ausschlüsse und Rechtsbezug mit Quellen dokumentiert?
Prüfpfad B · Prozesse und Ende-zu-Ende-Kette
- Sind Kern-, Unterstützungs-, Betriebs-, Sicherheits-, Incident- und Wiederanlaufprozesse enthalten?
- Sind manuelle Schritte, Übergaben, Entscheidungen und Ausnahmen sichtbar?
- Sind Informationen, Systeme, Identitäten, Personal, Standorte und Versorgung zugeordnet?
- Sind externe Anbieter, Unterauftragnehmer und gemeinsam genutzte Plattformen enthalten?
- Besitzt jede kritische Abhängigkeit Owner, Ausfallwirkung, Alternative und Nachweis?
Prüfpfad C · Kritikalität und Mindestbetrieb
- Welche Folgen entstehen je Empfängergruppe und Ausfallzeit?
- Sind MTPD/MAO, RTO, RPO und Mindestbetriebsniveau begründet und konsistent?
- Können Notverfahren die erforderliche Menge, Dauer, Qualität und Sicherheit tragen?
- Sind Ressourcen-RTOs und Wiederanlaufreihenfolge mit dem Dienstziel abgestimmt?
- Wurden Notbetrieb, Restore, fachliche Abnahme und Rückkehr praktisch getestet?
Prüfpfad D · Steuerung, Änderung und Nachweis
- Sind Dienst-, Prozess-, Informations-, System- und Lieferanten-Owner samt Vertretung bestätigt?
- Stimmen Dienstekatalog, Scope, Asset-, Datenfluss-, Lieferanten- und Risikoregister überein?
- Lösen Leistungs-, Organisations-, Standort-, System- und Anbieteränderungen Reviews aus?
- Sind Risiken, Maßnahmen, Tests, Abweichungen und Entscheidungen referenziert?
- Sind sensible Originale geschützt und öffentliche Aussagen angemessen begrenzt?
¶ 19. Lebenszyklus eines relevanten Dienstes
| Phase | Tätigkeit | Ergebnis | Freigabekriterium |
|---|---|---|---|
| 1 · erkennen | neue/änderte Tätigkeit oder Leistung erfassen | vorläufiger Eintrag | Owner und Klärtermin |
| 2 · abgrenzen | Empfänger, Ergebnis, Region, Zeit und Grenze bestimmen | Dienstesteckbrief | Quellen und Annahmen |
| 3 · modellieren | Prozesse, Ressourcen und Dritte zuordnen | Ende-zu-Ende-Kette | Vollständigkeitsprüfung |
| 4 · bewerten | Scope, Kritikalität, Risiken und Mindestbetrieb prüfen | Entscheidungsvorlage | fachliche/technische Prüfung |
| 5 · freigeben | Grenze, Status, Ressourcen und offene Punkte entscheiden | freigegebener Stand | befugte Entscheidung |
| 6 · betreiben | Leistung, Vorfälle, Änderungen, Tests und Nachweise überwachen | Managementinformation | Datenqualität und Eskalation |
| 7 · ändern | Auswirkung vor Umsetzung prüfen | kontrollierter neuer Stand | Test, Abnahme, Registerupdate |
| 8 · beenden | Exit, Daten, Zugänge, Verträge und Restpflichten behandeln | historischer Stand | Abschluss- und Archivnachweis |
¶ 20. Änderungs- und Reviewauslöser
| Auslöser | mindestens zu prüfen |
|---|---|
| neue/geänderte Leistung oder Empfängergruppe | Einrichtungs-/Tätigkeitsbezug, Grenze, Kritikalität |
| neue Region oder Mitgliedstaat | Registrierung, Vertrag, Daten-/Lieferkette, Zuständigkeit |
| Umstrukturierung, Fusion oder Rechtsträgerwechsel | Betroffenheit, Owner, Vertrag und Scope |
| neue Plattform/Schnittstelle/Cloud | Systeme, Datenflüsse, Schutzbedarf und Resilienz |
| neuer Anbieter/Unterauftragnehmer | Lieferkette, Zugriff, Region, Incident und Exit |
| Standort-/Kapazitätsänderung | Versorgung, Mindestbetrieb und Wiederanlauf |
| Vorfall/erhebliche Störung | Folgen, Meldung, Erkennung und Maßnahmen |
| fehlgeschlagener Test | Machbarkeit, RTO/RPO, Notverfahren und Risiko |
| Rechts-/Behörden-/Kundenänderung | Pflichten, Leistung, Nachweis und Freigabe |
| Registerwiderspruch | führende Quelle, Ursache, Korrektur und Nachkontrolle |
¶ 21. Umgang mit Registerwidersprüchen
| Widerspruch | Risiko | Klärweg |
|---|---|---|
| Dienst im Scope, aber kein System zugeordnet | technische Schutzlücke oder falsche Dienstgrenze | Dienst- und System-Owner gemeinsam prüfen |
| System kritisch, aber keinem Dienst zugeordnet | Kaskade/Shared Service übersehen | Abhängigkeiten und Basisdienste analysieren |
| Lieferant aktiv, aber im Dienstekatalog nicht genannt | externe Kette unvollständig | Vertrag, Leistung und Unterauftragnehmer zuordnen |
| Prozesslandkarte nennt anderen Owner | Verantwortungs- und Eskalationskonflikt | führende Rolle und Vertretung entscheiden |
| RTO im BCM weicht vom Dienstesteckbrief ab | Wiederanlauf nicht steuerbar | BIA und technische Machbarkeit abstimmen |
| Datenfluss ohne Dienstbezug | Scope oder Zweck ungeklärt | Information Owner und Prozess prüfen |
| historischer Dienst besitzt aktive Zugänge/Verträge | unvollständiger Exit | Sperrung, Kündigung und Restpflichten behandeln |
Widersprüche werden nicht stillschweigend überschrieben. Sie erhalten Ticket/Abweichung, Owner, Priorität, Entscheidungsquelle und Abschlussnachweis.
¶ 22. Kritikalität, Risiko und Priorität trennen
| Dimension | Aussage | typische Entscheidung |
|---|---|---|
| Kritikalität | Folge eines Ausfalls über die Zeit | Mindestbetrieb und Wiederanlaufziel |
| Risiko | Szenario aus Bedrohung, Schwachstelle, Wahrscheinlichkeit und Auswirkung | Behandlung oder Akzeptanz |
| Datenqualität | Belastbarkeit der Bewertung | Klärung, Vorbehalt und Eskalation |
| Wiederanlaufpriorität | Reihenfolge in der konkreten Lage | Ressourcenzuteilung |
| Scope-Status | rechtlich/fachlich bestätigte oder vorsorgliche Einbeziehung | Pflichten- und Steuerungsumfang |
Ein grüner Qualitätsstatus sagt nicht, dass ein Dienst wenig kritisch ist. Ein kritischer Dienst kann sehr gut dokumentiert sein; ein ungeklärter Dienst darf nicht vorschnell als unkritisch behandelt werden.
¶ 23. Risiken, Maßnahmen und Nachweise zuordnen
| Objekt | notwendige Referenz | Prüffrage |
|---|---|---|
| Dienst | Dienst-ID in Risiko und Maßnahme | Welche Leistung und Empfänger sind betroffen? |
| Prozess | Prozess-ID und Schritt | Wo entsteht das Szenario oder wirkt die Kontrolle? |
| System/Information | Asset-/Informations-ID | Welche Ressource ist Ursache, Ziel oder Nachweisquelle? |
| Lieferant | Anbieter-/Service-ID | Welche externe Verantwortung und Kette besteht? |
| Kontrolle | Kontroll-ID und Control Owner | Welche konkrete Wirkung wird erwartet? |
| Nachweis | Nachweis-ID, Zeitraum und Scope | Trägt er die behauptete Aussage? |
| Entscheidung | Protokoll-/Freigabe-ID | Wer hat mit welcher Befugnis entschieden? |
¶ 24. Fiktives Musterregister
| Dienst-ID | Musterleistung | Empfänger | Scope-Status | Kritikalität | Datenqualität | offener Punkt |
|---|---|---|---|---|---|---|
| DEMO-D-001 | Beispieldienst A | fiktive externe Kunden | ▲ VORLÄUFIG | K1 – Muster | ! GELB | Anbieterabhängigkeit offen |
| DEMO-D-002 | Musterleistung B | Beispielpartner | ◆ IN PRÜFUNG | K2 – Muster | × ROT | Dienstgrenze/Region klären |
| DEMO-D-003 | interne Beispielvorleistung C | andere Musterdienste | ○ ERFASST | offen | ○ GRAU | Owner und Abhängigkeiten fehlen |
Alle Namen, Werte und Zustände sind fiktiv. Sie dürfen nicht als reale Betroffenheits-, Scope-, Kritikalitäts- oder Wirksamkeitsaussage verwendet werden.
¶ 25. Sinnvolle Registeransichten
| Ansicht | Filter | Nutzen |
|---|---|---|
| Management | vorläufig/ungeklärt, K1/K2, rote Qualität, überfällige Entscheidung | Scope, Ressourcen, Eskalation |
| Dienst-Owner | eigener Dienst, offene Felder, Prozesse, Tests und Änderungen | Gesamtsteuerung |
| Prozessmanagement | Prozessklasse, Owner, Schnittstelle, Mehrfachnutzung | Prozesskonsistenz |
| IT/OT | Systeme, Dienstbezug, RTO/RPO und technische Owner | technische Priorisierung |
| Einkauf | Anbieter, Unterauftragnehmer, Vertrag, Exit und Review | Lieferkettensteuerung |
| BCM/Incident | Kritikalität, Mindestbetrieb, Eskalation und Wiederanlauf | Vorsorge und Lageführung |
| Audit | Quelle, Entscheidung, Version, Nachweis und Abweichung | Prüfbarkeit |
¶ 26. Kennzahlen und Managementinformation
| Kennzahl | Aussage | mögliche Eskalation |
|---|---|---|
| Dienste ohne bestätigten Owner | fehlende Ergebnisverantwortung | jede relevante Lücke berichten |
| vorläufige/ungeklärte Scopeentscheidungen | Pflichten- und Ressourcenunsicherheit | Klärtermin/Managemententscheidung |
| Dienste ohne vollständige Prozesskette | Schutz- und Nachweislücke | Workshop/Datenerhebung |
| Prozesse ohne System-/Lieferantenzuordnung | indirekte Abhängigkeit unbekannt | Ownerprüfung |
| kritische Abhängigkeiten ohne Alternative | Resilienzrisiko | Risiko/Maßnahme eskalieren |
| RTO/RPO ohne Machbarkeitsnachweis | Planungswiderspruch | technische/fachliche Prüfung |
| wesentliche Changes ohne abgeschlossene Auswirkung | unkontrollierte Scopeänderung | Change stoppen/Entscheidung |
| fehlgeschlagene Dienst-/Notbetriebstests | Fähigkeit nicht bestätigt | Korrektur und Nachtest |
| widersprüchliche Registereinträge | Governance-/Datenqualitätslücke | Abweichung mit Owner |
| überfällige Reviews | veralteter Scope/Steuerungsstand | Eskalation nach Kritikalität |
Kennzahlen benötigen Datenquelle, Scope, Nenner, Stichtag, Zielwert, Toleranz, Trend, Owner und Kommentierung. Eine sinkende Zahl registrierter Dienste ist nicht automatisch positiv; sie kann aus unbegründeten Ausschlüssen entstehen.
¶ 27. Nachweise und geschützte Ablage
| Nachweis | belegt | Schutz |
|---|---|---|
| Betroffenheits-/Scopeentscheidung | Einrichtungs-/Tätigkeitsbezug, Annahmen und Freigabe | intern/vertraulich |
| freigegebener Dienstesteckbrief | Grenze, Empfänger, Owner, Leistung und Version | intern |
| Prozesslandkarte/-steckbrief | Ablauf, Übergaben, Ressourcen und Kontrollen | intern/vertraulich |
| Abhängigkeitsmodell | Systeme, Informationen, Standorte, Personal und Dritte | vertraulich |
| BIA-/Kritikalitätsentscheidung | Auswirkungen, Zeitziele und Mindestbetrieb | vertraulich |
| Leistungs-/Betriebsnachweis | tatsächliche Diensterbringung und Abweichung | intern |
| Notbetriebs-/Wiederanlauftest | praktische Fähigkeit und Grenzen | geschützt |
| Change-/Freigabeprotokoll | kontrollierte Änderung und Entscheidung | intern/vertraulich |
| Maßnahmen-/Risikofreigabe | Behandlung, Restrisiko, Budget und Termin | Entscheidungsschutz |
Das öffentliche Wiki enthält Methodik, Status und kontrollierte Referenzen, aber keine sensiblen Dienstketten, Kundendaten, Angriffspfade, Notzugänge, Vertragsoriginale oder personenbezogenen Kontaktdaten.
¶ 28. Häufige Fehler
| Fehler | Folge | Korrektur |
|---|---|---|
| Dienst wird mit Produkt oder Abteilung gleichgesetzt | Empfänger und Ergebnis bleiben unklar | Leistung aus Empfängersicht beschreiben |
| nur Kernprozess wird dokumentiert | Betrieb, Sicherheit und Notfall fehlen | Prozessklassen vollständig zuordnen |
| Outsourcing gilt als Ausschluss | Verantwortung und Kette verschwinden | externe Leistung im Dienst belassen |
| technische Verfügbarkeit wird als Dienstleistung behandelt | fachliche Mindestleistung fehlt | Ergebnis, Menge, Qualität und Abnahme definieren |
| Scope und Kritikalität werden vermischt | falsche Ausschlüsse oder Prioritäten | Statusdimensionen trennen |
| Sammel-Owner „IT“ | Verantwortung nicht entscheidungsfähig | konkrete Rollen und Vertretung benennen |
| Shared Services keinem Dienst zugeordnet | Kaskaden und Konzentration unbekannt | Dienst-zu-Dienst-/Ressourcenbeziehungen pflegen |
| grüner Status ohne Nachweis | Scheinsicherheit | Scope, Aussage, Zeitraum und Test angeben |
| Dienstende ohne Exitkontrolle | aktive Zugänge, Daten und Verträge bleiben | Restpflichten und Abschlussnachweis |
¶ 29. Qualitätsgate vor Freigabe
| Prüffrage | Musterstatus |
|---|---|
| Ist die Betroffenheit oder vorsorgliche Einbeziehung dokumentiert? | Offen |
| Sind Tätigkeit, Leistung, Empfänger, Regionen, Betriebszeiten und Grenzen bestätigt? | Offen |
| Sind Normal-, Mindest-, Not- und Wiederanlaufleistung definiert? | Offen |
| Sind Kern-, Unterstützungs-, Betriebs-, Sicherheits-, Incident- und BCM-Prozesse erfasst? | Offen |
| Sind Owner, Stellvertretungen, Befugnisse und Eskalationen bestätigt? | Offen |
| Sind Informationen, Systeme, Identitäten, Personal, Standorte und Versorgung verknüpft? | Offen |
| Sind Anbieter, Unterauftragnehmer, Verträge und Exit-Abhängigkeiten enthalten? | Offen |
| Sind Kritikalität, MTPD/MAO, RTO, RPO und Mindestbetrieb konsistent? | Offen |
| Sind Risiken, Maßnahmen, Kontrollen, Nachweise und Wirksamkeitsstatus zugeordnet? | Offen |
| Sind Ausschlüsse, Annahmen und Restunsicherheiten begründet und entschieden? | Offen |
| Sind Registerwidersprüche, Änderungen und Reviewauslöser behandelt? | Offen |
| Bleiben sensible Originale geschützt? | Offen |
¶ 30. Offene Entscheidungen vor produktiver Nutzung
| Entscheidung | Verantwortliche Funktion | Musterstatus |
|---|---|---|
| führender Dienstekatalog und ID-System | NIS2-Koordination / Prozessmanagement | Offen |
| Dienstdefinition und Abgrenzungstiefe | Geschäftsleitung / Dienst-Owner | Offen |
| Scope-Status und Ausschlusskriterien | Recht / NIS2-Koordination / Leitung | Offen |
| Mindestfelder und Datenqualitätsampel | Dienst-/Prozessmanagement | Offen |
| Prozessklassen und Mehrfachzuordnung | Prozessmanagement / Informationssicherheit | Offen |
| Regeln für Mindestbetrieb, RTO und RPO | BCM / Dienst-/System-Owner | Offen |
| Lieferanten-/Shared-Service-Zuordnung | Einkauf / Architektur / Dienst-Owner | Offen |
| Änderungs-, Review- und Eskalationsprozess | NIS2-Koordination / Change | Offen |
| geschützte Nachweisablage und Berechtigungen | Dokumentenverantwortung | Offen |
Bis zur dokumentierten Freigabe bleiben sämtliche Musterdaten, Status und Ampeln Entwurf.
¶ 31. Verknüpfte Seiten
| Thema | Wiki-Seite |
|---|---|
| Betroffenheit | Betroffenheits- und Einstufungsprüfung |
| Geltungsbereich | Geltungsbereich und relevante Dienste |
| Assets/Systeme | Asset- und Systeminventar |
| Netz-/Informationssysteme | Netz- und Informationssysteme |
| Informationswege | Daten- und Informationsflüsse |
| Kritikalität | Kritikalität und Abhängigkeiten |
| externe Dienste | Externe Dienste und Cloud |
| Standorte | Standorte und Infrastruktur |
| Risiken | NIS2-Risikoregister |
| Nachweise | NIS2-Nachweisregister |
| ISMS-Prozesse | ISMS-Prozesslandkarte |
| Lieferanten | Lieferanten und Dienstleister |
| BCM | Notfallvorsorge und BCM |
| Wiederanlauf | Wiederanlaufplanung |
¶ 32. Offizielle Grundlagen und Orientierung
| Quelle | Verwendung |
|---|---|
| § 28 BSIG | Einordnung besonders wichtiger und wichtiger Einrichtungen anhand Einrichtungsart, Tätigkeit und Größenmerkmalen |
| § 30 BSIG | Risikomanagement für die zur Diensterbringung genutzten Systeme, Komponenten und Prozesse |
| § 33 BSIG | Registrierung, Sektor und Mitgliedstaaten der Diensterbringung |
| Anlage 1 BSIG | Sektoren hoher Kritikalität und Einrichtungsarten |
| Anlage 2 BSIG | sonstige kritische Sektoren und Einrichtungsarten |
| BSI – Entscheidungsbaum zur NIS2-Betroffenheit | Orientierung für die vorgeschaltete Einrichtungsprüfung |
Anwendbarkeit, Rechtsstand, Scope und sektorale Anforderungen werden vor produktiver Nutzung aktuell geprüft. Alle externen Links öffnen in einem neuen Tab.
¶ 33. Weiterführende Unterstützung durch SMCT MANAGEMENT
SMCT MANAGEMENT
Unterstützung bei NIS2-Betroffenheit, Dienstekatalog, Prozessabgrenzung, Kritikalitätsanalyse, ISMS-Integration und prüffähigen Nachweisen.
Informationen zur NIS2-Beratung öffnen
Unterstützung bei NIS2-Betroffenheit, Dienstekatalog, Prozessabgrenzung, Kritikalitätsanalyse, ISMS-Integration und prüffähigen Nachweisen.
Informationen zur NIS2-Beratung öffnen
¶ 34. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Seite fachlich und visuell neu aufgebaut; Cockpit, Tätigkeit-Dienst-Ressourcen-Kette, Dienstgrenzen, Mindestbetrieb, Prozesslandkarte, Dienstkette, Scope-Matrix, Status- und Qualitätsampeln, aufklappbare Dienstprüfung, Lebenszyklus, Registerkonflikte, Musterregister, Kennzahlen und Qualitätsgate ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Rollen, Lebenszyklus, Prozesssteckbrief, Abhängigkeiten, Statusmodell, Kennzahlen und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Leere Musterstruktur für relevante Dienste und Prozesse erstellt | Ausstehend |