KI-beschleunigte Cyberangriffe unter DORA: Der 5-Punkte-Plan für LSIs, Vorstand und ICT-Manager

Künstliche Intelligenz schafft keinen vollständig neuen Cybersicherheitsrisikotyp. Sie verändert jedoch Geschwindigkeit, Umfang und Qualität bekannter Angriffsmuster. Schwachstellen können schneller identifiziert und ausgenutzt, funktionsfähige Exploits schneller erstellt, Phishing- und Social-Engineering-Angriffe überzeugender gestaltet und Angriffe stärker automatisiert werden. Hinzu kommen Risiken aus Software-Lieferketten, Open-Source-Komponenten, Cloud-Umgebungen und ausgelagerten IKT-Dienstleistungen.

Die Europäische Zentralbank beschreibt diese Entwicklung als langfristige Veränderung der Bedrohungslage. KI erzeugt nicht zwingend völlig neue Angriffsarten, kann aber die Geschwindigkeit und Skalierung etablierter Cyberangriffe erheblich verstärken. Im Mittelpunkt stehen daher nicht isolierte KI-Sonderregelungen, sondern die Frage, ob Institute ihre bestehenden Schutz-, Erkennungs-, Reaktions- und Wiederanlauffähigkeiten an diese beschleunigte Bedrohungslage anpassen.

Für weniger bedeutende Institute — Less Significant Institutions, LSIs — folgt aus dem EZB-Schreiben vom 7. Juli 2026 keine pauschale Verpflichtung, bis zum 31. Oktober 2026 einen KI-Cybersicherheits-Aktionsplan an ein Joint Supervisory Team der EZB zu übermitteln. Das Schreiben richtet sich ausdrücklich an bedeutende Institute — Significant Institutions, SIs — und fordert diese auf, bis zum 31. Oktober 2026 einen risikobasierten Aktionsplan an ihr zuständiges Joint Supervisory Team zu übermitteln.

Für LSIs ist das Schreiben dennoch ein deutliches Aufsichtssignal. Entscheidend ist nicht, ob ein LSI einen SI-spezifischen Aktionsplan übernimmt. Entscheidend ist, ob das Institut nachvollziehbar belegen kann, dass es KI-beschleunigte Cyberrisiken erkannt, bewertet, priorisiert, behandelt, getestet und an das Leitungsorgan berichtet hat.

DORA verlangt keine vollständige Risikofreiheit und keine jederzeit vollständig modernisierte IKT-Landschaft. Gefordert ist vielmehr ein angemessener, umfassender, dokumentierter und wirksamer IKT-Risikomanagementrahmen. Dieser muss sich an Größe, Gesamtrisikoprofil sowie Art, Umfang und Komplexität der Geschäftstätigkeit orientieren. Proportionalität reduziert dabei nicht die Pflicht zur wirksamen Risikosteuerung. Sie bestimmt vielmehr die angemessene Ausgestaltung von Governance, Kontrollen, Dokumentation und Ressourcen.

Für LSIs ist deshalb regelmäßig kein isoliertes KI-Sonderprogramm erforderlich. Angemessen ist ein dokumentierter, risikobasierter DORA-Management-Review. Dieser sollte die individuelle IKT-Landschaft, kritische oder wichtige Funktionen, externe Angriffsflächen, Auslagerungs- und Dienstleisterabhängigkeiten, offene Schwachstellen sowie bekannte Prüfungs- oder Aufsichtsfeststellungen einbeziehen.

II. Verantwortung von Vorstand und Geschäftsleitung

Art. 5 Abs. 2 DORA weist dem Leitungsorgan eine klare Governance-Verantwortung zu. Das Leitungsorgan definiert, genehmigt, überwacht und verantwortet die Umsetzung des IKT-Risikomanagementrahmens. Dazu gehören insbesondere die Festlegung einer angemessenen Risikotoleranz für IKT-Risiken, die Genehmigung relevanter Strategien und Policies, die Bereitstellung ausreichender Ressourcen sowie die regelmäßige Überprüfung der Wirksamkeit des Rahmens.

Dies bedeutet nicht, dass Vorstand oder Geschäftsleitung technische Einzelmaßnahmen selbst ausführen, Sicherheitsupdates freigeben oder einzelne Protokolldaten prüfen müssen. Solche Aufgaben sind operativ an IT, Informationssicherheit, Datenschutz, Business Continuity Management, Auslagerungsmanagement, Compliance und Fachbereiche zu delegieren.

