Business-Impact-Analyse (BIA): Was Nummer 4.1.3 verbindlich verlangt — und was nur empfohlen ist

Eine Business-Impact-Analyse steht in der NIS-2-Richtlinie nicht. Im BSI-Gesetz steht sie ebenfalls nicht: § 30 Absatz 2 Nummer 3 BSIG verlangt „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“ — die Wörter „Business“, „Impact“ und „Ausfallzeit“ kommen in der Vorschrift kein einziges Mal vor [3]. Daraus zieht der deutschsprachige Markt fast einhellig denselben Schluss: die BIA sei „nicht ausdrücklich gefordert, aber anerkannte Praxis“.

Dieser Schluss ist unvollständig. In der Durchführungsverordnung (EU) 2024/2690 taucht die Analyse genau vier Mal auf, zwei davon im bindenden Anhang — und eine dieser Stellen, Nummer 4.1.3, ist als glatte Pflicht formuliert, ohne jeden Angemessenheitsvorbehalt [2]. Wo die Pflicht steht, entscheidet, was Sie dokumentieren müssen, welche Kennzahlen ein Prüfer verlangen darf und welche Sie begründet weglassen dürfen. ENISA führt Betriebskontinuität und Notfallwiederherstellung mit 49 Prozent als zweitschwierigste NIS2-Anforderung überhaupt, direkt hinter dem Patchmanagement [6].

Gilt das für mein Unternehmen?

Drei Regelwerke beschreiben dieselbe Pflicht auf drei Ebenen — aber nur eines bindet Sie unmittelbar, und welches das ist, hängt von Ihrer Einrichtungsart ab.

Ebene	Was dort steht	Für wen bindend
Art. 21 Abs. 2 Buchst. c NIS2	„Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“ — keine Methode, keine Kennzahl [1]	Über die nationale Umsetzung; in Deutschland über das BSIG
§ 30 Abs. 2 Nr. 3 BSIG	Wortgleich mit Buchstabe c. Dazu § 30 Abs. 1 Satz 3: „Die Einhaltung der Verpflichtung … ist durch die Einrichtungen zu dokumentieren.“ [3]	Alle besonders wichtigen und wichtigen Einrichtungen in Deutschland
DVO (EU) 2024/2690, Anhang Kapitel 4	Überschrieben „Betriebskontinuitäts- und Krisenmanagement (Artikel 21 Absatz 2 Buchstabe c …)“. Nummer 4.1.3 verlangt die Analyse ausdrücklich [2]	Unmittelbar nur für die in Art. 1 genannten Digitaldienste — DNS, TLD-Registries, Cloud, Rechenzentren, CDN, MSP/MSSP, Online-Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdiensteanbieter

Für Compliance und Recht: Gehört Ihr Unternehmen zu keiner der in Artikel 1 der Durchführungsverordnung genannten Arten, bindet Sie Kapitel 4 nicht direkt. Es bleibt trotzdem der Maßstab, an dem die Aufsicht misst, was „geeignet, verhältnismäßig und wirksam“ nach § 30 Absatz 1 BSIG bedeutet — denn es ist die einzige Konkretisierung, die die Kommission zu Buchstabe c erlassen hat. § 30 Absatz 3 BSIG schreibt für die genannten Einrichtungsarten sogar ausdrücklich den „Vorrang“ des Durchführungsrechtsakts fest [3].

Für die Geschäftsführung: Die praktische Konsequenz ist für beide Gruppen dieselbe. Ohne eine nachvollziehbare Analyse gibt es keine begründbaren Wiederherstellungsziele, und ohne begründbare Ziele ist die Dokumentationspflicht aus § 30 Absatz 1 Satz 3 BSIG nicht erfüllbar. Das Thema ist im Detail im Leitfaden zur NIS2-Betriebskontinuität eingeordnet.

Wo die BIA im Recht steht: vier Fundstellen, zwei davon bindend

Der deutsche Verordnungstext spricht nicht von „Business-Impact-Analyse“, sondern von der „Analyse der betrieblichen Auswirkungen“. Die Abkürzung BIA steht nur in Klammern in zwei Erwägungsgründen. Genau diese Formulierung kommt im deutschen Volltext der Verordnung vier Mal vor — und die vier Stellen haben unterschiedliches Gewicht [2].

