Wenn Active Directory, Entra ID, Mail, Teams, VPN oder ein kritisches Fachsystem ausfällt, müssen Reihenfolge, Verantwortliche, Kommunikation und Wiederherstellung bereits geklärt sein. Dieses Beispiel zeigt, welche Angaben ein kompakter IT-Wiederanlaufplan enthalten sollte.
Sie können die Struktur direkt auf Ihre wichtigsten Dienste übertragen und anschließend festlegen, ob eine Kundenanfrage, eine Meldebewertung oder eine Entscheidung der Geschäftsführung vorliegt.
Das folgende Beispiel zeigt einen kompakten Plan für den Ausfall von Identität, Mail und zentralen Fachsystemen. Ersetzen Sie die Beispielangaben durch Ihre tatsächlichen Dienste, Rollen, Kontakte und Wiederherstellungswege.
Die Vorlage wird direkt in Ihrem Browser bearbeitet. Ihre Eingaben bleiben in diesem Browser und werden nicht an Khosla Compliance übertragen. Die PDF-Speicherung erfolgt über den Druckdialog Ihres Browsers.
Tragen Sie hier keine Zugangsdaten, Passwörter, Recovery-Codes oder geheimen Schlüssel ein. Nutzen Sie die lokale Speicherung nur auf einem geschützten Unternehmensgerät.
| Feld | Beispiel | Eigene Angabe |
|---|---|---|
| Auslöser | Active Directory und Entra ID sind nicht erreichbar. Neue Anmeldungen schlagen fehl. | |
| Zeitpunkt der Kenntnis | 08:05 Uhr · Meldung durch IT-Service | |
| Betroffene Dienste | Windows-Anmeldung, VPN, Microsoft 365, zentrale Fachanwendung | |
| Betriebswirkung | Mitarbeiter können sich nicht neu anmelden. Externe Zugriffe sind unterbrochen. | |
| Wiederanlaufpriorität | 1. Identitätsdienst · 2. Administratorzugriff · 3. Ersatzkommunikation · 4. VPN · 5. Fachanwendung · 6. reguläre Kommunikation | |
| Verantwortliche Rolle | IT-Leitung koordiniert. Systemowner bestätigen die Wiederherstellung ihrer Dienste. | |
| Technische Umsetzung | Notfallzugang prüfen, Identitätsdienst stabilisieren, abhängige Dienste kontrolliert starten. | |
| Ersatzkommunikation | Offline-Telefonliste und vorab freigegebener externer Kommunikationskanal. | |
| Interner Ansprechpartner | IT-Leitung; Vertretung und Eskalationsrolle sind benannt. | |
| Externer Dienstleister | Managed-Service-Provider über Notfallnummer kontaktieren. Ticketnummer im Plan dokumentieren. | |
| Letzter Backup-Stand | Letzte erfolgreiche Sicherung: 02:00 Uhr | |
| Letzter Restore-Test | Letzter erfolgreicher Restore-Test: [Datum eintragen] | |
| Notfallzugang | Break-Glass-Konto im geschützten Offline-Tresor; Nutzung wird protokolliert. | |
| Abhängigkeiten | Netzwerk, DNS, Administratorzugriff, Cloud-Verbindung und Dienstleisterzugang. | |
| Entscheidung | IT-Leitung bestätigt Reihenfolge; wesentliche Abweichungen werden der Geschäftsführung vorgelegt. | |
| Offene Maßnahmen | Ursache klären, betroffene Konten prüfen, Restore dokumentieren, Meldebewertung durchführen. | |
| Nächster Prüftermin | Beispiel: Review innerhalb von fünf Arbeitstagen nach Wiederherstellung. Den verbindlichen Termin legt das Unternehmen nach Kritikalität und interner Regelung fest. |
Ein Beispiel ist nur dann hilfreich, wenn das Unternehmen seine eigenen Dienste, Abhängigkeiten, Rollen und Kommunikationswege einträgt und regelmäßig prüft.
Ein IT-Wiederanlaufplan enthält die kritischen Dienste, ihre Wiederanlaufreihenfolge, verantwortliche Rollen, Offline-Kontakte, Ersatzkommunikation, Dienstleister, Backup- und Restore-Informationen, Notfallzugänge, Abhängigkeiten, Entscheidungen, offene Maßnahmen und den nächsten Prüftermin.
Konkrete Wiederherstellung von IT-Diensten, Kommunikation, Rollen und Reihenfolge.
Technische Sicherung und Wiederherstellung von Daten oder Systemen.
Unternehmensweiter Umgang mit kritischen Prozessen, Auswirkungen, Abhängigkeiten und Fortführung.
Erkennung, Bewertung, Eindämmung und Behandlung eines Sicherheitsereignisses.
§30 BSIG verlangt bei betroffenen Unternehmen angemessene Maßnahmen zur Aufrechterhaltung und Wiederherstellung des Betriebs. Dazu gehören unter anderem Backup-Management, Wiederherstellung nach einem Notfall und Krisenmanagement. Der konkrete Umfang richtet sich nach Risiko, Kritikalität und Betriebsmodell.
Ein kompakter IT-Wiederanlaufplan ist ein praktischer Einstieg. Er ersetzt bei hoher Kritikalität, mehreren Standorten, Produktion oder komplexen Abhängigkeiten keine Business Impact Analysis und kein vollständiges Business Continuity Management.
Wenn der Ausfall auf einem Sicherheitsereignis beruht oder erhebliche Auswirkungen verursacht, muss zusätzlich geprüft werden, ob eine Meldebewertung nach §32 BSIG erforderlich ist.
Erfassen Sie Kenntniszeitpunkt, betroffene Dienste, Betriebswirkung, Maßnahmen und Wiederanlauf. Prüfen und dokumentieren Sie anschließend die Meldeentscheidung.
Meldebewertung führen → §32 BSIG einordnen →Ordnen Sie vorhandene Wiederanlauf-, Backup- und BCM-Nachweise der Kundenanforderung zu und dokumentieren Sie offene Punkte.
Kundenanfrage jetzt ausfüllen → Kundenanfrage einordnen →Bereiten Sie kritische Dienste, Abhängigkeiten, offene Maßnahmen, Restrisiken und den benötigten Entscheidungsumfang für die Geschäftsführung auf.
GF-Entscheidung führen → Verantwortung der Geschäftsführung →Übertragen Sie die Beispielstruktur auf Ihre kritischen Dienste. Wählen Sie anschließend, ob ein aktuelles Sicherheitsereignis bewertet, eine Kundenanfrage beantwortet oder eine Entscheidung der Geschäftsführung vorbereitet werden muss.