PlanB
Ratgeber Stand: 11.06.2026

IT-Notfallplan erstellen: Aufbau, Inhalte und typische Fehler

Wenn die IT steht, zählt jede Minute – und jeder dokumentierte Schritt.

Der IT-Notfallplan ist das Herzstück der technischen Notfallvorsorge: Er legt fest, in welcher Reihenfolge Systeme wiederanlaufen, wer welche Zugänge braucht und wie der Betrieb überbrückt wird. Dieser Ratgeber zeigt Aufbau, Pflichtinhalte und die Fehler, die im Ernstfall am teuersten sind.

Was ist ein IT-Notfallplan?

Der IT-Notfallplan beschreibt, wie ein Unternehmen auf den Ausfall seiner IT reagiert: vom einzelnen Serverausfall über den Verschlüsselungstrojaner bis zum kompletten Rechenzentrumsausfall. Er ist der technische Kern des Notfallhandbuchs – während das Handbuch die gesamte Organisation abdeckt, fokussiert der IT-Notfallplan auf Systeme, Daten und deren Wiederherstellung.

Ein guter IT-Notfallplan beantwortet für jedes kritische System drei Fragen: Wie schnell muss es wieder laufen? Wie viel Datenverlust ist verkraftbar? Und wie genau läuft der Wiederanlauf ab – Schritt für Schritt, mit benannten Verantwortlichen und dokumentierten Zugängen.

RTO und RPO: die zwei wichtigsten Kennzahlen

Zwei Kennzahlen strukturieren jeden IT-Notfallplan: Die Recovery Time Objective (RTO) gibt an, wie lange ein System maximal ausfallen darf, bevor der Schaden untragbar wird. Die Recovery Point Objective (RPO) beschreibt, wie viel Datenverlust akzeptabel ist – sie bestimmt direkt die nötige Backup-Frequenz.

Beide Werte werden pro System mit den Fachbereichen festgelegt, nicht von der IT allein: Ob die Warenwirtschaft vier Stunden oder zwei Tage stehen darf, ist eine Geschäftsentscheidung. Aus RTO und RPO ergibt sich die Wiederanlauf-Reihenfolge – und damit das Rückgrat des Plans.

Diese Inhalte gehören in den IT-Notfallplan

Bewährt hat sich pro kritischem System ein eigener Steckbrief mit folgenden Punkten:

  • Systembeschreibung und Priorität: Was leistet das System, welche Prozesse hängen daran, welche RTO/RPO gelten?
  • Abhängigkeiten: Welche anderen Systeme, Netzwerkkomponenten oder Dienstleister müssen vorher laufen?
  • Wiederanlaufschritte: Die konkrete Reihenfolge der Wiederherstellung – so beschrieben, dass auch die Vertretung sie ausführen kann.
  • Zugänge und Lizenzen: Wo liegen Admin-Zugänge, Wiederherstellungsschlüssel und Lizenznachweise – auch offline verfügbar, falls der Passwortmanager selbst betroffen ist?
  • Ausweichverfahren: Wie wird der Geschäftsbetrieb überbrückt, solange das System steht – Papierprozess, Ersatzsystem, manueller Workaround?
  • Dienstleister und Eskalation: Wer unterstützt beim Wiederanlauf, mit welchen Reaktionszeiten laut Vertrag, und wer eskaliert wann?

In vier Schritten zum IT-Notfallplan

Der Weg zum belastbaren IT-Notfallplan folgt einer klaren Logik:

  • 1. Systeme inventarisieren: Alle Systeme erfassen und mit den Fachbereichen nach Geschäftskritikalität priorisieren.
  • 2. RTO und RPO festlegen: Pro System klären, wie lange Ausfall und wie viel Datenverlust tragbar sind – daraus folgt die Wiederanlauf-Reihenfolge.
  • 3. Wiederanlauf dokumentieren: Für die kritischen Systeme Schritt-für-Schritt-Pläne mit Zugängen, Abhängigkeiten und Ausweichverfahren schreiben.
  • 4. Testen und aktualisieren: Wiederanlaufpläne regelmäßig durchspielen – ein Backup, das nie testweise zurückgespielt wurde, ist nur eine Hoffnung.

Die teuersten Fehler in der Praxis

Drei Fehler tauchen in fast jeder Nachbetrachtung auf: Der Plan liegt ausschließlich digital auf Systemen, die im Ernstfall selbst betroffen sind. Die Wiederanlauf-Reihenfolge ignoriert Abhängigkeiten – das ERP startet nicht ohne Datenbank, die Datenbank nicht ohne Storage. Und der Plan kennt nur den Normalfall einer verfügbaren IT-Mannschaft, aber keine Vertretungsregelung für Urlaub und Krankheit.

Dazu kommt der Klassiker: Der Plan wurde einmal geschrieben und nie aktualisiert. Neue Systeme fehlen, alte Dienstleisterkontakte stimmen nicht mehr. Ein digitales Notfallhandbuch mit Erinnerungen an fällige Reviews und einem Aktivitätsprotokoll über jede Änderung beugt genau dem vor.

Verzahnung mit Notfallhandbuch und BCM

Der IT-Notfallplan steht nicht allein: Er ist Teil des Notfallhandbuchs, das zusätzlich Rollen, Krisenkommunikation und organisatorische Szenarien regelt, und er liefert die technische Grundlage für das Business Continuity Management nach BSI-Standard 200-4. Wer den IT-Notfallplan in dieser Struktur pflegt, erfüllt zugleich zentrale Anforderungen aus NIS2 an Backup-Management, Wiederherstellung und Krisenbewältigung.

Häufige Fragen

Was ist der Unterschied zwischen IT-Notfallplan und Notfallhandbuch?

Der IT-Notfallplan ist der technische Teil: Systeme, Wiederanlauf, Zugänge, Backups. Das Notfallhandbuch umfasst zusätzlich die organisatorische Seite – Krisenstab, Kommunikation, Meldepflichten und Szenarien jenseits der IT. Der IT-Notfallplan ist also ein Kapitel des Notfallhandbuchs.

Was bedeuten RTO und RPO?

RTO (Recovery Time Objective) ist die maximal tolerierbare Ausfallzeit eines Systems. RPO (Recovery Point Objective) ist der maximal tolerierbare Datenverlust, gemessen als Zeitspanne seit der letzten Sicherung. Beide Werte bestimmen Wiederanlauf-Reihenfolge und Backup-Strategie.

Wo sollte der IT-Notfallplan aufbewahrt werden?

Immer mehrfach: im digitalen Notfallhandbuch für die tägliche Pflege, als aktueller PDF-Export an einem von der eigenen IT unabhängigen Ort und in Kurzform als Notfallkarte für die wichtigsten Erreichbarkeiten und ersten Schritte.

Wie oft muss der Wiederanlauf getestet werden?

Kritische Systeme mindestens einmal jährlich, idealerweise als realistische Wiederherstellungsübung inklusive Backup-Rückspielung. Jeder Test gehört dokumentiert – auch als Nachweis für Versicherer und Audits.

Weiterlesen

Vom Ratgeber zum eigenen Notfallhandbuch.

PlanB führt Schritt für Schritt durch alle Bausteine – von Rollen und Wiederanlaufplänen bis zu Szenario-Checklisten und Compliance-Nachweisen.