Fundstelle	Wortlaut (gekürzt)	Rechtliche Wirkung
Anhang Nr. 4.1.3	„Die betreffenden Einrichtungen führen eine Analyse der betrieblichen Auswirkungen durch … und legen auf der Grundlage der Ergebnisse Kontinuitätsanforderungen für die Netz- und Informationssysteme fest.“	Bindend. Kein „soweit angemessen“, kein „sollten“
Anhang Nr. 2.1.3	Bei der Priorisierung von Risikobehandlungsmaßnahmen ist „die in Nummer 4.1.3 genannte Analyse der betrieblichen Auswirkungen“ zu berücksichtigen	Bindend — verknüpft die BIA mit dem Risikomanagement
Erwägungsgrund 13	Einrichtungen „werden dazu ermuntert„, im Zuge der BIA „— soweit angemessen — maximal tolerierbare Ausfallzeiten, Vorgaben für Wiederherstellungszeiten und Wiederherstellungspunkte und Zielvorgaben für die Erbringung der Dienste“ zu erfassen	Nicht bindend. Erwägungsgründe erklären die Absicht, sie begründen keine Pflicht
Erwägungsgrund 25	Bei der BIA können Einrichtungen die Klassifizierungsstufe ihrer Anlagen „auf der Grundlage der Folgen einer Störung“ bestimmen	Nicht bindend, aber die einzige Brücke zwischen BIA und Asset-Klassifizierung

Das Ergebnis ist unbequemer, als es zunächst klingt. Verbindlich ist die Durchführung der Analyse und die Ableitung von Kontinuitätsanforderungen. Der vollständige Kennzahlensatz aus MTA, RTO, RPO und Zielvorgaben für die Diensterbringung ist dagegen ausdrücklich als Ermunterung formuliert. Bindend im Anhang bleiben nur die „Wiederherstellungsziele“, die Nummer 4.1.2 Buchstabe f — dort wiederum „soweit angemessen“ — im Notfallplan verlangt, sowie die „Wiederherstellungszeiten“ in den Sicherungsplänen nach Nummer 4.2.2 Buchstabe a [2].

Praktisch heißt das: Wer alle vier Kennzahlen erhebt, ist auf der sicheren Seite. Wer aus guten Gründen nur drei erhebt, hat einen Verteidigungsspielraum — muss die Begründung aber aufschreiben. Artikel 2 Absatz 2 der Verordnung verlangt genau das, wo eine Einrichtung eine als angemessen gekennzeichnete Anforderung nicht umsetzt.

Vier Kenngrößen, vier Vokabulare

Die größte Reibung in deutschen BIA-Projekten ist nicht methodisch, sondern sprachlich. Dieselben vier Zahlen heißen in den drei maßgeblichen Quellen unterschiedlich, und keine der Quellen definiert die Begriffe der jeweils anderen.

Was gemessen wird	DVO, Erwägungsgrund 13	ENISA-Leitfaden	BSI-Standard 200-4
Wie lange ein Prozess ausfallen darf, bevor der Schaden untragbar wird	maximal tolerierbare Ausfallzeiten	MAO / MTPD	MTPD, deutsch: Maximal Tolerierbare Ausfallzeit (MTA)
Bis wann der Notbetrieb stehen muss	Vorgaben für Wiederherstellungszeiten	RTO	RTO, deutsch: Geforderte Wiederanlaufzeit (WAZ)
Wie alt die verfügbaren Daten maximal sein dürfen	Wiederherstellungspunkte	RPO	RPO, deutsch: maximal zulässiger Datenverlust
Wie leistungsfähig der Notbetrieb sein muss	Zielvorgaben für die Erbringung der Dienste	SDO	Notbetriebsniveau (MBCO)

Ein Hinweis zur Sorgfalt, weil er in der Praxis Fehler verursacht: Der ENISA-Leitfaden definiert das RPO zunächst korrekt als akzeptierten Datenverlust, beschreibt es im selben Absatz dann aber als „maximum time needed to recover data“ und nennt als Beispiel die „maximum recovery time“ eines Webshops [5]. Das vermischt RPO und RTO. Halten Sie sich an die eindeutige Definition des BSI: Das RPO bestimmt, „wie alt verfügbare Daten maximal sein dürfen, um im Notbetrieb sinnvoll damit arbeiten zu können“ — und daraus wird der notwendige Datensicherungszyklus abgeleitet, nicht umgekehrt [4].

