In vielen Unternehmen gilt das Notfallkonzept als Sache der IT-Abteilung oder des IT-Dienstleisters. Die Annahme dahinter klingt plausibel: Wer die Systeme betreut, weiss auch, wie man sie wiederherstellt. Technisch stimmt das oft. Organisatorisch führt es in eine gefährliche Lücke.
Denn ein IT-Ausfall ist kein technisches Ereignis, sondern ein betriebswirtschaftliches. Nicht der Serverausfall kostet Geld, sondern der Auftrag, der nicht ausgeliefert wird, die Lohnzahlung, die nicht ausgelöst werden kann, oder die Kundschaft, die keine Antwort erhält. Wer nur die Technik plant, plant an der eigentlichen Frage vorbei.
Warum die IT die Prioritäten nicht allein festlegen kann
Die IT kennt die Infrastruktur: Server , Schnittstellen, Datensicherungen, Abhängigkeiten zwischen Systemen. Was sie in grösseren Organisationen aber selten vollständig überblickt, sind die realen Abläufe in den Fachbereichen.
Typische blinde Flecken im Notfallkonzept
- ⚠️ Eine als unkritisch eingestufte Applikation blockiert im Ausfall die gesamte Auftragsabwicklung.
- ⚠️ Ein Fachbereich arbeitet mit einer Schnittstelle, die nie offiziell dokumentiert wurde.
- ⚠️ Zwei Abteilungen halten dasselbe System für Priorität eins, und niemand hat entschieden, wer zuerst bedient wird.
- ⚠️ Saisonale Spitzen verändern die Rangfolge, etwa im Jahresabschluss oder vor einem Versandtermin.
Wird die Reihenfolge erst im Ernstfall improvisiert, entstehen Diskussionen genau dann, wenn keine Zeit dafür bleibt. Die Aussage «die IT hat das im Griff» ist deshalb kein Sicherheitsgefühl, sondern eine ungeprüfte Annahme.
Business definiert die Prioritäten, IT stellt sie wieder her
Ein tragfähiger IT-Notfallplan beruht auf einer klaren Arbeitsteilung. Beide Seiten beantworten unterschiedliche Fragen, und erst zusammen ergeben die Antworten ein belastbares Konzept.
Diese Fragen beantwortet die Geschäftsleitung
- Welche Prozesse sind wirklich geschäftskritisch?
- Wie lange darf ein Prozess stillstehen, bevor echter Schaden entsteht?
- Welcher Datenverlust ist im schlimmsten Fall verkraftbar, eine Stunde, ein Tag, eine Woche?
- Wer entscheidet im Ernstfall, und wer informiert Kundschaft, Mitarbeitende und Partner?
Diese Fragen beantwortet die IT
- Welche Systeme und Daten hängen an diesen Prozessen?
- Wie schnell ist die Datenwiederherstellung technisch möglich, und was kostet eine kürzere Frist?
- Welche Abhängigkeiten bestimmen die Reihenfolge der Wiederherstellung?
- Wo klafft heute eine Lücke zwischen Anspruch und Machbarkeit?
RTO und RPO: zwei Begriffe, die das Gespräch präzise machen
Zwei Kennzahlen aus der Business Continuity helfen, unternehmerische Erwartungen in technische Vorgaben zu übersetzen.
Die Wiederanlaufzeit (Recovery Time Objective, RTO) beschreibt, wie lange es dauern darf, bis ein System wieder verfügbar ist. Der tolerierbare Datenverlust (Recovery Point Objective, RPO)beschreibt, wie viel Arbeit im Notfall verloren gehen darf, gemessen am Abstand zwischen zwei Sicherungen.
Beide Werte sind keine technischen Grössen, sondern unternehmerische Entscheide mit einem Preisschild. Eine Wiederherstellung innerhalb von zwei Stunden kostet deutlich mehr als eine innerhalb von zwei Tagen. Ob sich das lohnt, kann nur das Business beurteilen.
IT-Notfallplan erstellen: vier Schritte
Ein Notfallplan entsteht nicht in einem Dokument, sondern in vier aufeinander aufbauenden Schritten.
1. Geschäftsprozesse erfassen
Nicht Systeme auflisten, sondern Abläufe. Was muss das Unternehmen tun können, um handlungsfähig zu bleiben? Diese Sicht liefern die Fachbereiche, nicht die IT.
2. Prioritäten festlegen
Die Geschäftsleitung definiert eine verbindliche Rangfolge und setzt für jeden kritischen Prozess RTO und RPO fest. Nicht alles kann Priorität 1 sein.
3. Technische Machbarkeit prüfen
Die IT gleicht die Vorgaben mit der bestehenden Infrastruktur ab und macht Lücken sichtbar, etwa bei Datensicherung, Ersatzhardware oder Wartungsverträgen. Häufig zeigt sich hier, dass die gewünschte Wiederanlaufzeit mit der heutigen Umgebung gar nicht erreichbar ist. Genau das ist ein wertvolles Ergebnis, solange es vor dem Ernstfall auf dem Tisch liegt.
4. Verantwortlichkeiten und Kommunikation regeln
Wer alarmiert wen, über welchen Kanal, wenn E-Mail und Telefonie ausgefallen sind? Ein IT-Notfallplan, der nur im internen Netzwerk liegt, ist im Ernstfall nicht verfügbar. Er gehört zusätzlich in ausgedruckter oder offline zugänglicher Form hinterlegt.
Ein Notfallplan, der nie getestet wurde, ist nur ein Dokument
Der häufigste Fehler nach der Erstellung ist die Ablage. Notfallpläne veralten schnell: Systeme werden abgelöst, Zuständigkeiten wechseln, Telefonnummern stimmen nicht mehr. Eine jährliche Überprüfung und mindestens eine praktische Übung, etwa die testweise Wiederherstellung eines einzelnen Systems, zeigen innerhalb weniger Stunden, ob der Plan hält. Diese Übung ist deutlich günstiger als die Erkenntnis im Ernstfall.
Sinnvoll ist zudem, die Notfallplanung mit der übrigen IT-Sicherheit zu verbinden. Wer weiss, welche Prozesse kritisch sind, weiss auch, welche Systeme den stärksten Schutz benötigen.
Häufige Fragen zum IT-Notfallplan
Die folgenden Fragen erreichen uns in Gesprächen mit KMU am häufigsten.
Was gehört in einen IT-Notfallplan?
Eine Liste der geschäftskritischen Prozesse mit Prioritäten, die zugehörigen Systeme und Daten, RTO und RPO je Prozess, die Wiederherstellungsschritte, klare Verantwortlichkeiten sowie ein Kommunikationsplan mit Kontaktdaten, der auch ohne funktionierende IT verfügbar ist.
Wie oft muss ein IT-Notfallplan überprüft werden?
Mindestens einmal jährlich, zusätzlich nach jeder wesentlichen Veränderung an Systemen, Prozessen oder Zuständigkeiten. Empfehlenswert ist eine jährliche praktische Übung.
Braucht auch ein KMU einen IT-Notfallplan?
Ja. Kleinere Unternehmen sind bei einem IT-Ausfall oft stärker betroffen, weil es weniger Ausweichmöglichkeiten und selten eine interne Vertretung gibt. Der Plan darf dafür entsprechend schlank ausfallen. Entscheidend ist nicht der Umfang, sondern dass die Prioritäten geklärt und die Wiederherstellung getestet sind.
Was kostet ein IT-Notfallplan?
Die Erstellung selbst verursacht vor allem internen Aufwand für Workshops und Dokumentation. Kosten entstehen dort, wo die gewünschte Wiederanlaufzeit zusätzliche Massnahmen erfordert, etwa Ersatzgeräte, erweiterte Datensicherung oder Wartungsverträge mit garantierten Reaktionszeiten. Deshalb gehört die Priorisierung an den Anfang: Sie bestimmt, wo investiert werden muss und wo nicht.
Fazit: Notfallplanung ist ein Führungsinstrument
Ein IT-Notfallplan ist keine technische Dokumentation. Die IT liefert das Wissen über Systeme, Abhängigkeiten und Wiederherstellungswege. Die Geschäftsleitung liefert die Prioritäten und trägt die Entscheide über Kosten und Risiken. Fehlt eine der beiden Seiten, bleibt der Plan unvollständig. Und das zeigt sich erst dann, wenn es niemandem mehr nützt.
Wie weiter?
Sie wissen nicht genau, wie belastbar Ihre heutige Notfallplanung ist? Wir gehen mit Ihnen Ihre kritischen Prozesse durch, prüfen die technische Machbarkeit und zeigen auf, wo die grössten Lücken liegen. Nehmen Sie mit uns Kontakt auf für ein unverbindliches Erstgespräch.
Wir sind für Sie da!
Für weitere Informationen oder ein unverbindliches, Beratungsgespräch nehmen Sie bitte direkt Kontakt mit uns auf. WIR SIND FÜR SIE DA.
KONTAKTIEREN SIE UNS JETZT