Nicht delegierbar bleibt jedoch die Verantwortung für:

• Die Einrichtung einer angemessenen IKT-Risikogovernance.
• Die Festlegung von Risikotoleranzen, Eskalationswegen und Entscheidungsrechten.
• Die Ausstattung der zuständigen Funktionen mit ausreichenden personellen, finanziellen und technischen Ressourcen.
• Die Überwachung wesentlicher IKT-, Cyber-, Resilienz- und Drittparteirisiken.
• Die Entscheidung über wesentliche Maßnahmen, Prioritäten und befristete Restrisikoakzeptanzen.
• Die Nachverfolgung kritischer Maßnahmen, Ausnahmen und Eskalationen.
• Die regelmäßige Überprüfung der Wirksamkeit des IKT-Risikomanagementrahmens.

Eine persönliche Haftung entsteht nicht automatisch durch einen Cybervorfall, einen DORA-Verstoß oder eine aufsichtliche Feststellung. Bei einer Aktiengesellschaft setzt eine Innenhaftung nach § 93 Abs. 2 AktG grundsätzlich voraus, dass ein Vorstandsmitglied seine Pflichten schuldhaft verletzt und der Gesellschaft hierdurch ein Schaden entsteht. Für Geschäftsführer einer GmbH gilt nach § 43 Abs. 2 GmbHG ein entsprechender Haftungsmaßstab.

Eine aufsichtliche Feststellung oder ein DORA-Verstoß kann jedoch ein erhebliches Indiz dafür sein, dass Organisations-, Informations-, Überwachungs- oder Reaktionspflichten nicht angemessen erfüllt wurden. Maßgeblich bleiben stets der Einzelfall, der konkrete Pflichtenkreis, die Informationslage, die Qualität und Dokumentation des Entscheidungsprozesses, ein mögliches Verschulden sowie ein Schaden der Gesellschaft.

Kritisch wird es insbesondere dann, wenn bekannte Risiken trotz klarer Hinweise nicht adressiert werden, entscheidungsrelevante Informationen das Leitungsorgan nicht erreichen, Ressourcen trotz dokumentierter Lücken nicht bereitgestellt werden, Ausnahmen unbegrenzt fortbestehen oder beschlossene Maßnahmen trotz wiederholter Eskalation nicht umgesetzt werden.

Die belastbare Managementformel lautet:

Risiko erkennen. Maßnahmen beschließen. Umsetzung überwachen. Restrisiken dokumentieren.

III. Der 5-Punkte-Plan

1. Betroffenheit und Angriffsflächen bewerten

Der erste Schritt ist keine neue KI-Policy. Erforderlich ist eine anlassbezogene Überprüfung und Aktualisierung der bestehenden IKT-Risikoanalyse.

Die Kernfrage lautet:

Wo kann ein KI-beschleunigter Angriff zu Geschäftsausfall, Datenabfluss, Betrug, Manipulation, einer Beeinträchtigung kritischer oder wichtiger Funktionen oder einem schwerwiegenden IKT-bezogenen Vorfall führen?

Art. 8 DORA verlangt, dass Finanzunternehmen alle IKT-gestützten Geschäftsfunktionen, Informationsassets und IKT-Assets identifizieren, klassifizieren und dokumentieren. Dabei sind auch Abhängigkeiten zu IKT-Drittdienstleistern zu erfassen. Für Institute, die nicht als Kleinstunternehmen einzustufen sind, ist zudem das Risiko von Legacy-IKT-Systemen angemessen zu berücksichtigen.

Die Bewertung sollte mindestens folgende Bereiche einbeziehen:

• Kundenportale, Online-Banking, Mobile Banking, Web-Anwendungen und APIs.
• VPNs, Remote-Zugänge, externe Fernwartung und administrativ nutzbare Oberflächen.
• Cloud-Tenants, SaaS-Anwendungen und Cloud-Management-Konten.
• Identitäts-, Berechtigungs- und privilegierte Administrationssysteme.
• Zahlungsverkehr, Kernbankverfahren, Kredit-, Handels- und Meldeprozesse.
• AML-Transaktionsmonitoring, Sanktionsscreening, KYC-Systeme und Video-Ident-Verfahren.
• Backup-, Recovery-, Logging-, SIEM-, EDR- und Security-Orchestration-Systeme.
• Nicht unterstützte, End-of-Life- oder nur schwer patchbare Legacy-Systeme.
• Kritische IKT-Drittdienstleister, wesentliche Subdienstleister und relevante Open-Source-Komponenten.
• Kritische Datenbestände, kryptografische Schlüssel, Schnittstellen und automatisierte Datenübertragungen.

