BCM nach NIS2: Business Continuity Management aufbauen (2026)

1. Rechtsbasis der BCM-Pflicht (DE und AT)

Die BCM-Pflicht steht in Deutschland in § 30 Abs. 2 Nr. 3 BSIG und in Österreich in § 32 Abs. 4 lit. c NISG 2026 — ISO 22301 und BSI-Standard 200-4 sind der Weg dorthin, nicht die Pflicht selbst.

§ 30 Abs. 2 Nr. 3 BSIG verlangt "Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement".

Den Maßstab dafür setzt § 30 Abs. 1 BSIG: geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen, um Störungen der Verfügbarkeit, Integrität und Vertraulichkeit der IT-Systeme zu vermeiden und die Auswirkungen von Sicherheitsvorfällen gering zu halten; die Einhaltung ist zu dokumentieren. Nach § 30 Abs. 2 Satz 1 BSIG sollen die Maßnahmen „den Stand der Technik einhalten, die einschlägigen europäischen und internationalen Normen berücksichtigen und müssen auf einem gefahrenübergreifenden Ansatz beruhen“. Genau hier docken ISO 22301 und BSI-Standard 200-4 an: als berücksichtigungsfähige Normen und Standards, aus denen sich die Umsetzungstiefe herleiten lässt.

Adressat der Pflicht sind besonders wichtige und wichtige Einrichtungen nach § 28 BSIG. Als besonders wichtige Einrichtung gilt eine Einrichtung einer in Anlage 1 BSIG bestimmten Art, die mindestens 250 Mitarbeiter beschäftigt oder einen Jahresumsatz von über 50 Mio. EUR und zudem eine Jahresbilanzsumme von über 43 Mio. EUR aufweist; als wichtige Einrichtung gilt eine Einrichtung einer in Anlage 1 oder Anlage 2 bestimmten Art ab mindestens 50 Mitarbeitern oder mit einem Jahresumsatz und einer Jahresbilanzsumme von jeweils über 10 Mio. EUR, soweit sie nicht bereits besonders wichtige Einrichtung ist (§ 28 Abs. 1 und 2 BSIG). Daneben zählen Betreiber kritischer Anlagen, qualifizierte Vertrauensdiensteanbieter, Top-Level-Domain-Name-Registries, DNS-Diensteanbieter und bestimmte Telekommunikationsanbieter größenunabhängig zu den besonders wichtigen Einrichtungen. Prüfen Sie deshalb in dieser Reihenfolge: erst die Zuordnung zu einer Einrichtungsart der Anlagen, dann die Größenschwelle. Anlage 1 BSIG umfasst die hochkritischen Sektoren Energie, Transport und Verkehr, Finanzwesen (Bankwesen und Finanzmarktinfrastrukturen), Gesundheit, Wasser (Trinkwasser und Abwasser), Digitale Infrastruktur einschließlich der Verwaltung von IKT-Diensten sowie Weltraum; Anlage 2 umfasst Post- und Kurierdienste, Abfallbewirtschaftung, Produktion, Herstellung und Handel mit chemischen Stoffen, Produktion, Verarbeitung und Vertrieb von Lebensmitteln, verarbeitendes Gewerbe, Anbieter digitaler Dienste und Forschung; Einrichtungen der Bundesverwaltung werden nicht über Anlage 1, sondern gesondert nach § 29 BSIG erfasst. Welche Einrichtungsarten die Anlagen im Einzelnen benennen, prüfen Sie mit dem NIS2-Selbsttest. In Österreich läuft die Prüfung parallel über § 24 und § 25 NISG 2026, wobei die Zuordnung zu einer Anlage-1- oder Anlage-2-Art Voraussetzung für die Einstufung als wesentliche oder wichtige Einrichtung ist.

Konkretisiert wird dieser Maßstab durch den BSI-Standard 200-4 sowie die ENISA "Technical Implementation Guidance on Commission Implementing Regulation (EU) 2024/2690" (Juni 2025, Version 1.0) zur Durchführungsverordnung (EU) 2024/2690 vom 17.10.2024. Praktisch heißt das: Woran sich die Aufsichten beim Stand der Technik orientieren, ist für jeden der zehn Maßnahmenbereiche des § 30 Abs. 2 BSIG dasselbe Material — BSI-Grundschutz-Bausteine, ISO 27002, die ENISA Technical Implementation Guidance und branchenspezifische Standards. Ein statischer Standard ist das nicht; die Auswahl ist laufend fortzuschreiben.

