DORA – Digitale operationale Resilienz
Meridian Payments – Montag, 9:47 Uhr – Monatsende
Ein interaktives Szenario über einen kritischen Ausfall eines Lieferanten, die vierstündige Meldefrist und was passiert, wenn der CEO im Flugzeug sitzt und die Verordnung am Telefon ist.
Ein 4-Stunden-Fenster. Der Geschäftsführer ist nicht erreichbar. Die Verordnung wartet.
Leiter der Compliance-Abteilung bei Meridian Payments – einem mittelständischen EU-Zahlungsdienstleister mit einem jährlichen Transaktionsvolumen von 2,3 Milliarden Euro. DORA-reguliert. 850 Mitarbeiter.
Es ist 9:47 Uhr am letzten Werktag des Monats. Die Statusseite Ihres wichtigen Cloud-Anbieters hat gerade auf „gelb“ gewechselt.
Dies ist ein „Wähle-dein-eigenes-Abenteuer“-Szenario. Sie stehen vor drei realen Entscheidungen, mit denen ein Beauftragter der DORA bei einem schwerwiegenden IKT-Vorfall konfrontiert wird – und Ihre Entscheidungen bestimmen, wie sich die Geschichte entwickelt.
Die 4 Stakeholder-Balken (oben rechts)
Jeder Balken beginnt bei 50 %. Ihre Entscheidungen beeinflussen diese Werte. Es gibt keine perfekte Lösung – nur Kompromisse.
Score Toasts
Nach jeder Entscheidung wird die Auswirkung kurz angezeigt – z. B. +3 Verordnung | -1 Händler. Achten Sie darauf, um die Vor- und Nachteile in Echtzeit zu erkennen.
Legal References
Im gesamten Text finden sich Verweise auf Artikel – klicken Sie darauf, um den entsprechenden DORA-Artikel zu lesen.
Es ist Monatsende. 14.000 Händlerabrechnungen stehen in der Warteschlange. Ihr größter Kunde – die NatAlliance Bank, die heute 180 Millionen Euro abwickelt – hat eine SLA, die bei einer Verfügbarkeit von unter 99,5 % Strafklauseln auslöst. Sie liegen bereits darunter. Und nun wartet der Leiter des Händlerbetriebs auf Ihre Antwort.
Es ist 9:47 Uhr. Der Anruf ist immer noch in der Warteschleife. Ihr Kaffee ist kalt.
„Jordan, es ist schlimmer, als ich dachte. In der Region EU-West von CloudVault gibt es ein schwerwiegendes Problem. Auf ihrer Statusseite steht ‚wird untersucht‘, aber ich warte nun schon seit 20 Minuten in der Warteschleife beim Support.“
„Die Zahlungsabwicklung läuft nur noch mit 40 % ihrer Kapazität. Die Abrechnungswarteschlange staut sich. Wenn das Problem nicht innerhalb der nächsten Stunde behoben wird, verpassen wir das Monatsabschlussfenster für 8.000 Händler.“
Sie: „Was ist mit dem Failover?“
Emma: „Ich kann auf EU-Central umschalten. Fünfundvierzig Minuten Ausfallzeit, vielleicht auch mehr. Aber Jordan – das sind zwölf Millionen an Zahlungen, die gerade in Bearbeitung sind. Wenn auch nur eine davon von einer Privatkundenbank stammt, die gerade Lastschriften abwickelt – und NatAlliance hat Sie gerade angerufen –, dann sind das echte Menschen, deren Mietzahlungen platzen. Fatima Khourys Gehaltsabrechnung befindet sich wahrscheinlich in dieser Warteschlange.“
Ihr Handy vibriert. Eine SMS von David Chen, Ihrem CEO, die er vor seinem Flug geschickt hat: „Die Monatsbilanz ist in Ordnung, oder? Die Präsentation vor dem Vorstand in Singapur hängt davon ab. Lassen Sie nichts schiefgehen, während ich im Flugzeug sitze.“ Er ist nun für 10 Stunden nicht erreichbar.
Beantworten Sie drei Fragen, um den CloudVault-Ausfall einzustufen. Jede Frage entspricht einem Wesentlichkeitskriterium gemäß Art. 17.
Frage 1: War ein kritischer ITS-Dienst während der Geschäftszeiten für mehr als zwei aufeinanderfolgende Stunden unterbrochen?
Ihr Monitoring zeigt, dass 14.000 Händler betroffen sind. Die Zahlungsabwicklung läuft mit 40 % der Kapazität. Abrechnungen in Höhe von 180 Mio. € zum Monatsende sind gefährdet. Die Frage, die sich Ihnen stellt: Wie ernst ist die Lage?
Emma glaubt, dass es sich um ein Problem von CloudVault handelt. Auf der Statusseite steht „wird derzeit untersucht“. Sie verfügen nur über unvollständige Informationen – doch die Warteschlange wird von Minute zu Minute länger.
Würden Sie dies als schwerwiegenden IKT-Vorfall einstufen?
„Dies ist ein schwerwiegender Vorfall. 14.000 Händler, 180 Millionen Euro an Abrechnungsbeträgen, kritische Funktionen unterhalb der Schwelle. Ich stufe den Vorfall nun ein und leite den Benachrichtigungsprozess ein.“
Emma: „Jordan, das Problem könnte sich in 20 Minuten von selbst lösen. Bei CloudVault gab es schon früher solche Ausfälle. Wenn Sie einen Bericht über einen schwerwiegenden Vorfall einreichen und sich herausstellt, dass es nichts Ernstes war, sehen wir so aus, als hätten wir überreagiert.“
Sie: „Wenn sich das Problem innerhalb von 20 Minuten löst, aktualisiere ich den Bericht. Wenn nicht und ich es noch nicht klassifiziert habe, müssen wir der Verordnung erklären, warum wir gewartet haben. Welches Gespräch würden Sie lieber führen?“
Sie öffnen die Plattform für das Störungsmanagement und erfassen die Vorfallklassifizierung. Die 4-Stunden-Meldefrist beginnt jetzt: 10:15 Uhr. Frist: 14:15 Uhr.
Gemäß Artikel 17 müssen Finanzunternehmen IKT-bezogene Vorfälle als „schwerwiegend“ einstufen, wobei folgende Kriterien zu berücksichtigen sind: die Anzahl der betroffenen Kunden, die Kritikalität der beeinträchtigten Dienste und die Dauer. Die RTS (EU) 2024/1772 legt konkrete Schwellenwerte fest – z. B. >10 % der Kunden oder >100 Mio. € an betroffenen Transaktionen. Eine frühzeitige Einstufung ist mit keinen Kosten verbunden. Eine verspätete Einstufung schafft eine Lücke zwischen dem „Zeitpunkt, zu dem Sie davon wussten“ und dem „Zeitpunkt, zu dem Sie gehandelt haben“, die von den Verordnungen genau geprüft wird.
Emmas Einschätzung: „Es handelt sich definitiv um CloudVault. Ihre Speicherschicht in der EU-West ist ausgefallen. Sie führen derzeit eine Wiederherstellung aus Backups durch. Voraussichtliche Dauer: unbekannt.“
Sie stufen es um 11:17 Uhr als schwerwiegend ein. Das 4-Stunden-Fenster beginnt jetzt. Frist: 15:17 Uhr.
Der Vorfall begann jedoch um 9:47 Uhr. Als Dr. Rossi fragt: „Wann haben Sie davon Kenntnis erlangt?“, lautet die Antwort 9:47 Uhr. Als sie fragt: „Wann haben Sie die Einstufung vorgenommen?“, lautet die Antwort 11:17 Uhr. Die Zeitspanne beträgt 90 Minuten.
„Warum haben Sie 90 Minuten gebraucht, um festzustellen, dass 14.000 betroffene Händler und gefährdete Zahlungen in Höhe von 180 Millionen Euro einen schwerwiegenden Vorfall darstellten?“
DORA schreibt vor, dass eine Einstufung „sobald der Vorfall festgestellt wird“ erfolgen muss. Die vierstündige Meldefrist gemäß Artikel 19 beginnt mit der Einstufung – doch der Zeitrahmen der Aufsichtsbehörde beginnt bereits mit dem Zeitpunkt der Kenntnisnahme. Eine Lücke von 90 Minuten zwischen Feststellung und Einstufung wird bei jeder Aufsichtsprüfung zur ersten Frage: „Was haben Sie in dieser Zeit getan?“ Das Abwarten auf Gewissheit ist zwar verständlich, entspricht jedoch nicht den Anforderungen der Verordnung.
Der Vorfall ist noch nicht behoben. Die Situation hat sich sogar verschlimmert. Die Zahlungsabwicklung läuft derzeit nur noch mit 15 % ihrer Kapazität. Drei Händlerkunden haben den Fall eskaliert. Die Vertragsstrafe wegen SLA-Verstoßes für Ihren größten Kunden ist nun in Kraft getreten: 50.000 € pro Stunde.
Sie wechseln um 11:47 Uhr in den schwerwiegenden Studiengang. Das 4-Stunden-Fenster beginnt um 11:47 Uhr. Frist: 15:47 Uhr.
Um 11:22 Uhr ruft Fatima Khoury in Rotterdam ihre Bank an. Sie leitet ein Logistikunternehmen mit zwölf Mitarbeitern. Die Gehaltsabrechnung wurde nicht ausgeführt. Zwölf Mitarbeiter, die heute ihr Gehalt erwarten, werden es nicht erhalten. Sie wartet bereits seit 40 Minuten in der Warteschleife. Niemand kann ihr sagen, warum.
Die Aufsichtsbehörde wird den Zeitablauf einsehen. 9:47 bis 11:47 Uhr – zwei Stunden, in denen eine kritische Zahlungsfunktion beeinträchtigt war, bevor eine Einstufung erfolgte. Gemäß Artikel 17 sollte die Einstufung „unverzüglich nach Feststellung des Vorfalls“ erfolgen. Zwei Stunden sind nicht „unverzüglich“.
Artikel 17 schreibt vor, dass die Einstufung „sobald der Vorfall festgestellt wird“ erfolgen muss. Eine zweistündige Beeinträchtigung einer kritischen Zahlungsfunktion bei einer Kapazität von 15 % – während 14.000 Händler keine Transaktionen abwickeln können – geht weit über jede vernünftige Auslegung des Begriffs „sobald“ hinaus. Gemäß Artikel 19 beginnt die 4-Stunden-Meldefrist ab der Einstufung, doch die Verordnung wird den gesamten Zeitablauf von der Feststellung (9:47 Uhr) bis zur Einstufung (11:47 Uhr) rekonstruieren. Diese zweistündige Verzögerung stellt nun einen dokumentierten Verstoß gegen die Vorschriften dar.
Under DORA Article 17müssen Finanzinstitute IKT-Vorfälle wie folgt klassifizieren: major or nicht wesentlich. Die Verordnung (EU) 2024/1772 legt bestimmte Schwellenwerte fest: Anzahl der betroffenen Kunden, Kritikalität des Dienstes, geografische Ausbreitung, Dauer und Auswirkungen auf die Daten.
Bevor Sie mit einem tatsächlichen Vorfall konfrontiert werden, üben Sie die Einstufung anhand von sechs Szenarien. Jedes Szenario weist unterschiedliche Merkmale auf – Ihre Aufgabe ist es, zu entscheiden, ob der Schwellenwert für die Meldepflicht überschritten wird.
SCHWERWIEGEND = Meldepflicht gegenüber der zuständigen Behörde (Erstmeldung innerhalb von 4 Stunden nach Einstufung) · NICHT SCHWERWIEGEND = interne Erfassung
Geldautomaten-Netzwerk – 340 Automaten in DE, NL und AT außer Betrieb (seit 3 Stunden und es dauert an)
Systemrelevanter Dienst; 3 EU-Mitgliedstaaten; 14 % der Privatkunden können kein Bargeld abheben
Internes HR-Portal – Leistungsbeeinträchtigung (Ladezeit 8 Sekunden, normalerweise 2 Sekunden)
Nur für den internen Gebrauch; keine Auswirkungen auf Kunden, Finanzpartner oder Transaktionen
⚠ Betrugserkennungssystem – seit 85 Minuten außer Betrieb; geschätzte Verluste durch unentdeckten Betrug: 120.000 €
Kritische Funktion; Dauer unterhalb der 2-Stunden-Schwelle; wirtschaftliche Auswirkungen bereits über 100.000 €
Kernbankensystem – Abwicklungsmodul mit 40 % Auslastungsgrad (2,5 Stunden)
Kritische Funktion; Gefährdung der aufsichtsrechtlichen Tagesabschlussberichterstattung; systemisches finanzielles Risiko
⚠ Mobile Banking – zeitweise auftretende Anmeldefehler, von denen 7 % der aktiven Nutzer betroffen sind (90 Min.)
Kundenkontakt; 7 % Auswirkungen auf den Kunden; Dauer: 90 Minuten; geschätzte wirtschaftliche Auswirkungen: < 100.000 €
Mitarbeiter-VPN – 3 Mitarbeiter im Homeoffice können keine Verbindung herstellen
Nur intern; keine Auswirkungen auf Kunden, Geschäftspartner, Transaktionen oder kritische Funktionen
Ihr Geschäftsführer, David Chen, befindet sich auf einem Flug nach Singapur. Er ist vor zwei Stunden gestartet. Er ist in den nächsten 8 Stunden nicht erreichbar.
In der Zwischenzeit meldet sich der Kundenbetreuer von CloudVault endlich zurück:
Marcus Hahn — CloudVault „Jordan, hören Sie – ich weiß, dass der Zeitpunkt ungünstig ist. Wir haben Probleme in der Region EU-West. Unser Team kümmert sich darum.“
„Marcus, als wir den Vertrag unterzeichneten, haben Sie mir persönlich versichert, dass EU-West über eine vollständige Redundanz verfügt. Sie sagten – ich habe die E-Mail noch vor mir –: ‚Es gibt keinen Single Point of Failure in unserer EU-Infrastruktur.‘ Was ist passiert?“
Marcus: Eine kurze Pause. „Die Redundanz befindet sich auf der Anwendungsebene. Das ist ein Problem mit dem Speichercontroller. Wir … Ich will ehrlich sein, Jordan: Ich bin mir nicht sicher, ob unser Wartungsplan die Firmware dieser Controller abdeckt. Das muss ich erst überprüfen.“
Sie: „Das ‚No Single Point of Failure‘ hatte also doch einen Single Point of Failure.“
Marcus: „Ich melde mich in einer Stunde wieder bei Ihnen.“
Die Meldefrist rückt näher. Ihr Geschäftsführer ist nicht erreichbar. Der Anbieter äußert sich nur vage. Sie müssen entscheiden, was Sie einreichen sollen.
Das 4-Stunden-Fenster gemäß Artikel 19 läuft ab. Sie müssen eine Erstmeldung bei Ihrer zuständigen nationalen Behörde einreichen. Der Geschäftsführer sitzt im Flugzeug. Der Anbieter sagt „2–4 Stunden“. Sie kennen die Ursache noch nicht.
Was legen Sie ab?
Sie reichen den Antrag um 14:12 Uhr ein – drei Minuten vor Ablauf der Frist.
Dr. Elena Rossi – Zuständige nationale Behörde „Herr Adams, ich habe Ihre Erstmeldung erhalten. Vielen Dank, dass Sie diese fristgerecht eingereicht haben. Ich nehme zur Kenntnis, dass die Ursache noch unbekannt ist – wann rechnen Sie mit dem Zwischenbericht?“
Sie: „Innerhalb von 72 Stunden. Wir arbeiten gemeinsam mit CloudVault daran, die Ursache zu ermitteln.“
Elena: „In dem Bericht wird darauf hingewiesen, dass Ihr Geschäftsführer nicht erreichbar war. Wer hat die Einreichung genehmigt?“
Sie: „Das habe ich. Im Rahmen der übertragenen Befugnisse gemäß Abschnitt 4.3 unserer Richtlinie zum Management von IKT-Vorfällen.“
Elena: „Gut. Genau diese Art von Unterlagen erwarten wir.“
Ihr Telefon vibriert. Vorwahl aus Singapur. David Chen ist vor 20 Minuten gelandet.
David Chen – CEO „Jordan. Mein Rechtsberater hat während der Präsentation des Vorstands angerufen. Sie haben unter Ausnutzung der übertragenen Befugnisse eine Meldung über einen schwerwiegenden Vorfall bei der BaFin eingereicht. Und das, während ich im Flugzeug saß. Ich musste dem Vorstand in Singapur erklären, warum unser Compliance-Beauftragter die Aufsichtsbehörden einseitig benachrichtigen kann, ohne dass ich dies genehmigt habe.“
Sie: „Die Frist gemäß Artikel 19 endete um 14:15 Uhr. Sie waren nicht erreichbar. Abschnitt 4.3 der IKT-Richtlinie sieht vor, dass –“
David: „Ich weiß, was in Abschnitt 4.3 steht. Ich habe ihn verfasst. Wir sprechen uns am Donnerstag.“
Artikel 19 schreibt drei Berichte vor: (1) eine Erstmeldung innerhalb von 4 Stunden nach der Einstufung, (2) einen 72-Stunden-Zwischenbericht und (3) einen Abschlussbericht innerhalb eines Monats. Der Erstbericht erfordert keine Angabe der Grundursache – lediglich die Ihnen bekannten Informationen: Art, Einstufung, erste Folgenabschätzung und einen Ansprechpartner. Eine frühzeitige Meldung mit unvollständigen Informationen entspricht genau dem, was die DORA beabsichtigt. Die Ursachenanalyse gehört in den Zwischenbericht. Die Meldung im Rahmen der übertragenen Befugnisse war korrekt – doch „korrekt“ und „angenehm“ sind zwei verschiedene Dinge.
Marcus' Update trifft um 15:08 Uhr ein: „Ursache ermittelt – Firmware-Fehler im Speichercontroller in EU-West. Der Patch wird gerade bereitgestellt. Vollständige Behebung bis 17:00 Uhr.“
Sie reichen den Antrag um 15:15 Uhr ein. Bessere Daten. Aber 60 Minuten nach Ablauf der Frist.
Dr. Rossi: „Herr Adams, Ihre Erstmeldung war um 14:15 Uhr fällig. Sie ging um 15:15 Uhr ein. Gemäß Artikel 19 muss die Erstmeldung innerhalb von vier Stunden nach der Einstufung gesendet werden. Können Sie die Verzögerung erklären?“
Sie: „Wir haben darauf gewartet, dass der Anbieter die Ursache bestätigt –“
Dr. Rossi: „Der Erstbericht erfordert keine Angabe der Ursache. Er erfordert lediglich die Ihnen vorliegenden Informationen. Sie hätten den Bericht um 14:15 Uhr einreichen und aktualisieren können, sobald die Ursache bestätigt war. Dafür ist der Zwischenbericht da.“
Die Erstmeldung erfordert keine Angabe der Grundursache. Sie erfordert lediglich die Ihnen vorliegenden Informationen: Art, Klassifizierung, erste Folgenabschätzung und einen Ansprechpartner. Das Warten auf „bessere Daten“ über die 4-Stunden-Frist hinaus ist der häufigste Grund für das Versäumnis der DORA-Meldung. Die Verordnung ist auf schnelle, unvollständige Erstmeldungen ausgelegt – deshalb gibt es den Zwischenbericht (72 Stunden) und den Abschlussbericht (1 Monat). Eine verspätete Meldung mit Angabe der Ursache gleicht die Nichteinhaltung der Frist nicht aus.
„Herr Adams, ich habe Ihre Erstmeldung erhalten. Darin steht: ‚IKT-Vorfall wird derzeit untersucht.‘ Das ist alles.“
„Gemäß Artikel 19 muss die Erstmeldung folgende Angaben enthalten: Art und Einstufung des Vorfalls, eine erste Folgenabschätzung sowie einen Ansprechpartner. Ihre Meldung enthält keine dieser Angaben.“
Sie: „Wir sind noch dabei, den Umfang festzulegen –“
Elena: „Sie haben dies als schwerwiegend eingestuft. Das bedeutet, dass Sie bereits festgestellt haben, dass die Kriterien erfüllt sind. Der ursprüngliche Bericht sollte diese Einschätzung widerspiegeln. Ich benötige innerhalb von zwei Stunden eine überarbeitete Fassung.“
Sie bemühen sich, den Antrag zu überarbeiten und erneut einzureichen. Die Verzögerung wird protokolliert. Elena Rossis Büro bestätigt den Eingang, weist jedoch darauf hin, dass der ursprüngliche Antrag die vier Mindestanforderungen gemäß Artikel 19 nicht erfüllte – eine Tatsache, die in der nachträglichen Überprüfung zur Sprache kommen wird.
Artikel 19 legt vier Mindestangaben für die Erstmeldung fest: (1) Art und Einstufung des Vorfalls, (2) eine erste Abschätzung der Auswirkungen, (3) die Identifikationsdaten des Finanzunternehmens und (4) einen Ansprechpartner. Die Angabe „IKT-Vorfall wird derzeit untersucht“ erfüllt keine dieser Anforderungen. Die Aufsichtsbehörde behandelt eine unvollständige Meldung als nicht erfolgte Meldung – Sie haben zwar die Frist eingehalten, aber die Meldepflicht nicht erfüllt. Eine überarbeitete Einreichung innerhalb von zwei Stunden verhindert zwar eine formelle aufsichtsrechtliche Feststellung, doch der Mangel ist bereits aktenkundig.
Der Vorfall bei CloudVault ist behoben. Die Zahlungen werden wieder wie gewohnt abgewickelt. Die Abrechnungswarteschlange wird bis 19 Uhr abgearbeitet. Es sind keine Daten verloren gegangen – allerdings kam es zum Monatsende zu einer sechsstündigen Beeinträchtigung des Dienstes.
Marcus Hahn: „Es handelte sich um einen Firmware-Fehler in unserem Speichercontroller. Betroffen war ausschließlich die Region EU-West. Wir haben den Patch bereitgestellt. Das wird nicht wieder vorkommen.“
„Marcus, dieser Ausfall dauerte sechs Stunden und beeinträchtigte unsere kritische Zahlungsfunktion. Gemäß Artikel 28 der DORA müssen wir prüfen, ob Ihre Vorkehrungen zur Gewährleistung der Ausfallsicherheit den Standards in unserem Outsourcing-Vertrag entsprechen.“
Marcus: „Das ist … ich werde mich bei unserer Compliance-Abteilung erkundigen und dann bei Ihnen zurückmelden.“
Er meldet sich nicht bei Ihnen. Die Sitzung des Vorstands findet am Donnerstag statt. Der Geschäftsführer ist morgen zurück. Sie müssen entscheiden, wie Sie das angehen wollen.
CloudVault hat seinen Vorfallbericht gesendet. Vor der Sitzung des Vorstands müssen Sie diesen anhand Ihrer Outsourcing-Verpflichtungen gemäß Artikel 28 des DORA-Gesetzes prüfen. Ermitteln Sie alle Lücken im Bericht.
Ein Firmware-Fehler im Speichercontroller der Region „EU-West“ führte am 14. Dezember 2027 von 09:47 bis 16:02 Uhr MEZ (6 Stunden und 15 Minuten) zu Beeinträchtigungen bei der Zahlungsabwicklung. Die Regionen „EU-Central“ und „US-East“ waren davon nicht betroffen.
Der Fehler wurde durch ein automatisches Firmware-Update verursacht, das um 09:30 Uhr MEZ bereitgestellt wurde. Die interne Überwachung von CloudVault erkannte die Beeinträchtigung um 09:47 Uhr, woraufhin das Technikteam umgehend mit der Untersuchung begann.
Mit der Firmware-Version 4.1.2 trat ein Konflikt bei der Speicherzuweisung auf, der Schreibvorgänge unter Dauerbelastung beeinträchtigte. Das Problem war auf den Cluster „EU-West“ beschränkt. Der Patch (v4.1.3) wurde um 16:02 Uhr MEZ bereitgestellt.
Das Firmware-Update wurde von der Nexon Storage Systems GmbH bereitgestellt, einem Subunternehmer, der für die Speicherinfrastruktur von CloudVault in Europa verantwortlich ist.
Patch v4.1.3 wurde um 16:02 Uhr MEZ bereitgestellt. Alle Warteschlangen für die Zahlungsabwicklung wurden bis 19:00 Uhr MEZ wiederhergestellt. Es wurde kein Datenverlust festgestellt. CloudVault wird die Verfahren für Firmware-Updates überprüfen.
CloudVault wird vor der Bereitstellung von Firmware in der Produktionsumgebung einen obligatorischen 48-stündigen Test in der Staging-Umgebung durchführen. Die interne Überprüfung ist für Januar 2028 geplant.
CloudVault bestätigt, dass der Vorfall zu einer Beeinträchtigung der Dienstleistung geführt hat. Wir prüfen derzeit in Abstimmung mit unserer Rechtsabteilung die einschlägigen SLA-Bestimmungen und werden innerhalb von 30 Werktagen auf die formelle SLA-Anfrage von Meridian antworten.
Wählen Sie alle zutreffenden Optionen aus – und klicken Sie dann auf „Senden“.
Donnerstagmorgen. David Chen ist zurück. Der Vorstand möchte wissen, was passiert ist. Ihre SLA-Strafen belaufen sich auf insgesamt 300.000 Euro. Drei Händlerkunden haben um „Beratungsgespräche“ gebeten.
Die Frage lautet nicht nur: „Was ist schiefgelaufen?“, sondern: „Wer war schuld?“ Der Firmware-Fehler von CloudVault hat den Ausfall verursacht. Doch laut Artikel 28 der DORA-Richtlinie sind Sie für das Management des IKT-Drittparteienrisikos verantwortlich. Der Anbieter hat versagt. Aber hat auch Ihre Aufsicht versagt?
„Der Ausfall wurde durch einen Firmware-Fehler bei CloudVault verursacht. Unser Risikomanagement für das Drittparteienrisiko hat jedoch versäumt, festzustellen, dass es eine Lücke im Wartungsplan für die Region EU-West gab. Das geht auf unsere Kappe.“
„Hier ist der Abhilfemaßnahmenplan: vierteljährliche Überprüfungen der Ausfallsicherheit unserer Lieferanten, automatisierte Überwachung der Wartungspläne unserer kritischen IKT-Anbieter sowie eine aktualisierte Dokumentation der Ausstiegsstrategie für CloudVault.“
Der Geschäftsführer nickt. Der Vorstand weiß diese Ehrlichkeit zu schätzen. Als Dr. Rossi Ihren Zwischenbericht prüft und dieselbe Verantwortungsbereitschaft feststellt, bemerkt sie: „Die Vorfallreaktion von Meridian zeugt von einem ausgereiften Ansatz beim Risikomanagement im Bereich des IKT-Drittparteienrisikos.“
Vorstandsvorsitzender – Patrick Lund: „Jordan, Ihre Verantwortungsbereitschaft wird zur Kenntnis genommen – und respektiert. Aber wir müssen über die Vertragsverlängerung mit CloudVault sprechen. Es handelt sich um einen Jahresvertrag im Wert von 4 Millionen Euro. Angesichts der Geschehnisse muss der Vorstand prüfen, ob wir aussteigen sollten.“ Die von Ihnen empfohlene Ausstiegsstrategie ist mit geschätzten Übergangskosten in Höhe von 2 Millionen Euro und einer Verzögerung von sechs Monaten bis zur nächsten Produkteinführung verbunden. Die richtige Antwort hat also ihren Preis.
Artikel 28 macht das Finanzunternehmen für das Management des IKT-Drittparteienrisikos verantwortlich – es reicht nicht aus, lediglich einen Vertrag zu haben. Die Aufsichtsbehörde will nicht hören, dass „es die Schuld des Anbieters war“. Sie will sehen, dass Sie die Aufsicht hatten, dass Sie daraus gelernt haben und dass Ihr Abhilfemaßnahmenplan eine Wiederholung verhindert. Vollständige Rechenschaftspflicht ist die richtige Antwort – doch dies eröffnet eine ernsthafte Diskussion über einen Vertrag im Wert von 4 Millionen Euro und die nächsten Schritte.
„Bei CloudVault kam es in der Region EU-West zu einem Firmware-Ausfall. Wir haben wie folgt reagiert: Wir haben den Vorfall eingestuft, die Verordnung innerhalb des 4-Stunden-Fensters eingehalten und Failover-Maßnahmen eingeleitet sowie den vollständigen Betrieb bis 19 Uhr wiederhergestellt.“
„Empfehlung: Verstärkte Aufsicht über die Lieferanten, einschließlich vierteljährlicher Überprüfungen der Ausfallsicherheit.“
David Chen – CEO: „Wann haben wir das letzte Mal eine Risikobewertung für CloudVault durchgeführt?“
Eine Pause. Der Vorsitzende des Vorstands blickt von seinen Notizen auf.
Sie: „Vor vierzehn Monaten.“
David: „Die DORA erfordert eine kontinuierliche Überwachung. Vierzehn Monate sind keine kontinuierliche Überwachung. Der Vorstand hat im Januar ein Budget für die Aufsicht über die Lieferanten bewilligt. Ich möchte wissen, warum diese Bewertung nicht aktualisiert wurde.“
Der Vorstand ist nach wie vor weitgehend zufrieden mit der Vorfallreaktion. Doch die 14-monatige Lücke ist nun aktenkundig. Dr. Rossis Zwischenbericht bestätigt dies: „Das Drittparteienrisiko des Unternehmens für CloudVault wurde zuletzt vor 14 Monaten aktualisiert. DORA-Artikel 28 schreibt eine kontinuierliche Überwachung vor, keine periodische Überprüfung.“
Ein kompetenter Reaktionszeitplan kann eine veraltete Risikobewertung nicht ausgleichen. Artikel 28 Absatz 2 verpflichtet Finanzunternehmen dazu, das IKT-Drittparteienrisiko fortlaufend zu steuern – was eine kontinuierliche Überwachung der Widerstandsfähigkeit Ihrer kritischen IKT-Drittdienstleister bedeutet und nicht nur eine jährliche Abhakübung. Eine Lücke von 14 Monaten zwischen den Risikobewertungen von Anbietern signalisiert der Aufsichtsbehörde, dass Ihr Rahmenwerk zur Aufsicht über Drittanbieter zwar auf dem Papier existiert, in der Praxis jedoch nicht umgesetzt wird. Der Zwischenbericht wird dies als strukturelle Lücke kennzeichnen.
„Die Infrastruktur von CloudVault ist ausgefallen. Die Firmware-Verwaltung des Unternehmens war unzureichend. Wir prüfen derzeit den Vertrag und erwägen die Verhängung von Vertragsstrafen.“
Der Geschäftsführer fragt: „Wussten wir von diesem Risiko?“ Die ehrliche Antwort lautet: Nein – denn Ihre letzte Risikobewertung der Lieferanten liegt bereits 14 Monate zurück. Sie sagen das jedoch nicht.
Dr. Rossis Bericht fällt weniger wohlwollend aus: „In der Darstellung des Unternehmens gegenüber dem Leitungsorgan wurde der Vorfall vollständig dem IKT-Drittdienstleister angelastet. Gemäß Artikel 28 Absatz 2 trägt das Finanzunternehmen jedoch die volle Verantwortung für die Einhaltung der DORA, einschließlich der Aufsicht über IKT-Drittdienstleister. Das Fehlen einer aktualisierten Risikobewertung deutet auf eine unzureichende laufende Überwachung hin.“
Artikel 28 Absatz 2 ist eindeutig: Das Finanzunternehmen trägt die volle Verantwortung für die Einhaltung der DORA-Vorschriften, einschließlich der Aufsicht über IKT-Drittdienstleister. Dem Anbieter die Schuld zu geben, ist keine Compliance-Strategie – es ist ein Beweis dafür, dass Ihr Rahmenwerk für das Drittparteienrisiko versagt hat. Die Aufsichtsbehörde erwartet drei Dinge: dass Sie vor dem Vorfall eine Aufsicht hatten, dass Sie währenddessen Verantwortung übernommen haben und dass Ihre Abhilfemaßnahmen eine Wiederholung verhindern. Dies als „ihre Schuld“ darzustellen, beweist nichts davon.
System Status
§ 19 Einreichungsfrist
01:42:18
remaining
Incident Feed
Erstmeldung eines Vorfalls – Artikel 19
Bitte füllen Sie alle Felder aus. Die zuständige Behörde wartet darauf.
Klicken Sie die vier Meldefristen in der richtigen Reihenfolge an – von der ersten bis zur letzten. Wählen Sie sie nacheinander aus.
Article 17 — ICT incident classification criteria
Article 19 — Reporting obligations (4h initial, 72h intermediate, 1 month final)
Article 28 — Third-party ICT risk management
Article 30 — Wesentliche Vertragsbestimmungen für IKT-Dienstleistungen
Sie haben eine Punktzahl von . Die 4-Stunden-Frist läuft ab. Möchten Sie es auf einem anderen Weg versuchen?