Nicht nur das einzelne System, sondern der konkrete Angriffspfad ist zu bewerten:

Eintrittspunkt ? Kompromittierung ? Privilegienausweitung ? laterale Ausbreitung ? Geschäftsschaden

Ein Angreifer kann beispielsweise eine Schwachstelle in einem Kundenportal oder eine kompromittierte Cloud-Admin-Berechtigung nutzen. Daraus können unberechtigte Zugriffe auf Kundendaten, Zahlungsbetrug, Manipulationen, Störungen im Zahlungsverkehr oder die Ausbreitung in weitere Systeme folgen.

Die Bewertung sollte deshalb auch erfassen, ob ein Angriff durch bestehende Schutzmaßnahmen rechtzeitig erkannt, eingedämmt und forensisch aufgeklärt werden kann. Hierzu gehören insbesondere Multi-Faktor-Authentifizierung, Least-Privilege-Konzepte, Schutz privilegierter Konten, Netzwerksegmentierung, EDR, SIEM, zentrale Protokollierung und belastbare Eskalationswege.

Ergebnis: Eine Top-10-Liste der wesentlichsten KI-beschleunigten Cyberrisiken mit Risikoeigner, betroffenem Asset oder Prozess, Angriffspfad, bestehenden Kontrollen, Restrisiko, Maßnahme, Termin und Eskalationsstatus.

2. Schwachstellen-, Patch- und Mitigation-Management realistisch testen

Eine Patch-Policy beweist noch nicht, dass ein Institut bei einer kritischen Schwachstelle handlungsfähig ist.

Art. 10 der Delegierten Verordnung (EU) 2024/1774 verlangt dokumentierte Verfahren für das Schwachstellen- und Patch-Management. Dazu gehören zuverlässige Informationsquellen, risikogerechte automatisierte Schwachstellenscans, die Priorisierung von Patches und sonstigen Gegenmaßnahmen, die Überwachung und Verifizierung der Behebung sowie die Dokumentation festgestellter Schwachstellen und ihres Bearbeitungsstatus.

Für IKT-Assets, die kritische oder wichtige Funktionen unterstützen, verlangt die Delegierte Verordnung regelmäßig eine mindestens wöchentliche automatisierte Schwachstellenprüfung. Die Priorisierung muss nicht allein technische Scores, sondern auch die konkrete Gefährdungslage, die Exponiertheit eines Systems, seine Bedeutung für Geschäftsprozesse und mögliche Auswirkungen auf kritische oder wichtige Funktionen berücksichtigen.

Das Management-Reporting sollte daher nicht bei allgemeinen Patchquoten stehen bleiben. Entscheidend sind insbesondere folgende Fragen:

• Welche Systeme werden nicht gescannt, nicht gepatcht oder nicht ausreichend überwacht?
• Welche kritischen oder hoch priorisierten Schwachstellen sind überfällig?
• Welche offenen Schwachstellen betreffen extern erreichbare, privilegierte oder geschäftskritische Systeme?
• Gibt es Hinweise auf aktive Ausnutzung oder relevante Threat-Intelligence-Meldungen?
• Welche Systeme sind wegen Legacy, Herstellerabhängigkeit oder Betriebsrestriktionen nicht kurzfristig patchbar?
• Besteht für jede nicht kurzfristig behebbare Schwachstelle eine dokumentierte kompensierende Kontrolle?
• Wer kann außerhalb regulärer Change-Fenster Notfallmaßnahmen anordnen?
• Haben Ausnahmen einen Owner, eine Begründung, eine Risikobewertung, kompensierende Kontrollen, einen Termin und ein Ablaufdatum?
• Wird die Behebung technisch verifiziert oder lediglich die Patch-Installation dokumentiert?

CVSS-Werte allein reichen nicht aus. Eine technisch mittel bewertete Schwachstelle kann geschäftskritisch sein, wenn sie ein extern erreichbares Kundenportal, einen privilegierten Zugang, ein Cloud-Management-Konto oder eine kritische IKT-gestützte Funktion betrifft.