Wie die MTA tatsächlich entsteht

Die MTA wird nicht geschätzt und nicht verhandelt. Sie ist das Ergebnis einer Kurve. BSI-Standard 200-4 stellt der Erhebung eine einzige Leitfrage voran: „Wenn ein Geschäftsprozess ausfällt, mit welchem Schadenspotenzial ist im jeweiligen Zeithorizont zu rechnen?“ [4]

Daraus folgen drei Festlegungen, die vor dem ersten Interview stehen müssen:

1. Zeithorizonte. Punkte auf der Zeitachse, zu denen der Schaden bewertet wird — jeder Punkt x bedeutet „der Prozess ist ausgefallen bis zum Zeitpunkt x“. Das BSI nennt fünf bis acht Horizonte als bewährt und empfiehlt, sie dort zu setzen, wo sich der Schadensverlauf im Unternehmen typischerweise wesentlich ändert. Ein Onlinehändler wählt kurze Horizonte, ein Anlagenbauer mit langen Bearbeitungszeiten längere [4].
2. Schadensszenarien. Die Auswirkungskategorien, in denen überhaupt Schaden entstehen kann.
3. Untragbarkeitsniveau. Die Schwelle, ab der ein Ausfall „nicht länger akzeptiert werden kann“. Erst dieser Schwellenwert macht aus einer Schadenseinschätzung eine Zahl: Der Zeitpunkt, an dem die Schadenskurve die Schwelle schneidet, ist die MTA — und ab dem der Prozess als zeitkritisch gilt [4].

BSI-Standard 200-4 nennt fünf Schadensszenarien als Mindestumfang. Sie decken direkte Schäden wie entgangene Gewinne ebenso ab wie indirekte, etwa Marktanteilsverluste oder Auswirkungen auf Dritte [4]:

Schadensszenario	Typische Prüffrage im Interview
Beeinträchtigung der persönlichen Unversehrtheit	Kann der Ausfall Menschen gefährden — direkt oder über ausbleibende Leistungen?
Beeinträchtigung der Aufgabenerfüllung	Welche Leistung gegenüber Kunden, Patienten oder Bürgern entfällt?
Verstoß gegen Gesetze, Vorschriften und Verträge	Welche Frist, Meldepflicht oder Vertragsstrafe wird nach x Stunden verletzt?
Negative Innen- und Außenwirkung	Ab wann wird der Ausfall öffentlich sichtbar?
Finanzielle Auswirkungen	Welcher Umsatz, welche Vertragsstrafe, welcher Mehraufwand fällt je Zeithorizont an?

Eine Verwechslung, die das BSI ausdrücklich adressiert: Schadensszenarien sind Auswirkungskategorien einer Prozessunterbrechung. Ausfallszenarien sind die möglichen Ausfälle der Ressourcen — Gebäude, Personal, Dienstleister, IT. Die BIA fragt nach den Schadens-, nicht nach den Ausfallszenarien; die Ausfallszenarien gehören in die nachgelagerte BCM-Risikoanalyse [4]. Wer beides im selben Fragebogen mischt, bekommt Antworten, die sich nicht aggregieren lassen.

Warum die RTO zwingend kürzer sein muss als die MTA

Der häufigste Fehler in fertigen BIA-Tabellen ist eine RTO, die genauso groß ist wie die MTA. Das ist rechnerisch falsch, und BSI-Standard 200-4 sagt warum: Die RTO „umfasst den Zeitraum vom Ausrufen des Notfalls bis zum Zeitpunkt der geforderten Inbetriebnahme der BC-Lösung“ — die Uhr für die MTA läuft dagegen ab dem Ausfall selbst. „Die RTO muss zwingend kürzer sein als die MTPD des relevanten Geschäftsprozesses, denn die Reaktionszeit wird von der MTPD abgezogen“ [4].

Zwischen Ausfall und Ausrufen des Notfalls liegen Erkennung, Bewertung und Eskalation. Das BSI empfiehlt darüber hinaus einen zusätzlichen Puffer, „da insbesondere die Detektion mit Unsicherheiten hinsichtlich des genauen zeitlichen Ablaufs einhergeht“ [4]. Ein Rechenbeispiel für einen Bestellprozess:

