¶ Kritikalität und Abhängigkeiten
Bewertungsentwurf: Diese Seite ist eine Arbeits- und Entscheidungshilfe. Sie enthält ausschließlich beispielhafte Kriterien und fiktive Datensätze. Kritikalitätsstufen, Toleranzen, Wiederanlaufziele, Abhängigkeiten und Freigaben sind für die jeweilige Organisation zu erheben. Ein grüner Musterstatus belegt weder Umsetzung noch Wirksamkeit.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-MA-03-03 |
| Dokumentenart | Methodik, Bewertungslogik und Registerstruktur |
| Wiki.js-Pfad | /NIS2/03-Assets-Prozesse-und-Dienste/Kritikalitaet-und-Abhaengigkeiten |
| Verantwortlich | Dienst-/Prozess-Owner, BCM und Informationssicherheitsfunktion |
| Mitwirkende | IT-Betrieb, Einkauf, Lieferantenmanagement, Facility, Datenschutz, Recht und Fachbereiche |
| Status | Entwurf – Schwellenwerte, Bewertungen und Zeitziele nicht freigegeben |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Methodik intern; reale Dienstketten, Engpässe und Notbetriebsdetails vertraulich |
| Review | mindestens jährlich sowie anlassbezogen |
Ausfallfolgen, zeitliche Toleranzen und Ende-zu-Ende-Abhängigkeiten nachvollziehbar bewerten. Eigene redaktionelle SVG-Grafik. Zum Vergrößern in einem neuen Tab öffnen.
¶ 1. Steuerungscockpit
■ Kritische Dienste ohne bestätigte BIA
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
▲ Single Points of Failure
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
● Zeitziele ohne Machbarkeitsnachweis
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
? Ungetestete Ersatzwege
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Das Cockpit wird nur aus freigegebenen Registern gespeist. Ein fehlender Wert wird als „— / nicht ermittelt“ angezeigt und niemals als null offene Punkte interpretiert.
¶ 2. Wozu diese Seite dient
Die Kritikalitätsanalyse beantwortet nicht nur, welcher Dienst wichtig ist. Sie macht sichtbar:
- welche Folgen eine Unterbrechung für Empfänger, Betrieb, Sicherheit, Verträge und Gesellschaft hat,
- wie sich diese Folgen mit der Dauer, dem Zeitpunkt und dem Umfang verändern,
- welches Mindestbetriebsniveau spätestens wann benötigt wird,
- welche internen und externen Ressourcen dafür erforderlich sind,
- welche gemeinsamen Ursachen mehrere angeblich redundante Wege gleichzeitig treffen können,
- welche Reihenfolge bei Notbetrieb, Wiederanlauf und Rückkehr zum Normalbetrieb fachlich vertretbar ist und
- ob die geplanten Zeitziele technisch, personell, räumlich und vertraglich erreichbar sind.
Das Ergebnis steuert Risikoanalyse, Schutzmaßnahmen, Lieferantenanforderungen, Backup, Wiederanlauf, Übungen, Krisenentscheidungen und Investitionsprioritäten. Es ersetzt weder die NIS2-Betroffenheitsprüfung noch die Risikobewertung.
¶ 3. Rechtlicher und fachlicher Bezug
| Bezug | Bedeutung für die Arbeitsseite |
|---|---|
| § 30 Abs. 1 BSIG | Maßnahmen müssen geeignet, verhältnismäßig und wirksam sein; Schwere, Eintrittswahrscheinlichkeit sowie gesellschaftliche und wirtschaftliche Auswirkungen sind zu berücksichtigen. |
| § 30 Abs. 2 BSIG | Der gefahrenübergreifende Ansatz umfasst unter anderem Risikoanalyse, Vorfallbewältigung, Aufrechterhaltung des Betriebs, Lieferkettensicherheit und Wirksamkeitsbewertung. |
| BSI-Standard 200-4 | Eine Business-Impact-Analyse ermittelt zeitkritische Geschäftsprozesse, tolerierbare Ausfallzeiten und für den Notbetrieb benötigte Ressourcen. |
| DVO (EU) 2024/2690 | Für die in der Verordnung genannten digitalen Einrichtungsarten konkretisiert sie unter anderem Business-Impact-Analyse, Wiederherstellungsziele und Assetklassifizierung. |
Die EU-Durchführungsverordnung ist nicht pauschal auf jede NIS2-Einrichtung anzuwenden. Ihr persönlicher und sachlicher Geltungsbereich wird vor einer verbindlichen Zuordnung geprüft. Auf dieser Musterseite dient sie zugleich als fachliche Orientierung.
¶ 4. Begriffe sauber trennen
| Begriff | Leitfrage | Ergebnis |
|---|---|---|
| Kritikalität | Welche Folgen entstehen, wenn Dienst oder Prozess ausfällt? | Kritikalitäts- und Zeitklasse |
| Schutzbedarf | Welches Schutzniveau benötigen Information oder Asset hinsichtlich Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität? | Schutzbedarfsklasse |
| Risiko | Welches Szenario kann mit welcher Wahrscheinlichkeit und Auswirkung eintreten? | Risikostufe und Behandlung |
| Abhängigkeit | Welche Ressource oder Vorleistung benötigt der Dienst? | gerichtete Beziehung mit Ausfallmodus |
| Priorität | Was muss in der konkreten Lage zuerst versorgt oder wiederhergestellt werden? | lageabhängige Reihenfolge |
| Resilienz | Wie gut kann der Dienst Störungen aufnehmen, überbrücken und sich erholen? | Fähigkeiten, Alternativen und Nachweise |
Eine hohe Kritikalität bedeutet nicht automatisch ein hohes aktuelles Risiko. Ein kritischer Dienst kann gut abgesichert sein. Umgekehrt kann ein weniger kritischer Dienst ein hohes Cyberrisiko besitzen. Auch die Wiederanlaufpriorität darf nicht allein aus einer Ampelfarbe abgeleitet werden: technische Vorbedingungen können zuerst wiederhergestellt werden müssen.
¶ 5. Analyseobjekte und Betrachtungsebenen
| Ebene | Abzugrenzendes Objekt | Typische Quelle |
|---|---|---|
| Dienst | nach außen oder innen erbrachte Leistung mit Empfänger und Qualitätsmerkmalen | Dienstekatalog, Verträge, NIS2-Scope |
| Geschäftsprozess | fachliche Abläufe, Entscheidungen und Übergaben | Prozesslandkarte, Arbeitsanweisungen |
| Teilprozess/Aktivität | kritische Schritte und Mindestaktivitäten im Notbetrieb | Interviews, Ablauf- und Notfallpläne |
| Information/Datenfluss | erforderliche Ein- und Ausgaben sowie zulässige Ersatzdaten | Informationsflussregister |
| Anwendung/System | technische Verarbeitung, Speicherung und Kommunikation | Asset- und Systeminventar |
| Infrastruktur/Standort | Netz, Energie, Raum, Zugang, Kühlung und Kommunikation | Standort- und Infrastrukturregister |
| Personal/Wissen | Rollen, Mindestbesetzung, Befugnisse und Schlüsselwissen | Stellen-, Vertretungs- und Schulungsplanung |
| externe Leistung | Anbieter, Cloud, Telekommunikation, Logistik und Unterauftragnehmer | Lieferanten- und Cloud-Register |
Die Bewertung beginnt beim Dienst und folgt den Abhängigkeiten bis zu den tatsächlich benötigten Ressourcen. Eine reine Systemliste zeigt sonst nicht, warum ein System gebraucht wird oder welche Notbetriebsalternative besteht.
¶ 6. Rollen und Entscheidungskompetenz
| Rolle | Verantwortlicher Beitrag | Darf nicht allein entscheiden |
|---|---|---|
| Geschäftsleitung | Skalen, Toleranzen, Prioritätsregeln, wesentliche Restrisiken und Ressourcen freigeben | technische Machbarkeit ohne Fachprüfung |
| Dienst-/Prozess-Owner | Empfänger, Auswirkungen, Mindestleistung, Zeitfenster und fachliche Abhängigkeiten bestätigen | Sicherheit externer Plattformen |
| BCM-Verantwortung | BIA-Methode, Konsistenz, Strategien, Pläne, Übungen und Eskalation koordinieren | fachliche Auswirkung ohne Owner |
| System-/Service-Owner | technische Ketten, Kapazität, Wiederherstellbarkeit und Betriebsabhängigkeiten bewerten | geschäftliche Schadensschwellen |
| Informationssicherheit | Cyberursachen, Kontrolllücken, Schutzbedarf und Risiken zuordnen | Geschäftsakzeptanz des Restrisikos |
| Einkauf/Lieferantenmanagement | Verträge, Anbieter, Unterauftragnehmer, Konzentration und Exit pflegen | fachliche Kritikalität des Dienstes |
| Facility/Standort | Energie, Zutritt, Kühlung, Umweltgefahren und Ausweichflächen bewerten | Anwendungswiederanlauf |
| Datenschutz/Recht | Folgen für Betroffene, Rechts- und Meldepflichten fachlich einordnen | operative Wiederanlaufreihenfolge |
| Audit/Compliance | Quellen, Freigaben, Aktualität und Nachweise unabhängig prüfen | operative Selbstfreigabe |
¶ 7. Ablauf der Kritikalitäts- und Abhängigkeitsanalyse
| Schritt | Tätigkeit | Ergebnis | Qualitätskontrolle |
|---|---|---|---|
| 1 | Dienst, Empfänger, Leistungsgrenze und Betriebsvarianten festlegen | eindeutiges Analyseobjekt | Scope stimmt mit Diensteregister überein |
| 2 | Ausfallfolgen je Zeitfenster und Dimension bewerten | Schadensverlauf | Quellen und Annahmen benannt |
| 3 | MTPD/MAO und Mindestbetriebsniveau festlegen | äußerste Toleranz | fachlich begründet und freigegeben |
| 4 | RTO, RPO und Service-Delivery-Ziele ableiten | Wiederherstellungsziele | unterhalb der Toleranz mit Reserve |
| 5 | Ressourcen und Vorleistungen Ende-zu-Ende erheben | Dienstkette | interne und externe Ebenen enthalten |
| 6 | Ausfallmodi, Kaskaden, Engpässe und gemeinsame Ursachen prüfen | Schwachstellenbild | Scheinredundanzen erkannt |
| 7 | Alternativen und Notbetrieb bewerten | Resilienzoptionen | unabhängig, ausreichend, aktivierbar |
| 8 | Ziele mit technischer und organisatorischer Machbarkeit abgleichen | Soll-Ist-Abweichung | Owner und Evidenz vorhanden |
| 9 | Maßnahmen, Pläne und Prioritäten freigeben | Entscheidungspaket | Budget, Termin, Risiko und Eskalation |
| 10 | Tests, Ereignisse und Änderungen zurückspielen | aktualisierte Bewertung | Abweichung und Wirksamkeit dokumentiert |
¶ 8. Auswirkungsdimensionen
| Dimension | Beispiele für belastbare Kriterien | Mögliche Quellen |
|---|---|---|
| Dienst und Empfänger | Anteil ausgefallener Leistung, Zahl/Art betroffener Empfänger, nicht erfüllbare Mindestversorgung | Leistungsberichte, Verträge, Dienstekatalog |
| Gesundheit und Sicherheit | mögliche Verletzung, Gesundheitsgefährdung oder gefährlicher Anlagenzustand | Gefährdungsbeurteilungen, Notfallkonzepte |
| Gesellschaft/Versorgung | Reichweite, Dauer, regionale Wirkung, Abhängigkeit anderer Dienste | Lagebilder, Versorgungsauftrag, Kundenstruktur |
| Recht und Aufsicht | Fristverletzung, meldepflichtiges Ereignis, behördliche Maßnahme | Rechtskataster, Meldeprozess, Beratung |
| Information | Verlust von Verfügbarkeit, Integrität, Authentizität oder Vertraulichkeit | Schutzbedarfsanalyse, Datenschutzbewertung |
| Wirtschaft | entgangene Leistung, Mehrkosten, Vertragsfolgen, Liquiditäts- oder Fortbestandswirkung | Controlling, Versicherung, Vertragsdaten |
| Reputation/Vertrauen | nachhaltiger Vertrauensverlust bei Kunden, Partnern oder Öffentlichkeit | Beschwerden, Markt-/Kommunikationsanalyse |
| interne Steuerung | fehlende Entscheidungen, Koordination, Identitäten oder Kommunikation | Organigramm, Krisen- und Berechtigungskonzepte |
Der höchste begründete Einzelwert bestimmt grundsätzlich die Auswirkungsstufe. Eine schwerwiegende Gesundheits- oder Versorgungsfolge darf nicht durch Mittelwertbildung mit geringen Kostenfolgen abgeschwächt werden.
¶ 9. Visuelle Auswirkungsmatrix über die Zeit
Die folgende Matrix ist ein Muster. Bewertungsperioden und Schwellenwerte sind organisationsbezogen zu definieren.
| Auswirkungsstufe | 0–4 Stunden | 4–24 Stunden | 1–3 Tage | mehr als 3 Tage | Steuerungsfolge |
|---|---|---|---|---|---|
| 5 kritisch | sofort | sofort | sofort | sofort | Leitung/Krise eskalieren |
| 4 schwer | prüfen | kritisch | kritisch | kritisch | priorisierte Behandlung |
| 3 wesentlich | beobachten | hoch | kritisch | kritisch | Zeitgrenze festlegen |
| 2 begrenzt | tolerierbar | beobachten | hoch | kritisch | planmäßig absichern |
| 1 gering | gering | gering | beobachten | hoch | regulärer Review |
Die Matrix zeigt den Schadensverlauf, nicht die Eintrittswahrscheinlichkeit. Saison-, Monatsabschluss-, Produktions- oder Bereitschaftsfenster werden getrennt bewertet, wenn die Wirkung stark vom Ausfallzeitpunkt abhängt.
¶ 10. Kritikalitätsklassen
| Klasse | Bedeutung | Mindestanforderung im Muster |
|---|---|---|
| K1 – kritisch | nicht tolerierbare Wirkung bereits kurzfristig oder wesentliche Versorgungs-/Sicherheitsfolge | freigegebene BIA, getesteter Notbetrieb, enges Monitoring, priorisierte Wiederherstellung, Managementreview |
| K2 – hoch | schwere Wirkung innerhalb des relevanten Zeitfensters | dokumentierte Alternativen, technische Machbarkeitsprüfung, regelmäßiger Test |
| K3 – wesentlich | merkliche Wirkung, jedoch begrenzt überbrückbar | Wiederanlauf- und Ersatzverfahren, planmäßiger Review |
| K4 – normal | Wirkung innerhalb definierter Zeit tolerierbar | Basisvorsorge und nachvollziehbare Wiederherstellung |
| KU – ungeklärt | Daten, Scope oder Owner reichen nicht für eine Einstufung | kurzfristige Klärung; keine automatische Einstufung als niedrig |
Die Klasse wird mit einer Begründung, den maßgeblichen Dimensionen, der Zeit bis zur Schwelle und der Datenqualität gespeichert.
¶ 11. Zeitziele und ihre Konsistenz
| Größe | Steuerungsinhalt | Prüffrage |
|---|---|---|
| MTPD/MAO | äußerste tolerierbare Unterbrechungsdauer | Ab wann ist die Auswirkung nicht mehr akzeptabel? |
| RTO | Zielzeit bis zum definierten Wiederanlaufniveau | Liegt das Ziel mit ausreichender Reserve unter der Toleranz? |
| RPO | maximal tolerierbarer Datenverlust als Zeitspanne | Welche bestätigten Daten dürfen im Wiederanlauf fehlen? |
| Mindestbetriebsniveau | notwendige Leistung, Empfänger, Qualität und Kapazität im Notbetrieb | Was muss tatsächlich funktionieren? |
| Service-Delivery-Ziel | vereinbartes Leistungsniveau während der Störung | Welche reduzierte Leistung wird kommuniziert? |
| Wiederherstellungszeit | Zeit bis zum stabilen Normalbetrieb | Sind Nacharbeiten, Datenabgleich und fachliche Abnahme enthalten? |
Konsistenzregel: Das RTO einer benötigten Ressource muss früh genug liegen, damit der abhängige Dienst sein eigenes RTO erreicht. Ein Datenbank-RTO von acht Stunden trägt keinen Dienst, der nach vier Stunden verfügbar sein muss. Zeitziele sind daher entlang der gesamten Kette rückwärts zu planen und durch Tests zu bestätigen.
¶ 12. Zeitfenster und Spitzenlast
| Zeitkontext | Beispiel | erforderliche Entscheidung |
|---|---|---|
| Normalbetrieb | durchschnittliche Tageslast | Standardwerte |
| Spitzenbetrieb | Kampagne, Produktion, Saison oder Großauftrag | Kapazität und kürzere Toleranz prüfen |
| Stichtag | Lohnlauf, Abrechnung, Meldetermin | separates Wirkungsfenster |
| Krisenbetrieb | hohe Anfragezahl bei reduzierten Ressourcen | Mindestleistung und Priorisierung |
| Wartungs-/Änderungsfenster | planmäßige Einschränkung plus Störung | Rückfallweg und Bereitschaft |
| Mehrfachausfall | Standort und Anbieter zugleich betroffen | unabhängige Ersatzwege und Reserven |
Wird bewusst nicht der ungünstigste Zeitpunkt bewertet, werden Begründung, Zusatzrisiko und Entscheidung dokumentiert.
¶ 13. Ende-zu-Ende-Dienstkette
1 · Empfänger
Bedarf, Frist, Mindestqualität
Bedarf, Frist, Mindestqualität
2 · Dienst/Prozess
Leistung und Notbetrieb
Leistung und Notbetrieb
3 · Information/IT
Daten, Anwendung, Identität, Netz
Daten, Anwendung, Identität, Netz
4 · Infrastruktur
Standort, Energie, Kommunikation
Standort, Energie, Kommunikation
5 · Externe
Anbieter und Unterauftragnehmer
Anbieter und Unterauftragnehmer
Die Nummerierung zeigt die Leserichtung, ist aber keine vollständige Architektur. Jede Kante wird im Abhängigkeitsregister mit Richtung, Ausfallmodus, Zeitwirkung, Owner, Alternative und Nachweis beschrieben. Rückkopplungen – etwa Identitätsdienst benötigt Netzwerk, Netzwerkadministration benötigt Identität – werden ausdrücklich markiert.
¶ 14. Typen von Abhängigkeiten
| Typ | Beispiele | typische Ausfallwirkung |
|---|---|---|
| fachlich | Vorprozess, Freigabe, Stammdaten, Entscheidung | Leistung kann nicht begonnen oder abgeschlossen werden |
| Information | Transaktion, Schlüssel, Rezeptur, Konfiguration | falsches, unvollständiges oder nicht verfügbares Ergebnis |
| technisch | Anwendung, Datenbank, API, Identität, DNS, Netz | Ausfall, Degradation oder Integritätsfehler |
| personell | Mindestbesetzung, Rufbereitschaft, Spezialwissen | Betrieb oder Wiederanlauf nicht ausführbar |
| räumlich | Leitstand, Produktionsfläche, Rechenzentrum | gesamter Standort oder Prozessschritt nicht nutzbar |
| Versorgung | Strom, Kühlung, Wasser, Telekommunikation | gemeinsame Unterbrechung mehrerer Systeme |
| extern | Cloud, MSP, Logistik, Wartung, Zertifikatsstelle | SLA-, Zugriffs-, Kapazitäts- oder Lieferausfall |
| Governance | Entscheidungsbefugnis, Krisenstab, Freigabeschlüssel | verzögerte Eskalation oder blockierter Notbetrieb |
¶ 15. Direkt, indirekt und gemeinsam verursacht
| Beziehung | Beispiel | Analysefehler |
|---|---|---|
| direkte Abhängigkeit | Dienst benötigt Anwendung | nur die Anwendung wird dokumentiert |
| indirekte Abhängigkeit | Anwendung benötigt Identität, DNS und Zertifikate | unterstützende Plattformen fehlen |
| gemeinsame Ursache | Haupt- und Ersatzleitung nutzen denselben Gebäudeeintritt | formale Redundanz wird überschätzt |
| Konzentration | mehrere kritische Dienste liegen bei einem Provider/einer Region | Einzelbewertungen verdecken Gesamtauswirkung |
| Kaskade | Identitätsausfall blockiert Administration, Monitoring und Wiederanlauf | Wiederherstellungsplan kann sich nicht selbst ausführen |
| Rückkopplung | Kommunikation benötigt Strom, Störungsbehebung benötigt Kommunikation | Reihenfolge ist nicht ausführbar |
¶ 16. Single Points of Failure und Scheinredundanz
Eine Abhängigkeit wird als Engpass markiert, wenn ihr Ausfall den Dienst innerhalb seiner Toleranz stoppt und kein rechtzeitig aktivierbarer, hinreichend unabhängiger Ersatz besteht.
| Prüfaspekt | belastbare Alternative | Scheinredundanz |
|---|---|---|
| Fehlerursache | getrennte Technik und Administration | gleiche Plattform oder gemeinsames Steuerkonto |
| Standort/Region | räumlich und versorgungstechnisch getrennt | anderes Rack im gleichen Brandabschnitt |
| Anbieter/Lieferkette | unabhängige Betreiber und Vorleister | Reseller desselben Upstream-Providers |
| Identität/Schlüssel | Notzugang und getrennt verwahrte Schlüssel | beide Wege vom gleichen IdP abhängig |
| Daten | isolierte, aktuelle und wiederherstellbare Kopie | synchron replizierte Korruption |
| Personal | eingeübte Vertretung mit Befugnissen | Name auf Liste ohne Zugang oder Praxis |
| Kapazität | Last- und Dauerbedarf getestet | Ersatz nur für kurze oder geringe Last geeignet |
¶ 17. Abhängigkeitsregister – Pflichtfelder
| Feld | Inhalt und Qualitätsanforderung |
|---|---|
| Abhängigkeits-ID | unveränderliche Referenz und Version |
| Quelle/Ziel | abhängiger Dienst und benötigte Ressource mit Inventar-ID |
| Richtung | benötigt / liefert / wechselseitig |
| Typ und Ebene | fachlich, technisch, personell, räumlich, Versorgung, extern oder Governance |
| Ausfallmodus | Totalausfall, Degradation, Verzögerung, Datenfehler, Kapazitätsgrenze oder Kontrollverlust |
| Wirkung/Verzögerung | betroffene Leistung und Zeit bis zur relevanten Wirkung |
| Kritikalität | Klasse, maßgebliche Dimension, Begründung und Datenqualität |
| gemeinsame Ursache | Standort, Region, Plattform, IdP, Provider, Netz, Schlüssel, Versorgung oder Person |
| Erkennung | Monitoring, Meldung, manuelle Kontrolle und Eskalationsauslöser |
| Alternative | Ersatzweg, Notverfahren, Kapazität, Aktivierungszeit und Grenzen |
| Zeitziele | erforderliches Ressourcen-RTO/RPO und Beitrag zum Dienstziel |
| Teststatus | Methode, Datum, Ergebnis, Abweichung und nächster Termin |
| Owner | fachlich und technisch Verantwortliche sowie Vertretung |
| Risiko/Maßnahme | Register-ID, Restrisiko, Behandlung, Budget, Termin und Entscheidung |
| Quellenstand | Interview, Architektur, Vertrag, Test oder Monitoring mit Stand |
¶ 18. Ersatzwege und Notbetrieb bewerten
| Kriterium | Leitfrage | Nachweisbeispiel |
|---|---|---|
| Unabhängigkeit | Teilt der Ersatz kritische Fehlerursachen mit dem Primärweg? | Architektur- und Providerprüfung |
| Aktivierungszeit | Ist er einschließlich Entscheidung und Zugang rechtzeitig nutzbar? | Übungsprotokoll |
| Kapazität | Trägt er Mindestlast, Spitzenlast und erwartete Dauer? | Lasttest oder belastbare Kalkulation |
| Datenstand | Sind Daten vollständig, konsistent und fachlich nutzbar? | Restore- und Abstimmungstest |
| Sicherheit | Bleiben Zugriff, Protokollierung und Schutzanforderungen erhalten? | technische Prüfung |
| Personal | Sind Befugnisse, Wissen, Erreichbarkeit und Vertretung vorhanden? | Bereitschafts-/Schulungsnachweis |
| Vertrag | Darf und muss der Anbieter die Ersatzleistung erbringen? | Vertrag, SLA, Notfallkontakt |
| Rückkehr | Ist die kontrollierte Rückführung inklusive Abgleich geplant? | Rückkehrverfahren und Test |
Ein manuelles Verfahren ist nur dann eine Alternative, wenn zulässige Eingabedaten, Vier-Augen-Kontrollen, Kapazitätsgrenzen, Datenschutz, Rückerfassung und spätere Abstimmung geklärt sind.
¶ 19. Technischer Baustein: aufklappbare Prüffragen
Die Prüffelder lassen sich einzeln öffnen. Sie eignen sich für Workshops und Reviews, ersetzen jedoch kein freigegebenes Prüfprotokoll.
Prüffeld A · Dienst und Ausfallwirkung
- Sind Empfänger, Leistungsgrenze und Mindestqualität eindeutig?
- Welche Wirkung tritt in welchem Zeitfenster und bei welchem Ausfallzeitpunkt ein?
- Welche Schwelle macht eine Unterbrechung nicht mehr tolerierbar?
- Welche Annahmen, Mengen, Verträge oder gesetzlichen Pflichten stützen die Bewertung?
- Wer bestätigt die fachliche Auswirkung und wer gibt die Toleranz frei?
Prüffeld B · Dienstkette, Engpass und Konzentration
- Sind Identität, DNS, Netzwerk, Zertifikate, Monitoring und Administration mitbetrachtet?
- Gibt es gemeinsame Standorte, Regionen, Provider, Leitungen, Schlüssel oder Administrationswege?
- Welche Unterauftragnehmer und Vorleister liegen hinter dem unmittelbaren Anbieter?
- Kann ein Fehler mehrere kritische Dienste oder beide Redundanzpfade gleichzeitig treffen?
- Ist jeder erkannte Engpass mit Risiko, Owner, Maßnahme und Entscheidung verbunden?
Prüffeld C · Alternative, Wiederanlauf und Nachweis
- Sind RTO und RPO entlang der Kette widerspruchsfrei und praktisch erreichbar?
- Ist die Alternative unabhängig, ausreichend dimensioniert und rechtzeitig aktivierbar?
- Wurden Notbetrieb, Restore, Datenabgleich, fachliche Abnahme und Rückkehr getestet?
- Sind Befugnisse, Notzugänge, Kommunikationsmittel und Spezialwissen auch in der Störung verfügbar?
- Sind Abweichungen, Restrisiken, Maßnahmen und nächste Tests nachvollziehbar dokumentiert?
¶ 20. Datenqualität der Bewertung
✓ GRÜN · belastbar
Scope, Quellen, Owner, Schwellen und Abhängigkeiten bestätigt; aktueller Test vorhanden.
Scope, Quellen, Owner, Schwellen und Abhängigkeiten bestätigt; aktueller Test vorhanden.
! GELB · teilweise belegt
Einzelne Annahmen oder Nachweislücken mit Termin und Owner dokumentiert.
Einzelne Annahmen oder Nachweislücken mit Termin und Owner dokumentiert.
× ROT · hohe Unsicherheit
Scope, Wirkung, Kette oder Machbarkeit unzureichend; Entscheidung eskalieren.
Scope, Wirkung, Kette oder Machbarkeit unzureichend; Entscheidung eskalieren.
○ GRAU · ungeprüft
Noch keine belastbare Prüfung; nicht als geringe Kritikalität interpretieren.
Noch keine belastbare Prüfung; nicht als geringe Kritikalität interpretieren.
Kritikalitätsklasse und Datenqualität werden getrennt angezeigt. „K1/Rot“ bedeutet beispielsweise: potenziell kritischer Dienst, dessen Bewertung noch nicht belastbar ist. Genau diese Kombination benötigt besondere Aufmerksamkeit.
¶ 21. Szenarioanalyse
| Szenario | zusätzliche Prüfpunkte |
|---|---|
| Ransomware/Datenkorruption | saubere Wiederherstellungsquelle, Identität, Schlüssel, forensische Sperren, Rückfallrisiko |
| Ausfall Identitätsdienst | Break-Glass-Zugänge, Administration, Monitoring, Cloud- und Notfallkommunikation |
| Cloud-/Provider-Ausfall | Statuskanal, Abhängigkeit von Control Plane, Region, Exit, Datenexport und Unterauftragnehmer |
| Standortverlust | Zutritt, Ersatzarbeitsplätze, Hardware, Kommunikation, Papier-/Datenträgerzugriff |
| Energie/Telekommunikation | Überbrückungsdauer, Treibstoff, Leitungswege, Mobilfunkkonzentration |
| Personalausfall | Mindestbesetzung, Vertretung, Befugnisse, Arbeitszeit und Schlüsselwissen |
| Lieferkettenausfall | Lagerbestand, alternative Quelle, Qualifikation, lange Wiederbeschaffungszeit |
| fehlerhafte Änderung | Rollback, Konfigurationsstand, Datenmigration und unabhängige Freigabe |
| gleichzeitiger Mehrfachausfall | konkurrierende Ressourcen, Krisenpriorität, Kommunikation und Eskalation |
Szenarien prüfen nicht nur, ob irgendeine Alternative existiert, sondern ob sie unter realistischen Randbedingungen gleichzeitig mit anderen Anforderungen funktioniert.
¶ 22. Wiederanlaufprioritäten festlegen
| Priorisierungsfrage | Warum sie nötig ist |
|---|---|
| Welche Vorbedingung muss zuerst verfügbar sein? | technische Plattformen können vor dem fachlichen Dienst starten müssen |
| Welche Leistung schützt Gesundheit, Sicherheit oder Versorgung? | reine Umsatzpriorisierung wäre unzureichend |
| Welche Frist läuft zuerst ab? | Schadensverläufe unterscheiden sich |
| Welche Maßnahme verhindert Kaskaden? | ein zentraler Basisdienst stabilisiert mehrere Leistungen |
| Welche Ressource ist knapp? | Personal, Energie oder Kommunikation kann nicht gleichzeitig alles tragen |
| Welche Wiederherstellung ist reversibel? | voreilige Schritte können Daten oder Beweise gefährden |
Die generelle Prioritätsliste wird vorbereitet; die konkrete Reihenfolge bestätigt die befugte Lageführung anhand Ereignis, Sicherheitslage, Verfügbarkeit und aktuellen Folgen.
¶ 23. Änderungs- und Reviewauslöser
| Auslöser | erforderliche Aktualisierung |
|---|---|
| neuer/geänderter Dienst oder Prozess | Scope, Empfänger, Wirkung, Owner und Kette |
| Architektur-, Cloud- oder Standortänderung | Abhängigkeiten, gemeinsame Ursachen und Zeitziele |
| neuer Anbieter/Unterauftragnehmer | Konzentration, Vertrag, Incident- und Exit-Weg |
| geänderte Mengen, Saison oder Kundenstruktur | Schwellen, Spitzenlast und Mindestbetrieb |
| Vorfall, Test oder verfehltes Ziel | Annahmen, Machbarkeit, Maßnahmen und Restrisiko |
| Rechts-/Vertragsänderung | Wirkungsdimension, Fristen und Nachweise |
| organisatorische Änderung | Rollen, Befugnisse, Vertretung und Schlüsselwissen |
| regulärer Review | Vollständigkeit, Aktualität und Freigabe |
¶ 24. Verbindung zu Risiko-, Notfall- und Maßnahmensteuerung
| Befund | Weitergabe an | erwartetes Ergebnis |
|---|---|---|
| kritische Abhängigkeit ohne Alternative | NIS2-Risikoregister | Risikoszenario und Behandlung |
| Zielzeit technisch nicht erreichbar | Risikobehandlungsplan/Management | Investitions- oder Akzeptanzentscheidung |
| ungeprüftes Notverfahren | Übungs- und Testprogramm | Test mit Erfolgskriterien |
| Anbieter-/Konzentrationsrisiko | Lieferantensteuerung | Vertrag, Alternative oder Exit-Maßnahme |
| Daten-/Schnittstellenabhängigkeit | Informationsfluss- und Assetregister | Owner, Schutzbedarf und Kontrolle |
| Wiederanlaufkonflikt | BCM/Wiederanlaufplanung | abgestimmte Reihenfolge und Ressourcen |
| verfehlter Test | Korrekturmaßnahmen | Ursache, Korrektur und Nachprüfung |
¶ 25. Fiktives Musterregister
| ID | Musterobjekt | Klasse | kritische Abhängigkeit | Beispielziel | Datenqualität | Handlungsbedarf |
|---|---|---|---|---|---|---|
| DEMO-KA-001 | Beispieldienst A | ■ K1 · Muster | zentrale Beispielidentität | RTO 4 h / RPO 1 h | ! GELB | gemeinsamer Ausfallweg prüfen |
| DEMO-KA-002 | Beispielprozess B | ▲ K2 · Muster | fiktiver Cloud-Dienst | RTO 12 h / RPO 4 h | × ROT | Unterauftragnehmer/Exit offen |
| DEMO-KA-003 | Musterleistung C | ○ KU · Muster | noch nicht erhoben | offen | ○ GRAU | Owner und BIA festlegen |
Alle Namen, Klassen und Zeitwerte sind fiktiv. Sie dürfen nicht in ein echtes Notfall- oder Risikoregister übernommen werden.
¶ 26. Sinnvolle Registeransichten
| Ansicht | Filter | Nutzen |
|---|---|---|
| Management | K1/K2, rote Datenqualität, überfällige Maßnahmen | Entscheidungen und Ressourcen |
| BCM | MTPD, RTO, Mindestbetrieb, Teststatus | Notbetrieb und Wiederanlauf |
| Technik | System-/Plattformabhängigkeiten, RTO-Konflikte | Architektur und Recovery |
| Einkauf | externe Abhängigkeiten, Konzentration, Exit | Anbietersteuerung |
| Standort | Energie, Räume, Kommunikation, alternative Standorte | physische Resilienz |
| Audit | Quelle, Freigabe, Review, Nachweis, Abweichung | Nachvollziehbarkeit |
¶ 27. Kennzahlen und Berichtswesen
| Kennzahl | Berechnung/Aussage | Eskalationsbeispiel |
|---|---|---|
| kritische Dienste ohne freigegebene BIA | Anzahl K1/K2 ohne bestätigte Bewertung | jede Lücke berichten |
| Zeitziele ohne Machbarkeitsnachweis | offene technische/fachliche Bestätigungen | bei K1 sofort priorisieren |
| SPOFs ohne Behandlung | Engpässe ohne akzeptiertes Risiko oder Maßnahme | Managemententscheidung |
| ungetestete kritische Alternativen | Ersatzwege ohne gültigen Test | Testprogramm priorisieren |
| RTO-Konflikte in Dienstketten | Ressource später als abhängiger Dienst | Planung korrigieren |
| Konzentrationen ohne Exit/Alternative | kritische Dienste mit gemeinsamem Ausfallweg | portfolioübergreifend behandeln |
| verfehlte Wiederanlaufziele | Tests/Vorfälle außerhalb Ziel | Ursachen- und Wirksamkeitsprüfung |
| überfällige Reviews | Frist oder Trigger überschritten | Owner und Leitung informieren |
Zu jeder Kennzahl gehören Datenquelle, Stichtag, Scope, Owner, Zielwert, Toleranz, Trend und Kommentierung. Prozentwerte ohne Nenner und Datenqualität sind nicht aussagekräftig.
¶ 28. Nachweise und geschützte Ablage
| Nachweisart | zeigt | Schutzhinweis |
|---|---|---|
| freigegebene BIA | Wirkung, Zeit und Entscheidung | vertraulich |
| Dienstketten-/Architekturmodell | Abhängigkeiten und Engpässe | besonders schützenswert |
| technische Machbarkeitsbestätigung | Konsistenz von RTO/RPO/Kapazität | intern/vertraulich |
| Vertrag/SLA/Unterauftragnehmerliste | externe Verpflichtung und Konzentration | Vertragsablage |
| Restore-/Wiederanlauf-/Notbetriebstest | praktische Fähigkeit und Grenzen | geschützte Nachweisablage |
| Übungs- und Vorfallauswertung | Verhalten unter realen Randbedingungen | Zugriff beschränken |
| Maßnahmen-/Risikofreigabe | Behandlung, Budget, Restrisiko | Entscheidungsschutz |
Das öffentliche Wiki enthält Methodik, Status und kontrollierte Referenzen, jedoch keine verwertbaren Angriffspfade, Notzugänge, privaten Kontaktdaten, Vertragsoriginale oder vollständigen Dienstketten.
¶ 29. Häufige Fehler
| Fehler | Folge | Korrektur |
|---|---|---|
| Kritikalität wird aus Bauchgefühl vergeben | nicht vergleichbare Prioritäten | Dimensionen, Schwellen und Quellen verwenden |
| nur „24/7“ oder SLA wird übernommen | Geschäftsfolgen bleiben unbekannt | BIA aus Sicht der eigenen Leistung durchführen |
| nur primäre Anwendungen werden erfasst | Basisdienste und Governance fehlen | Kette bis Identität, Netz, Standort und Anbieter verfolgen |
| RTO = maximale Toleranz | keine Reserve für Erkennung, Entscheidung und Fehler | gestaffelte Zeitziele ableiten |
| Redundanz wird nicht auf gemeinsame Ursachen geprüft | beide Wege fallen gleichzeitig aus | Unabhängigkeit und Kaskaden testen |
| manuelles Verfahren gilt ungeprüft als Ersatz | Kapazität, Datenqualität und Befugnis fehlen | Notbetrieb realistisch üben |
| hohe Kritikalität wird mit hohem Risiko gleichgesetzt | falsche Maßnahmenpriorität | Kritikalität, Risiko und Datenqualität trennen |
| grün bedeutet „umgesetzt“ | Musterdarstellung erzeugt Scheinsicherheit | Statusaussage und Nachweisgrenze angeben |
¶ 30. Qualitätsgate vor Freigabe
| Prüffrage | Musterstatus |
|---|---|
| Sind Dienste, Empfänger, Leistungsgrenzen und Owner bestätigt? | Offen |
| Sind Auswirkungsdimensionen, Schwellen und Zeitfenster freigegeben? | Offen |
| Sind MTPD, RTO, RPO und Mindestbetriebsniveau konsistent? | Offen |
| Sind direkte, indirekte und externe Abhängigkeiten Ende-zu-Ende erfasst? | Offen |
| Sind gemeinsame Ursachen, Kaskaden, SPOFs und Konzentrationen bewertet? | Offen |
| Sind Alternativen unabhängig, dimensioniert, aktivierbar und sicher? | Offen |
| Ist die technische, personelle, räumliche und vertragliche Machbarkeit belegt? | Offen |
| Sind Ergebnisse mit Risiko-, Lieferanten-, Notfall- und Wiederanlaufplanung verknüpft? | Offen |
| Sind Tests, Abweichungen, Maßnahmen, Entscheidungen und Reviews aktuell? | Offen |
| Bleiben sensible Detailnachweise geschützt? | Offen |
¶ 31. Offene Entscheidungen vor produktiver Nutzung
| Entscheidung | Verantwortliche Funktion | Musterstatus |
|---|---|---|
| Analyse-Scope und Diensthierarchie | Geschäftsleitung / Dienststeuerung | Offen |
| Auswirkungsdimensionen und Schwellen | Management / BCM / Fachbereiche | Offen |
| Zeitraster, K1–K4 und KU | BCM / Informationssicherheit | Offen |
| Regeln für MTPD, RTO, RPO und Reserve | BCM / IT / Dienst-Owner | Offen |
| führendes Abhängigkeitsregister | Prozess-/Assetmanagement | Offen |
| SPOF-, Konzentrations- und Eskalationskriterien | Sicherheit / BCM / Einkauf | Offen |
| Mindestanforderungen an Ersatzwege und Tests | BCM / IT / Einkauf | Offen |
| Datenqualitätsampel und Reviewtakt | Informationssicherheit / Audit | Offen |
| geschützte Ablage und Berechtigung | Dokumentenverantwortung | Offen |
Bis zur dokumentierten Freigabe bleiben sämtliche Musterwerte und Ampeln Entwurf.
¶ 32. Verknüpfte Seiten
| Thema | Wiki-Seite |
|---|---|
| relevante Dienste | Relevante Dienste und Prozesse |
| Assets und Systeme | Asset- und Systeminventar |
| Informationswege | Daten- und Informationsflüsse |
| externe Abhängigkeiten | Externe Dienste und Cloud |
| Standorte | Standorte und Infrastruktur |
| Risikobewertung | NIS2-Risikomethodik |
| Risiken | NIS2-Risikoregister |
| Nachweise | NIS2-Nachweisregister |
| Lieferantensteuerung | Lieferanten und Dienstleister |
| Kontinuität | Notfallvorsorge und BCM |
| Wiederanlauf | Wiederanlaufplanung |
| Tests | Backup-, Restore- und Wiederanlauftests |
| Wirksamkeit | NIS2-Wirksamkeitsprüfung |
¶ 33. Offizielle Grundlagen und Orientierung
| Quelle | Verwendung |
|---|---|
| § 30 BSIG | Verhältnismäßigkeit, gefahrenübergreifende Risikomanagementmaßnahmen, Aufrechterhaltung des Betriebs, Lieferkette und Wirksamkeit |
| BSI-Standard 200-4 – Business Continuity Management | Business-Impact-Analyse, zeitkritische Prozesse, Ressourcen, Notbetrieb und Wiederanlauf |
| Durchführungsverordnung (EU) 2024/2690 | für die erfassten digitalen Einrichtungsarten Konkretisierung zu BIA, Kontinuität und Assetklassifizierung |
| BSI – Schutzbedarfsfeststellung | Abhängigkeiten, Schadensszenarien und Schutzbedarf von Zielobjekten |
Anwendbarkeit, Rechtsstand, Scope und sektorale Anforderungen werden vor produktiver Nutzung aktuell geprüft. Alle externen Links öffnen in einem neuen Tab.
¶ 34. Weiterführende Unterstützung durch SMCT MANAGEMENT
SMCT MANAGEMENT
Unterstützung bei NIS2-Kritikalitätsanalysen, Business Continuity, Dienstketten, Lieferantenabhängigkeiten und belastbaren Nachweisen.
Informationen zur NIS2-Beratung öffnen
Unterstützung bei NIS2-Kritikalitätsanalysen, Business Continuity, Dienstketten, Lieferantenabhängigkeiten und belastbaren Nachweisen.
Informationen zur NIS2-Beratung öffnen
¶ 35. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Seite visuell und fachlich neu aufgebaut; Cockpit, Begriffstrennung, BIA-Ablauf, Auswirkungsmatrix, Zeitziele, Dienstkette, SPOF-/Konzentrationsanalyse, Ersatzwegbewertung, aufklappbare Prüffelder, Datenqualitätsampel, Szenarien, Register, Kennzahlen und Qualitätsgate ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Rollen, Auswirkungsskala, Zeitziele, Abhängigkeitsregister, Szenarien, Kennzahlen und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Mustermethodik für Kritikalität und Abhängigkeiten erstellt | Ausstehend |