Institute sollten das Notfallverfahren mindestens einmal praktisch testen. Ein geeignetes Szenario ist eine aktiv ausgenutzte kritische Schwachstelle in einem extern erreichbaren System, für die noch kein Herstellerpatch verfügbar ist.

Zu prüfen ist dann, ob das Institut kurzfristig geeignete Gegenmaßnahmen umsetzen kann, beispielsweise:

• Abschaltung oder Einschränkung der betroffenen Funktion.
• Segmentierung oder zusätzliche Netzwerkfilterung.
• Einschränkung externer Zugriffe.
• Nachschärfung von MFA und privilegierten Berechtigungen.
• Verstärkte Überwachung von Logs, Datenabflüssen und Indicators of Compromise.
• Einsatz eines virtuellen Patches, einer Web Application Firewall oder anderer geeigneter Schutzmaßnahmen.
• Aktivierung eines Notbetriebs oder eines alternativen Zugangswegs.

Ergebnis: Ein Vulnerability-, Patch- und Mitigation-Dashboard mit P1-/P2-Schwachstellen, betroffenen Systemen, Fälligkeiten, Ausnahmen, kompensierenden Kontrollen, Eskalationen, Restrisiken und Management-Reporting.

3. IKT-Drittdienstleister und Lieferketten krisenfest steuern

DORA behandelt IKT-Drittrisiken nicht als bloßes Einkaufs-, Vertrags- oder Auslagerungsthema. Die Nutzung von Cloud-, SaaS-, Managed-Security-, Hosting-, Telekommunikations- oder Kernbankdienstleistern verlagert die Verantwortung für die Einhaltung regulatorischer Pflichten nicht auf den Provider.

Art. 28 DORA verlangt, IKT-Drittparteirisiken als integralen Bestandteil des IKT-Risikomanagementrahmens zu steuern. Art. 30 DORA enthält zusätzliche Anforderungen an Vertragsvereinbarungen über die Nutzung von IKT-Dienstleistungen, insbesondere bei Leistungen zur Unterstützung kritischer oder wichtiger Funktionen. Dazu gehören unter anderem Regelungen zu Leistungsbeschreibungen, Datenstandorten, Verfügbarkeit, Incident-Unterstützung, Audit- und Zugangsrechten, Kündigungsrechten sowie Übergangs- und Exit-Vorkehrungen.

Prüfen Sie zunächst die wichtigsten zehn bis zwanzig IKT-Dienstleister. Priorisieren Sie Anbieter, die kritische oder wichtige Funktionen unterstützen, privilegierte Zugriffe besitzen, zentrale Daten verarbeiten oder einen Single Point of Failure darstellen.

Zu prüfen sind insbesondere:

• Welche kritische oder wichtige Funktion unterstützt der Dienstleister?
• Welche Daten verarbeitet er und welche Systeme kann er administrativ erreichen?
• Wie schnell informiert er über kritische Schwachstellen, aktive Ausnutzung, Sicherheitsvorfälle und relevante Änderungen?
• Bestehen belastbare Patch-, Mitigation-, Incident- und Recovery-SLAs?
• Gibt es einen funktionsfähigen 24/7-Eskalationskontakt?
• Sind Informations-, Zugangs-, Audit- und Weisungsrechte ausreichend ausgestaltet und praktisch nutzbar?
• Sind wesentliche Subdienstleister, Unterauslagerungen und relevante Lieferketten transparent?
• Liegen belastbare Nachweise zu Backup, Recovery, Logging und Security Monitoring vor?
• Besteht eine nachvollziehbare Exit-, Übergangs- oder Substitutionsstrategie?
• Welche Konzentrations-, Lock-in- oder Single-Point-of-Failure-Risiken bestehen?
• Kann das Institut die Auswirkungen eines Provider-Ausfalls oder einer Provider-Kompromittierung auf kritische Geschäftsprozesse realistisch bewerten?

Die EZB nennt die Überprüfung der Drittparteiensteuerung, einschließlich kritischer IKT-Anbieter sowie Drittsoftware- und Open-Source-Abhängigkeiten, ausdrücklich als prioritäres Handlungsfeld bei KI-beschleunigten Cyberbedrohungen. Für LSIs ist dies keine Verpflichtung zur Übernahme eines SI-spezifischen Aktionsplans. Es ist jedoch ein nachvollziehbarer, risikoorientierter Maßstab für die Priorisierung eigener Maßnahmen.

