DORA-Meldepflichten: die Nachweise hinter der 4-Stunden-, der 72-Stunden- und der Ein-Monats-Frist

Die Meldekette läuft gegen die Uhr, und die Nachweise, die sie verlangt, müssen vorliegen, bevor die Uhr startet. Nachträglich zusammensuchen geht nicht. Hier steht, wie prüffähige Verfügbarkeitsdaten aussehen und warum Screenshots und Chatverläufe nicht zählen.

Es ist 02:40 Uhr. Ein Check auf Ihre Payments-API schlägt aus Frankfurt fehl. Dreißig Sekunden später bestätigen zwei weitere Prüfpunkte, einer in Nordamerika, einer in Asien, dass der Dienst nicht erreichbar ist. Der Incident ist echt, und unter DORA läuft ab diesem Moment eine Uhr, die rechtlich zählt. Wird der Vorfall als schwerwiegend eingestuft, schulden Sie Ihrer zuständigen Behörde eine Erstmeldung innerhalb von vier Stunden, einen ausführlicheren Zwischenbericht innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats.

Schwierig ist nicht das Schreiben dieser Meldungen. Schwierig ist, dass jede von ihnen Fakten verlangt, die um 02:40 Uhr wahr und aufgezeichnet gewesen sein müssen. Sie können nicht nachträglich messen, wann der Ausfall begonnen hat. Entweder die Aufzeichnung existiert oder sie existiert nicht.

Dieser Text ist ein praktischer Leitfaden für die Verfügbarkeitshälfte dieser Aufzeichnung: was die Meldekette verlangt, warum Screenshots und Slack-Threads nicht als Nachweis zählen und wie prüffähige Uptime-Daten tatsächlich aussehen. Es ist keine Rechtsberatung. Die Einstufung und der Meldeprozess selbst bleiben Ihre Aufgabe, und für die genauen Felder und Schwellenwerte lesen Sie die Verordnung und ihre technischen Standards.

Die drei Fristen

DORA gilt seit dem 17. Januar 2025. Für schwerwiegende IKT-bezogene Vorfälle schreibt die Verordnung eine gestaffelte Meldekette vor:

Die Vier-Stunden-Frist sollten Sie zweimal lesen. Sie beginnt nicht mit dem Incident. Sie beginnt mit der Einstufung als schwerwiegend, anhand von Kriterien wie der Zahl betroffener Kunden, der Dauer, der geografischen Ausbreitung und dem Datenverlust. Zwei Zeitstempel zählen also, bevor Sie ein Wort geschrieben haben: wann der Incident begonnen hat und wann Sie genug wussten, um ihn einzustufen. Beides sind Messwerte, keine Einschätzungen.

Was die Meldung tatsächlich verlangt

Wenn Sie die Formulare auf ihren Kern reduzieren, bleiben bei den verfügbarkeitsbezogenen Feldern ein paar sehr direkte Fragen übrig:

• Wann wurde der Incident erkannt, und wann hat er tatsächlich begonnen?
• Wie lange waren Dienste nicht verfügbar?
• Welche Dienste waren betroffen, und wie viele Kunden oder Transaktionen?
• Wie weit reichte die geografische Ausbreitung?
• Wann war der Dienst wiederhergestellt, und woher wissen Sie das?

Jede dieser Fragen ist eine Datenfrage, bevor sie eine Erzählfrage ist. Auf “Wie lange waren Dienste nicht verfügbar” gibt es eine richtige Antwort, sekundengenau, und die Aufsicht kann Ihren Abschlussbericht einen Monat später gegen Ihre eigene Statusseite halten. Weichen beide voneinander ab, ist das eine Feststellung.

Warum Screenshots und Chatverläufe keine Nachweise sind

Die meisten Teams greifen, wenn sie einen Ausfall im Nachhinein belegen sollen, zum Screenshot eines Dashboards und scrollen in Slack zurück. Beides fühlt sich nach Nachweis an. Keines hält stand.

Ein Screenshot hat keine nachprüfbare Herkunft. Er zeigt eine Zahl in dem Moment, in dem jemand eine Taste gedrückt hat, keine durchgehende Aufzeichnung, und nichts im Bild bindet ihn an eine Uhr, der Sie trauen können. Ein Chat-Thread ist eine Rekonstruktion: Er hält fest, wann Menschen über den Incident gesprochen haben, nicht wann der Incident stattgefunden hat. Erinnerung verschiebt sich, Nachrichten werden nachträglich bearbeitet, und das erste “ist prod gerade unten?” landet in der Regel Minuten nach dem ersten fehlgeschlagenen Request.

Ein Prüfer ist nicht schwierig, wenn er das zurückweist. Er stellt eine faire Frage: Woher kommt dieser Zeitstempel, und hätte er verändert werden können? Lautet die Antwort “jemand erinnert sich” oder “jemand hat ein Dashboard zurechtgeschnitten”, haben Sie keine Aufzeichnung. Sie haben eine Geschichte.