Beachten Sie die Reichweite dieser Konkretisierung in Deutschland: Die quantitativen Kriterien der Durchführungsverordnung zur Schwelle des erheblichen Sicherheitsvorfalls gelten nur für bestimmte digitale Einrichtungsarten — unter anderem DNS-Diensteanbieter, TLD-Name-Registries, Cloud- und Rechenzentrumsdienste, CDN, Managed (Security) Service Provider, Online-Marktplätze, Suchmaschinen, soziale Netzwerke und Vertrauensdiensteanbieter (vgl. § 30 Abs. 3 BSIG). Für alle übrigen Einrichtungen bleibt § 2 Nr. 11 BSIG maßgeblich, bis eine Rechtsverordnung nach § 56 Abs. 5 BSIG ergeht.

DE/AT-Hinweis: Dieser Leitfaden bildet die deutsche Rechtslage (BSIG 2025) ab. In Österreich gilt statt des BSIG das NISG 2026 (BGBl. I Nr. 94/2025, kundgemacht am 23.12.2025, anwendbar ab 01.10.2026): Business Continuity ist dort Risikomanagementmaßnahme nach § 32 Abs. 4 NISG 2026 — innerhalb des Katalogs lit. a bis j ist es lit. c —, die Verantwortung der Leitungsorgane regelt § 31 NISG, und Bußgelder richten sich nach § 45 Abs. 2 und 3 NISG 2026 (bis 10 Mio. EUR bzw. 2 % des weltweiten Jahresumsatzes für wesentliche, 7 Mio. EUR bzw. 1,4 % für wichtige Einrichtungen). Zuständige Aufsicht ist die Cybersicherheitsbehörde; erhebliche Vorfälle sind nach § 34 NISG (24 h / 72 h / 1 Monat) an das zuständige CSIRT zu melden.

DE und AT im direkten Vergleich

Die Tabelle nennt je Zeile die maßgebliche Norm des jeweiligen Rechtsraums. Alle Angaben sind gesetzliche Regelungen, keine Praxisempfehlungen.

2. Business Impact Analyse (BIA)

Die BIA ist der Arbeitsschritt, der aus der Gesetzesformel eine Prioritätenliste macht: Sie bestimmt, welche Prozesse überhaupt „aufrechtzuerhalten“ sind und wie schnell. Ohne diese Grundlage lässt sich die von § 30 Abs. 1 BSIG geforderte Verhältnismäßigkeit nicht begründen — und in Österreich ebenso wenig, dass die Risikomanagementmaßnahmen nach § 32 Abs. 1 NISG 2026 geeignet und verhältnismäßig sind.

BIA-Schritte:

1. Geschäftsprozesse-Inventar erstellen. Alle wertschöpfenden und regulatorisch gebundenen Prozesse erfassen, mit Prozessverantwortlichem. Ohne Inventar bleibt die Auswahl der geschützten Prozesse angreifbar.
2. Pro Prozess: Kritikalität bewerten (Geld, Reputation, Recht). Die Rechts-Dimension umfasst gerade auch Melde- und Nachweispflichten: Ein Prozess, dessen Ausfall einen erheblichen Sicherheitsvorfall auslöst, ist unabhängig vom Umsatzbeitrag kritisch.
3. Pro kritischem Prozess: IT-Abhängigkeiten dokumentieren. Anwendungen, Schnittstellen, Rechenzentren und externe Dienstleister benennen — die Abhängigkeitskette ist die Brücke zur Lieferkettensicherheit nach § 30 Abs. 2 Nr. 4 BSIG bzw. § 32 Abs. 4 lit. d NISG 2026.
4. Pro IT-System: max. tolerierbare Ausfallzeit (MTPD) definieren. Die MTPD ist die Obergrenze, ab der der Schaden nicht mehr beherrschbar ist; sie wird fachlich festgelegt, nicht technisch.
5. Daraus RTO/RPO-Ziele ableiten. RTO und RPO müssen unterhalb der MTPD liegen, sonst ist das Ziel bereits auf dem Papier verfehlt.

Halten Sie Methodik, Bewertungsskala und Ergebnis schriftlich fest — die BIA ist das Dokument, aus dem sich jede spätere Priorisierung erklären lässt, und damit Kernbestandteil der in Abschnitt 1 genannten Dokumentationspflicht. Praxisempfehlung: die BIA bei jeder wesentlichen Prozess- oder IT-Änderung sowie anlassunabhängig einmal jährlich fortschreiben.

3. RTO + RPO definieren

RTO (Recovery Time Objective) legt fest, wie lange ein Prozess maximal ausfallen darf, RPO (Recovery Point Objective), wie viel Datenverlust hinnehmbar ist — beides je Prozess, abgeleitet aus der BIA und getragen von der Geschäftsleitung.

Die folgende Matrix ist ein Praxisbeispiel für typische KMU-Prozesse, keine gesetzliche Vorgabe; die Zeilen zeigen, wie sich aus fachlichen Zielwerten technische Architekturentscheidungen ergeben.

