Inhaltsverzeichnis
- Warum KMU ohne Notfallplan schlechter abschneiden
- IT-Notfallplan vs. BCP vs. DRP: Die Abgrenzung
- Die 4 häufigsten Ausfallszenarien für KMU
- Die 7 Bestandteile eines funktionalen IT-Notfallplans
- NIS2 und Notfallplanung: Was die Richtlinie verlangt
- Praxis-Checkliste: Sofortmaßnahmen bei IT-Ausfall
- Häufige Fehler bei IT-Notfallplänen
Warum KMU ohne Notfallplan schlechter abschneiden
Stellen Sie sich folgende Situation vor: Ein Montagmorgen, 8:15 Uhr. Der erste Mitarbeiter versucht sich anzumelden — nichts geht. Der Server reagiert nicht, das ERP-System ist nicht erreichbar, E-Mails kommen nicht durch. Keine Ahnung, was passiert ist. Niemand weiß, wen man zuerst anrufen soll. Der IT-Dienstleister ist nicht zu erreichen. Die Geschäftsführung ist im Außentermin. Nach drei Stunden stellt jemand fest, dass das RAID im Serverraum ausgefallen ist — aber die Zugangsdaten zum NAS liegen auf einem Zettel, den niemand mehr findet.
Dieses Szenario ist kein Worst Case aus dem Lehrbuch. Es ist die täglich erlebte Realität in kleinen und mittleren Unternehmen, die nie die Zeit gefunden haben, einen IT-Notfallplan zu erstellen. Und die Zahlen sprechen eine deutliche Sprache: Laut einer Studie des Digitalverbands Bitkom entstanden deutschen Unternehmen in den vergangenen Jahren IT-Ausfallschäden in Milliardenhöhe — ein erheblicher Teil davon bei Betrieben mit weniger als 250 Mitarbeitern.
Unternehmen mit einem dokumentierten und regelmäßig getesteten IT-Notfallplan kommen im Schnitt deutlich schneller aus einer Krise heraus. Sie haben kürzere Wiederherstellungszeiten, weniger Datenverluste und verursachen weniger Folgekosten. Der Notfallplan ist dabei keine technische Spielerei für IT-Abteilungen — er ist ein unternehmerisches Steuerungsinstrument.
Und seit Oktober 2024 gilt: Mit dem deutschen NIS2-Umsetzungsgesetz ist Business-Continuity-Planung inklusive IT-Notfallplänen für regulierte Unternehmen keine freiwillige Best Practice mehr, sondern gesetzliche Pflicht. Für alle anderen KMU gilt: Wer in regulierten Lieferketten tätig ist, wird über kurz oder lang von seinen Kunden nach entsprechenden Dokumenten gefragt.
IT-Notfallplan vs. Business Continuity Plan vs. Disaster Recovery Plan: Die Abgrenzung
Bevor wir in den Aufbau einsteigen, müssen wir drei Begriffe voneinander abgrenzen, die häufig synonym verwendet werden, aber unterschiedliche Ebenen abdecken:
Der IT-Notfallplan (auch: IT Emergency Plan) ist das operative Dokument für die ersten Stunden nach einem Ausfall. Er beantwortet die Fragen: Wer wird sofort informiert? Was wird abgeschaltet oder isoliert? Welche Sofortmaßnahmen greifen? Er ist für Nicht-Techniker lesbar und muss auch dann funktionieren, wenn der Hauptverantwortliche nicht erreichbar ist.
Der Business Continuity Plan (BCP) ist auf einer strategischeren Ebene angesiedelt. Er beschreibt, wie das Unternehmen seinen Betrieb auch bei einem längeren IT-Ausfall aufrechterhalten kann — mit manuellen Prozessen, Ausweichstandorten, reduzierten Serviceangeboten oder alternativen Kommunikationswegen. Der BCP denkt in Szenarien, die Tage oder Wochen dauern können.
Der Disaster Recovery Plan (DRP) ist technisch ausgerichtet und beschreibt die systematische Wiederherstellung der IT-Infrastruktur nach einem Katastrophenereignis. Er enthält konkrete Reihenfolgen für Systemrestores, Backup-Rücksicherungen, Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO).
Alle drei Dokumente sind sinnvoll und ergänzen sich gegenseitig. Für KMU, die noch am Anfang stehen, empfiehlt sich ein pragmatischer Ansatz: Beginnen Sie mit einem kombinierten IT-Notfallplan, der die wichtigsten Elemente aller drei Dimensionen in einem lesbaren Dokument vereint — und bauen Sie darauf auf.
Die 4 häufigsten Ausfallszenarien für KMU
Ein guter IT-Notfallplan wird nicht für alle denkbaren Katastrophen geschrieben. Er fokussiert sich auf die wahrscheinlichsten Szenarien. Für KMU sind das erfahrungsgemäß vier Klassen von Vorfällen:
Ransomware und Cyberangriff
Ransomware ist das IT-Schreckgespenst unserer Zeit — und das aus gutem Grund. Angreifer verschlüsseln Daten und Systeme und verlangen Lösegeld für die Freigabe. KMU sind dabei besonders gefährdet, weil sie weniger Ressourcen für Prävention haben als Großunternehmen, aber genauso wertvolle Daten besitzen.
Die typische Angriffskette: Ein Mitarbeiter öffnet einen präparierten E-Mail-Anhang. Die Schadsoftware breitet sich still über das Netzwerk aus. Stunden oder Tage später werden alle erreichbaren Laufwerke verschlüsselt — inklusive der Backups, sofern diese dauerhaft verbunden waren.
Was ein Notfallplan für dieses Szenario leisten muss: klare Anweisung zur sofortigen Netzwerktrennung betroffener Systeme, Liste der Eskalationskontakte (IT-Dienstleister, BSI-Meldestelle, ggf. Cyber-Versicherer), Anleitung zur forensischen Sicherung vor Wiederherstellung, Backup-Rücksicherung aus offline-gespeicherter Kopie.
Hardware-Ausfall (Server, NAS, Festplatte)
Hardware stirbt — und meistens zu einem ungünstigen Zeitpunkt. Ein Festplattenausfall im RAID-Verbund, ein defektes Netzteil im Server, ein überhitzter Switch: Solche Vorfälle sind alltäglich und für sich genommen lösbar, wenn die Reaktion stimmt.
Problematisch wird es, wenn keine aktuelle Systemdokumentation existiert, die Garantie des Geräts abgelaufen ist und niemand weiß, wo der Liefervertrag liegt, oder wenn das letzte Backup drei Wochen alt ist. Ein Notfallplan verhindert, dass ein behebbares technisches Problem zur Unternehmenskrise eskaliert.
Konkret gehört dazu: Hardwareinventarliste mit Seriennummern, Gewährleistungsstatus und Lieferantenkontakten; Backup-Status und Zeitpunkt der letzten erfolgreichen Sicherung; Eskalationspfad zum Hardware-Support-Anbieter; Anforderungen an Ersatzhardware (Spezifikationen, Bezugsquellen).
Internet- und Stromausfall
Nicht jeder IT-Ausfall ist technisch komplex. Manchmal fällt der Internetanschluss aus — und damit ist das gesamte cloudbasierte Arbeiten lahmgelegt: VoIP-Telefonie, cloudbasiertes ERP, SaaS-Applikationen, Remote-Zugriffe. Oder es fällt der Strom aus und zieht gleich mehrere Systeme mit.
Ein Notfallplan muss für dieses Szenario klären: Gibt es einen mobilen Backup-Internetzugang (LTE-Router)? Können kritische Anwendungen auch ohne Internetverbindung genutzt werden? Sind USV-Anlagen vorhanden, die im Stromausfall den geordneten Shutdown ermöglichen? Welche Arbeitsprozesse können manuell oder analog weitergeführt werden?
Ausfall eines kritischen Lieferanten oder SaaS-Dienstleisters
In den vergangenen Jahren hat die Abhängigkeit von externen Cloud-Diensten massiv zugenommen. Wenn der Anbieter Ihrer Buchhaltungssoftware, Ihres CRM oder Ihrer Telefonanlage eine Störung meldet — oder schlimmer: insolvent geht — kann das Ihr gesamtes Tagesgeschäft lahmlegen.
Ein Notfallplan adressiert dieses Szenario mit: einer Übersicht aller genutzten SaaS-Dienste und ihrer Kritikalität, alternativen Prozessen oder Anbietern für die kritischsten Systeme, klaren Regelungen für den Datenzugriff und Export bei Anbieter-Ausfall sowie einem Monitoring der Anbieter-Statusseiten.
Die 7 Bestandteile eines funktionalen IT-Notfallplans
Ein IT-Notfallplan ist nur so gut wie seine Nutzbarkeit im Ernstfall. Das Dokument muss auch von Personen bedienbar sein, die keinen tiefen IT-Hintergrund haben — und es muss schnell auffindbar sein, wenn der Druck groß ist. Die folgenden sieben Bestandteile bilden den Kern eines praxistauglichen Plans:
1. Notfallkontaktliste: Wer ruft wen an, wann?
Die Notfallkontaktliste ist das erste, was jemand aufschlägt, wenn etwas schiefläuft. Sie muss auf Papier vorhanden sein — denn wenn der Server ausgefallen ist, sind digitale Dokumente auf dem Netzlaufwerk häufig nicht erreichbar.
Die Liste enthält: Name und Funktion aller Personen, die im Notfall entscheiden oder handeln müssen; direkte Mobilnummern (keine Durchwahlen, die über das interne Telefonsystem laufen); externe IT-Dienstleister mit Notfall-Rufnummer und SLA-Eskalationspfad; Kontakte beim Internet-Provider (Kundenservice, technischer Notfalldienst); Hersteller-Supportnummern für kritische Hardware und Software; bei NIS2-Pflicht: BSI-Meldestelle und zuständige Behörde.
Wichtig: Die Liste muss definieren, in welcher Reihenfolge und bei welchem Auslöser wer kontaktiert wird. "IT-Dienstleister anrufen" ist keine ausreichende Anweisung. "Bei vollständigem Serverausfall: zuerst Max Mustermann (0151 / 123 45 67) anrufen, bei Nichterreichen innerhalb 15 Minuten: Notfall-Ticket unter [URL] öffnen und gleichzeitig die Geschäftsleitung informieren" — das ist ein Notfallplan.
2. Systemübersicht und Kritikalitätsbewertung
Dieser Abschnitt schafft Klarheit darüber, welche IT-Systeme existieren und wie kritisch sie für den Betrieb sind. Viele Unternehmen haben keine aktuelle Dokumentation ihrer eigenen IT-Landschaft — das rächt sich im Notfall.
Die Systemübersicht enthält: alle Server (physisch und virtuell) mit Hostname, IP-Adresse, Betriebssystem, installierten Anwendungen und zugeordnetem Backup-Konzept; alle genutzten SaaS-Dienste und Cloud-Plattformen mit Kontodaten-Verweise (sicher aufbewahrt); Netzwerkgeräte (Switches, Router, Firewalls) mit Zugangsweg; und eine Kritikalitätsbewertung nach einem einfachen Schema: Kritisch (Ausfall stoppt den Betrieb sofort), Wichtig (Ausfall verursacht erhebliche Einschränkungen), Unkritisch (Ausfall wird toleriert).
Die Kritikalitätsbewertung ist entscheidend für die Priorisierung der Wiederherstellung. Nicht jedes System muss gleichzeitig wieder laufen — aber das ERP, die Telefonanlage oder der E-Mail-Server haben in der Regel höchste Priorität.
3. Eskalationsstufen und Entscheidungsbäume
Nicht jeder IT-Vorfall rechtfertigt denselben Aufwand. Ein Eskalationsmodell definiert, ab welcher Schwere welche Maßnahmen und welche Personen einzuschalten sind. Ein bewährtes Drei-Stufen-Modell für KMU sieht so aus:
Stufe 1 — Lokales Problem: Ein einzelner Arbeitsplatz oder eine einzelne Anwendung ist betroffen. Verantwortlich: IT-Verantwortlicher intern oder IT-Dienstleister im Tagesgeschäft. Reaktionszeit: innerhalb von zwei Stunden.
Stufe 2 — Bereichsstörung: Mehrere Arbeitsplätze, ein Server oder eine kritische Anwendung ist betroffen. Kommunikation: IT-Verantwortlicher informiert die Abteilungsleitung. Reaktionszeit: sofort, IT-Dienstleister mit Notfall-SLA einschalten.
Stufe 3 — Kritischer Ausfall: Großteil der IT-Infrastruktur ist betroffen oder geschäftskritische Systeme sind ausgefallen. Kommunikation: Geschäftsführung, IT-Dienstleister, ggf. externe Forensiker, Rechtsanwalt (bei Ransomware/Datenschutzverletzung), Kunden und Behörden. Reaktionszeit: sofort.
Entscheidungsbäume helfen dabei, im Stress die richtige Eskalationsstufe zu wählen. Ein einfaches Flussdiagramm — "Sind mehrere Systeme betroffen? Ja: Stufe 2. Ist die gesamte IT ausgefallen? Ja: Stufe 3." — ist besser als kein Entscheidungsrahmen.
4. Backup-Wiederherstellungsprozedur mit konkreten Schritten
Backups sind nur so gut wie ihre Wiederherstellbarkeit. Ein Backup, das nie getestet wurde, ist ein theoretisches Backup. Der Notfallplan muss die Wiederherstellungsprozedur Schritt für Schritt dokumentieren — so konkret, dass ein technisch versierter Mitarbeiter sie ohne zusätzliche Nachfragen durchführen kann.
Die Mindestinhalte: Wo liegen die Backups (lokal, NAS, Cloud, Offsite)? Wie wird auf das Backup-System zugegriffen (Zugangsdaten sicher aufbewahrt, Offline-Kopie der Credentials)? Welche Software wird für die Rücksicherung verwendet? In welcher Reihenfolge werden Systeme wiederhergestellt (priorisierte Liste aus der Systemübersicht)? Was ist die erwartete Recovery Time Objective (RTO) — wie lange dauert die vollständige Wiederherstellung?
Ein konkretes Beispiel für einen Schritt: "Schritt 3: Server-VM aus Backup rücksichern. Anmeldung an Backup-Konsole unter [interne IP/URL]. Backup-Job [Jobname] auswählen, letzten erfolgreichen Restore-Punkt wählen (Datum prüfen!), Rücksicherung in Test-VM starten, Funktionstest: Anmeldung mit [Testaccount], ERP-Start prüfen. Danach: Produktions-VM ersetzen."
Wichtig: Die 3-2-1-Regel ist Pflicht. Mindestens drei Kopien der Daten, auf mindestens zwei verschiedenen Medientypen, davon mindestens eine Kopie außerhalb des Unternehmensstandorts oder in einer airgapped Cloud.
5. Kommunikationsplan: intern, extern, behördlich
Im IT-Notfall muss kommuniziert werden — und zwar strukturiert, nicht in Panik. Ein Kommunikationsplan regelt, wer mit wem spricht, wann und mit welcher Botschaft.
Intern: Wie werden Mitarbeiter über den Ausfall informiert? (SMS, Messenger-Gruppe, Aushang — nicht E-Mail, wenn das Mailsystem ausgefallen ist.) Wer darf nach außen kommunizieren? Oft sinnvoll: eine einzige benannte Pressesprecherin oder ein Sprecher.
Extern — Kunden und Lieferanten: Ab welchem Ausmaß werden Kunden aktiv informiert? Mit welcher Formulierung? Ein vorbereitetes Textbaustein-Dokument spart im Stress wertvolle Zeit. Beispiel: "Aufgrund einer technischen Störung kommt es derzeit zu Verzögerungen in unserer Auftragsbearbeitung. Wir arbeiten mit Hochdruck an der Behebung und melden uns spätestens bis [Uhrzeit/Datum] mit einem Update."
Behördlich: Bei einem datenschutzrelevanten Vorfall (Datenverlust, unbefugter Zugriff auf personenbezogene Daten) gilt eine DSGVO-Meldepflicht von 72 Stunden an die zuständige Datenschutzaufsichtsbehörde. Bei NIS2-relevanten Vorfällen zusätzlich: Erstmeldung an das BSI innerhalb 24 Stunden. Der Notfallplan muss die entsprechenden Meldestellen und -formulare verlinken oder beilegen.
6. Rückkehr zum Normalbetrieb
Oft wird die Rückkehr zum Normalbetrieb als selbstverständlich betrachtet — dabei ist sie ein kritischer und fehleranfälliger Schritt. Systeme, die nach einem Vorfall wieder hochgefahren werden, müssen vor der produktiven Nutzung validiert sein.
Checkliste für die Rückkehr: Sind alle kritischen Systeme wiederhergestellt und getestet? Wurden temporäre Maßnahmen (isolierte Netzwerksegmente, abgeschaltete Dienste) rückgängig gemacht? Haben alle betroffenen Mitarbeiter wieder Zugriff auf ihre Systeme? Sind Sicherheitslücken, die den Vorfall ausgelöst oder ermöglicht haben, geschlossen? Wurden Betroffene (Kunden, Behörden) über die Wiederherstellung informiert?
Dieser Abschnitt muss auch Kriterien definieren, nach denen entschieden wird, ob ein System wirklich wieder produktionsreif ist. Ein Server, der nach einer Ransomware-Infektion aus dem Backup wiederhergestellt wurde, muss vor der Rückkehr ins Netz forensisch untersucht werden — sonst droht die Reinfektion.
7. Nachbereitung und Lessons Learned
Der letzte Schritt eines jeden Notfalls ist der wichtigste für die Zukunft: die strukturierte Nachbereitung. Was genau ist passiert? Was hat im Notfallprozess gut funktioniert, was nicht? Welche Maßnahmen werden als Konsequenz ergriffen?
Ein Post-Incident-Meeting innerhalb von maximal einer Woche nach dem Vorfall ist Best Practice. Ergebnis ist ein kurzes Protokoll mit: Zeitstrahl des Vorfalls (wann was passiert ist), Bewertung der Reaktionszeiten und Kommunikation, konkreten Maßnahmen mit Verantwortlichen und Fristen sowie einem Update des Notfallplans.
Ohne diesen Schritt ist der Notfallplan statisch. Mit diesem Schritt wird er zu einem lebenden Dokument, das nach jedem Vorfall und nach jeder Übung besser wird.
NIS2 und Notfallplanung: Was die Richtlinie konkret verlangt
Die NIS2-Richtlinie (Network and Information Security Directive 2) wurde im Oktober 2022 auf EU-Ebene verabschiedet und in Deutschland mit dem NIS2-Umsetzungsgesetz (NIS2UmsuCG) im Oktober 2024 in nationales Recht überführt. Was bedeutet das konkret für Notfallplanung?
Für direkt betroffene Einrichtungen (ab 50 Mitarbeitern oder 10 Mio. € Umsatz in regulierten Sektoren wie Energie, Gesundheit, Transport, IT/TK, Wasserversorgung, öffentliche Verwaltung) schreibt NIS2 explizit vor:
- Business Continuity Management (BCM): Einrichtungen müssen Konzepte für die Aufrechterhaltung des Betriebs bei erheblichen Störungen entwickeln und pflegen — dazu gehören Notfallpläne, Backup-Konzepte und Wiederanlaufpläne.
- Incident-Response-Prozesse: Dokumentierte Prozesse für die Erkennung, Analyse und Reaktion auf Sicherheitsvorfälle sind Pflicht — inklusive der Festlegung von Verantwortlichkeiten und Eskalationspfaden.
- Meldepflichten: Erhebliche Vorfälle müssen dem BSI gemeldet werden: Erstmeldung innerhalb von 24 Stunden, detaillierter Zwischenbericht innerhalb von 72 Stunden, abschließende Meldung nach einem Monat.
- Lieferkettenmanagement: NIS2-pflichtige Unternehmen müssen die Sicherheitsstandards ihrer Lieferanten und Dienstleister bewerten — was wiederum Druck auf KMU als Zulieferer ausübt, eigene Notfallpläne nachzuweisen.
- Geschäftsführerhaftung: Die Umsetzung dieser Maßnahmen liegt in der persönlichen Verantwortung der Geschäftsführung. Bußgelder bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes sind möglich — und Unwissenheit schützt nicht vor Haftung.
Auch wenn Ihr KMU nicht direkt NIS2-pflichtig ist: Die Richtlinie setzt de facto einen neuen Standard für IT-Sicherheit in Deutschland. Unternehmen, die heute einen funktionalen IT-Notfallplan aufbauen, sind nicht nur auf Kundenanfragen vorbereitet — sie sind auch deutlich widerstandsfähiger gegenüber echten Vorfällen.
Praxis-Checkliste: Sofortmaßnahmen bei IT-Ausfall
Diese Checkliste ist zum Ausdrucken und Aufhängen gedacht — im Serverraum, in der Teeküche, beim Empfang. Sie muss auch dann nutzbar sein, wenn das IT-System nicht verfügbar ist.
- Ruhe bewahren. Nicht vorschnell handeln oder Systeme ausschalten, bevor Ursache geklärt ist.
- Vorfall dokumentieren: Uhrzeit, betroffene Systeme, Fehlermeldungen, wer was bemerkt hat — auf Papier.
- Sofort IT-Verantwortlichen informieren (Kontaktliste, Seite __). Bei Nichterreichbarkeit: Eskalation zu Geschäftsführung.
- Bei Verdacht auf Cyberangriff oder Ransomware: betroffene Systeme sofort vom Netzwerk trennen (Netzwerkkabel ziehen oder WLAN deaktivieren), NICHT ausschalten.
- Externe IT-Dienstleister kontaktieren (Notfallnummer, Seite __). Symptome schildern, Schadensbild beschreiben.
- Kritikalität bestimmen: Sind geschäftskritische Systeme betroffen? Eskalationsstufe festlegen (Seite __).
- Bei Datenverlust oder Datenschutzverletzung: Rechtsberater und Datenschutzbeauftragten informieren. DSGVO-72-Stunden-Frist beginnt zu laufen.
- Bei NIS2-Pflicht: BSI-Erstmeldung innerhalb von 24 Stunden vorbereiten und absenden.
- Mitarbeiter informieren (SMS/Messenger, da E-Mail ggf. ausgefallen): Kurze Statusmeldung, kein Aktionismus.
- Backup-Status prüfen: Wann war letztes erfolgreiches Backup? Zugang zu Backup-System sicherstellen.
- Technische Wiederherstellung nach Plan starten (Seite __). Prioritäten: [kritische Systeme eintragen].
- Kunden informieren, wenn Lieferverzögerungen oder Serviceausfälle entstehen (Textbaustein, Seite __).
- Nach Wiederherstellung: Post-Incident-Meeting ansetzen, Notfallplan aktualisieren.
Häufige Fehler bei IT-Notfallplänen
Viele KMU haben einen IT-Notfallplan — aber keinen, der im Ernstfall hilft. Die häufigsten Fehler aus unserer Beratungspraxis:
Den Plan nie testen. Das ist der häufigste und folgenschwerste Fehler. Ein Notfallplan, der nie in der Praxis erprobt wurde, enthält mit hoher Wahrscheinlichkeit Lücken: veraltete Kontaktdaten, falsche Zugangsdaten zum Backup-System, fehlende Berechtigungen für Ersatzpersonen. Eine jährliche Tabletop-Übung kostet zwei Stunden und kann im Ernstfall Tage ersparen.
Zu komplex und zu lang. Ein 80-seitiges Dokument, das im Stressfall von Seite 1 bis 80 gelesen werden muss, ist kein Notfallplan. Er ist ein Ablagesystem. Ein funktionaler Notfallplan ist modular aufgebaut: eine Kurzversion mit den wichtigsten Sofortmaßnahmen (2–3 Seiten, immer griffbereit), detaillierte Anhänge für Technikverantwortliche. Was nicht in 30 Sekunden auffindbar ist, wird im Notfall nicht benutzt.
Falsche oder fehlende Ansprechpartner. Die Notfallkontaktliste muss mindestens jährlich aktualisiert werden. Mitarbeiterwechsel, neue Dienstleister, geänderte Mobilnummern — wenn die Liste veraltet ist, greift der erste und wichtigste Schritt ins Leere. Tipp: Verknüpfen Sie die Aktualisierung der Kontaktliste mit dem Mitarbeiter-Onboarding- und -Offboarding-Prozess.
Backup ohne Wiederherstellungstest. "Wir haben ein Backup" ist keine Aussage über Wiederherstellbarkeit. Backups können fehlerhaft, unvollständig oder mit dem falschen Schlüssel verschlüsselt sein. Ohne regelmäßigen Restore-Test — mindestens quartalsweise — ist ein Backup eine theoretische Sicherheitsnetz, kein echtes.
Notfallplan liegt nur digital auf dem Server. Wenn der Server ausgefallen ist und der Notfallplan nur dort liegt: Das Dokument ist im Moment des Falles nicht erreichbar. Ausgedruckte Exemplare im Serverraum, beim Geschäftsführer, beim IT-Verantwortlichen und beim externen Dienstleister sind Pflicht. Zusätzlich: Ablage in einer Cloud, die unabhängig von der internen IT-Infrastruktur ist.
Kein definierter Eigentümer für den Plan. "Der Plan gehört der IT" klingt logisch, führt aber in der Praxis dazu, dass niemand sich wirklich verantwortlich fühlt. Der Notfallplan braucht einen benannten Verantwortlichen mit der expliziten Aufgabe, ihn aktuell zu halten, Tests zu koordinieren und Aktualisierungen nach Vorfällen einzupflegen.