Größe	Wert	Herkunft
MTA	8 Stunden	Schadenskurve schneidet das Untragbarkeitsniveau beim Zeithorizont „8 Stunden“
Detektion und Eskalation	2 Stunden	Gemessen aus den Alarmierungszeiten des Monitorings
Sicherheitspuffer	1 Stunde	Empfehlung BSI 200-4 wegen Detektionsunsicherheit
RTO (Wiederanlaufzeit)	5 Stunden	8 − 2 − 1
RPO	1 Stunde	Maximal tolerierter Datenverlust; bestimmt den Sicherungszyklus
Notbetriebsniveau	60 % des normalen Bestellvolumens	Je Prozess festgelegt, prozentual oder über priorisierte Aktivitäten

Für die IT-Leitung: Die 5 Stunden sind keine Zielvorgabe für die vollständige Wiederherstellung. Sie sind die Frist bis zum Erreichen des Notbetriebsniveaus. Die Rückkehr in den Normalbetrieb ist ein eigener Schritt — im BSI-Vokabular der Wiederherstellungsplan, in der Durchführungsverordnung Nummer 4.1.2 Buchstabe h, „Wiederherstellung und Wiederaufnahme der Tätigkeiten nach vorübergehenden Maßnahmen“ [2][4]. Welche Abschnitte der Plan sonst noch braucht, steht in der Vorlage für den IT-Notfallplan.

Die Erhebung — und der Vorfilter, der Ihnen Wochen spart

BSI-Standard 200-4 nennt drei Erhebungsformate: Selbstauskunft per Fragebogen, Einzelinterviews und Workshops. Für den ersten Durchlauf empfiehlt das BSI ausdrücklich Workshops, moderiert von einer BCM-kundigen Person [4]. Der Grund ist weniger organisatorisch als psychologisch — und er erklärt zwei Sätze, die das BSI wörtlich als Hinweis in die Workshop-Vorbereitung schreibt:

• Die BIA „dient nicht der Organisationsoptimierung“; aus ihren Ergebnissen lassen sich „weder Umstrukturierungen, Arbeitsplatzverdichtung oder ähnliches“ ableiten, weil die Fragen sich auf einen temporären Notbetrieb beziehen [4].
• Die Frage, ob ein Prozess zeitkritisch ist, ist nicht die Frage, ob er wichtig ist [4].

Ohne diese beiden Klarstellungen bewertet jede Abteilung ihren eigenen Prozess als kritisch — entweder aus Sorge vor Kürzungen oder aus Stolz. Das Ergebnis ist eine BIA, in der 80 Prozent der Prozesse eine MTA von vier Stunden haben und die deshalb nichts priorisiert.

Für KMU: Eine vollständige BIA über sämtliche Geschäftsprozesse ist selten der richtige erste Schritt, und das BSI sagt das selbst. Weil die BIA „mit einem erhöhten Aufwand verbunden ist und eine langwierige Untersuchung eine schnelle BC-Planung verzögern kann“, stellt BSI-Standard 200-4 ihr im Reaktiv- und im Aufbau-BCMS einen BIA-Vorfilter voran. Dieser filtert den Untersuchungsbereich grob vor, „sodass in dieser nur noch die zeitkritischsten Einheiten untersucht werden“ [4]. Wer mit 120 Prozessen startet, untersucht nach dem Vorfilter vielleicht 15 gründlich — und hat damit ein belastbares Ergebnis statt 120 oberflächlicher Schätzungen.

Was die BIA außerhalb des Notfallplans steuert

Die BIA wird meist als BCM-Dokument behandelt. Im Anhang der Durchführungsverordnung ist sie das nicht: Ihr Ergebnis ist Eingangsgröße für drei weitere Kapitel. Das ist der stärkste Grund, sie sauber zu machen — ein schwaches BIA-Ergebnis schwächt nicht nur den Notfallplan.