Drei Punkte entscheiden über die Belastbarkeit dieser Werte. Erstens die Freigabe durch die Geschäftsleitung — die Verantwortung für Umsetzung und Überwachung der Maßnahmen liegt nach § 38 Abs. 1 BSIG bei der Geschäftsleitung selbst und ist nicht delegierbar. Zweitens der Abgleich mit Dienstleisterverträgen: Wo ein Prozess auf externen Diensten beruht, muss die vertraglich zugesagte Wiederherstellungszeit das interne RTO tragen; andernfalls ist entweder der Vertrag oder das Ziel zu ändern. Drittens der Nachweis: RTO und RPO sind erst dann belastbare Zielwerte, wenn ein Test sie bestätigt hat.

4. Notfallplan + Krisenstab

Der Notfallplan setzt das Tatbestandsmerkmal „Krisenmanagement“ aus § 30 Abs. 2 Nr. 3 BSIG um (Abschnitt 1) — und muss so gebaut sein, dass er die gesetzlichen Meldefristen trägt.

Notfallplan-Inhalte:

• Krisenstab-Liste mit 24h-Erreichbarkeit (Mobil, Privat-E-Mail) und benannter Vertretung je Rolle — weil die Frühwarnfrist ab Kenntnis läuft, nicht ab Beginn des Vorfalls, und Kenntnis auch nachts und am Wochenende entstehen kann. Praxisbewährte Mindestbesetzung: Leitungsvertretung (Entscheidung und Freigabe der Meldung), IT- bzw. Informationssicherheitsverantwortlicher (technische Lage), Datenschutzbeauftragter (Prüfung des DSGVO-Meldestrangs nach Art. 33 DSGVO), Kommunikation (interne und externe Sprachregelung), Fachverantwortlicher des betroffenen Prozesses (Auswirkungsbewertung) sowie Protokollführung (Zeitstempel für die Fristenkette) — Praxisempfehlung, keine gesetzliche Vorgabe
• Eskalations-Workflow: wer entscheidet wann was — inklusive der Entscheidung, ob ein erheblicher Sicherheitsvorfall vorliegt, und einer benannten Vertretung für jede Rolle
• Kommunikations-Plan: Mitarbeiter, Kunden, Behörden, Presse — mit vorbereiteten Textbausteinen, damit die 24-Stunden-Meldung nicht an der Formulierung scheitert
• Backup-Lokationen (alternativer Standort, Home-Office) — samt Zugangsdaten und Nachweis, dass der Zugang ohne die ausgefallene Umgebung funktioniert
• Lieferanten-Notfall-Kontakte — für die Dienstleister, die in der BIA als Abhängigkeit kritischer Prozesse identifiziert wurden
• Rollback-Verfahren — dokumentierter Rückweg auf den letzten bekannten sicheren Stand, mit Freigabekriterium für die Wiederinbetriebnahme

Auslöser für die Meldepflichten ist der erhebliche Sicherheitsvorfall: ein Vorfall, der schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die Einrichtung verursacht hat oder verursachen kann oder der andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann (§ 2 Nr. 11 BSIG); § 35 Abs. 1 NISG 2026 bildet dieselben zwei Fallgruppen ab, verlangt in Fallgruppe 1 jedoch schwerwiegende finanzielle Verluste. Diese Bewertung gehört als erster Tagesordnungspunkt in den Krisenstab.

Fristen, die der Krisenstab kennen muss

Alle Zeilen dieser Tabelle sind gesetzliche Fristen; der jeweilige Fristbeginn steht in der Spalte „Auslöser“.

Zwei Anschlusspflichten gehören in denselben Ablauf. In Deutschland kann das BSI jederzeit eine Zwischenmeldung über relevante Statusaktualisierungen verlangen; dauert der Vorfall nach einem Monat noch an, tritt zunächst eine Fortschrittsmeldung an die Stelle der Abschlussmeldung, die dann nach abschließender Bearbeitung folgt (§ 32 Abs. 1 Nr. 3 und Abs. 2 BSIG) — in Österreich entspricht dem § 34 Abs. 2 Z 3 und Z 5 NISG 2026. Und hat eine zugleich vorliegende Datenschutzverletzung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge, sind die betroffenen Personen nach Art. 34 Abs. 1 DSGVO unverzüglich zu benachrichtigen; die Benachrichtigung kann unter den Voraussetzungen des Art. 34 Abs. 3 DSGVO entfallen, etwa bei wirksamer Verschlüsselung der betroffenen Daten. Verhängt eine Datenschutzaufsichtsbehörde für dasselbe Verhalten bereits ein Bußgeld nach der DSGVO, ist eine zusätzliche Geldbuße nach dem BSIG ausgeschlossen (§ 65 Abs. 11 BSIG).

Praxisempfehlung zum Übungsrhythmus — drei Formate mit unterschiedlichem Zweck und unterschiedlicher Taktung, die einander nicht ersetzen:

• Restore-Test (technisch: Wiederherstellung einzelner Systeme in der Testumgebung) — quartalsweise
• Tabletop-Übung (Krisenstab: Entscheidungs- und Meldewege am Tisch) — mindestens jährlich, mit dem vollständigen Krisenstab
• Live-Test (Umschaltung einer kritischen Anwendung im Echtbetrieb) — alle zwei Jahre

Hinzu kommt nach jedem realen Vorfall ein Lessons-Learned-Workshop mit Nachführung des Plans. Diese Rhythmen sind Erfahrungswerte aus der Praxis, keine Wiedergabe einer gesetzlichen Frist.

5. Disaster Recovery

Disaster Recovery ist der technische Teilbereich von § 30 Abs. 2 Nr. 3 BSIG — konkret das dort genannte „Backup-Management und Wiederherstellung nach einem Notfall“ (Abschnitt 1).

DR-Komponenten:

• 3-2-1-Backup: 3 Kopien, 2 Medien, 1 offsite — das Prinzip (oder ein gleichwertiges) verhindert, dass ein einzelnes Ereignis Produktion und Sicherung gemeinsam trifft
• Immutable Backup gegen Ransomware — Sicherungen, die im Aufbewahrungszeitraum nicht überschrieben oder gelöscht werden können; der Zweck ist, dass ein Angriff auf die Produktivumgebung die Sicherung nicht miterfasst
• Quartalsweise DR-Test (Praxisempfehlung, keine gesetzliche Frist) mit Wiederherstellung in Test-Umgebung — der Test belegt das RPO und misst die tatsächliche Wiederherstellungsdauer gegen das RTO; er ist der Restore-Test aus dem Übungsrhythmus in Abschnitt 4 und dort gegen Tabletop-Übung und Live-Test abgegrenzt
• RPO-konformer Replikations-Mechanismus — Replikationsintervall und Aufbewahrung müssen zu den in Abschnitt 3 gesetzten Zielwerten passen, nicht umgekehrt
• Dokumentierte Recovery-Prozeduren — Schritt-für-Schritt, ausführbar auch durch Vertretungen, offline verfügbar, mit benannter Freigabe für die Wiederinbetriebnahme

Die Testergebnisse haben doppelten Wert. Sie sind zum einen der Beleg für die nach § 30 Abs. 1 BSIG geforderte Dokumentation der Einhaltung. Zum anderen zahlen sie auf einen eigenen Pflichtbereich ein: § 30 Abs. 2 Nr. 6 BSIG verlangt „Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen im Bereich der Sicherheit in der Informationstechnik“. Ohne Protokoll fehlt für beides der Nachweis. Wer bereits nach ISO 27001 zertifiziert ist, deckt den BCM-Bereich weitgehend über die dortigen Continuity-Anforderungen ab; prüfen Sie im Delta-Abgleich vorrangig die Bereiche, die ISO 27001 nicht in NIS2-Tiefe abbildet: die Meldepflichten aus § 32 BSIG bzw. § 34 NISG 2026 und die Lieferkettensicherheit nach § 30 Abs. 2 Nr. 4 BSIG bzw. § 32 Abs. 4 lit. d NISG 2026.

6. 8-Wochen-Roadmap KMU

In acht Wochen lässt sich ein prüffähiges BCM-Grundgerüst aufbauen — die folgende Taktung ist eine Praxisempfehlung für KMU und ersetzt keine der in Abschnitt 1 und 4 genannten gesetzlichen Fristen.

Daneben laufen die festen Termine. In Deutschland gilt das BSIG seit dem 06.12.2025 ohne Übergangsfrist; die Registrierungsfrist von drei Monaten nach § 33 Abs. 1 BSIG lief am 06.03.2026 ab — wer sie versäumt hat, holt die Registrierung nach, die Pflicht besteht fort. In Österreich wird das NISG 2026 am 01.10.2026 anwendbar (§ 51 Abs. 1 und 2); die Registrierung bei der Cybersicherheitsbehörde hat binnen drei Monaten ab Inkrafttreten zu erfolgen (§ 29 Abs. 2 und 3 NISG 2026), also bis Ende 2026. Die Selbstdeklaration der umgesetzten Risikomanagementmaßnahmen ist binnen zwölf Monaten nach Eintritt der Registrierungspflicht zu übermitteln (§ 33 Abs. 1 NISG 2026). Zum Nachweis durch eine unabhängige Stelle kann die Behörde frühestens zwei Jahre nach Inkrafttreten auffordern, also ab 01.10.2028; ab der Aufforderung läuft dann die Nachweisfrist von zwei Jahren, wobei wesentliche Einrichtungen die operative und organisatorische Umsetzung bereits binnen zwei Monaten nach der Aufforderung nachzuweisen haben (§ 33 Abs. 2 NISG 2026).