Ergebnis: Eine Provider- und Lieferkettenlandkarte mit Kritikalität, unterstützter Funktion, Konzentrationsrisiko, vorhandenen Nachweisen, offenen Vertrags- oder SLA-Lücken, verantwortlicher Stelle und priorisiertem Remediationsplan.

4. Detection, Incident Response und Recovery nachweisen

Ein Backup allein ist kein Resilienznachweis. Resilienz zeigt sich erst, wenn ein Angriff rechtzeitig erkannt, eingedämmt, aufgeklärt, kommuniziert und ein kontrollierter Wiederanlauf durchgeführt werden kann.

KI-beschleunigte Angriffe verkürzen die Zeit zwischen Erstkompromittierung, Privilegienausweitung, lateraler Bewegung und möglichem Geschäftsschaden. Institute sollten daher insbesondere externe Anwendungen, Cloud-Management-Konten, privilegierte Zugriffe, Identitätsereignisse, API-Zugriffe, auffällige Datenübertragungen und relevante Indicators of Compromise wirksam überwachen.

Zu prüfen sind insbesondere folgende Aspekte:

• Werden sicherheitsrelevante Logs zentral, vollständig und ausreichend lange gespeichert?
• Sind Kundenportale, Cloud-Management-Konten, VPNs, Administratorzugriffe und kritische Schnittstellen in das Monitoring einbezogen?
• Werden ungewöhnliche Admin-Anmeldungen, unmögliche Reisebewegungen, Berechtigungsänderungen, Massendownloads und atypische Datenabflüsse erkannt?
• Können EDR-, SIEM-, SOAR- oder vergleichbare Systeme Alarme priorisieren und an die zuständigen Stellen eskalieren?
• Besteht eine belastbare 24/7-Reaktionsfähigkeit oder eine vertraglich geregelte externe Unterstützung?
• Können forensisch relevante Daten gesichert werden, bevor Systeme bereinigt, abgeschaltet oder wiederhergestellt werden?
• Funktionieren Eskalation und Krisenkommunikation auch dann, wenn E-Mail oder Kollaborationstools beeinträchtigt sind?

Der Einsatz KI-gestützter Detection- oder Defence-Tools kann sinnvoll sein. Er ersetzt jedoch weder klare Verantwortlichkeiten noch menschliche Prüfung, belastbare Datenqualität, dokumentierte Entscheidungswege oder geeignete Kontrollmechanismen.

Art. 17 bis 19 DORA regeln Anforderungen an das Management, die Klassifizierung und die Meldung IKT-bezogener Vorfälle. Die digitalen operationellen Resilienztests nach Art. 24 und 25 DORA dienen dazu, die Wirksamkeit von IKT-Systemen, Kontrollen und Prozessen regelmäßig zu überprüfen.

Führen Sie mindestens eine Tabletop-Übung durch. Ein realistisches Szenario lautet:

• Eine kritische Zero-Day-Schwachstelle betrifft eine externe Zugangsplattform. Es gibt Hinweise auf aktive Ausnutzung. Parallel werden ungewöhnliche Administrator-Anmeldungen und auffällige Datenübertragungen festgestellt. Der Provider kann erst am Folgetag patchen. Das Kundenportal muss möglicherweise eingeschränkt oder abgeschaltet werden.

Die Übung sollte konkrete Entscheidungen erzwingen:

• Wer klassifiziert den Vorfall und aktiviert den Krisenmodus?
• Wer entscheidet über Abschaltung, Notbetrieb oder eingeschränkten Weiterbetrieb?
• Welche forensischen Daten müssen unverzüglich gesichert werden?
• Wann werden Vorstand, Datenschutz, Compliance, Kommunikation, Auslagerungsmanagement und Fachbereiche eingebunden?
• Wann ist eine DORA-Meldung eines schwerwiegenden IKT-bezogenen Vorfalls zu prüfen?
• Wie kommuniziert der Krisenstab bei Ausfall interner Kommunikationssysteme?
• Können kritische Anwendungen innerhalb der vorgesehenen Wiederanlaufzeit wiederhergestellt werden?
• Können Daten konsistent und innerhalb des definierten Datenverlustfensters wiederhergestellt werden?
• Werden Lessons Learned verbindlich in das Maßnahmenregister, die Risikoanalyse und die Kontrollarchitektur überführt?

