Die Uhr tickt: Ihr Fahrplan bis zum 31. Oktober

Die EZB verlangt von den bedeutenden Instituten einen Aktionsplan gegen KI-gestützte Cyberangriffe. Verlangt wird allerdings kein Strategiepapier, sondern der Nachweis operativer Bereitschaft. Dieser Beitrag ordnet ein, was konkret gefordert wird, wo es in der Praxis hakt und wie sich die verbleibenden Wochen nutzen lassen.

Am 7. Juli hat die EZB-Bankenaufsicht ein Schreiben an rund 110 bedeutende Institute gerichtet. Der Auftrag: bis zum 31. Oktober einen dedizierten Aktionsplan gegen KI-gestützte Cyberangriffe vorlegen. Dass die Aufsicht das Thema aufgreift, überrascht niemanden. Bemerkenswert ist, wie konkret sie dabei wird. Ein reines Strategiepapier reicht nicht mehr; gefragt ist der Nachweis operativer Leistungsfähigkeit. Am deutlichsten zeigt sich das beim Patch-Tempo. Wo früher drei Monate vertretbar schienen, um eine Sicherheitslücke zu schließen, zählt heute die Reaktion binnen Stunden. Und die Rechenschaft dafür trägt der Vorstand – sie ist nicht länger optional.

Adressiert wurde das Schreiben bewusst an die Geschäftsleitung, nicht an die IT-Abteilung. Dazu kommt eine Warnung des ESRB vom 25. Juni vor systemischen Cyberrisiken durch KI-Modelle, und zugleich hat die Aufsicht den jährlichen IT-Risiko-Fragebogen verschoben. Das Signal ist eindeutig: Dieses Thema gehört auf die Vorstandsagenda!

Die Grundlage des Aktionsplans

Der Aktionsplan schafft kein neues Regelwerk. Er konkretisiert, was DORA ohnehin fordert – nur mit spürbar höherem Anspruch an Tempo und Nachweisbarkeit. Die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz ist seit dem 17. Januar 2025 vollständig anwendbar. Sie bündelt die Widerstandsfähigkeit des Finanzsektors in fünf Säulen: dem Management von ITK-Risiken, der Behandlung und Meldung ITK-bezogener Vorfälle, dem Testen der digitalen Resilienz, dem Management von Drittparteirisiken sowie dem Informationsaustausch.

Der KI-Cyberaktionsplan erfindet davon nichts neu. Er verlangt, drei dieser Säulen unter dem Druck KI-gestützter Angriffe zu schärfen: das ITK-Risikomanagement (Weiß ich, was ich schützen muss? Wie schnell kann ich reagieren?), das Testen der Resilienz (Halten meine Annahmen einer realen Belastung stand?) und das Drittparteirisiko (Wie abhängig bin ich und von wem?). Wer DORA bereits ernst genommen hat, muss nicht bei null anfangen. Wer sie als reine Dokumentationsübung behandelt hat, wird jetzt spüren, wo die Lücken sind.

Wie die Aufsicht die Umsetzung bewerten wird

Das zuständige Joint Supervisory Team liest nicht den Wortlaut des Dokuments, es prüft die Substanz dahinter. Vier Dinge trennen einen belastbaren Plan von der bloßen Absichtserklärung:

• Greifbare Maßnahmen statt Prinzipien. Der Plan muss zeigen, welche Systeme betroffen sind, in welcher Reihenfolge sie bearbeitet werden und welche Zielwerte dabei gelten. Vage Verbesserungsabsichten genügen nicht.
• Namentlich benannte Verantwortliche statt Gremien. Erforderlich ist eine Person, die den Plan trägt – ausgestattet mit einem echten Mandat, nicht mit bloßer Zuständigkeit.
• Zugewiesene Ressourcen. Budget und Personal, sichtbar hinterlegt statt vage in Aussicht gestellt.

Der vierte Bestandteil ist zugleich die entscheidende Frage: Können Sie belegen, was Sie behaupten? Belegen heißt hier, drei Nachweise auf Anfrage erbringen zu können:

• Beim Patch-Tempo: Eine Auswertung, die für die zuletzt offengelegten kritischen Schwachstellen zeigt, wie viele Stunden oder Tage zwischen Offenlegung und flächendeckendem Patch lagen. Sie sollte die Werte als Verteilung und im Zeitverlauf ausweisen, mit Zeitstempel. Ein gerundeter Mittelwert genügt der Aufsicht nicht. Ein Beispiel: 95 % der kritischen CVEs wurden innerhalb von 72 Stunden geschlossen, Stand [Datum].
• Bei der Asset-Transparenz: ein Abgleich zwischen dem tatsächlich aufgefundenen Bestand und Ihrer CMDB, der die Differenz sichtbar macht. Er zeigt, wie viele Endpunkte, Server und Cloud-Workloads existieren, die in keiner offiziellen Liste stehen, und auf welchem Weg Sie diese nicht verwalteten und veralteten Systeme aufspüren. Die Abweichung selbst ist der aussagekräftigste Beleg.
• Beim Fortschritt: ein Bericht, den Sie kurzfristig, idealerweise in Minuten, aus einer einzigen Datenquelle erzeugen, datiert und nachvollziehbar. Fragt das JST heute nach, sollte die Antwort bereitstehen und nicht erst manuell aus verschiedenen Systemen zusammengesucht werden müssen.