Nummer	Was dort mit dem BIA-Ergebnis geschieht	Zugehöriger Bereich
2.1.3	Risikobehandlungsoptionen werden unter Berücksichtigung „der in Nummer 4.1.3 genannten Analyse der betrieblichen Auswirkungen“ priorisiert	Risikomanagement nach Art. 21(2)(a)
12.1.2 Buchst. c	Die Verfügbarkeitsanforderungen der Anlagen werden „an die … festgelegten Ziele für die Bereitstellung und Wiederherstellung“ angepasst	Asset-Management nach Art. 21(2)(i)
4.2.2 Buchst. a	Sicherungspläne werden auf Basis von Risikobewertung und Betriebskontinuitätsplan festgelegt und enthalten „Wiederherstellungszeiten“	Backup und Redundanz
4.1.2 Buchst. e und f	„Reihenfolge der Wiederherstellung der Betriebsabläufe“ und „Wiederherstellungspläne … einschließlich der Wiederherstellungsziele“	Notfallplan

Die Reihenfolge im Verordnungstext ist dabei irreführend: Nummer 4.1.2 beschreibt den fertigen Plan, Nummer 4.1.3 erst die Analyse. Arbeiten lässt sich nur in umgekehrter Richtung — ohne MTA gibt es keine begründbare „Reihenfolge der Wiederherstellung“.

Ist, Soll und was ein Prüfer sehen will

ENISA nennt für Nummer 4.1.3 genau zwei Nachweisbeispiele: eine „documented BIA with specific recovery objectives“ und „processes, procedures and measures to ensure the required level of continuity in disruptive situations“ [5]. Das erste Beispiel ist der eigentliche Prüfpunkt — eine BIA ohne konkrete Wiederherstellungsziele erfüllt es nicht, und eine Tabelle mit Zielen ohne erkennbare Herleitung ebenfalls nicht.

Ist-Zustand (typisch)	Soll nach Nr. 4.1.3	Aufwand
RTO/RPO stehen im Backup-Tool, hergeleitet wurde nichts	Dokumentierte Methodik mit Zeithorizonten, Schadensszenarien und Untragbarkeitsniveau	Mittel — ein Dokument, einmalig
Prozessliste ohne Kritikalitätsaussage	Bewertetes Schadenspotenzial je Prozess und Zeithorizont, MTA je Prozess	Hoch beim ersten Durchlauf, mit Vorfilter deutlich geringer
RTO = MTA in der Tabelle	RTO aus MTA abgeleitet, Reaktionszeit und Puffer abgezogen	Gering — Rechenschritt, keine neue Erhebung
Kein Notbetriebsniveau definiert	Je Prozess festgelegt, prozentual oder über priorisierte Aktivitäten	Gering bis mittel
BIA-Ergebnis fließt nirgends ein	Verknüpfung zu Risikobehandlung (2.1.3) und Asset-Klassifizierung (12.1.2)	Mittel — Querverweise in bestehenden Dokumenten

Für die Aktualisierung gibt es keine eigene Frist für die BIA. Nummer 4.1.4 verlangt Test und Überprüfung des Notfallplans „in geplanten Zeitabständen“ sowie nach erheblichen Sicherheitsvorfällen und wesentlichen Änderungen; ENISA empfiehlt dafür mindestens jährlich [2][5]. Da die Planinhalte aus der BIA stammen, folgt der Analyse-Turnus in der Praxis demselben Takt — als Auslegung, nicht als Buchstabe des Gesetzes.

Häufige Fragen

Ist eine Business-Impact-Analyse nach NIS2 Pflicht?
In der Richtlinie selbst und in § 30 BSIG wird sie nicht genannt. Nummer 4.1.3 des Anhangs der Durchführungsverordnung (EU) 2024/2690 verlangt sie ausdrücklich und ohne Angemessenheitsvorbehalt — unmittelbar bindend allerdings nur für die in Artikel 1 der Verordnung aufgeführten Digitaldienste. Für alle anderen Einrichtungen ist sie der Maßstab, an dem sich die Angemessenheit nach § 30 Absatz 1 BSIG messen lässt [2][3].

Muss ich RTO und RPO erheben?
Die vier Kenngrößen als Satz stehen in Erwägungsgrund 13 und sind dort als Ermunterung formuliert. Bindend im Anhang sind „Wiederherstellungsziele“ im Notfallplan (Nr. 4.1.2 Buchst. f, soweit angemessen) und „Wiederherstellungszeiten“ in den Sicherungsplänen (Nr. 4.2.2 Buchst. a). In der Praxis lässt sich keine dieser Anforderungen ohne RTO und RPO erfüllen [2].