Wie prüffähige Verfügbarkeitsdaten aussehen

Nachweise für den Verfügbarkeitsteil einer DORA-Meldung haben ein paar Eigenschaften, die Sie nachprüfen können.

Zeitstempel aus dem System, nicht aus dem Gedächtnis

Erkennungs- und Wiederherstellungszeiten kommen aus dem Monitoring selbst, aufgezeichnet in dem Moment, in dem sie eintreten, nicht nachträglich eingetippt. Ein Zeitstempel ist nur so viel wert wie die Uhr dahinter.

Bestätigung statt einer einzelnen Stimme

Ein einzelner fehlschlagender Prüfpunkt kann bedeuten, dass das Ziel ausgefallen ist, oder dass ein Netzpfad gerade wackelt. Perstat eröffnet einen Incident erst, wenn ein Quorum aus Regionen zustimmt. Der aufgezeichnete Beginn ist deshalb die Quorum-Bestätigung, nicht der erste fehlgeschlagene Check. In einer Meldung ist das der Unterschied zwischen “unser Dienst war ausgefallen” und “eine Route zu unserem Dienst war kurz unpässlich”.

Ausschlüsse, die gepflegt und sichtbar sind

In die SLA-Rechnung gehen oft Ausschlussfenster ein, angekündigte Wartung zum Beispiel. Prüffähig heißt: Diese Ausschlüsse tragen ihre echten Grenzen und den Zeitstempel ihrer Ankündigung, und ein Ausschluss ohne passendes angekündigtes Fenster wird nicht akzeptiert. Es geht nicht darum, die Zahl zu schönen. Es geht darum, dass jeder genau sehen kann, was ausgeschlossen wurde und warum.

Eine Aufzeichnung, nicht vier

Dieselben Daten speisen den SLA-Report, die Statusseite und die Incident-Zeitleiste. Die öffentliche Darstellung und die Darstellung für die Prüfung können deshalb nicht unbemerkt auseinanderlaufen.

Wie das konkret aussieht, zeigt der Beispiel-SLA-Report von Perstat für einen Demo-Dienst über ein Quartal:

• 91 Tage, 131.040 Minuten, 1.572.480 Checks aus sechs Regionen.
• Ein bestätigter Incident: Um 02:40:42 schlägt ein Check aus eu-fra fehl, um 02:41:12 bestätigt das Quorum, weil na-ewr und as-sgp zustimmen, um 02:48:24 ist die Wiederherstellung über die Regionen hinweg bestätigt.
• Das SLA-Fenster reicht von 02:41:12 bis 02:48:24, von der Bestätigung bis zur bestätigten Wiederherstellung, 7 Minuten 12 Sekunden. Die 30 Sekunden vor der Bestätigung bleiben in der Aufzeichnung sichtbar, sie werden nicht stillschweigend gedehnt oder gekürzt.
• Bruttoverfügbarkeit 99,925 %, und 99,994 % nach dem einen gepflegten, angekündigten Wartungsausschluss.

Jede einzelne dieser Zahlen können Sie nachrechnen. Das ist der Test.

Rückwärts von der Meldung her denken

Die nützliche Übung: Nehmen Sie ein Feld der Meldung und fragen Sie, wo die Antwort darauf schon vor einem Incident liegt, nicht erst danach.

Steht heute in einer Zeile keine Quelle, ist das die Lücke, die Sie vor der nächsten Prüfung schließen, nicht während des nächsten Incidents.

Wo ein Monitoring-Werkzeug hilft und wo nicht

Die Grenze gehört klar benannt. Ein Monitoring-Produkt erfüllt DORA nicht für Sie, und kein Werkzeug sollte das behaupten. Die Einstufung, das Informationsregister zu IKT-Drittdienstleistern, der Meldeprozess und die rechtliche Bewertung bleiben bei Ihnen. Was ein Werkzeug leisten kann: die Verfügbarkeitsnachweise liefern, nach denen der Rahmen immer wieder fragt. Echte Erkennungs- und Wiederherstellungszeiten, über Regionen hinweg bestätigt, mit Ausschlüssen, die Sie begründen können, und einer Aufzeichnung, die Sie um 02:40 Uhr nicht von Hand zusammentragen mussten.

Perstat ist für diese Hälfte des Problems gebaut. Es führt HTTP-, TCP- und DNS-Checks in Intervallen bis hinunter zu 10 Sekunden aus, aus Prüfregionen auf sechs Kontinenten, mit einer Control Plane in der EU und einem deutschen Unternehmen dahinter. Wenn der Prüfer fragt, wie lange Sie ausgefallen waren, steht die Antwort bereits in der Aufzeichnung.

Den ganzen Ablauf, von der Incident-Zeitleiste bis zum exportierten Report, können Sie in der Produkt-Tour durchgehen, ohne Anmeldung. Wenn Sie so weit sind: kostenlos mit dem Monitoring starten .