¶ BCM-Szenarien und Notfallpläne – Musterbeispiele
Beispieldokument: Sämtliche Szenarien, Dummy-Assets, Rollen, RTA-, RTO- und Zeitwerte dieser Seite sind fiktiv. Sie belegen weder eine durchgeführte Business-Impact-Analyse noch freigegebene oder getestete Notfallpläne.
Anpassungsregel: Wiederanlaufziele und Maßnahmen dürfen nicht ungeprüft übernommen werden. Sie werden aus den tatsächlichen Geschäftsanforderungen, Abhängigkeiten, Verträgen, Risiken und verfügbaren Ressourcen abgeleitet, fachlich geprüft und durch befugte Rollen freigegeben.
Ablagegrenze: Reale Systemnamen, Kontakte, Zugangsinformationen, Wiederanlaufdetails und ausgefüllte Notfallprotokolle gehören in eine geschützte Ablage – nicht in das öffentliche Muster-Wiki.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-05-07 |
| Dokumentenart | BCM-Arbeitshilfe / konsolidiertes Szenario- und Planbeispiel |
| Wiki.js-Pfad | /ISMS/05-Vorfaelle-und-Notfallmanagement/BCM-Szenarien-und-Notfallplaene |
| Verantwortlich | BCM-Verantwortliche/r |
| Fachlich geprüft durch | Geschäftsführung, Fachbereiche, IT, ISMS, Facility, Personal und Einkauf |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – ausschließlich fiktive Musterwerte |
| Version | 0.1 |
| Stand | 10.08.2026 |
| Nächste Prüfung | Mindestens jährlich sowie nach wesentlichen Änderungen, Ereignissen oder Übungen |
| Schutzklasse | Öffentlich – nur fiktive Demonstrationsdaten |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.29 und 5.30; ergänzend ISO 22301 und ISO/IEC 27031 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Incident- und Krisenmanagement sowie Business Continuity |
Vier typische Szenariogruppen und der Weg von der Geschäftsauswirkungsbewertung bis zur Wiederanlauffreigabe. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck und Einordnung
Diese Seite überführt eine tabellarische BCM-Arbeitshilfe in eine verständliche Wiki-Darstellung. Sie zeigt, wie Szenarien, betroffene Geschäftsprozesse, Dummy-Assets, Zielzeiten, Ersatzmaßnahmen und Verantwortlichkeiten miteinander verbunden werden können.
Die Seite ist dem Business Continuity Management zugeordnet. Das Incident-Response-Verfahren erkennt und bearbeitet einen Sicherheitsvorfall. BCM wird zusätzlich benötigt, sobald kritische Leistungen, Mindestbetrieb oder rechtzeitiger Wiederanlauf gefährdet sind.
| Verfahren | Leitfrage | Typisches Ergebnis |
|---|---|---|
| Incident Management | Wie wird ein Sicherheitsvorfall analysiert, eingedämmt und bereinigt? | Incident-Ticket, Lagebild, technische Maßnahmen und Abschlussbericht |
| BCM | Wie bleiben kritische Leistungen verfügbar oder werden rechtzeitig wieder aufgenommen? | BIA, Zielwerte, Kontinuitätsstrategie, BCP und Notbetrieb |
| IT-Wiederanlauf | Wie werden benötigte IT-Services in der bestätigten Reihenfolge wiederhergestellt? | Restore-Plan, technische Abhängigkeiten, Tests und Freigaben |
| Krisenmanagement | Welche außergewöhnlichen Managemententscheidungen und Kommunikationsmaßnahmen sind erforderlich? | Krisenorganisation, Lageentscheidungen und abgestimmte Kommunikation |
¶ 2. Übergang vom Incident zum BCM
graph TD
A[Ereignis oder Störung erkannt] --> B[Incident Triage]
B --> C{Kritische Leistung gefährdet}
C -->|Nein| D[Incident weiter bearbeiten]
C -->|Ja| E[Geschäftsauswirkung bewerten]
E --> F{BCM Aktivierung erforderlich}
F -->|Nein| G[Entscheidung dokumentieren]
F -->|Ja| H[BCM Leitung und Notbetrieb aktivieren]
H --> I[Mindestleistung sichern]
I --> J[Wiederanlauf priorisiert durchführen]
D --> K[Vorfall abschließen]
G --> K
J --> L[Funktionsprüfung und Freigabe]
L --> K
K --> M[Erkenntnisse und Maßnahmen nachführen]
Ein technischer Vorfall wird nicht allein wegen einer hohen technischen Einstufung automatisch zum BCM-Fall. Entscheidend ist die bestätigte oder absehbare Auswirkung auf priorisierte Produkte, Leistungen und Geschäftsprozesse. Incident Response und BCM können anschließend parallel laufen.
¶ 3. Begriffe und Zielwerte
| Begriff | Verwendung in diesem Muster |
|---|---|
| RTA | Organisationsspezifischer Zeitpunkt, ab dem erste definierte Mindestaktivitäten wieder anlaufen sollen. Der Begriff wird nicht überall einheitlich verwendet und muss deshalb im eigenen BCM eindeutig definiert werden. |
| RTO | Zielzeit, innerhalb der ein Prozess oder Service nach einer Unterbrechung wieder in den festgelegten Zielzustand gebracht werden soll. |
| RPO | Maximal tolerierbarer Datenverlust, ausgedrückt als Zeitraum. RPO ist insbesondere für datenverarbeitende Systeme zusätzlich festzulegen. |
| MTPD/MAO | Maximal tolerierbare Dauer einer Unterbrechung. Das bestätigte RTO darf diese Grenze nicht überschreiten. |
| Mindestbetrieb | Vorübergehend reduzierter, aber definierter Leistungsumfang zur Aufrechterhaltung kritischer Tätigkeiten. |
| Wiederanlauf | Geordnete technische, organisatorische und fachliche Wiederaufnahme bis zum bestätigten Zielbetrieb. |
Eine ausführliche Erläuterung enthält die Seite RPO und RTO verständlich erklärt.
¶ 4. Aufbau eines Szenariodatensatzes
| Feld | Erwarteter Inhalt | Qualitätsfrage |
|---|---|---|
| Szenario | eindeutig beschriebene Unterbrechung | Ist der betrachtete Ausfall klar abgegrenzt? |
| Geschäftsprozess/Leistung | betroffene priorisierte Tätigkeit | Wurde die Kritikalität durch die BIA bestätigt? |
| Ressourcen und Dummy-Assets | Personal, Informationen, Systeme, Standort und Lieferanten | Sind vor- und nachgelagerte Abhängigkeiten berücksichtigt? |
| Ursache | beispielhafte Auslöser, ohne den Plan darauf zu beschränken | Funktioniert die Strategie auch bei einer anderen Ursache? |
| RTA/RTO/RPO | bestätigte Zielwerte und Voraussetzungen | Sind Zielwerte konsistent, finanzierbar und testbar? |
| Ersatz-/Notfallmaßnahmen | Fortführung, Ersatz, Verlagerung oder Wiederherstellung | Sind Zugänge, Ressourcen und Befugnisse vorhanden? |
| Verantwortlichkeit | Owner, Stellvertretung und Freigaberolle | Ist die Rolle erreichbar und handlungsbefugt? |
| Nachweis | Test, Freigabe, Protokoll oder Vertrag | Belegt der Nachweis tatsächlich die behauptete Fähigkeit? |
¶ 5. Szenariogruppe Personal
| Szenario | Betroffener Prozess | Kritische Ressource/Dummy-Assets | RTA | RTO | Ersatz- und Notfallmaßnahmen | Verantwortung |
|---|---|---|---|---|---|---|
| Kurzfristiger Personalausfall | Entwicklung, Support, Verwaltung | Schlüsselrollen; D-A13 Demo-ERP; D-A20 Demo-Dokumentation | ≤ 2 Std. | ≤ 4 Std. | Vertretung aktivieren, Aufgaben und Tickets übergeben | Teamleitung |
| Mehrfachausfall Entwicklung | Softwareentwicklung | Entwicklungsteam; D-A16 Demo-Quellcode; Testumgebung | ≤ 4 Std. | ≤ 8 Std. | Projekte priorisieren, teamübergreifende Reviews, externe Kapazität prüfen | Entwicklung/Geschäftsführung |
| Ausfall IT-Administration | IT-Betrieb | Administration; D-A23 IAM; D-A09 Netzwerk; D-A22 Demo-Virtualisierung | ≤ 1 Std. | ≤ 2 Std. | Stellvertretung, geschützte Notfallkonten, vereinbarte externe Unterstützung | IT-Leitung |
| Ausfall Buchhaltung | Abrechnung und Zahlungsverkehr | Buchhaltung; D-A14 Demo-Finanzsoftware | ≤ 24 Std. | ≤ 48 Std. | Stellvertretung, priorisierte Fristen, externe Fachunterstützung | Buchhaltung |
| Ausfall ISMS-Funktion | ISMS-Steuerung | ISMS-Rolle; D-A32 ISMS-Dokumentation | ≤ 4 Std. | ≤ 24 Std. | Stellvertretung und Managementeinbindung aktivieren | Geschäftsführung |
| Ausfall Geschäftsleitung | Krisen- und Entscheidungsprozess | Geschäftsleitung; D-A35 BCP | sofort | ≤ 2 Std. | Stellvertretungs- und Notfallbefugnisse anwenden | Stellvertretende Leitung |
Die Beispielzeiten sind keine Empfehlung. Ein Personalausfall kann den Mindestbetrieb früher beeinträchtigen als die technische Verfügbarkeit eines Systems.
¶ 6. Szenariogruppe Gebäude und Infrastruktur
| Szenario | Betroffener Prozess | Ressourcen/Dummy-Assets | RTA | RTO | Ersatz- und Notfallmaßnahmen | Verantwortung |
|---|---|---|---|---|---|---|
| Teilweiser Gebäudeausfall | Entwicklung, Beratung, Verwaltung | Arbeitsplätze; D-A07 Laptops; D-A20 Demo-Dokumentation | ≤ 2 Std. | ≤ 8 Std. | Homeoffice, mobile Endgeräte, Rufumleitung | Geschäftsführung/Facility |
| Vollständiger Standortausfall | Gesamtbetrieb | Hauptstandort; D-A24 VPN; D-A27 Internet | ≤ 4 Std. | ≤ 24 Std. | Remote-Arbeit und freigegebene Ausweicharbeitsplätze | Geschäftsführung |
| Ausfall Serverraum | IT-Betrieb | Technikraum; D-A22 Demo-Virtualisierung; Serversysteme | ≤ 1 Std. | ≤ 4 Std. | geordnete Abschaltung, Ausweichbetrieb, Restore | IT-Leitung |
| Längerer Stromausfall | IT und Kommunikation | Versorgung; D-A12 Versorgungseinrichtungen | ≤ 30 Min. | ≤ 2 Std. | USV, sichere Abschaltung und priorisierter Betrieb | IT/Facility |
| Ausfall Internetanbindung | Kommunikation und Cloud | D-A27 Internet; D-A24 VPN | ≤ 1 Std. | ≤ 4 Std. | Mobilfunk-Fallback und alternative Kommunikationswege | IT |
| Standort unbenutzbar | Gesamtbetrieb | D-A35 BCP; Standort- und IT-Abhängigkeiten | ≤ 4 Std. | ≤ 48 Std. | Standortverlagerung und formaler Notbetrieb | Geschäftsführung |
Personensicherheit, Evakuierung und behördliche Anweisungen haben Vorrang. BCM beginnt nicht mit der Fortführung, solange dadurch Menschen gefährdet würden.
¶ 7. Szenariogruppe Dienstleister und Lieferanten
| Szenario | Betroffener Prozess | Externe Abhängigkeit/Dummy-Assets | RTA | RTO | Ersatz- und Notfallmaßnahmen | Verantwortung |
|---|---|---|---|---|---|---|
| Ausfall IT-Dienstleister | IT-Betrieb und Support | Demo-Servicepartner; D-A37 Dienstleister | ≤ 2 Std. | ≤ 8 Std. | SLA-Eskalation, interne Notfalladministration, Ersatzpartner | IT-Leitung |
| Ausfall Hostinganbieter | öffentlich erreichbare Dienste | Demo-Rechenzentrumsanbieter; D-A25 DNS | ≤ 4 Std. | ≤ 24 Std. | Supporteskalation, Restore, technisch vorbereiteter Wechsel | IT/Geschäftsführung |
| Ausfall Cloud-Dienst | Kommunikation und Zusammenarbeit | Demo-Cloud-Kollaboration; D-A19 E-Mail | ≤ 2 Std. | ≤ 8 Std. | Telefon, freigegebener Alternativkanal und Offline-Verfahren | IT |
| Ausfall Sicherheitsdienst | Objektschutz | Demo-Wachdienst; Zutritt und Video | ≤ 1 Std. | ≤ 4 Std. | Ersatzdienst und manuelle Zutrittskontrolle | Geschäftsführung |
| Ausfall Hardwarelieferant | IT-Infrastruktur | Demo-Lieferant; Ersatzkomponenten | ≤ 24 Std. | ≤ 72 Std. | Alternativlieferanten und definierter Ersatzbestand | IT/Einkauf |
| Mehrfachausfall kritischer Anbieter | Gesamtbetrieb | mehrere externe Dienste; D-A35 BCP | ≤ 4 Std. | ≤ 48 Std. | BCM-Aktivierung, Priorisierung und Managementeskalation | Geschäftsführung |
Eine Ausweichlösung ist nur belastbar, wenn Kapazität, Vertrag, Datenschutz, Informationssicherheit, Zugriff und Umschaltverfahren vorab geprüft wurden.
¶ 8. Szenariogruppe Informationstechnik
| Szenario | Betroffener Prozess | IT-Komponenten/Dummy-Assets | RTA | RTO | Ersatz- und Notfallmaßnahmen | Verantwortung |
|---|---|---|---|---|---|---|
| Ausfall Arbeitsplatzgerät | mehrere Fachbereiche | D-A07 Demo-Laptop | ≤ 30 Min. | ≤ 2 Std. | vorbereitetes Ersatzgerät und sicherer Benutzerwechsel | IT |
| Ausfall zentrale Fachanwendung | Projekt- und Facharbeit | D-A13 Demo-ERP; D-A30 Testumgebung | ≤ 2 Std. | ≤ 6 Std. | definiertes Fallback-Verfahren und Supporteskalation | IT/Fachbereich |
| Ausfall Virtualisierungsplattform | IT-Betrieb | D-A22 Demo-Virtualisierung; Serversysteme | ≤ 1 Std. | ≤ 4 Std. | Failover oder priorisierter Restore | IT |
| Ausfall Netzwerk | Kommunikation und IT | D-A09 Netzwerk; D-A26 Segmentierung | ≤ 30 Min. | ≤ 2 Std. | Ersatzkomponenten und geprüfte Fallback-Konfiguration | IT |
| Ausfall Identitätsdienst | Zugriff und Authentisierung | D-A23 Demo-IAM | ≤ 30 Min. | ≤ 2 Std. | geschützte Notfallkonten und Service-Restore | IT |
| Ausfall E-Mail | Kommunikation | D-A19 Demo-E-Mail | ≤ 1 Std. | ≤ 6 Std. | Telefon und freigegebener Alternativkanal | IT |
| Ransomware | mehrere kritische Prozesse | Daten, Identitäten und mehrere IT-Systeme | ≤ 1 Std. | ≤ 48 Std. | Isolation, Incident Response, saubere Wiederherstellung und Krisensteuerung | IT/Geschäftsführung |
| Vollständiger IT-Ausfall | Gesamtbetrieb | D-A35 BCP; D-A22 Virtualisierung; D-A27 Internet | ≤ 2 Std. | ≤ 72 Std. | Notbetrieb, priorisierte Wiederanlaufreihenfolge und kontrollierter Restore | Geschäftsführung/IT |
Bei datenverarbeitenden Systemen wird zusätzlich ein RPO festgelegt. Ein technisch erfolgreicher Restore ist noch keine fachliche Wiederanlauffreigabe.
¶ 9. Konsolidierter BCM-Maßnahmenplan
| Phase | Maßnahme | Auslöser | Verantwortlich | Beispielziel | Erforderlicher Nachweis |
|---|---|---|---|---|---|
| Erkennung | Störung bestätigen und protokollieren | Meldung, Alarm oder Nichterreichbarkeit | Fachbereich/IT | sofort | Zeitstempel und Ereignis-ID |
| Erstbewertung | Auswirkung und betroffene Leistung bestimmen | bestätigte Störung | Incident-/BCM-Verantwortung | ≤ 30 Min. | dokumentierte Ersteinschätzung |
| Personenschutz | Notruf, Räumung oder Gefahrenabwehr | Gefahr für Menschen | Standortverantwortung | sofort | Alarmierungs-/Einsatzprotokoll |
| Eskalation | Management und erforderliche Rollen einbinden | kritische Auswirkung | Incident-/BCM-Leitung | ≤ 1 Std. | Eskalationsentscheidung |
| BCM-Aktivierung | Stufe, Leitung und Notbetrieb festlegen | kritische Leistung gefährdet | befugte Geschäftsrolle | gemäß RTA | Aktivierungsprotokoll |
| Eindämmung | Folgeschäden und Ausbreitung begrenzen | laufendes Ereignis | Incident-/Fachteam | lageabhängig | Maßnahmen- und Entscheidungsprotokoll |
| Ersatzbetrieb | Vertretung, Ausweichort oder Ersatzsystem aktivieren | reguläre Ressource nicht verfügbar | Prozess-Owner | gemäß RTA | Funktions- und Zugriffsprüfung |
| Priorisierung | nichtkritische Tätigkeiten zurückstellen | Ressourcen reichen nicht aus | Geschäftsführung | vor Notbetrieb | dokumentierte Prioritäten |
| Wiederherstellung | Ressourcen und Systeme geordnet wiederanlaufen lassen | Ursache beherrscht | IT/Fachbereich | gemäß RTO | Restore- und Wiederanlaufprotokoll |
| Funktionsprüfung | technische und fachliche Kriterien testen | Wiederherstellung abgeschlossen | IT und Prozess-Owner | vor Freigabe | Test- und Abnahmeprotokoll |
| Normalisierung | Regelbetrieb kontrolliert freigeben | stabiler Zielbetrieb | Geschäftsführung/Owner | lageabhängig | Freigabeentscheidung |
| Nachbereitung | Ursachen, Wirksamkeit und Maßnahmen bewerten | Abschluss der Lage | ISMS/BCM | ≤ 14 Tage | Review und Maßnahmenregister |
¶ 10. Beispiel für den Notbetrieb
| Aspekt | Fiktive Festlegung | Verantwortlich | Prüfnachweis |
|---|---|---|---|
| Zweck | priorisierte Geschäftsleistungen im bestätigten Mindestumfang fortführen | Geschäftsführung | BIA und Freigabe |
| Aktivierung | formale Entscheidung anhand Auswirkung, Dauer und Zielwerten | BCM-/Geschäftsleitung | Aktivierungsprotokoll |
| Priorisierte Prozesse | Projektsteuerung, Kommunikation und fristkritische Abrechnung | Prozess-Owner | freigegebene Prioritätenliste |
| Ausgesetzte Tätigkeiten | nichtkritische Tätigkeiten zeitlich begrenzt zurückstellen | Geschäftsführung | Lageentscheidung |
| Arbeitsform | Homeoffice oder geprüfter Ausweicharbeitsplatz | IT/Fachbereich | Zugriffs- und Funktionstest |
| Zugriffssteuerung | nur notwendige Rollen und privilegierte Zugriffe zulassen | IT/ISMS | Berechtigungsprüfung |
| Kommunikation | regelmäßige interne Lageinformation; externe Information nur befugt | Geschäftsführung | Kommunikationsprotokoll |
| Überwachung | Wirkung, Kapazität, Sicherheit und neue Risiken fortlaufend prüfen | BCM-/Incident-Leitung | Lagebericht |
| Beendigung | Notbetrieb erst nach bestätigter Stabilität aufheben | Geschäftsführung/Owner | Rückkehr- und Freigabeprotokoll |
Temporäre Abweichungen von Sicherheitsregelungen werden nicht stillschweigend akzeptiert. Sie benötigen Befristung, Verantwortung, Risikobewertung, Ersatzmaßnahmen und dokumentierte Rücknahme.
¶ 11. Qualitätsprüfung vor Verwendung
| Prüffrage | Status dieses Musters |
|---|---|
| Wurden kritische Leistungen und maximal tolerierbare Ausfallzeiten durch eine BIA bestätigt? | Nein |
| Sind RTA, RTO und gegebenenfalls RPO widerspruchsfrei beschlossen? | Nein |
| Sind Dummy-Assets durch reale, aktuelle Abhängigkeiten ersetzt? | Nein |
| Sind Vertretungen, Befugnisse und Erreichbarkeiten festgelegt? | Nein |
| Sind Ersatzlösungen technisch, vertraglich und organisatorisch verfügbar? | Nein |
| Sind Notfallzugänge und Offline-Unterlagen geschützt verfügbar? | Nein |
| Wurde jede priorisierte Strategie praktisch getestet? | Nein |
| Wurden Abweichungen, Restrisiken und offene Maßnahmen freigegeben? | Nein |
Gesamtstatus: Das Beispiel erklärt Aufbau und Zusammenhänge. Es ist weder ein einsatzfähiger BCP noch ein Nachweis dafür, dass die Organisation Unterbrechungen beherrscht.
¶ 12. Nachweise und geschützte Ablage
| Nachweis | Inhalt | Öffentliche Darstellung |
|---|---|---|
| BIA | reale Prozesse, Auswirkungen, Zielzeiten und Abhängigkeiten | nur Methodik und fiktives Beispiel |
| BCM-Szenarioregister | reale Szenarien, Assets, Standorte und Owner | nur anonymisierte Struktur |
| BCP/Notfallplan | Kontakte, Zugänge, Maßnahmen und Wiederanlaufdetails | nur Metadaten und Kurzbeschreibung |
| Aktivierungs- und Lageprotokoll | tatsächliche Ereignisse, Entscheidungen und Zeitlinie | nicht öffentlich |
| Restore-/Funktionstest | Systeme, Testergebnisse, Fehler und Freigaben | nur Status und geschützter Ablageverweis |
| Übungsbericht | Teilnehmer, Ablauf, Befunde und Maßnahmen | nur aggregierter Status |
¶ 13. Mitgeltende Seiten
- Notfallvorsorge und BCM
- Incident Response
- Meldeweg für Sicherheitsvorfälle
- Kontakt- und Eskalationslisten
- RPO und RTO verständlich erklärt
- Tests und Übungen
- Asset-Inventar
- Lieferanten und Dienstleister
- Backup-, Restore- und Wiederanlauftests
- Vorfall- und Notfallübungen
¶ 14. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 10.08.2026 | Anonymisierte Tabellenstruktur in eine eigenständige Markdown-Seite mit konsolidierten Personal-, Standort-, Dienstleister- und IT-Szenarien, BCM-Maßnahmenplan, Notbetrieb und Qualitätsprüfung überführt | BCM-Verantwortliche/r | Ausstehend | – |
¶ 15. Offizielle und fachliche Quellen
- ISO – ISO/IEC 27001 Informationssicherheitsmanagementsysteme
- ISO – ISO 22301:2019 Business Continuity Management Systems
- ISO – ISO/IEC 27031 ICT readiness for business continuity
- BSI – Standard 200-4 Business Continuity Management
Maßgeblich bleiben die aktuellen Normfassungen, bestätigten gesetzlichen und vertraglichen Anforderungen sowie die organisationsbezogen freigegebenen Rollen, Zielwerte und Pläne.
Seite 1 von 1 · ISMS-MA-05-07 · Version 0.1