Im Ernstfall zählt nicht das Wissen Einzelner, sondern ein schriftlicher, erreichbarer und geübter Plan, den alle kennen.

Ein IT-Notfallplan beschreibt Verantwortliche, Sofortmaßnahmen, Kommunikationswege und den geregelten Wiederanlauf. Er muss schriftlich vorliegen, auch bei ausgefallener IT erreichbar sein und regelmäßig geübt werden — sonst hilft er im Ernstfall nicht. Wichtig sind klar definierte Wiederanlaufzeiten (RTO) und ein Notfallkontakt, den jeder im Team kennt.
Im Ernstfall zählt nicht das Wissen einzelner Personen, sondern ein Plan, den alle kennen. Wenn Server verschlüsselt sind, das Telefon stillsteht und mehrere Mitarbeitende gleichzeitig fragen, was nun zu tun ist, hilft kein Bauchgefühl. Genau dann braucht es eine klare, schriftliche Anleitung, an der sich alle orientieren können — denn unter Stress trifft niemand verlässlich gute Entscheidungen.
Ein IT-Notfallplan beschreibt, wer im Notfall welche Aufgabe übernimmt, welche Sofortmaßnahmen gelten, wie kommuniziert wird und wie der geregelte Wiederanlauf abläuft. Er nimmt der Situation die Panik, weil niemand improvisieren muss, sondern einer vorab durchdachten Reihenfolge folgt. Fachlich ist er Teil eines übergeordneten Notfallmanagements, wie es das BSI im IT-Grundschutz (Baustein DER.4 „Notfallmanagement") beschreibt und wie es die NIS2-Richtlinie für betroffene Unternehmen ausdrücklich verlangt.
Damit er funktioniert, muss er drei Bedingungen erfüllen: Er muss schriftlich vorliegen, jederzeit erreichbar sein — auch wenn die IT komplett ausgefallen ist — und regelmäßig geübt werden. Fehlt eine dieser Bedingungen, bleibt der schönste Plan im Ernstfall wirkungslos. Ein Notfallplan, der ausschließlich auf dem verschlüsselten Fileserver liegt, ist der klassische Fehler, der teuer wird.
Zwei Kennzahlen geben jedem Wiederanlauf eine messbare Richtung: RTO und RPO. Die Recovery Time Objective (RTO) legt fest, wie lange ein System maximal ausfallen darf, bevor es geschäftskritisch wird. Die Recovery Point Objective (RPO) bestimmt, wie viel Datenverlust verkraftbar ist — also wie alt das jüngste Backup im Ernstfall höchstens sein darf.
Diese beiden Werte klingen technisch, sind aber eine unternehmerische Entscheidung. Ein Onlineshop, der pro Stunde Stillstand spürbar Umsatz verliert, braucht eine kurze RTO. Ein Archivsystem dagegen darf auch einmal einen Tag warten. Erst wenn diese Vorgaben pro System feststehen, lässt sich beurteilen, ob die vorhandene Backup-Strategie überhaupt ausreicht.
Genau hier verzahnt sich der Notfallplan mit der Datensicherung: Eine RPO von vier Stunden bedeutet, dass mindestens alle vier Stunden eine brauchbare Sicherung entstehen muss. Wie man Backups sauber aufstellt und vor allem getrennt aufbewahrt, vertiefen wir in der 3-2-1-Regel. Ohne realistische RTO- und RPO-Werte bleibt ein Notfallplan eine Sammlung guter Absichten ohne Maßstab.
Der wichtigste Teil eines Notfallplans ist die klare Zuordnung von Rollen. Im Ernstfall darf nicht erst diskutiert werden, wer entscheidet, wer mit Behörden spricht und wer die Geschäftsleitung informiert. Jede dieser Aufgaben braucht eine benannte Person und eine Vertretung, falls diese ausfällt oder im Urlaub ist.
Bewährt hat sich ein kleines Notfallteam mit klaren Zuständigkeiten — oft als Krisenstab bezeichnet. So weiß jede beteiligte Person genau, was sie zu tun hat, und die Abstimmung läuft ohne Reibungsverluste. Auch externe Partner wie der IT-Dienstleister gehören mit festen Ansprechpersonen in diese Struktur. Wer hier auf einen verlässlichen Partner zurückgreifen kann, gewinnt im Ernstfall wertvolle Zeit; bei implec liegt die durchschnittliche Reaktionszeit auf gemeldete Störungen bei 29 Minuten.
Halten Sie zudem die Erreichbarkeiten zentral fest, und zwar nicht nur digital: Wenn die Systeme verschlüsselt sind, hilft eine ausgedruckte Kontaktliste mehr als jeder Eintrag im gesperrten E-Mail-Postfach. Auf diese Liste gehören neben dem internen Team auch der IT-Dienstleister, die Cyber-Versicherung, gegebenenfalls die Datenschutzaufsicht und die Polizei. Diese Liste sollte aktuell gehalten und an einem sicheren, unabhängigen Ort verwahrt werden.
Die ersten Stunden entscheiden über das Ausmaß des Schadens. Eine festgelegte Reihenfolge sorgt dafür, dass nichts Wichtiges vergessen wird und die Beteiligten ruhig und strukturiert vorgehen, statt unter Druck Fehler zu machen. International orientiert sich dieser Ablauf am NIST-Modell der Incident Response: erkennen, eindämmen, beseitigen, wiederherstellen.
Folgende Sofortmaßnahmen gehören in jeden Plan:
Ein wichtiger Hinweis: Bei einer Datenpanne mit Personenbezug verlangt die DSGVO (Art. 33) in der Regel eine Meldung an die Aufsichtsbehörde binnen 72 Stunden. NIS2 sieht für betroffene Unternehmen eine erste Meldung sogar innerhalb von 24 Stunden vor. Wer im Notfall erst nachdenken muss, verliert genau die Zeit, die diese Fristen so knapp macht.
Kommunikation entscheidet im Ernstfall oft mehr über den langfristigen Schaden als die Technik selbst. Wer schweigt oder widersprüchliche Aussagen macht, verliert das Vertrauen von Kunden und Mitarbeitenden — und das wiegt häufig schwerer als der eigentliche Ausfall. Deshalb gehört ein klarer Kommunikationsplan in jeden Notfallplan.
Zu klären ist dabei vor allem: Wer darf nach außen sprechen, und wer auf keinen Fall? Im Notfall braucht es eine einzige, abgestimmte Stimme — nicht ein Dutzend Mitarbeitende, die auf eigene Faust Vermutungen weitergeben. Intern sollten alle wissen, an wen sie Fragen richten und was sie selbst sagen dürfen. Halten Sie zudem vorbereitete Textbausteine für typische Szenarien bereit, damit unter Druck nicht jede Formulierung neu erfunden werden muss.
Wichtig ist auch der rechtliche Rahmen: Sind personenbezogene Daten betroffen, müssen unter Umständen die Betroffenen informiert werden — die DSGVO verlangt das, wenn ein hohes Risiko für deren Rechte besteht. Wer diese Pflicht im Notfallplan mitdenkt, vermeidet zusätzlich zum Vorfall auch noch einen vermeidbaren Regelverstoß. Eine ehrliche, sachliche und zeitnahe Information schützt am Ende den Ruf besser als jeder Beschwichtigungsversuch.
Auf die akute Schadensbegrenzung folgt der Wiederanlauf. Hier zeigt sich, ob die Vorbereitung gestimmt hat: Aus welchen Backups wird wiederhergestellt? In welcher Reihenfolge gehen Systeme zurück ans Netz? Und wie wird sichergestellt, dass die Schadsoftware nicht erneut zuschlägt, etwa über eine übersehene Hintertür?
Der Plan sollte festhalten, welche Anwendungen geschäftskritisch sind und deshalb zuerst laufen müssen — entsprechend den zuvor definierten RTO-Werten. Erst danach folgen weniger dringende Systeme. Wichtig ist, ausschließlich aus geprüft sauberen Sicherungen wiederherzustellen; wer ein infiziertes Backup einspielt, holt sich den Angreifer direkt zurück. So kehrt der Betrieb kontrolliert zurück, statt im Blindflug.
Genauso wichtig ist eine saubere Nachbereitung, im NIST-Modell „Lessons Learned" genannt. Was war die Ursache, welche Lücke wurde genutzt, und was lässt sich künftig besser machen? Aus jedem Vorfall lassen sich Lehren ziehen, die den Notfallplan beim nächsten Mal noch wirksamer machen — und die zeigen, ob etwa zusätzlicher Schutz vor Ransomware nötig ist.
Ein Plan in der Schublade nützt nichts. Erst eine Übung zeigt, ob die Kontaktdaten stimmen, ob die Backups sich tatsächlich zurückspielen lassen und ob alle ihre Rolle kennen. Häufig kommen genau dabei Lücken ans Licht, die im echten Notfall teuer geworden wären — eine veraltete Telefonnummer, ein Backup, das sich nicht entschlüsseln lässt, eine Zuständigkeit, die niemand übernommen hat.
Wir empfehlen, den Plan mindestens einmal jährlich und nach jeder größeren Änderung an Systemen, Personal oder Dienstleistern durchzuspielen. Schon ein durchgesprochenes Szenario am Konferenztisch — eine sogenannte Tabletop-Übung — macht das Team handlungsfähig und nimmt im Ernstfall einen großen Teil der Panik. Wer es genauer wissen will, testet zusätzlich die technische Wiederherstellung an einem isolierten System.
Ein ungeübter Notfallplan ist eine Hoffnung. Erst die Übung macht daraus ein verlässliches Werkzeug.
Gern erstellen und testen wir den Notfallplan gemeinsam mit Ihnen. So entsteht ein Dokument, das nicht nur auf dem Papier überzeugt, sondern im Ernstfall wirklich trägt und Ihren Betrieb in Stunden statt in Wochen wieder zum Laufen bringt. Sprechen Sie uns an — am besten, bevor der Ernstfall eintritt.
FAQ
Kurz und konkret beantwortet.
Mindestens einmal jährlich sowie nach jeder größeren Änderung an Systemen, Personal oder Dienstleistern. Nur ein aktueller Plan mit stimmigen Kontaktdaten und Backups hilft im Ernstfall zuverlässig.
Nein. Das Backup ist ein wichtiger Baustein, aber nur einer von vielen. Der Notfallplan regelt darüber hinaus Zuständigkeiten, Sofortmaßnahmen, Meldefristen und Kommunikation — Dinge, die ein Backup allein nicht abdeckt.
An einem Ort, der auch bei ausgefallener IT erreichbar ist, etwa als Ausdruck und an einem unabhängigen, vom Firmennetz getrennten Speicherort. Ein Plan, der nur im verschlüsselten System liegt, hilft im Ernstfall nicht.
Die RTO (Recovery Time Objective) legt fest, wie lange ein System maximal ausfallen darf. Die RPO (Recovery Point Objective) bestimmt, wie viel Datenverlust verkraftbar ist, also wie aktuell das jüngste Backup sein muss. Beide steuern die Reihenfolge des Wiederanlaufs.
Fragen zu Ihrem Projekt?
Ob IT-Sicherheit oder ein anderes Thema — wir schauen uns Ihre Situation an und sagen Ihnen ehrlich, was sinnvoll ist.
Kontakt aufnehmenKostenlose Erstberatung
Unverbindlich und ohne Fachchinesisch. Wählen Sie den Weg, der Ihnen am liebsten ist.
4,7 ★ GoogleAntwort in unter 4 Stundenpersönlich seit 2002
Rückruf anfordern
Innerhalb von 4 Stunden — kostenlos und unverbindlich.
Wir melden uns innerhalb von 4 Stunden bei Ihnen.