¶ Vorfall- und Notfallübungen
Beispieldokument: Diese Seite beschreibt eine Übungs- und Nachweisstruktur für die fiktive „Muster GmbH“. Die Mustereinträge bestätigen weder durchgeführte Übungen noch erreichbare Meldewege, beherrschte Sicherheitsvorfälle, funktionsfähige Notfallpläne, eingehaltene Wiederanlaufziele oder wirksame Krisenorganisation.
Nachweisgrundsatz: „Geplant“, „durchgeführt“, „bestanden“ und „wirksam“ sind unterschiedliche Aussagen. Eine Teilnahmeliste oder ein Übungsprotokoll belegt die Durchführung, aber erst festgelegte Kriterien, objektive Beobachtungen, Messwerte, behandelte Befunde und ein geeigneter Retest stützen eine Wirksamkeitsaussage.
Schutzregel: Szenarien, Schwachstellen, Kontaktlisten, technische Reaktionswege, Netz- und Systemdetails, Kommunikationsentwürfe und Übungsbefunde können vertraulich oder streng vertraulich sein. Originale verbleiben in geschützten, auch im Notfall erreichbaren Ablagen.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-NW-07-08 |
| Dokumentenart | Nachweisverfahren für Vorfall-, Krisen- und Notfallübungen |
| Wiki.js-Pfad | /ISMS/07-Nachweise/Vorfall-und-Notfalluebungen |
| Verantwortlich | Incident-Management-, BCM-/Notfall- und jeweilige Service-/Prozessverantwortung |
| Fachlich geprüft durch | IT/OT, Informationssicherheit, Geschäftsführung/Krisenleitung, Datenschutz, Kommunikation, Personal, Facility, Lieferantenmanagement, ISMS und Audit/QM |
| Freigabe durch | Geschäftsführung beziehungsweise festgelegte befugte Incident-, Krisen- und Notfallverantwortung |
| Status | Entwurf – keine realen Vorfall- oder Notfallübungen nachgewiesen |
| Version | 0.1 |
| Stand | 08.08.2026 |
| Gültig ab | Nach fachlicher Prüfung und Freigabe |
| Nächste Prüfung | Nach freigegebenem risikobasiertem Übungsprogramm sowie anlassbezogen bei Änderungen, Vorfällen, Befunden oder fehlgeschlagenen Übungen |
| Schutzklasse | Vertraulich; technische und szenariobezogene Detailnachweise regelmäßig streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 6, 7.5, 8.1, 9 und 10 sowie Annex A 5.24 bis 5.30, 8.13 und 8.14 |
| TISAX-Bezug | Maßgebliche ISA-Fassung und zugeordnete Kontrollfragen zu Vorfallmanagement, Meldewegen, Notfallvorsorge, Wiederherstellung, Übungen und Nachweisen |
| Weitere Bezüge | ISO 22301, BSI-Standard 200-4, NIS2-Umsetzung, DSGVO, Kunden-, Vertrags- und Versicherungsanforderungen, soweit anwendbar |
Übungskette von Auftrag, Alarmierung und Reaktion über Notbetrieb und Wiederanlauf bis zu Lessons Learned, Maßnahmen und Retest. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Dieses Verfahren legt fest, wie Vorfall- und Notfallübungen geplant, sicher durchgeführt, beobachtet, ausgewertet und nachgewiesen werden. Es soll sicherstellen, dass:
- Übungen aus Risiken, Vorfällen, BIA, Änderungen und Anforderungen abgeleitet werden,
- Ziel, Scope, Szenario, Grenzen und Erfolgskriterien vorab feststehen,
- Meldewege, Rollen, Befugnisse und Stellvertretungen praktisch geprüft werden,
- technische, organisatorische und kommunikative Reaktionen zusammenwirken,
- Notbetrieb, Wiederherstellung und fachliche Nutzbarkeit angemessen getestet werden,
- Messwerte und Beobachtungen die Auswertung tragen,
- Befunde in Maßnahmen überführt und durch Wiederholungsprüfungen geschlossen werden,
- tatsächliche externe Stellen nicht versehentlich durch eine Übung alarmiert werden.
Die Seite ersetzt weder Incident-Response-Plan, Notfallhandbuch, Krisenkommunikationsplan, Wiederanlaufplan, technische Runbooks noch die geschützten Originalprotokolle.
¶ 2. Geltungsbereich
Der reale Übungs-Scope kann umfassen:
- Sicherheitsereignisse und Cybervorfälle,
- Ausfall von IT-, OT-, Cloud-, Kommunikations- oder Standortdiensten,
- Datenverlust, Ransomware, Fehlkonfiguration oder Lieferkettenvorfall,
- Strom-, Gebäude-, Infrastruktur- oder Personalausfall,
- Alarmierung, Eskalation, Krisenleitung und Entscheidungsfähigkeit,
- interne, Kunden-, Behörden-, Datenschutz- und Medienkommunikation,
- Notbetrieb, Ersatzverfahren, Restore und Wiederanlauf,
- Lieferanten, Kunden, Rettungs-, Behörden- und weitere externe Schnittstellen,
- Rückkehr in den Normalbetrieb und nachgelagerte Verbesserungen.
Nicht geübte Teile und künstliche Annahmen werden ausdrücklich als Aussagegrenze dokumentiert.
¶ 3. Übungsarten und Aussagegrenzen
| Übungsart | Hauptaussage | Grenze |
|---|---|---|
| Dokumenten-/Planprüfung | Plan ist vorhanden, lesbar und strukturell prüfbar | keine praktische Reaktionsfähigkeit |
| Kontakt-/Alarmierungstest | vorgesehene Rollen und Kanäle sind erreichbar | keine Lagebewältigung |
| Tabletop-Übung | Rollen diskutieren Entscheidungen anhand eines Szenarios | technische Umsetzung meist nicht geprüft |
| Stabs-/Krisenübung | Lagebild, Führung, Ressourcen und Kommunikation werden geübt | produktive Technik kann simuliert sein |
| technische Incident-Übung | Erkennung, Analyse, Eindämmung und Wiederherstellung werden praktisch geprüft | Geschäftsprozesswirkung kann begrenzt sein |
| Restore-/Wiederanlauftest | Daten, Systeme oder Services werden wiederhergestellt | Krisenführung und Kommunikation eventuell nicht umfasst |
| End-to-End-Notfallübung | Organisation, Technik, Fachprozess und Kommunikation wirken zusammen | gilt nur für dokumentiertes Szenario und Scope |
| Lieferanten-/Verbundübung | externe Abhängigkeiten, Verträge und Schnittstellen werden geprüft | Ergebnis hängt vom Beteiligungsumfang ab |
| unangekündigte Übung | reale Reaktionsbereitschaft wird stärker sichtbar | erhöhte Betriebs- und Fehlalarmrisiken |
Ein niedrigerer Übungstyp wird nicht als vollständige End-to-End-Übung dargestellt.
¶ 4. Übungsprogramm
Das risikobasierte Übungsprogramm verbindet:
- kritische Prozesse, Services, Standorte und Ressourcen,
- relevante Bedrohungs- und Ausfallszenarien,
- BIA, RTO, RPO und Mindestbetriebsniveaus,
- ISMS-, TISAX-, NIS2-, DSGVO-, Kunden- und Vertragsanforderungen,
- vergangene Vorfälle, Übungen, Auditbefunde und Änderungen,
- verantwortliche Rollen, Turnus, Ressourcen und erwartete Nachweise.
| Übungsfeld | Beispielrhythmus zur Freigabe | Status |
|---|---|---|
| Meldeweg und Alarmierung | halbjährlich sowie nach wesentlicher Kontaktänderung | Nicht freigegeben |
| Incident-Tabletop | mindestens jährlich und nach wesentlicher Prozessänderung | Nicht freigegeben |
| technische Cyberübung | risikobasiert für kritische Services | Nicht freigegeben |
| Krisenstabsübung | mindestens jährlich oder risikobasiert | Nicht freigegeben |
| Restore-/Wiederanlaufübung | nach Servicekritikalität und Wiederanlaufplan | Nicht freigegeben |
| End-to-End-BCM-Übung | nach BIA, Risiko und Reifegrad | Nicht freigegeben |
| Lieferanten-/Kommunikationsübung | risikobasiert | Nicht freigegeben |
Diese Werte sind Muster und keine pauschalen ISO-, TISAX- oder gesetzlichen Fristen.
¶ 5. Übungsauftrag
| Feld | Mindestinhalt |
|---|---|
| Übungs-ID | dauerhaft eindeutige Referenz, zum Beispiel EX-YYYY-NNN |
| Anlass | Übungsprogramm, Risiko, Vorfall, Audit, Änderung oder Vertrag |
| Übungsart | Kontakt-, Tabletop-, technische, Stabs-, Wiederanlauf- oder End-to-End-Übung |
| Ziel | konkret zu prüfende Fähigkeit und erwartete Aussage |
| Scope | Prozesse, Services, Systeme, Standorte, Rollen und externe Parteien |
| Szenario | Ausgangslage, Annahmen, Ereignisse und ausgeschlossene Aspekte |
| Kriterien | messbare oder beobachtbare Bestehens- und Abbruchkriterien |
| Rollen | Übungsleitung, Steuerung, Teilnehmende, Beobachtung und Sicherheit |
| Zeitfenster | Start, Dauer, Abbruch, Rückbau und Nachbesprechung |
| Schutz | Klassifizierung, Daten, Verteilung und Aufbewahrung der Übungsunterlagen |
| Nachweise | erwartete Zeitlinie, Messwerte, Beobachtungen, Entscheidungen und Berichte |
¶ 6. Übungsziele und Erfolgskriterien
Ziele werden vor der Übung so formuliert, dass sie prüfbar sind. Beispiele:
| Ziel | mögliches Kriterium | Aussagegrenze |
|---|---|---|
| Meldeweg funktioniert | Meldung erreicht festgelegte Rolle und Vertretung innerhalb bestätigter Zeit | keine vollständige Lagebewältigung |
| Lagebild wird erstellt | Quelle, Zeit, Betroffenheit, Unsicherheit und Priorität nachvollziehbar | Richtigkeit hängt von Eingangsdaten ab |
| Incident-Team arbeitet | Rollen, Befugnisse, Protokoll und Entscheidungen erkennbar | Qualität separat bewerten |
| kritischer Service läuft wieder | definierter Zielzustand innerhalb bestätigter RTO | andere Abhängigkeiten möglicherweise nicht geprüft |
| Datenverlust bleibt im Ziel | tatsächlicher Recovery Point erfüllt bestätigte RPO | Datenkonsistenz zusätzlich prüfen |
| Kommunikation ist abgestimmt | freigegebene Botschaften, Adressaten und Zeitpunkt korrekt | reale Zustellung kann simuliert sein |
| Maßnahmen werden verbessert | Befunde besitzen Ursache, Owner, Termin und Retest | Umsetzung noch nicht belegt |
„Keine Eskalation erforderlich“ oder „keine Fehler beobachtet“ ist nur belastbar, wenn Szenario, Beobachtung und Kriterien geeignet waren.
¶ 7. Szenarioentwicklung
Ein Szenario beschreibt realistisch, aber sicher:
- Auslöser und Ausgangszustand,
- betroffene Prozesse, Informationen, Systeme und Standorte,
- bekannte und zunächst unbekannte Fakten,
- zeitliche Entwicklung und geplante Einspielungen,
- technische, personelle, rechtliche und kommunikative Auswirkungen,
- Lieferanten-, Kunden- und Behördenbezug,
- erwartete Entscheidungen ohne die Lösung vorzugeben,
- Grenzen, Sicherheitsmaßnahmen und Abbruchbedingungen.
Szenarien werden nicht so verteilt, dass sie reale Angriffswege oder sensible Schwachstellen unnötig offenlegen.
¶ 8. Sicherheit und Vermeidung von Fehlalarmen
Vor Beginn werden mindestens festgelegt:
- eindeutige Kennzeichnung
ÜBUNG / EXERCISEauf Nachrichten und Unterlagen, - freigegebene Empfänger- und Kontaktlisten,
- keine realen Behörden-, Kunden-, Versicherer- oder Notrufmeldungen ohne ausdrückliche Autorisierung,
- sichere Testdaten und kontrollierte technische Umgebung,
- Grenzen für produktive Eingriffe, Last, Isolation und Datennutzung,
- Abbruchcode und sofort erreichbare Übungs-/Sicherheitsleitung,
- Umgang mit einem während der Übung eintretenden realen Vorfall,
- Beweissicherung, Datenschutz und Löschung von Übungsdaten.
Ein realer Vorfall hat Vorrang und wird eindeutig vom Übungsgeschehen getrennt.
¶ 9. Rollen und Funktionstrennung
| Rolle | Aufgabe |
|---|---|
| Auftraggeber/Geschäftsführung | Ziele, Scope, Ressourcen und wesentliche Risiken freigeben |
| Übungsleitung | Planung, Ablauf, Sicherheit, Abbruch und Auswertung verantworten |
| Übungssteuerung | Einspielungen zeitgerecht und kontrolliert auslösen |
| Teilnehmende | in ihrer vorgesehenen Rolle handeln und Entscheidungen dokumentieren |
| Incident-/Krisenleitung | Lage, Prioritäten, Befugnisse und Kommunikation steuern |
| technische Teams | Analyse, Eindämmung, Restore und technische Nachweise bearbeiten |
| Fachbereiche/BCM | Notbetrieb, Prioritäten, Fachabnahme und Rückkehr bewerten |
| Beobachtende | Kriterienbezogene Fakten und Zeitpunkte erfassen, nicht eingreifen |
| Sicherheit/Schiedsrolle | Gefahren, Fehlalarme, Regelverstöße und Abbruch überwachen |
| Protokollführung | Zeitlinie, Entscheidungen, Annahmen und Belege nachvollziehbar führen |
Übungssteuerung und Beobachtung werden bei wesentlichen Prüfungen angemessen von den beübten Rollen getrennt.
¶ 10. Alarmierung und Meldeweg
Der Alarmierungstest dokumentiert:
- Auslöser, Kanal und Absender,
- Beginn, Zustellung, Bestätigung und Eskalationszeitpunkte,
- erreichte und nicht erreichte Rollen,
- Vertretungen, Bereitschaften und externe Kontakte,
- Korrektheit der Kontaktdaten und Verfügbarkeit alternativer Kanäle,
- Entscheidung zur Aktivierung von Incident-, Notfall- oder Krisenorganisation,
- technische und organisatorische Störungen im Meldeweg.
Die Inhalte der Kontakt- und Eskalationslisten werden im offenen Wiki nicht vollständig wiedergegeben.
¶ 11. Lagebild, Zeitlinie und Entscheidungen
Während der Übung werden mindestens erfasst:
| Ereignis | Mindestinhalt |
|---|---|
| Eingang | Zeitpunkt, Quelle, Meldung und erste Unsicherheit |
| Aktivierung | Rolle, Entscheidung, Begründung und Zeitpunkt |
| Lagebild | Betroffenheit, Auswirkung, Priorität, Annahmen und Lücken |
| Maßnahme | Entscheidung, Owner, Beginn, Ziel und Ergebnis |
| Eskalation | Auslöser, Empfänger, Zeitpunkt und Reaktion |
| Kommunikation | Adressat, Botschaft, Freigabe, Kanal und Simulation/Versand |
| Wiederanlauf | Priorität, Schritt, Messwert, Abnahme und Einschränkung |
| Abschluss | Zielerreichung, offene Risiken, Rückbau und Übergang |
Pauschale Aussagen wie „alles lief gut“ ersetzen keine prüfbare Zeitlinie.
¶ 12. Technische Incident-Übung
Abhängig vom Szenario werden praktisch oder kontrolliert simuliert:
- Erkennung und Validierung des Sicherheitsereignisses,
- Triage, Klassifizierung und technische Betroffenheit,
- Sicherung relevanter Protokolle und Beweise,
- Eindämmung, Isolation und Schutz kritischer Dienste,
- Beseitigung beziehungsweise sichere Übergangsmaßnahmen,
- Wiederherstellung in vertrauenswürdigem Zustand,
- Monitoring auf Wiederauftreten und fachliche Freigabe,
- Dokumentation für Lessons Learned und Folgemaßnahmen.
Die führende Regelung bleibt Incident Response. Die Übung greift nur die vorher freigegebenen, sicheren Prüfschritte auf.
¶ 13. Krisenführung und Kommunikation
Geprüft werden können:
- Aktivierung, Zusammensetzung und Stellvertretung des Krisenstabs,
- Lagebesprechung, Entscheidungsrhythmus und Protokollierung,
- Priorisierung von Menschen, Betrieb, Informationen und Verpflichtungen,
- Ressourcen, externe Unterstützung und Beschaffungsbefugnisse,
- abgestimmte Kommunikation an Beschäftigte, Kunden, Lieferanten und Medien,
- rechtliche, datenschutzrechtliche, NIS2-, Vertrags- und Versicherungsbewertung,
- Freigabe, Version und Konsistenz von Botschaften,
- alternative Kommunikationsmittel bei Ausfall regulärer Kanäle.
Simulierte Meldungen werden als Simulation dokumentiert; reale externe Versendung benötigt eine gesonderte Freigabe.
¶ 14. Notbetrieb, Restore und Wiederanlauf
Abhängig vom Übungsziel werden geprüft:
- priorisierte kritische Prozesse und Mindestbetriebsniveau,
- Personal, Räume, Technik, Daten, Kommunikation und Lieferanten,
- manuelle Ersatzverfahren und Übergangslösungen,
- Recovery Point, Restore und technische Vertrauenswürdigkeit,
- Schnittstellen, Abhängigkeiten und fachliche Nutzbarkeit,
- Messung gegen bestätigte RTO-/RPO-Ziele,
- Rückkehr, Synchronisation und kontrollierter Normalbetrieb.
Technische Restore- und Wiederanlaufdetails werden unter Backup-, Restore- und Wiederanlauftests geführt. Eine Vorfall-/Notfallübung bewertet zusätzlich Führung, Kommunikation und Prozesswirkung.
¶ 15. Lieferanten und externe Parteien
Bei Beteiligung externer Parteien werden festgelegt:
- Übungs-Scope, Rollen und erlaubte Informationen,
- vertragliche Mitwirkung und Erreichbarkeit,
- gemeinsame Alarmierungs-, Kommunikations- und Eskalationswege,
- technische Schnittstellen und Verantwortungsgrenzen,
- Beobachtungen, Nachweise und Berichtsaustausch,
- Vertraulichkeit, Aufbewahrung und Weitergabe,
- Maßnahmen, Owner und Nachprüfung über Organisationsgrenzen hinweg.
Die Lieferanteneignung wird unter Lieferantenbewertungen nachvollzogen.
¶ 16. Beobachtungs- und Messplan
| Beobachtungsfeld | möglicher Messwert | Grenze |
|---|---|---|
| Erkennung | Zeit bis zur ersten qualifizierten Meldung | Szenario und Startzeit definieren |
| Aktivierung | Zeit bis Incident-/Krisenorganisation arbeitsfähig ist | Arbeitsfähigkeit mit Kriterien belegen |
| Lagebild | Zeit, Vollständigkeit und Aktualisierung | Qualität nicht nur über Geschwindigkeit bewerten |
| Entscheidung | Zeit, Befugnis, Begründung und Nachverfolgung | schwierige Entscheidungen nicht künstlich vereinfachen |
| Eindämmung | Zeit und Umfang begrenzter Auswirkung | Simulation von realer Technik trennen |
| Kommunikation | Freigabe, Konsistenz und Erreichbarkeit | simulierte Zustellung kennzeichnen |
| Wiederanlauf | tatsächliche Zeit bis definiertem Zielzustand | Messbeginn und Endkriterium bestätigen |
| Fachabnahme | geprüfte Funktionen und Einschränkungen | technische Verfügbarkeit genügt nicht |
¶ 17. Auswertung und Bewertungslogik
| Bewertung | Mindestkriterium |
|---|---|
| Nicht bewertbar | Ziel, Scope, Beobachtung oder Daten reichen für eine Aussage nicht aus |
| Nicht bestanden | wesentliches Kriterium wurde nicht erreicht oder sicherheitsrelevant verletzt |
| Teilweise bestanden | wesentliche Teile funktionieren, aber relevante Lücken oder Grenzen bleiben |
| Bestanden | alle freigegebenen Kriterien im dokumentierten Scope erreicht |
| Wirksam bestätigt | bestanden und durch geeignete Nachprüfung beziehungsweise nachhaltige Belege gestützt |
Ein Gesamtergebnis darf kritische Einzelbefunde nicht durch Durchschnittswerte verdecken. „Bestanden“ gilt nur für den geprüften Scope, Zeitpunkt und das Szenario.
¶ 18. Hot Wash und Lessons Learned
Unmittelbar nach der Übung werden erste Beobachtungen strukturiert erfasst:
- was wie vorgesehen funktioniert hat,
- welche Verzögerungen, Unsicherheiten oder Fehlentscheidungen auftraten,
- welche Hilfsmittel, Informationen oder Befugnisse fehlten,
- welche Annahmen unrealistisch waren,
- welche Sicherheits- oder Datenschutzprobleme entstanden,
- welche Punkte vorläufig kritisch sind,
- welche Fakten erst nach Protokollauswertung bestätigt werden müssen.
Der Hot Wash ist eine erste Sammlung und ersetzt nicht die Ursachenanalyse oder den freigegebenen Abschlussbericht.
¶ 19. Befunde und Maßnahmen
Jeder Befund enthält:
- Übungs-, Ziel-, Prozess-, Service- und Kriterienbezug,
- beobachteten Ist-Zustand mit Zeit und Quelle,
- erwartetes Verhalten oder Ziel,
- Auswirkung und Priorität,
- Ursache beziehungsweise Analysebedarf,
- Maßnahme, Owner, Ressourcen und Termin,
- erwarteten Umsetzungs- und Wirksamkeitsnachweis,
- Retestart, Termin und Abschlussentscheidung.
Maßnahmen werden im Maßnahmen- und Umsetzungsregister gesteuert. Eine korrigierte Dokumentseite allein belegt keine verbesserte Reaktionsfähigkeit.
¶ 20. Retest und Abschluss
Ein Befund wird erst geschlossen, wenn:
- die Maßnahme nachvollziehbar umgesetzt wurde,
- der betroffene Plan, Prozess, technische Schritt oder Meldeweg aktualisiert ist,
- ein geeigneter Retest oder eine gleichwertige Nachprüfung durchgeführt wurde,
- das ursprüngliche Kriterium im relevanten Scope erneut bewertet wurde,
- verbleibende Einschränkungen und Restrisiken entschieden sind,
- Abschlussrolle, Datum und Nachweisreferenzen dokumentiert wurden.
Ein Retest kann auf den Befund begrenzt sein; seine Aussage darf dann nicht auf die gesamte Notfallorganisation erweitert werden.
¶ 21. Nachweispaket
| Nachweis | Mindestinhalt | Schutz |
|---|---|---|
| Übungsauftrag | ID, Ziele, Scope, Szenario, Kriterien, Rollen und Sicherheit | Vertraulich |
| Teilnehmer-/Rollenliste | Rolle, Beteiligung, Vertretung und Anwesenheit | Vertraulich; gegebenenfalls personenbezogen |
| Szenario-/Einspielungsplan | Ereignisse, Zeiten, erwartete Reaktionen und Steuerung | Streng vertraulich |
| Zeitlinie | Meldungen, Entscheidungen, Maßnahmen und Ergebnisse | Streng vertraulich |
| Beobachtungsbogen | Kriterien, Fakten, Messwerte und Quelle | Vertraulich |
| Kommunikationsnachweise | Entwürfe, Freigaben, Simulation und Zustellung | Vertraulich |
| technische Nachweise | Logs, Tickets, Screenshots, Restore- und Prüfergebnisse | Streng vertraulich |
| Abschlussbericht | Ergebnis, Grenzen, Befunde, Ursachen und Freigaben | Vertraulich |
| Maßnahmen-/Retestakte | Umsetzung, Nachprüfung, Ergebnis und Abschluss | Vertraulich |
Kontrollierte Referenzen werden im Nachweisregister geführt; sensible Originale werden nicht in dieser allgemein lesbaren Seite eingebettet.
¶ 22. Musterübungsregister ohne positive Nachweisbehauptung
| Übungs-ID | Übungstyp | Scope | Ziel | Termin | Durchführung | Ergebnis | Retest | Status |
|---|---|---|---|---|---|---|---|---|
| EX-2026-001 | Alarmierungstest | Incident- und Krisenrollen | Erreichbarkeit und Eskalation | Nicht freigegeben | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| EX-2026-002 | Cyber-Tabletop | kritischer IT-Service | Rollen, Lagebild und Entscheidungen | Nicht freigegeben | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| EX-2026-003 | technische Incident-Übung | Endgeräte und Netzwerk | Erkennung und Eindämmung | Nicht freigegeben | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| EX-2026-004 | Wiederanlaufübung | kritischer Geschäftsprozess | Notbetrieb, RTO und Fachabnahme | Nicht freigegeben | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
| EX-2026-005 | Lieferanten-/Krisenübung | externer kritischer Dienst | Kommunikation und Exitoption | Nicht freigegeben | Nicht durchgeführt | Nicht bewertbar | Nicht geplant | Benötigt |
Die Einträge sind offene Musterbedarfe und keine realen Übungsnachweise.
¶ 23. Kennzahlen und Aussagegrenzen
| Kennzahl | Berechnung | Aussagegrenze |
|---|---|---|
| Übungsabdeckung | geeignet geübte / fällige kritische Szenarien oder Services | Grundgesamtheit und Übungstyp angeben |
| fristgerechte Übungen | rechtzeitig durchgeführte / fällige Übungen | Durchführung ist noch kein Bestehen |
| bestandene Übungen | bestandene / bewertbare Übungen | Scope und Kritikalität getrennt berichten |
| Zielerreichung | erreichte / bewertbare Kriterien | Kriterienqualität und Gewichtung offenlegen |
| Alarmierungszeit | Zeit von Start bis bestätigter Aktivierung | Start- und Endpunkt festlegen |
| RTO-/RPO-Erreichung | Tests innerhalb bestätigter Ziele / bewertbare Tests | nur passende Wiederanlaufübungen einbeziehen |
| offene kritische Befunde | Anzahl nach Priorität und Alter | Vollständigkeit der Erfassung beachten |
| Retesterfolg | erfolgreich nachgeprüfte / fällige Befunde | nur behandelte Lücken bewerten |
Eine hohe Teilnahmequote wird nicht als Reaktions- oder Wiederanlauffähigkeit dargestellt.
¶ 24. Audit- und Assessmentprüfung
Vor Bereitstellung wird geprüft:
- Ist das Übungsprogramm aus Risiken, BIA, Vorfällen und Anforderungen abgeleitet?
- Sind Ziel, Scope, Szenario, Grenzen und Kriterien vorab freigegeben?
- Sind Übungs- und Sicherheitsleitung, Beobachtung und Teilnehmende angemessen getrennt?
- Wurden Fehlalarme, produktive Risiken und reale externe Meldungen verhindert?
- Sind Zeitlinie, Entscheidungen, Messwerte und Beobachtungen nachvollziehbar?
- Wurden technische, organisatorische und kommunikative Aspekte angemessen einbezogen?
- Sind nicht getestete Abhängigkeiten und Simulationen offengelegt?
- Wurden Befunde, Ursachen und Maßnahmen vollständig nachverfolgt?
- Stützt ein Retest die Abschluss- oder Wirksamkeitsaussage?
- Sind sensible Originale geschützt und kontrolliert referenziert?
¶ 25. Aktueller Entwurfsstatus
| Prüffrage | Status |
|---|---|
| Ist ein reales risikobasiertes Übungsprogramm freigegeben? | Nein |
| Sind Incident-, Krisen-, BCM- und Wiederanlaufrollen bestätigt? | Nein |
| Sind erreichbare Melde- und Eskalationswege praktisch getestet? | Nein |
| Sind reale Übungsaufträge und Szenarien referenziert? | Nein |
| Wurden Vorfall- oder Notfallübungen durchgeführt? | Nein |
| Sind RTO, RPO und Mindestbetriebsniveaus bestätigt? | Nein |
| Wurden Befunde durch Retests geschlossen? | Nein |
| Wurde die Nachweisstruktur intern auditiert? | Nein |
Der Musterbestand erlaubt keine positive Aussage über Incident-, Krisen-, Notfall- oder Wiederanlauffähigkeit.
¶ 26. Mitgeltende Seiten
| Thema | Führende Seite |
|---|---|
| Meldeweg und Erstreaktion | Meldeweg für Sicherheitsvorfälle |
| Incident-Verfahren | Incident Response |
| Kontakte und Eskalation | Kontakt- und Eskalationslisten |
| BCM und BIA | Notfallvorsorge und BCM |
| Wiederanlaufverfahren | Wiederanlaufplanung |
| Restore- und Wiederanlauftests | Backup-, Restore- und Wiederanlauftests |
| Lieferantenbeteiligung | Lieferantenbewertungen |
| Maßnahmensteuerung | Maßnahmen- und Umsetzungsregister |
| unabhängige Prüfung | Interne Audits |
¶ 27. Weiterführende Informationen von SMCT MANAGEMENT
SMCT MANAGEMENT
Unterstützung bei ISO 27001, TISAX, Incident Response, Business Continuity, Notfallvorsorge, Übungen und Auditnachweisen
Unterstützung bei ISO 27001, TISAX, Incident Response, Business Continuity, Notfallvorsorge, Übungen und Auditnachweisen
| SMCT-Information | Beschreibung |
|---|---|
| Business Continuity Management | Aufbau von BCM, Notfall- und Wiederanlaufplänen sowie regelmäßige Tests und Übungen mit Lessons Learned |
| ISO 27001 Best Practices | Vorbereitung auf Sicherheitsvorfälle, getestete Notfallpläne, Kommunikationswege und strukturierte Nachanalyse |
| ISO-27001-Rollen und Verantwortlichkeiten | Einbindung von Incident-Response-Team, Befugnissen und Eskalationswegen in das ISMS |
| Business Impact Analyse | Kritische Prozesse, Abhängigkeiten sowie realistische RTO-/RPO-Ziele als Grundlage für Notfall- und Wiederanlaufübungen |
| Leitfaden zur NIS2-Umsetzung | Incident Management, Wiederherstellungstests, Krisenübungen und Awareness im NIS2-Kontext |
Erstgespräch unter info@smct-management.de vereinbaren
¶ 28. Offene Punkte vor Freigabe
- reale kritische Prozesse, Services, Szenarien und Abhängigkeiten bestätigen,
- Übungsprogramm, Turnus, Ziele, Kriterien und Ressourcen freigeben,
- Incident-, Krisen-, BCM-, Kommunikations- und Wiederanlaufrollen bestätigen,
- erreichbare Kontakt-, Vertretungs- und Eskalationswege einrichten,
- sichere Übungs-, Testdaten-, Fehlalarm- und Abbruchregeln festlegen,
- Beobachtungs-, Mess-, Protokoll- und Bewertungsmethodik freigeben,
- erste Alarmierungs-, Tabletop- und technische Übung durchführen,
- Notbetrieb, Restore, RTO/RPO und Fachabnahme praktisch prüfen,
- Befunde im Maßnahmenregister behandeln und Retests durchführen,
- geschützte Ablage, fachliche Prüfung und formale Freigabe dokumentieren.
¶ 29. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 08.08.2026 | Erste Fassung für Übungsprogramm, Szenario, Alarmierung, Reaktion, Krisenkommunikation, Wiederanlauf, Auswertung, Maßnahmen und Retest | Incident-Management / BCM / ISMS | Ausstehend | – |
¶ 30. Quellen und fachliche Grundlagen
- BSI-Standard 200-4 – Business Continuity Management
- ISO – ISO 22301 Security and resilience – Business continuity management systems
- ISO – ISO/IEC 27001 Information security management systems
- ENX – TISAX Downloads und ISA
- SMCT MANAGEMENT – Business Continuity Management
- SMCT MANAGEMENT – ISO 27001 Best Practices
Vor der betrieblichen Nutzung sind die tatsächlich anwendbaren Norm-, ISA-, Rechts-, Vertrags-, Kunden-, Versicherungs- und Beteiligungsanforderungen sowie reale Ziele, Rollen, Kontakte und Freigaben zu bestätigen. Lizenzierte Norm- und ISA-Texte bleiben die führenden Quellen und werden nicht in dieser Wiki-Seite reproduziert.