Der gemeinsame Nenner: Zahlen mit Zeitstempel, aus einer belastbaren Quelle, jederzeit reproduzierbar.

Woran es in der Praxis hakt

Die Anforderungen klingen selbstverständlich. Dass sie vielen Instituten schwerfallen dürften, liegt nicht am Willen, sondern an gewachsenen Strukturen. Fünf Muster tauchen immer wieder auf:

• Zersplitterte Tool-Landschaft. Inventar, Schwachstellen, Patching und Reporting verteilen sich auf getrennte Lösungen. Jede Frage der Aufsicht wird zur Datensammlung über Systemgrenzen hinweg.
• Eine CMDB, die hinterherhinkt. Die Konfigurationsdatenbank bildet den Soll-, nicht den Ist-Zustand ab. Zwischen Realität und Datenbank klafft eine Lücke, die niemand in Echtzeit schließen kann.
• Blinde Flecken. Nicht verwaltete Geräte, Schatten-IT und veraltete Systeme stehen auf keiner Liste. Damit stellen sie die Einfallstore dar, auf die sich Angreifer fokussieren.
• Getrennte Welten von IT und Security. Wer Schwachstellen findet, ist oft nicht jener, der sie schließt. Jede Übergabe kostet Zeit, die knapp bemessen ist.
• Abhängigkeit vom Wartungsfenster. Wenn Exploits mittels KI in Stunden entstehen, genügen reaktive, periodische Patch-Zyklen nicht mehr.

Hinzu kommt: Den Nachweis gegenüber der Aufsicht erarbeiten sich viele Organisationen noch manuell mittels Tabellen, die jemand über Nacht zusammenstellt. Das ist weder wiederholbar noch belastbar, und es skaliert nicht, sollte das JST kurzfristig nachfragen.

Erfolgreich werden die Institute sein, die die Frist nicht als lästige Compliance-Übung begreifen, sondern als Anlass, die Automatisierung und die operativen Veränderungen umzusetzen, die längst überfällig sind.

Ihre Roadmap für die nächsten Wochen

In der kurzen Zeit bis zum 31. Oktober entscheidet, was den Plan operativ untermauert. Die folgenden vier Aufgaben greifen ineinander:

1. Bestand lückenlos klären. Verschaffen Sie sich einen vollständigen, Echtzeit-Überblick über alle Endpunkte, Server und Cloud-Workloads, einschließlich der nicht verwalteten und veralteten Systeme. Gleichen Sie das Ergebnis mit Ihrer CMDB ab, denn die Differenz ist Ihr Risiko. Erst wenn Sie wissen, was Sie betreiben, können Sie sinnvoll priorisieren.
   
2. Tempo messbar machen. Definieren Sie die Zeit von der Offenlegung einer kritischen Schwachstelle bis zum flächendeckenden Patch als Kennzahl (Mean-Time-to-Patch) und beginnen Sie, diese zu erheben. Lösen Sie die Erhebung vom Wartungsfenster, sonst messen Sie Ihren Kalender, nicht Ihre Fähigkeit zu reagieren.
3. Nachweis aufsetzen. Sorgen Sie dafür, dass sich Fortschritt auf Knopfdruck aus einer einzigen Datenquelle belegen lässt, mit Zeitstempel und vorlagefertig für das JST. Ein Bericht, den Sie in Minuten erzeugen, überzeugt mehr als einer, den Sie tagelang zusammentragen.
4. Verantwortung verankern. Benennen Sie eine rechenschaftspflichtige Person mit Mandat und Budget und bringen Sie das Thema in einen festen Board-Takt gegen dieselben Kennzahlen, an denen auch die Aufsicht Sie messen wird.

Die grobe Taktung: zuerst Transparenz und Kennzahlen, darauf aufbauend Automatisierung und Nachweis, die Governance von Anfang an mitlaufend. Wer in dieser Reihenfolge arbeitet, hat am 31. Oktober einen Plan – und die Belege, die ihn tragen.

Vom Plan zur nachweisbaren Realität

Als Plattform für Autonomous IT führt Tanium Inventar, Schwachstellen, Patching und Nachweis in einer gemeinsamen, jederzeit aktuellen Datenbasis zusammen. Ein schlanker Agent ersetzt damit die zersplitterte Tool-Landschaft. Das Ergebnis: Echtzeit-Transparenz über sämtliche Endgeräte, automatisierte Patch-Ausführung und autonome Reaktionsfähigkeit. Aus einem glaubwürdigen Aktionsplan wird so eine nachweisbare operative Realität, die einer aufsichtlichen Prüfung standhält.

Die Frist ist gesetzt. Die Frage ist nicht, ob Sie einen Plan vorlegen können, sondern ob er belastbar ist.

Machen Sie den EZB-AI-Cyber-Readiness-Check: ohne Terminvereinbarung, Ergebnis in wenigen Minuten, nur für Ihre interne Verwendung.