IT-Störung oder Notfall: Auswirkungen richtig einordnen

Ein System ist nicht erreichbar. Für ein Team ist das ein kurzer Umweg, für ein anderes steht ein zeitkritischer Ablauf still. Die technische Fehlermeldung allein sagt deshalb wenig über die betriebliche Bedeutung. Eine brauchbare Ersteinschätzung verbindet den Ausfall mit den betroffenen Geschäftsprozessen und dem vorgesehenen Eskalationsweg.

Mit der ausgefallenen Aufgabe beginnen

Fragen Sie zuerst, welche Arbeit tatsächlich nicht mehr möglich ist. „Server gestört“ beschreibt eine technische Komponente. „Aufträge können nicht freigegeben werden“ beschreibt eine Auswirkung. Beide Informationen gehören zusammen, weil sich Priorität und geeignete Reaktion nicht allein aus dem Namen des Systems ergeben.

Der BSI-Standard 200-4 behandelt Business Continuity Management und unterscheidet Störung, Notfall und Krise anhand des organisatorischen Zusammenhangs und ihrer Auswirkungen. Für die betriebliche Vorbereitung ist daher entscheidend, die eigenen zeitkritischen Prozesse und vorgesehenen Wiederanlaufwege zu kennen. Der Standard ist keine pauschale gesetzliche Meldefrist für jeden IT-Ausfall.

Die Begriffe in diesem Artikel dienen der organisatorischen Einordnung. Ob ein konkreter Vorfall gesetzliche Meldepflichten oder andere rechtliche Schritte auslöst, muss gesondert geprüft werden. Ein intern gewähltes Etikett entscheidet diese Frage nicht.

Eine erste Lageübersicht ohne Scheingenauigkeit

Kennzeichnen Sie unbekannte Angaben als unbekannt. Eine geschätzte Wiederherstellungszeit darf nicht als bestätigter Termin erscheinen. Halten Sie fest, von wem die Einschätzung stammt und wann sie gegeben wurde. Eine veraltete Prognose kann sonst noch in Umlauf sein, obwohl die technische Lage sich bereits verändert hat.

Die Übersicht soll eine Entscheidung vorbereiten. Sie muss nicht vor jeder Eskalation vollständig sein. Wenn der vorgesehene Ablauf eine sofortige Meldung bei bestimmten Auswirkungen verlangt, wird nicht erst auf ein schön ausgefülltes Formular gewartet.

Eskalation braucht einen erreichbaren Weg

Benennen Sie Funktionen und Vertretungen so, dass sie auch bei Ausfall des üblichen Kommunikationswegs erreichbar sind. Eine Kontaktliste, die ausschließlich auf dem ausgefallenen System liegt, hilft in genau diesem Fall nicht. Prüfen Sie den vorgesehenen Zugriff, ohne vertrauliche Kontaktdaten unnötig zu verbreiten.

Legen Sie fest, wer den betrieblichen Stand kommuniziert. Technische Fehlersuche und Information der betroffenen Bereiche können parallel nötig sein, sind aber unterschiedliche Aufgaben. Eine verlässliche Lageinformation nennt bekannte Auswirkungen, offene Punkte und den nächsten vorgesehenen Informationsschritt.

Eine Ersatzlösung wird nicht allein deshalb sicher oder zulässig, weil sie den Prozess wieder möglich macht. Prüfen Sie die dafür vorgesehenen Grenzen, etwa Berechtigungen und Datenwege. Improvisierte Umgehungen können zusätzliche Probleme erzeugen.

Praxisbeispiel: Derselbe Ausfall, unterschiedliche Folgen

In einem fiktiven Unternehmen fällt eine zentrale Anwendung aus. Ein Team kann vorbereitete Aufgaben vorübergehend offline weiterbearbeiten. Ein anderes Team benötigt dieselbe Anwendung für einen zeitkritischen Freigabeschritt und hat keinen sofort nutzbaren Ersatzweg. Die technische Ursache ist gleich, die betriebliche Lage ist es nicht.

Die Organisation bewertet deshalb die betroffenen Prozesse getrennt und führt die Ergebnisse in der Lageübersicht zusammen. Die Aussage „bei uns geht es noch“ aus dem ersten Team wird nicht auf den gesamten Betrieb übertragen. Ebenso wird eine einzelne dramatische Beschreibung nicht ungeprüft als vollständiges Lagebild übernommen.

RegelWerk kann bei der strukturierten Dokumentation von Zuständigkeiten und Maßnahmen unterstützen. Die Bewertung der konkreten Lage und die Entscheidung über Eskalation bleiben Aufgaben der dafür vorgesehenen Personen.

Mit einer kleinen Übung die unklaren Stellen finden

Verwenden Sie einen fiktiven Ausfall und bitten Sie die Beteiligten, den vorgesehenen Ablauf zu erklären. Welche Information würden sie zuerst erfassen? Wen erreichen sie, wenn die erste Person nicht verfügbar ist? Wo liegt die benötigte Anleitung? Eine solche Besprechung kann organisatorische Lücken zeigen, ohne einen echten Dienst abzuschalten.

Prüfen Sie besonders die Übergänge. Eine technische Meldung kann vollständig sein und trotzdem niemanden erreichen, der die betriebliche Auswirkung beurteilt. Umgekehrt kann eine Führungskraft den Ausfall kennen, aber keine aktuelle Information zum Wiederanlauf erhalten. Der Ablauf muss beide Richtungen verbinden.

Halten Sie aus der Übung konkrete Aufgaben fest. „Kommunikation verbessern“ bleibt zu allgemein. „Den Ersatzkontakt in der vorgesehenen Liste ergänzen und dessen Erreichbarkeit testen“ beschreibt eine nachprüfbare Handlung. Der Beitrag zur Auswertung einer Notfallübung führt diesen Schritt weiter aus.

Nach einem tatsächlichen Ereignis wird der Verlauf mit den damaligen Informationen betrachtet. Eine später bekannte Ursache darf nicht so dargestellt werden, als sei sie schon zu Beginn sicher gewesen. Eine ehrliche Chronik erklärt Entscheidungen aus ihrem damaligen Kenntnisstand und hilft dadurch bei der Verbesserung des Verfahrens.

Häufige Fragen

Ist jeder IT-Ausfall automatisch ein Notfall?

Nein. Die betriebliche Einordnung hängt von Auswirkungen, Zeitkritik und den vorgesehenen Bewältigungsmöglichkeiten ab.

Entscheidet die interne Einstufung über gesetzliche Meldepflichten?

Nein. Rechtliche Pflichten müssen anhand des konkreten Vorfalls und der einschlägigen Vorgaben gesondert geprüft werden.

Wie kann ich den Eskalationsweg gefahrlos testen?

Besprechen Sie einen fiktiven Ausfall und prüfen Sie Zuständigkeiten, Vertretung, Zugriff auf Anleitungen und den Informationsweg, ohne Produktivsysteme abzuschalten.

Das Wichtigste in Kürze

Hinweis: Dieser Beitrag ersetzt keine Rechts- oder Steuerberatung. Die Einstufung ersetzt keine Prüfung im Einzelfall – wenden Sie sich dafür an fachkundige Beratung.