- Das IT-Notfallhandbuch ist das zentrale Dokument für den Ernstfall. Es bündelt alle relevanten Informationen an einem Ort und ermöglicht schnelles, koordiniertes Handeln.
- Pflichtinhalte sind Eskalationsketten, Kontaktlisten, Meldewege, Sofortmaßnahmen und szenariospezifische Reaktionspläne.
- Das Handbuch muss über mehrere unabhängige Kanäle verfügbar sein: gedruckt, digital und idealerweise per QR-Code abrufbar.
- Regelmäßige Aktualisierung ist entscheidend. Ein veraltetes Notfallhandbuch mit falschen Kontaktdaten richtet im Ernstfall mehr Schaden an als keines.
- Das Handbuch verbindet BIA-Ergebnisse, Wiederanlaufpläne und Kommunikationspläne zu einem operativen Gesamtdokument.
Warum ein IT-Notfallhandbuch unverzichtbar ist
Montagmorgen, 7:45 Uhr. Der IT-Leiter ist im Urlaub, sein Stellvertreter krank. Der Helpdesk-Mitarbeiter stellt fest, dass sämtliche Server nicht erreichbar sind. Auf der Firewall-Konsole leuchten Alarme, und die ersten Mitarbeiter melden sich, weil sie nicht arbeiten können. Was jetzt?
Wenn es für diese Situation ein Notfallhandbuch gibt, weiß der Helpdesk-Mitarbeiter, wen er anrufen muss, welche Sofortmaßnahmen zu ergreifen sind und welche Eskalationsstufe greift. Wenn es kein Notfallhandbuch gibt, beginnt das Chaos: Hektische Anrufe, Informationslücken, verlorene Zeit.
Das IT-Notfallhandbuch ist kein theoretisches Dokument für die Ablage. Es ist ein operatives Werkzeug, das in einer Krisensituation funktionieren muss. Es beantwortet die Fragen, die unter Stress niemand beantworten kann: Wer ist zuständig? Welche Nummer hat der externe Dienstleister? Ab wann muss die Geschäftsführung informiert werden? Muss der Vorfall an eine Behörde gemeldet werden?
Für mittelständische Unternehmen, die unter NIS2 fallen, kommt ein regulatorischer Aspekt hinzu: Die Meldepflicht bei erheblichen Sicherheitsvorfällen läuft ab dem Zeitpunkt der Kenntnisnahme. 24 Stunden für die Erstmeldung ans BSI. Wer in dieser Zeit erst die Telefonnummer sucht und sich fragt, wer die Meldung eigentlich absetzen soll, hat schon verloren.
Abgrenzung: Notfallhandbuch vs. Notfallplan vs. Wiederanlaufplan
Diese Begriffe werden häufig synonym verwendet, beschreiben aber unterschiedliche Dokumente mit unterschiedlichem Fokus.
Das Notfallhandbuch ist das übergeordnete Dokument. Es ist die zentrale Informationsquelle, die alle relevanten Inhalte bündelt oder auf sie verweist. Du kannst es dir als Nachschlagewerk vorstellen, das im Ernstfall aufgeschlagen wird.
Ein Notfallplan beschreibt die Reaktion auf ein konkretes Szenario: Was tun bei Ransomware? Was tun bei Serverraumbrand? Was tun bei einem Datenleck? Notfallpläne sind Teil des Notfallhandbuchs.
Der Wiederanlaufplan beschreibt die systematische Wiederherstellung des Normalbetriebs nach einem Vorfall. Er wird aktiviert, nachdem die Erstreaktion (Notfallplan) abgeschlossen ist. Auch er ist Teil des Notfallhandbuchs oder wird von dort referenziert.
| Dokument | Charakter | Inhalt |
|---|---|---|
| Notfallhandbuch | Übergeordnetes Nachschlagewerk | Alle Kontakte, Pläne, Verfahren, Checklisten |
| Notfallplan | Szenariospezifische Reaktionsanweisung | Sofortmaßnahmen für ein konkretes Szenario |
| Wiederanlaufplan | Operative Wiederherstellungsanleitung | Recovery-Schritte, Reihenfolge, Verantwortliche |
Das Notfallhandbuch enthält also die Notfallpläne und den Wiederanlaufplan - oder verweist strukturiert auf sie. Es ist die Klammer, die alles zusammenhält.
Aufbau des IT-Notfallhandbuchs
Ein gutes Notfallhandbuch folgt einem klaren Aufbau, der sich im Ernstfall schnell navigieren lässt. Die folgenden Abschnitte haben sich in der Praxis bewährt.
1. Deckblatt und Dokumentensteuerung
Das Deckblatt enthält die grundlegenden Metadaten:
- Dokumententitel: "IT-Notfallhandbuch [Unternehmensname]"
- Version und Datum: z. B. "v3.1, Stand: März 2026"
- Verantwortlicher Herausgeber: Name und Funktion
- Vertraulichkeitsstufe: Typischerweise "Vertraulich" oder "Intern"
- Verteilerliste: Wer hat eine Kopie (gedruckt und digital)?
- Nächster Review-Termin: Wann steht die nächste Überprüfung an?
Direkt auf der zweiten Seite gehört eine Änderungshistorie, die jede Änderung mit Datum, Autor und Beschreibung protokolliert. Das ist nicht Bürokratie, sondern überlebenswichtig: Im Ernstfall muss klar sein, ob man die aktuelle Version in der Hand hält. In ISMS Lite wird die Versionierung automatisch mitgeführt, und Änderungen an Kontaktdaten oder Szenarien fließen sofort ins Notfallhandbuch ein.
2. Inhaltsverzeichnis mit Schnellzugriff
Das Inhaltsverzeichnis muss so gestaltet sein, dass jemand unter Stress in Sekunden den richtigen Abschnitt findet. Farbcodierte Reiter oder farbige Seitenränder helfen bei der gedruckten Version. In der digitalen Version sind verlinkte Lesezeichen Pflicht.
Ein bewährter Schnellzugriff auf der ersten Inhaltsseite:
SOFORT-KONTAKTE .......................... Seite 5
ESKALATIONSSTUFEN ....................... Seite 8
MELDEWEGE (BSI / DSGVO) ................ Seite 12
SZENARIO: Ransomware ................... Seite 15
SZENARIO: Serverausfall ................ Seite 22
SZENARIO: Datenverlust ................. Seite 28
WIEDERANLAUFPLAN ........................ Seite 35
3. Sofort-Kontaktliste
Die Kontaktliste ist der meistgenutzte Abschnitt des Handbuchs. Sie muss vollständig und aktuell sein. Eine veraltete Telefonnummer im Ernstfall ist schlimmer als keine, weil sie Zeit kostet und falsches Vertrauen erzeugt.
Interne Kontakte:
| Rolle | Name | Telefon (Mobil) | Erreichbarkeit | |
|---|---|---|---|---|
| IT-Leiter | [Name] | [Nummer] | [Mail] | Mo-Fr 7-18 Uhr, Rufbereitschaft WE |
| Stv. IT-Leiter | [Name] | [Nummer] | [Mail] | Mo-Fr 8-17 Uhr |
| Geschäftsführung | [Name] | [Nummer] | [Mail] | Jederzeit bei Stufe 3 |
| Datenschutzbeauftragter | [Name] | [Nummer] | [Mail] | Mo-Fr 9-17 Uhr |
| Informationssicherheitsbeauftragter | [Name] | [Nummer] | [Mail] | Mo-Fr 8-17 Uhr |
| Betriebsrat (falls vorhanden) | [Name] | [Nummer] | [Mail] | Mo-Fr 8-16 Uhr |
Externe Kontakte:
| Dienst | Anbieter | Hotline | Vertragsnr. | SLA |
|---|---|---|---|---|
| IT-Systemhaus | [Firma] | [Nummer] | [Nr.] | 4h Reaktionszeit |
| Firewall/Security | [Firma] | [Nummer] | [Nr.] | 2h Reaktionszeit |
| Internet-Provider | [Firma] | [Nummer] | [Nr.] | 8h Entstörung |
| Rechenzentrum/Hosting | [Firma] | [Nummer] | [Nr.] | 24/7 |
| Cyber-Versicherung | [Firma] | [Nummer] | [Policen-Nr.] | Schadenmeldung 72h |
| Forensik-Dienstleister | [Firma] | [Nummer] | [Rahmenvertrag] | Auf Abruf |
Behörden:
| Behörde | Kontakt | Wann |
|---|---|---|
| BSI (NIS2-Meldung) | Meldestelle: [URL/Tel.] | Erheblicher Sicherheitsvorfall, innerhalb 24h |
| Landesdatenschutzbehörde | [URL/Tel.] | Datenschutzvorfall mit personenbezogenen Daten, innerhalb 72h |
| Polizei / LKA Cybercrime | 110 / [Direktnummer LKA] | Bei Straftatverdacht |
4. Eskalationsketten
Die Eskalationskette definiert, wer wann informiert wird und wer welche Entscheidungen treffen darf. Ohne klare Eskalation passiert eines von zwei Dingen: Entweder wird die Geschäftsführung bei jedem kleinen Vorfall aus dem Meeting geholt, oder sie erfährt bei einem kritischen Vorfall erst nach 12 Stunden davon.
Dreistufiges Eskalationsmodell:
Stufe 1: Störung (IT-intern lösbar)
- Auslöser: Einzelsystem beeinträchtigt, Workaround möglich, keine Auswirkung auf Kernprozesse
- Beispiele: Drucker ausgefallen, einzelner Arbeitsplatz defekt, Performance-Problem bei nicht-kritischer Anwendung
- Wer wird informiert: IT-Team intern
- Wer entscheidet: IT-Teamleiter / Helpdesk-Lead
- Zeitrahmen für Lösung: Innerhalb der normalen SLA (z. B. 8 Arbeitsstunden)
Stufe 2: Erhebliche Störung (Eskalation an IT-Leitung)
- Auslöser: Mehrere Systeme oder Benutzer betroffen, Kernprozess beeinträchtigt, kein einfacher Workaround
- Beispiele: Mailserver ausgefallen, VPN nicht erreichbar, ERP-Performance stark degradiert
- Wer wird informiert: IT-Leiter, betroffene Abteilungsleiter
- Wer entscheidet: IT-Leiter
- Zeitrahmen für Lösung: Innerhalb 4 Stunden, ggf. externer Dienstleister hinzuziehen
Stufe 3: Notfall / Krise (Eskalation an Geschäftsführung)
- Auslöser: Geschäftskritisches System komplett ausgefallen, Sicherheitsvorfall (Ransomware, Datenleck), physischer Schaden (Brand, Wasser)
- Beispiele: Ransomware-Verschlüsselung, Totalausfall ERP > 2 Stunden, Datenleck mit personenbezogenen Daten, Serverraumbrand
- Wer wird informiert: Geschäftsführung, IT-Leiter, ggf. DSB, ISB, externe Dienstleister, Cyber-Versicherung
- Wer entscheidet: Geschäftsführung (in Abstimmung mit IT-Leitung und ggf. Krisenstab)
- Zeitrahmen: Sofortige Einberufung Krisenstab, Meldepflichten prüfen
5. Meldewege
Die Meldewege beschreiben, wie die Information von der Person, die den Vorfall entdeckt, bis zur richtigen Entscheidungsebene gelangt. Gerade in mittelständischen Unternehmen, wo es keinen 24/7-SOC gibt, ist das entscheidend.
Meldeweg bei einem IT-Sicherheitsvorfall:
Entdecker des Vorfalls
│
▼
IT-Helpdesk / IT-Hotline (Erstaufnahme)
│
├── Stufe 1? → IT-Team bearbeitet
│
▼ Stufe 2 oder 3?
IT-Leiter (Bewertung innerhalb 30 Min.)
│
├── Stufe 2? → IT-Leiter koordiniert Behebung
│
▼ Stufe 3?
Geschäftsführung + Krisenstab (sofortige Information)
│
├── Meldepflicht BSI? → Erstmeldung innerhalb 24h
├── Meldepflicht DSGVO? → Meldung innerhalb 72h
├── Strafanzeige? → Polizei / LKA
└── Cyber-Versicherung? → Schadenmeldung
Wichtig: Der Meldeweg muss auch außerhalb der Geschäftszeiten funktionieren. Wenn der Helpdesk nur bis 17 Uhr besetzt ist, brauchst du eine alternative Erreichbarkeit. Das kann eine Rufbereitschaft sein, eine weitergeleitete Hotline-Nummer oder im Minimum eine Mobilnummer des IT-Leiters, die allen Mitarbeitern bekannt ist.
6. Sofortmaßnahmen-Checkliste
Eine allgemeine Checkliste, die bei jedem IT-Sicherheitsvorfall abgearbeitet wird - unabhängig vom konkreten Szenario:
□ Vorfall dokumentieren: Was wurde wann von wem beobachtet?
□ Betroffene Systeme identifizieren: Welche Systeme sind betroffen oder potenziell gefährdet?
□ Eindämmung: Betroffene Systeme isolieren (Netzwerk trennen, NICHT ausschalten!)
□ Eskalationsstufe bestimmen und entsprechend eskalieren
□ Beweissicherung: Keine Änderungen an betroffenen Systemen vornehmen, Screenshots anfertigen
□ Kommunikation: Betroffene Mitarbeiter informieren (was geht, was nicht, Workarounds)
□ Meldepflichten prüfen: BSI (24h), Datenschutzaufsicht (72h)?
□ Externen Dienstleister kontaktieren (falls nötig)
□ Protokoll führen: Alle Maßnahmen mit Zeitstempel dokumentieren
□ Regelmäßige Lage-Updates an Krisenstab / Geschäftsführung
Der Hinweis "NICHT ausschalten" bei der Eindämmung ist bewusst hervorgehoben. Ein häufiger Reflex bei Ransomware ist, betroffene Systeme sofort herunterzufahren. Das kann aber forensische Spuren vernichten (RAM-Inhalte, laufende Prozesse), die für die spätere Beweissicherung wichtig sind. Netzwerktrennung ist die bessere Erstmaßnahme.
7. Szenariospezifische Reaktionspläne
Der Kern des Notfallhandbuchs: Für die wahrscheinlichsten und folgenschwersten Szenarien gibt es jeweils einen eigenen Reaktionsplan. Welche Szenarien du aufnimmst, hängt von deinem Unternehmen ab. Die folgenden vier decken die häufigsten Fälle im Mittelstand ab.
Szenario 1: Ransomware-Angriff
Beschreibung: Schadsoftware hat Daten verschlüsselt. Lösegeldforderung liegt vor.
Sofortmaßnahmen (erste 60 Minuten):
- Betroffene Systeme sofort vom Netzwerk trennen (Kabel ziehen, WLAN deaktivieren)
- Prüfen, ob sich die Verschlüsselung noch ausbreitet (weitere Systeme betroffen?)
- Nicht mit den Angreifern kommunizieren und kein Lösegeld zahlen (ohne Abstimmung mit GF und ggf. Behörden)
- Alle Passwörter für administrative Konten ändern (von einem sauberen System aus)
- Backup-Integrität prüfen: Sind die Backups erreichbar und nicht ebenfalls verschlüsselt?
- Eskalation Stufe 3 auslösen
Weitere Maßnahmen (Stunden 1-24):
- Forensik-Dienstleister kontaktieren (falls unter Vertrag)
- BSI-Erstmeldung vorbereiten (falls NIS2-pflichtig)
- Cyber-Versicherung informieren
- Ausmaß der Verschlüsselung ermitteln: Welche Systeme, welche Daten?
- Prüfen, ob personenbezogene Daten betroffen sind (DSGVO-Meldepflicht)
- Entscheidung über Restore-Strategie: Aus Backup wiederherstellen oder Entschlüsselungstool verfügbar?
Wiederherstellung: → Verweis auf Wiederanlaufplan, Abschnitt [X]
Szenario 2: Totalausfall Rechenzentrum
Beschreibung: Alle Server im lokalen Rechenzentrum sind nicht erreichbar (Hardware-Defekt, Stromausfall > USV-Laufzeit, physischer Schaden).
Sofortmaßnahmen:
- Ursache klären: Strom? Kühlung? Hardware? Physischer Schaden?
- Bei Brand/Wasser: Gebäude räumen, Feuerwehr verständigen, ERST DANN IT-Maßnahmen
- Prüfen, ob Cloud-Dienste (E-Mail, ggf. Cloud-Backup) noch verfügbar sind
- Mitarbeiter über Ausfall und voraussichtliche Dauer informieren
- Manuelle Workarounds für Kernprozesse aktivieren
- Eskalation Stufe 3
Weitere Maßnahmen:
- Externen IT-Dienstleister hinzuziehen
- Ersatzhardware beschaffen (falls nötig)
- Prüfen, ob Offsite-Backups für Restore verfügbar sind
- Alternative Arbeitsumgebung einrichten (falls Gebäude nicht nutzbar)
Szenario 3: Datenleck / Datenabfluss
Beschreibung: Es gibt Hinweise, dass vertrauliche oder personenbezogene Daten unberechtigt abgeflossen sind.
Sofortmaßnahmen:
- Art und Umfang der betroffenen Daten ermitteln
- Zugangswege identifizieren und schließen (kompromittiertes Konto sperren, Firewall-Regel anpassen)
- Datenschutzbeauftragten informieren
- Prüfen, ob personenbezogene Daten betroffen sind
- Betroffene Daten und Systeme dokumentieren
Meldepflichten:
- DSGVO: Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden, wenn personenbezogene Daten betroffen sind und ein Risiko für die Betroffenen besteht
- NIS2: Erstmeldung an das BSI innerhalb von 24 Stunden, wenn der Vorfall als erheblich eingestuft wird
- Betroffene Personen: Information der betroffenen Personen, wenn ein hohes Risiko für deren Rechte und Freiheiten besteht
Szenario 4: Ausfall Internet-Anbindung
Beschreibung: Die Internet-Verbindung des Unternehmens fällt aus. Cloud-Dienste (E-Mail, Online-Banking, Cloud-Backup) sind nicht erreichbar. VPN für Remote-Mitarbeiter fällt aus.
Sofortmaßnahmen:
- Provider-Störungshotline anrufen und Störung melden
- Prüfen, ob ein Redundanz-Anschluss (zweiter Provider, LTE-Failover) verfügbar ist
- Mitarbeiter informieren: E-Mail nur lokal (Cache), Cloud-Dienste nicht verfügbar
- Prüfen, welche Geschäftsprozesse vom Internet abhängen und Workarounds aktivieren
- Remote-Mitarbeiter informieren: Direkte Arbeit im Büro oder Telefon als Alternative
8. Wiederanlaufplan (Verweis oder integriert)
Das Notfallhandbuch enthält entweder den vollständigen Wiederanlaufplan oder verweist klar auf ihn. Die Variante hängt vom Umfang ab. Wenn der Wiederanlaufplan 15 Seiten hat, kann er integriert werden. Wenn er 50 Seiten hat, ist ein Verweis mit Angabe des Speicherorts sinnvoller.
Bei einem Verweis muss der Speicherort redundant sein: "Wiederanlaufplan IT-Infrastruktur v2.3, Speicherort: SharePoint Online [URL], Gedruckt: Tresor Raum 102, Mobil: Firmenhandy IT-Leiter"
9. Anhänge
Alles, was im Ernstfall gebraucht werden könnte:
- Netzwerkplan: Aktuelle Netzwerktopologie mit IP-Bereichen, VLANs, Firewalls
- Serverübersicht: Alle Server mit Funktion, IP, Standort, Verantwortlichem
- Passwort-Zugang: Nicht die Passwörter selbst, sondern der Zugang zum Passwortmanager (z. B. "KeePass-Datenbank auf USB-Stick im Tresor, Master-Passwort bei GF")
- Lizenzen und Verträge: Wichtige Lizenznummern, Vertragsnummern, SLA-Vereinbarungen
- Formulare: Vorlage für BSI-Erstmeldung, Vorlage für DSGVO-Meldung
- Checkliste Krisenstabssitzung: Tagesordnung und Protokollvorlage
Verfügbarkeit: Gedruckt, digital und per QR-Code
Ein Notfallhandbuch, das nur digital auf dem Fileserver liegt, ist im Ernstfall möglicherweise nicht erreichbar. Genau der Fileserver kann Teil des Ausfalls sein. Deshalb gilt: Mindestens drei unabhängige Verfügbarkeitswege.
Gedruckte Version
Klingt altmodisch, ist aber im Ernstfall Gold wert. Wenn das Netzwerk komplett ausfällt und die Cloud nicht erreichbar ist, greifst du zum Ordner im Tresor.
Anforderungen an die gedruckte Version:
- Farbcodierte Reiter für schnelles Finden
- Laminiertes Deckblatt mit Versionsnummer
- Aufbewahrung an einem definierten, allen Beteiligten bekannten Ort
- Mindestens zwei Exemplare: Eines beim IT-Leiter, eines im Tresor der Geschäftsführung
- Bei jeder Aktualisierung: Alte Version einziehen, neue verteilen
Digitale Version
- Cloud-Speicher: SharePoint, Google Drive oder ein anderer Dienst, der unabhängig von der eigenen Infrastruktur ist
- PDF auf Firmenhandys: Die verantwortlichen Personen (IT-Leiter, Stellvertreter, GF) haben die aktuelle Version auf ihrem Diensthandy
- USB-Stick im Tresor: Verschlüsselter USB-Stick mit dem Handbuch und den wichtigsten Anhängen
QR-Code für schnellen Zugriff
Ein QR-Code an strategischen Stellen - am Serverraum, am Helpdesk, im Büro des IT-Leiters - der direkt zur digitalen Version führt, ist eine einfache und effektive Ergänzung. Der QR-Code verweist auf die Cloud-Version, die jederzeit aktuell ist.
Voraussetzung: Der QR-Code muss auf eine URL verweisen, die auch ohne VPN und ohne interne Infrastruktur erreichbar ist. Ein Link auf den internen Fileserver ist nutzlos.
Praktischer Tipp: Erstelle den QR-Code für eine permanente URL (z. B. eine SharePoint-Seite) und ändere dort nur das verlinkte Dokument, wenn du aktualisierst. So muss der QR-Code nie neu gedruckt werden.
Das Notfallhandbuch aktuell halten
Ein Notfallhandbuch, das nicht gepflegt wird, wird mit jedem Monat wertloser. Neue Mitarbeiter, geänderte Telefonnummern, neue IT-Systeme, abgelaufene Verträge - all das muss ins Handbuch einfließen.
Anlassbezogene Aktualisierung
Das Handbuch wird sofort aktualisiert, wenn:
- Ein Mitarbeiter mit einer Notfallrolle das Unternehmen verlässt oder wechselt
- Sich Telefonnummern oder Erreichbarkeiten ändern
- Neue IT-Systeme eingeführt oder bestehende abgelöst werden
- Sich Verträge mit externen Dienstleistern ändern (neuer Provider, neuer SLA)
- Sich regulatorische Anforderungen ändern (neue Meldepflichten)
- Nach einem realen Vorfall: Lessons Learned fließen in den Plan ein
Regelmäßige Überprüfung
Unabhängig von anlassbezogenen Änderungen sollte das Handbuch mindestens einmal jährlich vollständig überprüft werden. Eine bewährte Methode: Verknüpfe die Überprüfung mit einer Tabletop-Übung. Dabei fällt automatisch auf, ob Informationen veraltet sind.
Checkliste für die jährliche Überprüfung:
□ Alle Kontaktdaten geprüft und aktuell?
□ Eskalationsketten noch korrekt? (Rollen und Personen)
□ Externe Dienstleister und SLAs noch aktuell?
□ Netzwerkplan aktuell?
□ Serverübersicht aktuell?
□ Meldewege und Meldepflichten noch korrekt?
□ Szenarien noch relevant? Neue Szenarien nötig?
□ Wiederanlaufplan noch aktuell?
□ Gedruckte Exemplare verteilt und aktuell?
□ QR-Code funktioniert?
□ Alle Beteiligten wissen, wo das Handbuch liegt?
Versionierung
Jede Änderung bekommt eine neue Versionsnummer und wird in der Änderungshistorie dokumentiert.
Versionierungsschema:
- Minor-Version (v3.1 → v3.2): Aktualisierung von Kontaktdaten, kleinen Details
- Major-Version (v3.2 → v4.0): Neues Szenario, grundlegend geänderte Infrastruktur, neue Eskalationsketten
- Jede Version wird mit Datum und Autor in der Änderungshistorie festgehalten
Vorlage: Inhaltsverzeichnis IT-Notfallhandbuch
Die folgende Vorlage zeigt den empfohlenen Aufbau für ein mittelständisches Unternehmen. Du kannst sie als Gerüst verwenden und an deine Gegebenheiten anpassen.
IT-NOTFALLHANDBUCH [Unternehmensname]
Version [x.x] | Stand: [Datum]
TEIL A: GRUNDLAGEN
A.1 Zweck und Geltungsbereich
A.2 Dokumentensteuerung und Änderungshistorie
A.3 Begriffe und Abkürzungen
A.4 Übersicht der Eskalationsstufen
TEIL B: KONTAKTE UND KOMMUNIKATION
B.1 Sofort-Kontaktliste (intern)
B.2 Externe Dienstleister und Hotlines
B.3 Behörden und Meldestellen
B.4 Eskalationsketten (Stufe 1/2/3)
B.5 Meldewege und Meldefristen
B.6 Kommunikationsplan (intern und extern)
TEIL C: ALLGEMEINE SOFORTMASSNAHMEN
C.1 Checkliste Erstmaßnahmen bei IT-Sicherheitsvorfall
C.2 Beweissicherung
C.3 Dokumentation und Protokollführung
TEIL D: SZENARIEN UND REAKTIONSPLÄNE
D.1 Szenario: Ransomware-Angriff
D.2 Szenario: Totalausfall Rechenzentrum
D.3 Szenario: Datenleck / Datenabfluss
D.4 Szenario: Ausfall Internet-Anbindung
D.5 Szenario: Kompromittiertes Administratorkonto
D.6 Szenario: DDoS-Angriff
[weitere unternehmensspezifische Szenarien]
TEIL E: WIEDERANLAUF
E.1 Wiederanlaufplan IT-Infrastruktur
E.2 Priorisierte Asset-Liste mit RTO/RPO
E.3 Recovery-Schritte pro Asset
TEIL F: ANHÄNGE
F.1 Netzwerkplan
F.2 Serverübersicht (Name, IP, Funktion, Standort)
F.3 Zugang Passwortmanager
F.4 Lizenzen und Vertragsnummern
F.5 Formularvorlagen (BSI-Meldung, DSGVO-Meldung)
F.6 Checkliste Krisenstabssitzung
Häufige Fehler und wie du sie vermeidest
Fehler 1: Zu lang und zu komplex
Ein Notfallhandbuch mit 200 Seiten wird im Ernstfall nicht gelesen. Es muss so kurz wie möglich und so ausführlich wie nötig sein. Nutze Verweise auf Detaildokumente statt alles in ein Dokument zu packen. Der Ransomware-Reaktionsplan braucht 2-3 Seiten, nicht 20.
Fehler 2: Nur Theorie, keine konkreten Handlungsanweisungen
"Im Falle eines Ransomware-Angriffs sind geeignete Maßnahmen zu ergreifen" - das hilft niemandem. Jedes Szenario braucht konkrete Schritte: Wer ruft wen an? Welche Systeme werden zuerst isoliert? Wo finde ich die Backup-Konsole?
Fehler 3: Veraltete Kontaktdaten
Der Klassiker. Herr Meier ist seit sechs Monaten nicht mehr im Unternehmen, steht aber noch als IT-Leiter im Handbuch. Die Hotline des externen Dienstleisters hat sich geändert. Die BSI-Meldestelle hat eine neue URL. Jede einzelne veraltete Information kostet im Ernstfall Zeit.
Fehler 4: Nur digital verfügbar
Wenn das Netzwerk ausfällt, ist das Handbuch auf dem Fileserver nicht erreichbar. Wenn der Cloud-Zugang über SSO läuft und Active Directory nicht funktioniert, kommt niemand an die SharePoint-Version. Physische Kopien und Offline-Zugriff sind Pflicht.
Fehler 5: Niemand weiß, dass es existiert
Das beste Notfallhandbuch bringt nichts, wenn die Mitarbeiter nicht wissen, dass es existiert und wo es liegt. Neue Mitarbeiter in der IT sollten im Onboarding auf das Handbuch hingewiesen werden. Bei Tabletop-Übungen wird es aktiv genutzt. Der Standort der gedruckten Version sollte im Serverraum sichtbar aushängen.
Das Notfallhandbuch in ISMS Lite
In ISMS Lite pflegst du die Grunddaten für das Notfallhandbuch direkt in der Anwendung: Assets, Kontakte, Eskalationsketten, Szenarien und Wiederanlaufpläne. Wenn sich ein Kontakt ändert, aktualisierst du ihn einmal, und alle Dokumente, die diesen Kontakt referenzieren, sind automatisch aktuell.
Der PDF-Export erzeugt ein vollständiges, druckfertiges Notfallhandbuch mit Inhaltsverzeichnis, farbcodierten Abschnitten und allen Anhängen. Du kannst wählen, ob du das gesamte Handbuch oder einzelne Szenarien exportieren möchtest.
Den QR-Code für den Schnellzugriff generiert ISMS Lite ebenfalls. Er verweist auf eine passwortgeschützte Seite, die auch ohne VPN erreichbar ist und immer die aktuelle Version zeigt.
Nächste Schritte
Wenn du noch kein Notfallhandbuch hast, starte mit den wichtigsten Bausteinen:
- Kontaktliste erstellen - das ist der schnellste Gewinn. Selbst wenn du sonst nichts hast: Eine aktuelle Kontaktliste mit allen relevanten Nummern spart im Ernstfall Stunden.
- Eskalationsketten definieren - wer wird wann informiert? Drei Stufen reichen für den Anfang.
- Zwei Szenarien ausarbeiten - Ransomware und Totalausfall Rechenzentrum decken die häufigsten Fälle ab.
- Verfügbarkeit sicherstellen - eine gedruckte Version und ein PDF auf dem Firmenhandy.
- Tabletop-Übung planen - das Handbuch in einer Übung durchspielen zeigt, wo Lücken sind.
Weiterführende Artikel
- Wiederanlaufplan erstellen: Anleitung mit Vorlage für den Mittelstand
- Incident Response Plan erstellen: Vorlage und Praxisbeispiel
- Tabletop-Übung planen und durchführen: So testest du deinen Notfallplan
- Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen
- Business Impact Analyse (BIA) durchführen: Geschäftsprozesse bewerten
Für die BIA als Grundlage empfiehlt sich der Artikel zur Business Impact Analyse, und für den Wiederanlaufplan als operativen Kern findest du eine ausführliche Anleitung im Artikel zum Wiederanlaufplan.
