¶ Tests und Übungen mit praxistauglichen Beispielen
Praxisgrundsatz: Ein Plan wird nicht dadurch wirksam, dass er vollständig geschrieben ist. Erst geeignete Tests und Übungen zeigen, ob Kontakte erreichbar sind, Rollen ihre Aufgaben verstehen, technische Verfahren funktionieren, Entscheidungen rechtzeitig getroffen werden und ein Geschäftsprozess tatsächlich wieder nutzbar wird.
Musterstatus: Die Beispiele auf dieser Seite sind Übungsentwürfe für eine fiktive Organisation. Sie belegen keine durchgeführte oder bestandene Übung. Szenarien, Zielwerte, Beteiligte, Sicherheitsgrenzen und Freigaben müssen vor der Nutzung organisationsbezogen festgelegt werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-05-06 |
| Dokumentenart | Praxisleitfaden für Tests und Übungen |
| Wiki.js-Pfad | /ISMS/05-Vorfaelle-und-Notfallmanagement/Tests-und-Uebungen |
| Verantwortlich | BCM-/Notfallverantwortliche/r und ISMS-Beauftragte/r |
| Fachlich geprüft durch | Incident Management, IT/OT, Fachbereiche, Informationssicherheit, Datenschutz, Kommunikation, Facility Management und Lieferantenmanagement |
| Freigabe durch | Geschäftsführung beziehungsweise befugte Notfall- oder Krisenleitung |
| Status | Entwurf – Testprogramm, Szenarien, Termine und Erfolgskriterien nicht organisationsbezogen bestätigt |
| Version | 1.0 |
| Stand | 09.08.2026 |
| Nächste Prüfung | Mindestens jährlich sowie nach Übungen, Vorfällen und wesentlichen Änderungen |
| Schutzklasse | Intern; Szenarien und Detailprotokolle abhängig vom Inhalt vertraulich oder streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 8 bis 10 sowie Annex A 5.24 bis 5.30, 8.13 und 8.14 |
| Ergänzende Orientierung | ISO 22301, ISO/IEC 27031, BSI-Standard 200-4 und NIST SP 800-84 |
Praxiszyklus von der risikobasierten Planung bis zum nachgewiesenen Retest. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Test, Übung und Simulation unterscheiden
Die Begriffe werden in der Praxis häufig vermischt. Für eine belastbare Aussage sollte vorab feststehen, was tatsächlich geprüft wird.
| Format | Schwerpunkt | einfaches Beispiel | zulässige Aussage |
|---|---|---|---|
| Test | definierte Funktion oder technisches Ergebnis | eine Datei aus der Sicherung wiederherstellen | genau diese Wiederherstellung hat unter den dokumentierten Bedingungen funktioniert |
| Übung | Handeln, Zusammenarbeit und Entscheidungen von Rollen | Krisenstab bearbeitet einen simulierten Ransomware-Fall | Rollen und Abläufe wurden im beschriebenen Szenario geübt und bewertet |
| Simulation | reale Wirkung wird kontrolliert nachgebildet | Lieferant meldet im Drehbuch einen Cloud-Ausfall | Reaktion auf die angenommene Lage wurde geprüft; der reale Anbieter ist nicht ausgefallen |
| Review | Dokumente und Annahmen werden systematisch geprüft | Kontaktliste und Wiederanlaufplan gemeinsam durchgehen | Unterlagen wurden auf definierte Qualitätsmerkmale geprüft |
Ein Tabletop beweist keinen technischen Restore. Ein erfolgreicher Restore beweist keine funktionierende Krisenkommunikation. Eine versandte Testmeldung beweist noch keine vollständige Alarmierungs- und Eskalationsfähigkeit.
¶ 2. Von einfach zu anspruchsvoll: die Test- und Übungsleiter
Organisationen müssen nicht mit einer unangekündigten Vollübung beginnen. Ein sinnvoller Reifeaufbau reduziert Risiken und erhöht schrittweise die Aussagekraft.
| Stufe | Format | Aufwand | typische Lernfrage |
|---|---|---|---|
| 1 | Dokumenten- und Plausibilitätsreview | niedrig | Sind Rollen, Kontakte, Entscheidungen und Schritte eindeutig? |
| 2 | Kontakt- und Alarmierungstest | niedrig | Erreichen Meldungen die richtigen Personen und Vertretungen? |
| 3 | Tabletop-Übung | mittel | Treffen die Beteiligten unter Zeitdruck nachvollziehbare Entscheidungen? |
| 4 | Funktions- oder Komponententest | mittel | Funktioniert ein technischer oder organisatorischer Teil praktisch? |
| 5 | Service- und Wiederanlauftest | hoch | Wird ein definierter Service einschließlich wesentlicher Abhängigkeiten nutzbar? |
| 6 | Stabs- oder Bereichsübung | hoch | Funktionieren Führung, Lagebild, Kommunikation und Ressourcensteuerung? |
| 7 | Ende-zu-Ende-Übung | sehr hoch | Wirken Organisation, Technik, Fachprozess und externe Parteien zusammen? |
Die Auswahl richtet sich nach Risiken, Kritikalität, Änderungen, bisherigen Befunden und dem möglichen Schaden durch die Übung selbst. Eine niedrigere Stufe kann bewusst richtig sein, wenn zunächst Grundlagen geprüft werden sollen.
¶ 3. Acht Regeln für praxistaugliche Übungen
- Ein klares Lernziel: Nicht „Ransomware üben“, sondern beispielsweise „innerhalb von 30 Minuten ein belastbares Lagebild mit Betroffenheit, Unsicherheiten und drei priorisierten Entscheidungen erstellen“.
- Begrenzter Scope: Systeme, Prozesse, Rollen, Standorte und ausdrücklich nicht geprüfte Bereiche dokumentieren.
- Messbare Kriterien: Zeiten, Vollständigkeit, Entscheidungsgüte, Kommunikationsqualität und fachliche Nutzbarkeit vorab definieren.
- Sicherer Rahmen: Testdaten, Zielumgebung, Abbruchcode, Rückfallverfahren und Schutz der Produktion festlegen.
- Realistische Einspielungen: Informationen schrittweise bereitstellen, ohne den Teilnehmenden die Lösung vorzugeben.
- Unabhängige Beobachtung: Beobachtende protokollieren Fakten und Zeitpunkte; sie lösen die Aufgabe nicht für die Teilnehmenden.
- Keine Schönfärbung: Planlücken, Fehlentscheidungen, technische Probleme und nicht getestete Teile sichtbar lassen.
- Verbesserung bis zum Retest: Ein Befund ist nicht mit dem Abschlussbericht erledigt, sondern erst nach geeigneter Korrektur und Überprüfung.
¶ 4. Der Übungsauftrag auf einer Seite
Vor jeder praktischen Durchführung sollte ein kurzer, freigegebener Auftrag vorliegen.
| Feld | Leitfrage | Beispiel |
|---|---|---|
| Übungs-ID | Wie wird die Durchführung eindeutig referenziert? | EX-2026-004 |
| Anlass | Warum wird geübt? | jährliches BCM-Programm und neuer Cloud-Anbieter |
| Ziel | Welche Fähigkeit wird geprüft? | Eskalation und Ersatzverfahren innerhalb von 45 Minuten aktivieren |
| Scope | Was ist einbezogen? | Auftragsprozess, SaaS-Dienst, Einkauf, IT und Kundenservice |
| Nicht im Scope | Was bleibt ausdrücklich ungeprüft? | realer Provider-Failover und Behördenmeldung |
| Szenario | Welche Lage wird angenommen? | SaaS-Ausfall während Auftragsspitze |
| Kriterien | Wann ist das Ziel erreicht? | bestätigte Aktivierung, vollständige Zeitlinie und arbeitsfähiges Ersatzverfahren |
| Rollen | Wer leitet, steuert, beobachtet und nimmt teil? | BCM-Leitung, Übungssteuerung, Fachbereich, IT, Kommunikation |
| Sicherheit | Welche Grenzen und Abbruchregeln gelten? | keine produktiven Änderungen; Abbruchcode STOP ÜBUNG |
| Nachweise | Was wird geschützt dokumentiert? | Zeitlinie, Entscheidungen, Messwerte, Befunde und Maßnahmen |
¶ 5. Praxisbeispiel 1: Kontakt- und Alarmierungstest
¶ Ziel
Prüfen, ob die festgelegten Erstkontakte und Vertretungen über primäre und alternative Kanäle erreichbar sind und den Eingang bestätigen.
¶ Ablauf
- Übungsleitung versendet eine deutlich als ÜBUNG gekennzeichnete Meldung.
- Die zuerst adressierte Rolle bestätigt Eingang, Uhrzeit und nächstes Vorgehen.
- Bei ausbleibender Antwort wird nach dem festgelegten Eskalationsweg die Vertretung alarmiert.
- Die angerufene Rolle nennt die aktuelle nächste Eskalationsstelle, ohne vertrauliche Kontaktdaten offen zu veröffentlichen.
- Übungsleitung beendet den Test ausdrücklich und dokumentiert fehlerhafte Daten oder Kanäle.
¶ Beispielhafte Kriterien
| Kriterium | Musterziel | Messung |
|---|---|---|
| Bestätigung der Erstrolle | 10 Minuten | Versand- bis Bestätigungszeit |
| Aktivierung der Vertretung | 15 Minuten nach Fristablauf | Zeitlinie des Eskalationswegs |
| korrekte Rollenzuordnung | 100 % der geprüften Rollen | Abgleich mit freigegebener Liste |
| Fehlalarm | 0 reale externe Meldungen | Abschlusskontrolle |
Typischer Lerngewinn: Eine Telefonnummer kann aktuell sein, obwohl die Person ihre Rolle nicht kennt. Erreichbarkeit und Handlungsfähigkeit werden deshalb getrennt bewertet.
¶ 6. Praxisbeispiel 2: Ransomware-Tabletop
¶ Ausgangslage
Der Service Desk meldet verschlüsselte Dateien auf mehreren Clients. Kurz darauf fällt ein Fileservice aus. Es ist unklar, ob Sicherungen, Identitätsdienste oder Produktionssysteme betroffen sind.
¶ Einspielungen
| Zeitpunkt | Einspielung | erwartete Fragestellung |
|---|---|---|
| T+0 | erste Verschlüsselungsmeldung | Wer übernimmt Triage und Incident-Leitung? |
| T+15 | privilegiertes Konto zeigt ungewöhnliche Anmeldung | Welche Eindämmung ist angemessen und wer darf sie freigeben? |
| T+30 | Fachbereich benötigt dringend Auftragsdaten | Welche Priorität und welches Ersatzverfahren gelten? |
| T+45 | Kunde fragt nach möglichem Datenabfluss | Wer bewertet Fakten, Vertrag, Datenschutz und Kommunikation? |
| T+60 | neueste Sicherung könnte betroffen sein | Wer wählt einen vertrauenswürdigen Recovery Point? |
¶ Bewertet werden
- Trennung bestätigter Fakten von Annahmen,
- klare Leitung, Rollen und Entscheidungsbefugnisse,
- Beweiserhalt vor vermeidbaren Veränderungen,
- sichere Eindämmung ohne unkontrollierten Gesamtausfall,
- parallele fachliche, datenschutzrechtliche, vertragliche und gegebenenfalls NIS2-bezogene Bewertung,
- Entscheidung über Clean Recovery und Wiederanlauf,
- abgestimmte interne und externe Kommunikation.
Nicht behaupten: Ein Tabletop weist nicht nach, dass Malware technisch erkannt oder ein System sauber wiederhergestellt werden kann. Dafür sind ergänzende technische Tests erforderlich.
¶ 7. Praxisbeispiel 3: Datei- und Datenbank-Restore
¶ Ziel
Nachweisen, dass ausgewählte Daten aus einer geschützten Sicherung in einer isolierten Umgebung vollständig, konsistent und fachlich lesbar wiederhergestellt werden können.
¶ Durchführung
- Prüfer wählt Sicherungsstand und Stichprobe unabhängig vom Backup-Administrator aus.
- Zeitstempel, Sicherungskette, Verschlüsselung und benötigte Schlüssel werden erfasst.
- Restore erfolgt nach Runbook in eine freigegebene Testumgebung.
- Hashwerte beziehungsweise technische Konsistenz werden geprüft.
- Fachbereich kontrolliert Datensatz, Zeitraum, Vollständigkeit und Nutzbarkeit.
- Ist-Dauer und tatsächliche Datenlücke werden gegen RTO und RPO bewertet.
- Testdaten und Zielumgebung werden kontrolliert bereinigt.
¶ Möglicher Befund
Der Restore benötigt 35 Minuten und liegt innerhalb des technischen Zeitfensters. Die Datenbank ist aber nicht nutzbar, weil ein Zertifikat im Runbook fehlt. Das Ergebnis lautet daher nicht „bestanden“, sondern beispielsweise teilweise bestanden – fachliche Nutzbarkeit nicht erreicht.
Die genaue Abgrenzung von RPO und RTO erläutert RPO und RTO verständlich erklärt.
¶ 8. Praxisbeispiel 4: Wiederanlauf eines Geschäftsservices
¶ Szenario
Die zentrale Auftragsbearbeitung steht nach einem Infrastrukturfehler nicht zur Verfügung. Netzwerk, Identitäten, Datenbank, Anwendung, Schnittstellen und Druckausgabe sind voneinander abhängig.
¶ Prüfpfad
| Phase | Prüffrage | möglicher Abnahmepunkt |
|---|---|---|
| Basisdienste | Sind Netz, Zeit, DNS und Identitäten vertrauenswürdig verfügbar? | technische Freigabe der Plattform |
| Daten | Ist ein konsistenter und akzeptabler Recovery Point vorhanden? | Datenabnahme durch Owner |
| Anwendung | Starten Anwendung, Jobs und Berechtigungen korrekt? | technischer Funktionstest |
| Schnittstellen | Werden Ein- und Ausgangsdaten korrekt verarbeitet? | abgestimmter End-to-End-Test |
| Fachprozess | Kann ein berechtigter Nutzer einen Auftrag vollständig bearbeiten? | fachliche Freigabe |
| Nachbetrieb | Sind Monitoring, Nacharbeiten und Rückfall geregelt? | dokumentierte Betriebsübergabe |
Das RTO endet nicht beim Start des Servers, sondern am vorab definierten, nutzbaren und freigegebenen Zielzustand. Nicht geprüfte Abhängigkeiten werden im Abschlussbericht sichtbar aufgeführt.
¶ 9. Praxisbeispiel 5: Cloud-/SaaS-Ausfall mit Lieferant
¶ Ziel
Prüfen, ob Fachbereich, IT und Lieferantenmanagement bei Ausfall eines externen Dienstes gemeinsam handlungsfähig bleiben.
¶ Szenarioelemente
- Statusseite des Anbieters ist nicht erreichbar.
- Support bestätigt den Eingang, nennt aber keine Wiederherstellungszeit.
- Der interne Ersatzprozess kann nur 40 % des üblichen Volumens verarbeiten.
- Ein Kunde verlangt innerhalb einer Stunde eine belastbare Auskunft.
- Der Datenexport des Vortags muss auf Vollständigkeit geprüft werden.
¶ Erfolgsmerkmale
- Vertrag, SLA, Eskalationskontakte und Exit-Unterlagen sind erreichbar,
- interner Owner und Provider-Owner sind eindeutig,
- Mindestbetriebsniveau und Priorisierung werden aktiviert,
- Kommunikation nennt Fakten, Auswirkungen, Maßnahmen und nächste Aktualisierung,
- Abweichung zwischen benötigtem und zugesagtem RTO/RPO wird als Risiko behandelt,
- Providerleistung und eigener Ersatzprozess werden getrennt bewertet.
¶ 10. Praxisbeispiel 6: Standortausfall und mobiles Ersatzverfahren
¶ Ausgangslage
Ein Gebäude ist wegen Strom- und Zutrittsausfall für einen Arbeitstag nicht nutzbar. Die Belegschaft soll teilweise mobil arbeiten. Gleichzeitig sind ein lokales Lager, Spezialdrucker und eine Produktionsfreigabe nur am Standort verfügbar.
¶ Prüfpunkte
- Wer stellt fest, dass der Standort nicht nutzbar ist?
- Welche Prozesse können mobil, an einem Ausweichort oder manuell weiterarbeiten?
- Reichen Endgeräte, MFA, Bandbreite, Telefonie und Lizenzen für das Mindestbetriebsniveau?
- Welche Tätigkeiten dürfen aus Sicherheits-, Qualitäts- oder Arbeitsschutzgründen nicht verlagert werden?
- Wie werden nicht verfügbare physische Ressourcen priorisiert?
- Wie werden Beschäftigte, Besucher, Lieferanten und Kunden informiert?
- Wer entscheidet über Rückkehr, Schichtbetrieb oder längeren Notbetrieb?
Eine reine Homeoffice-Anmeldung wäre nur ein Funktionstest. Erst die Bearbeitung der priorisierten Geschäftsleistung zeigt, ob das Ersatzverfahren praktisch trägt.
¶ 11. Beispiel für ein risikobasiertes Jahresprogramm
Hinweis: Die Intervalle sind Musterwerte. Sie sind weder allgemeine ISO-Fristen noch automatisch für eine konkrete Organisation angemessen.
| Quartal | Test oder Übung | Schwerpunkt | erwarteter Nachweis |
|---|---|---|---|
| Q1 | Kontakt- und Alarmierungstest | Erreichbarkeit, Vertretung, Ausfallkanal | Zeitlinie und korrigierte Kontaktreferenzen |
| Q1 | Restore-Stichprobe | wechselnde Dateien und Datenbank | technisches Protokoll und Fachabnahme |
| Q2 | Ransomware-Tabletop | Incident-Leitung, Entscheidungen, Kommunikation | Beobachtungsbogen und Maßnahmen |
| Q2 | Lieferantentest | Support, Eskalation, Datenexport | Providerprotokoll und SLA-Abgleich |
| Q3 | Service-Wiederanlauftest | Abhängigkeiten, RTO/RPO, Fachfunktion | Ende-zu-Ende-Zeitlinie und Abnahme |
| Q3 | Standortausfall-Übung | Notbetrieb und Ressourcen | Kapazitäts- und Prozessbewertung |
| Q4 | Krisenstabsübung | Lagebild, Priorität, Kommunikation | Entscheidungsprotokoll und Lessons Learned |
| Q4 | Retests | offene wesentliche Befunde | Schließungsnachweis oder Restrisikoentscheidung |
Kritische Änderungen, reale Vorfälle, neue Bedrohungen oder fehlgeschlagene Tests können zusätzliche Termine auslösen.
¶ 12. Rollen in der Durchführung
| Rolle | Verantwortung |
|---|---|
| Auftraggeber | Ziel, Scope, Ressourcen und akzeptiertes Übungsrisiko freigeben |
| Übungsleitung | Gesamtablauf, Sicherheit, Start, Pause und Abbruch steuern |
| Szenario-/Übungssteuerung | Einspielungen nach Drehbuch auslösen und Lage konsistent halten |
| Teilnehmende | in ihrer realen oder klar bezeichneten Übungsrolle handeln |
| Beobachtende | Kriterien, Zeiten, Entscheidungen und Abweichungen objektiv erfassen |
| Protokollführung | durchgehende Zeitlinie und Belegreferenzen führen |
| Sicherheitsrolle | Produktionswirkung, Datenschutz, Fehlalarm und reale Ereignisse überwachen |
| Fachabnahme | tatsächliche Nutzbarkeit des Prozesses oder Services bewerten |
Bei wichtigen Übungen sollten Steuerung und Bewertung nicht vollständig durch dieselben Personen erfolgen, deren Leistung bewertet wird.
¶ 13. Sicherheits- und Abbruchregeln
Vor dem Start werden mindestens vereinbart:
- Kennzeichnung aller simulierten Nachrichten mit
ÜBUNG / EXERCISE, - keine realen Behörden-, Kunden-, Medien-, Versicherungs- oder Notrufmeldungen ohne gesonderte Freigabe,
- sichere Testdaten und kontrollierte Empfängerlisten,
- Grenzen für produktive Abschaltungen, Last, Netzwerkisolation und Konfigurationsänderungen,
- sofort verständlicher Abbruchcode,
- Entscheidungspfad bei einem parallel eintretenden realen Vorfall,
- Rückbau und kontrollierte Bereinigung,
- Schutzklasse und Verteiler der Szenarien und Ergebnisse.
Ein echter Vorfall hat Vorrang. Die Übungsleitung beendet oder pausiert die Übung eindeutig und übergibt an die reale Incident- oder Notfallorganisation.
¶ 14. Bewertung ohne Schönfärbung
Die Bewertung trennt mehrere Aussagen:
| Status | Bedeutung |
|---|---|
| geplant | Auftrag und Termin sind vorgesehen |
| vorbereitet | Scope, Szenario, Rollen, Kriterien und Sicherheit sind freigegeben |
| durchgeführt | die dokumentierte Aktivität hat stattgefunden |
| bestanden | die vorab festgelegten Kriterien wurden im geprüften Scope erreicht |
| Ziel teilweise erreicht | einzelne Kriterien wurden erreicht, andere nicht |
| nicht bestanden | ein wesentliches Kriterium wurde verfehlt |
| wirksam | Ergebnis, Aussagekraft, Befundbehandlung und gegebenenfalls Retest stützen die Wirksamkeitsaussage |
¶ Beispielhafte Kennzahlen
| Kennzahl | Berechnung oder Beobachtung |
|---|---|
| Alarmierungszeit | Bestätigung der zuständigen Rolle minus Versandzeit |
| Aktivierungszeit | formale Aktivierung minus Erkennung der Lage |
| Lagebildzeit | erstes freigegebenes Lagebild minus Eingangsmeldung |
| Ist-RTO | nutzbarer freigegebener Service minus definierter Ausfallbeginn |
| Ist-Datenlücke | Ausfallzeitpunkt minus letzter akzeptabler Datenstand |
| Zielerreichungsgrad | erreichte gewichtete Kriterien geteilt durch alle gewichteten Kriterien |
| Maßnahmenabschluss | fristgerecht geschlossene Maßnahmen geteilt durch fällige Maßnahmen |
Eine hohe Prozentzahl darf wesentliche Sicherheits- oder Wiederanlauflücken nicht verdecken. Kritische Muss-Kriterien werden deshalb separat ausgewiesen.
¶ 15. Auswertung, Maßnahmen und Retest
Innerhalb eines festgelegten Zeitfensters findet eine strukturierte Nachbesprechung statt:
- Fakten und Zeitlinie bestätigen,
- erwartetes und tatsächliches Verhalten vergleichen,
- gute Praktiken ebenso wie Lücken dokumentieren,
- Ursachen statt nur Symptome untersuchen,
- Befunde nach Risiko und Dringlichkeit priorisieren,
- Maßnahmen mit Owner, Termin und Erfolgskriterium festlegen,
- Pläne, Kontakte, Technik und Schulungen aktualisieren,
- geeigneten Retest bestimmen,
- Restrisiken oder nicht umsetzbare Maßnahmen formal entscheiden,
- Ergebnisse in Managementbewertung und Verbesserungssteuerung einbeziehen.
| Befund | Ursache | Risiko | Maßnahme | Owner | Termin | Retest | Status |
|---|---|---|---|---|---|---|---|
[Beschreibung] |
[Ursachenanalyse] |
[Bewertung] |
[konkrete Korrektur] |
[Rolle] |
[Datum] |
[Methode/Datum] |
[offen] |
Die Musterzeile ist kein Nachweis für einen realen Befund oder eine umgesetzte Maßnahme.
¶ 16. Nachweise richtig ablegen
Die öffentliche Wiki-Seite beschreibt Verfahren und Metadaten. Vertrauliche Originale gehören in eine geschützte, berechtigungsgesteuerte und im Notfall erreichbare Ablage. Dazu können gehören:
- freigegebener Übungsauftrag und Drehbuch,
- Teilnehmer- und Rollenübersicht,
- Zeitlinie, Einspielungen und Entscheidungsprotokoll,
- technische Logs, Screenshots und Messwerte,
- Kommunikationsentwürfe und Freigaben,
- Beobachtungs- und Bewertungsbögen,
- Abschlussbericht, Befunde und Maßnahmen,
- Freigaben, Risikoakzeptanzen und Retest-Ergebnisse.
Die führende Nachweisregelung für organisatorische Übungen ist Vorfall- und Notfallübungen. Technische Wiederherstellungsnachweise werden unter Backup-, Restore- und Wiederanlauftests geführt.
¶ 17. Schnellcheck vor dem Start
- Ziel und Aussagegrenze sind verständlich formuliert.
- Scope und ausgeschlossene Bereiche sind dokumentiert.
- Kriterien und Messpunkte stehen vor der Durchführung fest.
- Rollen, Stellvertretungen und unabhängige Beobachtung sind besetzt.
- Testdaten, Empfänger, Umgebung und Produktivrisiken sind geprüft.
- Abbruchcode, Rückfall und Umgang mit einem realen Vorfall sind bekannt.
- Externe Beteiligte und simulierte Meldungen sind eindeutig geregelt.
- Zeitlinie, Nachweise und Schutzklasse sind vorbereitet.
- Nachbesprechung, Maßnahmenprozess und Retest sind terminiert.
- Die Übung ist formal freigegeben.
¶ 18. Weiterführende Seiten
- Incident Response
- Meldeweg für Sicherheitsvorfälle
- Kontakt- und Eskalationslisten
- Notfallvorsorge und BCM
- Wiederanlaufplanung
- RPO und RTO verständlich erklärt
- Vorfall- und Notfallübungen – Nachweise
- Backup-, Restore- und Wiederanlauftests
- Wirksamkeitsmessungen
- Maßnahmen- und Umsetzungsregister
¶ 19. Externe Orientierung
- BSI – Kapitel 8: Notfälle üben
- BSI-Standard 200-4 – Business Continuity Management
- NIST SP 800-84 – Guide to Test, Training, and Exercise Programs
Die Quellen dienen der Orientierung. Testprogramm, Turnus, Verantwortlichkeiten und Nachweisumfang werden aus den tatsächlich geltenden Risiken, Anforderungen und freigegebenen internen Regelungen abgeleitet.
¶ 20. Änderungsverlauf
| Version | Datum | Änderung | Status |
|---|---|---|---|
| 1.0 | 09.08.2026 | Erstfassung mit Testleiter, sechs Praxisszenarien, Jahresprogramm, Sicherheitsregeln, Messung, Auswertung und Retest | Entwurf |