Was ist der Unterschied zwischen MTA und RTO?
Die MTA misst ab dem Ausfall und beschreibt, wann der Schaden untragbar wird. Die RTO misst ab dem Ausrufen des Notfalls und beschreibt, wann der Notbetrieb stehen muss. Die RTO muss deshalb kürzer sein als die MTA — die Zeit für Erkennung und Eskalation wird abgezogen [4].

Reicht eine BIA für ein kleines Unternehmen mit zehn Prozessen?
Ja, und sie ist dort schneller belastbar als in einem Konzern. BSI-Standard 200-4 sieht für den Einstieg ohnehin einen BIA-Vorfilter vor, der den Untersuchungsbereich auf die zeitkritischsten Einheiten verengt [4]. Entscheidend ist nicht die Zahl der Prozesse, sondern dass Methodik und Schwellenwerte schriftlich festgelegt sind.

Was ist der Unterschied zwischen BIA und Risikoanalyse?
Die BIA fragt nach den Folgen eines Ausfalls, unabhängig von seiner Ursache — sie bewertet Schadensszenarien. Die Risikoanalyse fragt, gegen welche Ursachen man sich absichert — sie bewertet Ausfall- und Bedrohungsszenarien mit Eintrittswahrscheinlichkeit. Nummer 2.1.3 verbindet beide: Das BIA-Ergebnis ist eine Eingangsgröße der Risikobehandlung [2][4].

Wie oft muss die BIA wiederholt werden?
Die Verordnung nennt für die BIA selbst keine Frist. Nummer 4.1.4 verlangt Überprüfung des Notfallplans in geplanten Zeitabständen sowie nach erheblichen Vorfällen und wesentlichen Änderungen der Betriebsabläufe; ENISA empfiehlt mindestens jährlich. Eine Reorganisation, ein neues Werk oder ein neuer kritischer Dienstleister sind eigenständige Anlässe, unabhängig vom Kalender [2][5].

Fazit

Die verbreitete Auskunft, die BIA sei „unter NIS2 nicht gefordert, aber gute Praxis“, ist an einer Stelle nachweislich falsch: Nummer 4.1.3 der Durchführungsverordnung verlangt sie im Indikativ. Gleichzeitig ist der Kennzahlensatz, den der Markt als NIS2-Anforderung verkauft, eine Ermunterung aus Erwägungsgrund 13. Beides zu kennen ist der Unterschied zwischen einer BIA, die eine Prüfung trägt, und einer Tabelle, die Zahlen behauptet.

Der kürzeste belastbare Weg: Zeithorizonte, Schadensszenarien und Untragbarkeitsniveau schriftlich festlegen, den Untersuchungsbereich über den BIA-Vorfilter verengen, das Schadenspotenzial im moderierten Workshop erheben, die MTA am Schnittpunkt mit dem Untragbarkeitsniveau ablesen und die RTO daraus ableiten — nicht daneben stellen. Dass 49 Prozent der von ENISA befragten Organisationen Betriebskontinuität als schwierigste Baustelle nennen [6], liegt selten an der Methode. Es liegt daran, dass die Zahlen nie hergeleitet wurden.

Dieser Beitrag enthält allgemeine Informationen und stellt keine Rechts- oder Complianceberatung dar. Anforderungen können je nach Rechtsordnung, Sektor und Einrichtungsart abweichen. Für eine auf Ihre Situation zugeschnittene Bewertung ziehen Sie bitte qualifizierten Rechtsbeistand oder eine Compliance-Fachperson hinzu.

Quellen

1. Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie), Artikel 21 Absatz 2 Buchstabe c — EUR-Lex, deutsche Fassung
2. Durchführungsverordnung (EU) 2024/2690, Anhang Kapitel 4 sowie Nummern 2.1.3 und 12.1.2, Erwägungsgründe 13 und 25 — EUR-Lex, deutsche Fassung
3. § 30 BSIG — Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen — Gesetze im Internet, Bundesministerium der Justiz
4. BSI-Standard 200-4: Business Continuity Management, Version 1.0 (2023), Kapitel 6 und 7 — Bundesamt für Sicherheit in der Informationstechnik
5. Technical Implementation Guidance on Cybersecurity Risk Management Measures, Version 1.0 (Juni 2025), Abschnitt zu Nummer 4.1.3 — ENISA
6. NIS Investments 2025 — Main report (Dezember 2025) — ENISA