> For the complete documentation index, see [llms.txt](https://notfallkit.liquid-legal.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notfallkit.liquid-legal.org/notfallplane-fur-kanzleien/methodik-des-notfallmanagements.md).

# Methodik des Notfallmanagements

Ein wirksames Notfallmanagement erfordert eine strukturierte und nachvollziehbare Methodik, die sich an anerkannten Standards des BCM orientiert. Ausgangspunkt ist eine systematische Analyse der für die Organisation kritischen Geschäftsprozesse (Business Impact Analyse). Ziel dieser Analyse ist es, diejenigen Tätigkeiten zu identifizieren, deren Ausfall unmittelbare Auswirkungen auf die Handlungsfähigkeit, die Mandatsbearbeitung oder die Einhaltung rechtlicher Verpflichtungen hat.

Auf dieser Grundlage sind für jeden kritischen Prozess zentrale Parameter festzulegen. Hierzu gehören insbesondere die maximal tolerierbare Dauer einer Unterbrechung (Maximum Tolerable Period of Disruption – MTPD) sowie der Zielzeitpunkt für die Wiederherstellung (Recovery Time Objective – RTO). Ergänzend sind die Mindestvoraussetzungen für die Aufrechterhaltung eines Notbetriebs zu bestimmen. Diese betreffen regelmäßig die verfügbaren personellen Ressourcen, die erforderliche technische Ausstattung, den Zugang zu IT‑Systemen und Informationen sowie die Einbindung externer Dienstleister.

### Unterscheidung zwischen Betriebsstörung, Notfall und Krise

Ein wichtiger konzeptioneller Unterschied besteht zwischen Notfällen und Krisen (im engeren Sinne – oft wird der Begriff der Krise auch als Oberbegriff für Notfälle und Krisen verwendet („Krisensituation“)). Diese Differenzierung ist entscheidend für die Wahl der Führungsmittel und Reaktionsmechanismen. Ergänzend zur Unterscheidung zwischen Notfall und Krise ist in der IT-Praxis eine weitere Differenzierung erforderlich, nämlich zwischen einer bloßen Betriebsstörung und einem IT‑Notfall.

#### Betriebsstörung

Eine Betriebsstörung liegt vor, wenn Beeinträchtigungen mit den im Normalbetrieb verfügbaren Mitteln und innerhalb der üblichen Reaktionszeiten behoben werden können. Demgegenüber ist von einem IT‑Notfall auszugehen, wenn kritische Geschäftsprozesse betroffen sind und eine Wiederherstellung innerhalb der akzeptablen Ausfallzeit nicht gewährleistet werden kann.

Für die Einordnung sind insbesondere folgende Kriterien maßgeblich:

* erwartete Schadenshöhe (z. B. organisatorisch, finanziell, rechtlich),
* erforderliche Reaktionsgeschwindigkeit,
* Umfang und Art der einzusetzenden Ressourcen.

Eine solche strukturierte Einstufung stellt sicher, dass geeignete Maßnahmen frühzeitig eingeleitet und Eskalationen weder zu spät noch unnötig ausgelöst werden.

#### Notfall

Ein unerwünschtes Ereignis, dessen Eintritt möglich, aber nicht sicher erwartet werden kann und das zu Schaden führt. Der Notfall ist außerhalb des normalen Tagesgeschäfts, kann aber mit zur Verfügung stehenden Mitteln einer gesonderten Notfallbewältigungsorganisation bewältigt werden. Ein Notfall zeichnet sich durch einen hohen Grad an Standardisierbarkeit in der Reaktion aus.

{% hint style="info" %}
Beispiel: Ein Serverausfall, für den ein redundantes System bereitsteht, oder ein Stromausfall, der durch eine USV (Unterbrechungsfreie Stromversorgung) überbrückt wird. Hier greifen vorab definierte "Standard Operating Procedures" (SOPs).
{% endhint %}

#### Krise

Eine Situation, in der wesentliche Ziele oder die Existenz einer Organisation gefährdet sind. Krisen sind mindestens in Teilen einmalig und können deshalb nicht mit vorgefertigten Plänen bewältigt werden. Sie erfordern Improvisation, strategische Entscheidungen unter hoher Unsicherheit und oft eine Anpassung der Ziele.

{% hint style="info" %}
Beispiel: Ein erfolgreicher Ransomware-Angriff mit Datenabfluss ins Darknet und gleichzeitiger medialer Skandalisierung. Hier reichen technische Pläne nicht aus; es bedarf eines Krisenstabs, der juristische, kommunikative und technische Maßnahmen dynamisch koordiniert.
{% endhint %}

Krisen können struktureller Art sein (z.B. Wegfall einer maßgeblichen Branche auf Kundenseite, etwa durch Sanktionen) oder durch punktuelle Ereignisse hervorgerufen werden (politische Krise in einem Land mit wichtigen Kunden).

Diese Unterscheidung ist wichtig, da ein Notfallplan vorrangig für vorhersehbare Szenarien erstellt wird, während das Krisenmanagement auf unvorhergesehene Situationen reagieren muss. Der Notfallplan liefert das Fundament (z.B. funktionierende Kommunikationswege, Zugriff auf Dokumente), auf dem das Krisenmanagement operieren kann. Der Notfallplan ist auf eine kurzfristige Reaktion abgestellt (Wiederherstellung der Handlungsfähigkeit), die Bewältigung der Krise kann längere Zeit in Anspruch nehmen (Reputationswiederaufbau, juristische Aufarbeitung). In diesem Whitepaper beschäftigen wir uns vorrangig mit dem Notfall, also der operativen Vorsorge.

### Typischer Ablauf eines IT‑Notfalls

Ein strukturierter Umgang mit IT‑Notfällen folgt in der Praxis regelmäßig einem wiederkehrenden Ablauf, der sich an etablierten Modellen des Business Continuity Managements orientiert. Ausgangspunkt ist die Erfassung eines Ereignisses (z. B. durch Monitoring oder Meldung eines Mitarbeiters), gefolgt von einer Verifikation und ersten Einordnung.

Zunächst ist festzustellen, ob es sich um eine gewöhnliche Betriebsstörung oder einen IT‑Notfall handelt. Wird ein Notfall festgestellt, sind unverzüglich definierte Sofortmaßnahmen zur Schadensbegrenzung einzuleiten und die Notfallorganisation zu aktivieren. Parallel hierzu erfolgt die strukturierte Kommunikation sowie – soweit erforderlich – die Einbindung externer Stellen.

Im weiteren Verlauf steht die Herstellung eines stabilen Notbetriebs sowie anschließend die schrittweise Wiederherstellung des Normalbetriebs im Fokus. Den Abschluss bildet die Nachbereitung, insbesondere zur Identifikation von Verbesserungsmaßnahmen.

Dieser standardisierte Ablauf dient dazu, auch unter hoher zeitlicher und organisatorischer Belastung eine nachvollziehbare, koordinierte und rechtssichere Vorgehensweise sicherzustellen.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://notfallkit.liquid-legal.org/notfallplane-fur-kanzleien/methodik-des-notfallmanagements.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