Ergebnis: Ein Testprotokoll, dokumentierte Krisenentscheidungen, gesicherte Evidenzen, Lessons Learned, ein verbindliches Maßnahmenregister und ein belastbarer Restore-Nachweis.

5. Vorstand entscheidungsfähig machen

Der Vorstand benötigt keinen 80-seitigen Technikbericht. Er benötigt eine belastbare Entscheidungsgrundlage mit klaren Risiken, Auswirkungen, Maßnahmen, Ressourcenbedarf und Beschlusspunkten.

Bewährt ist eine Executive Summary von zwei bis vier Seiten, ergänzt durch technische Anlagen. Sie sollte mindestens enthalten:

• Die fünf bis zehn wichtigsten IKT-, Cyber- und Drittparteirisiken.
• Wesentliche externe Angriffsflächen und nicht ausreichend abgedeckte Systeme.
• Offene kritische und überfällige Schwachstellen einschließlich Ausnahme- und Kompensationslage.
• Risiken aus Legacy-, End-of-Life- und nicht kurzfristig patchbaren Systemen.
• Wesentliche Detection- und Monitoring-Lücken.
• Kritische Provider-, Subdienstleister- und Konzentrationsrisiken.
• Ergebnisse aus Vorfällen, Übungen, Restore-Tests und Kontrollprüfungen.
• Maßnahmen, Owner, Termine, Budgetbedarf, Abhängigkeiten und Eskalationsstatus.
• Befristete Restrisiken sowie erforderliche Managemententscheidungen.

Der Vorstand sollte mindestens drei Entscheidungen ausdrücklich und nachvollziehbar dokumentieren:

• Welche kritischen Risiken, Systeme und Maßnahmen werden priorisiert?
• Welche personellen, finanziellen und technischen Ressourcen werden bereitgestellt?
• Welche Restrisiken werden unter welchen kompensierenden Kontrollen und bis zu welchem Termin befristet akzeptiert?

Der Vorstand sollte ferner sicherstellen, dass die veränderte Bedrohungslage in Schulungs-, Awareness- und Krisenübungsprogramme einfließt. Dies umfasst insbesondere KI-optimiertes Phishing, überzeugende CEO-Fraud- und Deepfake-Szenarien, den Missbrauch privilegierter Zugänge, atypische Zahlungsanweisungen sowie sichere und getestete Eskalationswege.

Art. 5 DORA verlangt nicht, dass das Leitungsorgan technische Einzellösungen entwirft. Es verlangt jedoch, dass das Leitungsorgan den IKT-Risikomanagementrahmen wirksam steuert, überwacht und die Verantwortung für seine Umsetzung übernimmt.

Ergebnis: Eine Vorstandsvorlage, ein dokumentierter Beschluss, ein Maßnahmen- und Eskalationsmechanismus sowie ein fester Reporting-Rhythmus.

IV. Fazit

Für LSIs besteht aus dem EZB-Schreiben vom 7. Juli 2026 keine pauschale Pflicht, bis zum 31. Oktober 2026 einen SI-spezifischen KI-Cybersicherheits-Aktionsplan an ein Joint Supervisory Team zu übermitteln.

Das EZB-Schreiben zeigt jedoch, welche Themen die Aufsicht derzeit priorisiert: Schutz externer Angriffsflächen, beschleunigtes Schwachstellen- und Patch-Management, Monitoring und Detection, Steuerung kritischer IKT-Drittparteien und Lieferketten, Defence-in-Depth, Legacy-Risiken sowie getestete Incident- und Recovery-Fähigkeiten.

Die richtige Reaktion eines LSI ist kein abstraktes KI-Sonderprogramm ohne Bezug zur tatsächlichen Risikolage. Sinnvoll ist ein kompakter, dokumentierter und risikobasierter DORA-Management-Review:

Kritische Risiken erfassen. Kontrolllücken priorisieren. Maßnahmen beschließen. Wirksamkeit testen. Restrisiken dokumentieren. Vorstand entscheidungsfähig machen.

Entscheidend ist nicht die bloße Existenz einer eigenständigen KI-Policy. Entscheidend ist, ob das Institut seine tatsächlichen IKT-Risiken wirksam, angemessen und nachvollziehbar steuert. Soweit das Institut selbst KI-Systeme einsetzt, können daneben zusätzliche Anforderungen aus KI-Governance, Datenschutz, Informationssicherheit, Modellrisikomanagement und dem AI Act relevant werden.

