Worum es geht
Diese letzte Einheit liefert keinen neuen Inhalt — sie verdichtet, was in 13.1 bis 13.4 erarbeitet wurde, zu einem konkreten Plan. Das didaktische Versprechen: Wer diese Einheit gelesen hat, kann am nächsten Montagmorgen in eine Vorstandssitzung gehen und drei Sätze sagen: „Wir wissen, wo wir stehen. Wir wissen, was wir die nächsten 90 Tage tun. Wir wissen, welche Entscheidungen wir von Ihnen brauchen.”
Vier Bausteine bringen uns dorthin: eine Diagnose, ein gestaffelter Aktionsplan, eine Verteilung über die drei Verteidigungslinien und ein Vorstands-Briefing.
Baustein 1 — Zehn Diagnose-Fragen
Bevor irgendein Plan greift, muss klar sein, wo die Bank steht. Die folgenden zehn Fragen sind die banking-spezifische Übersetzung der Diagnose-Logik aus dem CSA-Strategy-Briefing „AI Vulnerability Storm”. Sie sind bewusst so formuliert, dass eine ehrliche Antwort möglich ist — nicht eine Policy-Antwort.
| # | Frage | Was sie offenlegt |
|---|---|---|
| 1 | Welche offizielle Haltung hat die Bank heute zu AI-Werkzeugen — erlaubt, geduldet, restriktiv, unbekannt? | Die Reife der AI-Governance |
| 2 | Dürfen Mitarbeiter Coding Agents im Bank-Kontext nutzen, mit welchen Leitplanken? | Schatten-IT-Risiko |
| 3 | Können Bank-Entwickler in Open-Source-Projekte beitragen, ohne IP- und Compliance-Risiken zu erzeugen? | Lieferketten-Reife |
| 4 | Haben wir disziplinierte Kontrolle über Repositories, Artefakte, MCP-Server und agentische Komponenten? | Software-Supply-Chain-Hygiene |
| 5 | Gibt es einen wirksamen Security Gate zwischen Code-Änderung und Bank-Produktion? | Pipeline-Integrität |
| 6 | Ist Security operativ wirksam oder primär beratend — mit einem konkreten Beispiel aus dem letzten Jahr? | Durchsetzungsfähigkeit |
| 7 | Was war die schnellste sicherheitsgetriebene Produktionsänderung im letzten Jahr — gemessen in Stunden? | Reaktionsfähigkeit der Organisation |
| 8 | Sind unsere | Schutzgut-Klarheit |
| 9 | Können wir bei kritischen Drittanbietern dringende Tickets priorisiert bekommen — mit Beleg? | Lieferanten-Hebel |
| 10 | Hat der Vorstand eine arbeitsfähige Definition von „dringend”? | Eskalations-Disziplin |
Baustein 2 — Der 90-Tage-Plan in drei Phasen
Der Plan ist bewusst in drei Phasen zu je 30 Tagen gestaffelt. Jede Phase hat ein klares Leitmotiv, definierte Lieferungen und einen Übergangs-Meilenstein:
Tage 1–30: Lagebild und Quick Wins
Leitmotiv: Sehen, was da ist. Anfangen, ohne neue Architektur abzuwarten.
- Diagnose abschließen. Die zehn Fragen aus Baustein 1 werden mit Reifegraden hinterlegt. Ergebnis ist ein einseitiges Lagebild.
- Coding Agents in mindestens drei Sicherheits-Funktionen testen. Code-Review,
GRC - Asset-Inventar aktualisieren. Mit einem AI-Werkzeug-gestützten Scan der externen Angriffsfläche und einer kurzen Liste der Crown Jewels.
- WAF- und Segmentierungs-Härtung. Quick Wins, die ohne Großprojekt umsetzbar sind: striktere Egress-Filterung auf wenigen besonders exponierten Endpunkten,
MFA - Erstes Vorstands-Update. Auf Basis des Lagebilds, mit Plan für die nächsten 60 Tage. Tonalität: faktenbasiert, keine Panik, klare Entscheidungspunkte.
Übergang nach Tag 30: Lagebild liegt vor, drei Werkzeuge sind im Pilotbetrieb, Vorstand hat das Update bekommen.
Tage 31–60: Strukturelle Verankerung
Leitmotiv: Aus Pilot wird Praxis. Verantwortlichkeiten werden klar.
VulnOps - Mitigation-Playbooks dokumentieren. Für die fünf häufigsten Schwachstellen-Klassen werden vordefinierte Mitigationen ausgearbeitet, die in unter zwei Stunden umsetzbar sind. Ohne fertigen Patch.
DORA „schwerwiegender IKT-Vorfall” - TPRM-Fragebögen erweitern. Bestehende Lieferanten-Fragebögen werden um AI-Nutzungsangaben ergänzt. Bei kritischen Drittanbietern wird aktiv nachgefragt.
- 2L-Funktion auf höhere Taktung. Die Berichterstattung der zweiten Verteidigungslinie an den Vorstand wird von quartalsweise auf monatlich verdichtet, mit einem AI-Threat-Block als festem Bestandteil.
Übergang nach Tag 60: VulnOps läuft im Pilotbetrieb, fünf Playbooks sind dokumentiert, die zweite Linie berichtet monatlich.
Tage 61–90: Konsolidierung und Berichterstattung
Leitmotiv: Beweisbarkeit. Aus Anstrengung wird Disziplin.
- Erste
Tabletop-Übung - EU-AI-Act-Klassifizierung abschließen. Alle eingesetzten AI-Werkzeuge werden gegen die Hochrisiko-Kriterien geprüft. Für Hochrisiko-Systeme werden die Konformitäts-Anforderungen geplant — vor dem 2. August 2026, falls noch nicht erreicht.
- Risikoregister formalisieren. Das in 13.4 vorgestellte Register mit acht Einträgen wird zur Bank-Realität konkretisiert, mit Schwere-Bewertung, Verantwortlichen und Eskalationspfaden.
- Vorstands-Abschluss-Briefing. Mit Lessons Learned aus der Tabletop, Status der VulnOps-Funktion, finaler Roadmap für Q3 und Q4.
- Übergang zur Daueroperation. Das, was bisher Projekt war, wird Linienaufgabe.
Übergang nach Tag 90: Das Modul wechselt von Aufbau in Betrieb. Die nächsten Aufgaben laufen quartalsweise weiter, nicht mehr als Sonderprojekt.
Baustein 3 — Verteilung über die drei Verteidigungslinien
Die
1L
IT-Security operativ
Wer es macht
- ▸Coding Agents im täglichen Werkzeugkasten
- ▸WAF, Segmentierung, MFA-Härtung
- ▸Detection-Tuning mit AI-Komponente
- ▸VulnOps-Pipeline operativ betreiben
- ▸Mitigation-Playbooks anwenden
2L
Risk & Compliance, ISO
Wer es überwacht und rahmt
- ▸Risikoregister mit AI-Einträgen pflegen
- ▸TPRM-Fragebögen erweitern
- ▸Compliance-Mapping über DORA, MaRisk, EU AI Act (plus BAIT in der verbleibenden Übergangsphase)
- ▸Monatliche Berichterstattung an den Vorstand
- ▸Genehmigte-AI-Tool-Liste führen
3L
Interne Revision
Wer es unabhängig prüft
- ▸Audit der AI-Tool-Einführung
- ▸Wirksamkeitsprüfung der ersten und zweiten Linie
- ▸Coding Agents in der eigenen Audit-Vorarbeit pilotieren
- ▸Eigene Berichterstattung an Vorstand und Aufsichtsrat
Baustein 4 — Das Vorstands-Briefing
Spätestens am Ende der ersten 30 Tage muss der Vorstand ein präzises, faktenbasiertes Update bekommen. Sechs Talking Points strukturieren das Briefing — bewusst knapp, weil Vorstände Zeit-knapp sind und Faktentreue erwarten.
Die Zero Day Clock zeigt eine Verkürzung der Time-to-Exploit von 2,3 Jahren in 2018 auf rund 9 Stunden in 2026. Diese Verkürzung ist permanent, nicht ein Ausreißer. Konkret bedeutet das, dass Patching alleine nicht mehr ausreicht — Mitigation und Containment werden zur Architektur-Frage. (Verweis auf 13.1)
Phishing-resistente MFA, Egress-Filterung, Mikrosegmentierung, Three Lines of Defense — diese Investitionen sind nicht entwertet. Sie sind in der neuen Lage wertvoller, weil sie genau das schützen, was Patching nicht mehr in Echtzeit schließen kann. (Verweis auf 13.2 und 13.3)
Aus dem Risikoregister: typischerweise drei bis fünf Punkte mit konkreten Eintrittswahrscheinlichkeiten und Schadenshöhen. Nicht alles ist gleich dringend. (Verweis auf 13.4)
Personal, Werkzeuge, externe Unterstützung. Konkret, in Euro. Eine mittlere Bank rechnet hier typischerweise mit niedrigem siebenstelligen Bereich — abhängig von der Ausgangslage.
Drei Ebenen: regulatorisch (Aufsichts-Feststellungen bei nächster Prüfung, im Extremfall Anordnungen nach §44 KWG), operativ (höhere Eintrittswahrscheinlichkeit für einen meldepflichtigen Vorfall mit Reputationsschaden), wettbewerblich (Banken, die schneller adaptieren, gewinnen Vertrauen).
Konkret — nicht „bitte um Unterstützung”, sondern: „Wir bitten um Freigabe von Budget X für Maßnahme Y bis Datum Z; um Bestätigung der TPRM-Schärfung; um Mandat für die Schaffung der VulnOps-Funktion.”
Der Y2K-Vergleich — warum Mut angebracht ist
Eine Beobachtung zum Schluss, die das Briefing trägt: Die Branche hat schon einmal eine systemische Bedrohung mit harter Deadline gemeistert. Y2K war zur Mitte der 1990er-Jahre eine reale Gefahr — Mainframes, in denen Jahreszahlen zweistellig abgelegt waren, hätten am 1. Januar 2000 unkontrolliert versagen können. Banken, Versorger, Verkehrsbetriebe, Krankenhäuser.
Es passierte fast nichts. Nicht weil die Bedrohung übertrieben war, sondern weil die Industrie sie ernstgenommen hat. Mit koordinierter Anstrengung, klaren Verantwortlichkeiten, Aufsicht und Geld. Heute schreibt niemand mehr darüber, weil es geklappt hat.
Der AI-Sturm hat eine andere Form — keine einzelne harte Deadline, sondern eine kontinuierliche Verschärfung. Aber die Logik der Antwort ist dieselbe: ernsthaft, koordiniert, mit klaren Verantwortlichkeiten, ausreichend Ressourcen und der Disziplin, die nächsten Quartale durchzuhalten. Banken haben das schon einmal gemacht. Sie können es wieder.
Was sich gegenüber Y2K verbessert hat: Diesmal stehen die Werkzeuge, die die Bedrohung erzeugen, auch der Verteidigung zur Verfügung. Coding Agents helfen, das Asset-Inventar zu erstellen, die GRC-Arbeit zu beschleunigen, die ersten Minuten eines Vorfalls anzureichern. Das war 1998 nicht so.
Banking-Szenario: Die xbank nach 90 Tagen
Was du aus dem gesamten Modul mitnimmst
Modul 13 hat fünf Lerneinheiten umfasst. Was du im Idealfall aus jeder mitnimmst:
Time-to-Exploit von 2,3 Jahren auf 9 Stunden. Gemessen, nicht prognostiziert. Banking-IT-Prozesse unter Stress.
Vier Phasen — gleich wie immer, aber schneller und fachfreier. MFA, Egress, Mikrosegmentierung bleiben wirksam.
Drei Einsatzfelder: Code, Operations, Detection. VulnOps als Antwort. Schatten-IT ist das größere Risiko.
Vier Rahmen unter Stress, nicht obsolet. Risikoregister mit acht Einträgen als pragmatischer Startpunkt.
10 Fragen, 3 Phasen, 3 Linien, 6 Vorstands-Punkte. Y2K macht Mut: schon einmal geschafft.
Das Modul endet hier — als Curriculum-Baustein. Die Arbeit, die es beschreibt, beginnt erst.
Quellen und weiterführendes Material
- CSA Strategy Briefing „The AI Vulnerability Storm” — die Originalvorlage mit Priority Actions Tabelle und 10 Diagnose-Fragen
- xbank Academy — DORA-Dokumentenlandschaft — alle relevanten Rechtsakte für Baustein 3
- Modul 6 dieser Academy — Regulatorik-Grundlagen
- Modul 8 dieser Academy — Three Lines of Defense in voller Tiefe
- Modul 9 dieser Academy — Vorfallmanagement nach ISO 27035
- Lerneinheit 13.1 bis 13.4 dieses Moduls