V. Quellenverzeichnis

Europäisches Recht

Amtsblatt der Europäischen Union – Verordnungen

Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationelle Resilienz im Finanzsektor und zur Änderung der Verordnungen (EG) Nr. 1060/2009, (EU) Nr. 648/2012, (EU) Nr. 600/2014, (EU) Nr. 909/2014 und (EU) 2016/1011 (Digital Operational Resilience Act – DORA), ABl. L 333 vom 27. Dezember 2022, S. 1: https://eur-lex.europa.eu/…:32022R2554, abgerufen am 15. September 2026.

Insbesondere relevant: Art. 5 zur Verantwortung des Leitungsorgans, Art. 6 zum IKT-Risikomanagementrahmen, Art. 8 zur Identifizierung und Klassifizierung von IKT-Assets, Art. 17 bis 19 zum Management, zur Klassifizierung und Meldung IKT-bezogener Vorfälle, Art. 24 und 25 zu Tests der digitalen operationalen Resilienz sowie Art. 28 bis 30 zu IKT-Drittparteirisiken und vertraglichen Vereinbarungen.

Delegierte Verordnung (EU) 2024/1774 der Kommission vom 13. März 2024 zur Ergänzung der Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates durch technische Regulierungsstandards zur Festlegung von Instrumenten, Methoden, Prozessen und Strategien für das IKT-Risikomanagement und des vereinfachten IKT-Risikomanagementrahmens, ABl. L vom 25. Juni 2024: https://eur-lex.europa.eu/…:32024R1774, abgerufen am 15. September 2026.

Insbesondere relevant: Art. 3 zur IKT-Risikobewertung, Art. 5 zur IKT-Asset-Management-Policy sowie Art. 10 zum Schwachstellen- und Patch-Management.

Nationales Recht Deutschland

Bundesrecht

Aktiengesetz (AktG) vom 6. September 1965, BGBl. I S. 1089, in der jeweils geltenden Fassung: https://www.gesetze-im-internet.de/…, abgerufen am 15. September 2026.

Insbesondere relevant: § 93 AktG zur Sorgfaltspflicht und Verantwortlichkeit der Vorstandsmitglieder.

Gesetz betreffend die Gesellschaften mit beschränkter Haftung (GmbHG) in der jeweils geltenden Fassung: https://www.gesetze-im-internet.de/…, abgerufen am 15. September 2026.

Insbesondere relevant: § 43 GmbHG zur Sorgfaltspflicht und Verantwortlichkeit der Geschäftsführer.

Behördliche Veröffentlichungen und Aufsichtspraxis

Europäische Zentralbank (EZB) – Bankenaufsicht: Addressing AI-enabled cybersecurity threats, Schreiben der Vorsitzenden des Aufsichtsgremiums der EZB vom 7. Juli 2026 an die Chief Executive Officers bedeutender Institute unter direkter EZB-Aufsicht: https://www.bankingsupervision.europa.eu/…, abgerufen am 15. September 2026.

Relevanz für den Beitrag: Das Schreiben richtet sich an bedeutende Institute und fordert einen risikobasierten Aktionsplan bis zum 31. Oktober 2026 an das zuständige Joint Supervisory Team. Inhaltlich stellt die EZB insbesondere auf Schutz externer Angriffsflächen, beschleunigtes Schwachstellen- und Patch-Management, Monitoring und Detection, Drittparteien- und Lieferkettenrisiken, Defence-in-Depth, Legacy-Risiken sowie Incident Response und Recovery ab.

Über S+P Compliance

S+P Compliance ist eine Compliance-Beratung mit Sitz in München und unterstützt BaFin-beaufsichtigte Institute bei der Organisation und Durchführung regulatorischer Kontrollaufgaben. Zu den Tätigkeitsfeldern gehören ausgelagerte Geldwäsche- und Compliance-Funktionen, das Auslagerungsmanagement sowie die Interne Revision. Das Unternehmen verfügt über ein nach ISO/IEC 27001:2022 zertifiziertes Informationssicherheitsmanagementsystem. Über das S+P Unternehmerforum werden Fachseminare für Beauftragte, Führungskräfte und Kontrollfunktionen angeboten, darunter zu KYC und Kundensorgfaltspflichten.