Zahlungsverkehr und Operations

DORA-Resilienz-Testplan — Penetration Testing

anymize hält Asset-Inventar-Identitäten (System-Namen, IP-Bereiche) aus dem Cloud-LLM heraus, während das Frontier-Modell einen DORA-Art.-24/25-konformen Penetration-Testplan drafted — Scope, Test-Szenarien mit MITRE-ATT&CK-Phase, Abbruchkriterien, Eskalations-Pfade. Scope-Entscheidung bleibt CISO-Sache.

Schwierigkeit: Spezialist · Datenklasse: Mandantendaten · Letztes Review:

Zur Orientierung gedacht. Die anwaltliche Würdigung im Einzelfall bleibt selbstverständlich bei Ihnen — KI-Outputs sind vor jeder Verwendung zu prüfen. Mehr dazu am Ende.

01

Anwendungsbereich

Worum geht es hier?

KI im Zahlungsverkehr, FinTech-Operations und unter DORA

DORA Art. 24/25 verlangt ein angemessenes Test-Programm: regelmäßige Penetration-Tests, Schwachstellen-Scans, Code-Reviews, Resilienz-Stresstests. Manuelle Testplan-Erstellung 12–20 h. anymize beschleunigt das Drafting; Scope-Entscheidungen, Out-of-Scope-Liste und Abbruchkriterien bleiben CISO/DORA-Beauftragter.

02

Für wen passt das?

Zielgruppe und Kontext

Rolle
DORA-Beauftragter, CISO, IT-Sicherheit, Red-Team-Lead, Interne Revision.
Seniorität
Senior — Testplan-Drafting ist Compliance-relevant und Vorstands-Thema.
Kanzleigröße
Alle DORA-pflichtigen Institute; bei kritischen Marktteilnehmern zusätzlich TIBER-DE (UC-V-FIN-PAY-003).
Spezifische Kontexte
Jahres-Testplanung, vor BaFin-Vor-Ort-Prüfung, vor Major-Release, vor TIBER-DE-Test.
03

Die Situation in der Kanzlei

So bringen Sie Tempo und Sorgfalt zusammen

DORA Art. 24 fordert ein Test-Programm mit methodischen Anforderungen (PTES, OWASP, OSSTMM). Manuelle Testplan-Erstellung 12–20 h, oft mit generischer OWASP-Top-10-Befüllung ohne institutsspezifische Threat-Anknüpfung. anymize pseudonymisiert das Asset-Inventar (System-Namen, IP-Bereiche) und lässt die KI gegen ein aktuelles Threat-Model (UC-V-FIN-PAY-003) strukturierte Test-Szenarien drafted — der CISO macht die Scope-Entscheidung.

04

Was Sie davon haben

Zeit, Wert, Vertraulichkeit

Zeit pro Testplan

6–12 h

Scope-Tabelle, Test-Szenarien mit MITRE-Mapping, Out-of-Scope-Liste, Abbruchkriterien. Scope-Entscheidung bleibt CISO.

Threat-Anknüpfung

institutsspezifisch

Test-Szenarien gegen aktuelles Threat-Model (TIBER-DE-TI-Bericht), nicht generische OWASP-Liste.

Vertraulichkeit

Asset-Inventar pseudonymisiert

System-Namen, IP-Bereiche werden zu Platzhaltern. Test-Ergebnisse (später Klasse A) bleiben außerhalb des Drafting-Workflows.

Compliance-Bezug

DORA Art. 24/25

Pro Test-Szenario expliziter DORA-Artikel/EBA-RTS-Anker — BaFin-Vorhalt-tauglich.

05

So gehen Sie vor

In 5 Schritten zum Antrag

1

Scoping durch DORA-Beauftragten und CISO: welche kritischen Funktionen, Systeme und Schnittstellen werden getestet, mit welcher Frequenz und Tiefe. Asset-Inventar und Threat-Model (UC-V-FIN-PAY-003) laden.

Sie

DORA Art. 24 · Letztverantwortung

2

anymize pseudonymisiert. System-Namen, IP-Bereiche und konkrete Asset-Identifier werden zu Platzhaltern. Vorjahres-Findings bleiben außerhalb des Cloud-LLM (Klasse A, höchste Vertraulichkeit).

anymize + Sie

Informations-Klassifikation

3

Frontier-KI drafted. Mit dem CRAFT-Prompt fragen Sie Scope-Tabelle, Test-Szenarien (Tabelle mit MITRE-Phase, Methodik, Erfolgskriterium), Out-of-Scope-Liste, Abbruchkriterien, Eskalations-Pfade und Compliance-Bezug ab.

GPT / Claude / Gemini in anymize

Strukturierung · PTES/OWASP/OSSTMM

4

Scope-Validierung CISO. Out-of-Scope-Liste manuell ergänzen (Produktiv-Datenbank-Schreibzugriffe, bewusste DoS-Effekte). Test-Provider-Vertrag und AVV einleiten (UC-V-FIN-PAY-002).

Sie

Letztverantwortung · DORA Art. 28

5

Test-Durchführung (eigener Workflow durch externen Provider + intern). Ergebnis-Bericht später Klasse A. Follow-up der Findings dokumentieren; bei Critical Finding sofortige Test-Pause + DORA-Klassifikation prüfen.

Externe + Sie

DORA-Pflicht · Krisen-Workflow

06

Womit Sie arbeiten

So setzen Sie anymize konkret ein

Was anymize tut

  • Pseudonymisiert System-Namen, IP-Bereiche und konkrete Asset-Identifier.
  • Hält Vorjahres-Findings (Klasse A) außerhalb des Drafting-Workflows.
  • Re-identifiziert den Testplan-Entwurf für die interne Verteilung.
  • Verarbeitung in deutschen Rechenzentren (Hetzner). AVV im Standardvertrag.

Was Sie als CISO/DORA-Beauftragter tun

  • Scope-Entscheidung treffen — welche kritischen Funktionen, welche Tiefe.
  • Out-of-Scope-Liste manuell vervollständigen — Produktiv-Risiken explizit ausschließen.
  • Abbruchkriterien konkret formulieren (Confirmed-Path-Datenexfiltration, Privileged-Account-Kompromittierung).
  • Test-Provider-Vertrag und AVV (UC-V-FIN-PAY-002) parallel einleiten.

Daten-Input

Asset-Inventar (System-Namen, IP-Bereiche, Kritikalitäts-Markierung), kritische Funktions-Liste, aktuelles Threat-Model aus TIBER-DE-Vorbereitung (UC-V-FIN-PAY-003), Vorjahres-Findings (Klasse A, OFFLINE).

Output-Kontrolle

Pseudonymisiertes Asset-Inventar geht an die KI. Re-identifizierter Testplan-Entwurf (Scope, Test-Szenarien, Out-of-Scope, Abbruchkriterien, Eskalations-Pfade, Compliance-Bezug) kommt zurück.

Freigabeprozess

Sie behalten die Hoheit: Scope-Entscheidung, Out-of-Scope-Vervollständigung, Abbruchkriterien-Konkretisierung, Test-Provider-Auswahl, Test-Pause bei Critical Finding. anymize ist der Anonymisierungs-Layer.

07

Die KI-Anweisung

Prompt zum Kopieren

So nutzen Sie diesen Prompt:

1. Asset-Inventar und Threat-Model in anymize einfügen — System-Namen werden zu Platzhaltern.

2. Vorjahres-Findings NICHT einfügen — Klasse A, OFFLINE behalten.

3. Diesen Prompt kopieren und an das pseudonymisierte Inventar anhängen.

4. In anymize unter „Tools → Reasoning„ auf ”Thinking-Modus„ stellen.

Empfohlener Reasoning-Modus in anymize: Thinking-Modus.
# Rolle
Du bist Pen-Test-Planungs-Assistenz mit Kenntnis PTES, OWASP, OSSTMM,
MITRE ATT&CK, DORA Art. 24/25 und BaFin DORA-Aufsichtsmitteilung.
Rechtsstand: <heutiges Datum — bitte aktuell ermitteln und hier einsetzen>.

# Aufgabe
Drafte einen DORA-Penetration-Testplan. Input: pseudonymisiertes
Asset-Inventar (System-Namen als Platzhalter), Liste kritischer
Funktionen, aktuelles Threat-Model.

# Inhalt

1. Scope
   Tabelle: Kritische Funktion | System (Pseudonym) | Test-Methodik |
   Frequenz

2. Test-Szenarien
   Tabelle: Szenario | MITRE-Phase | Methodik | Erfolgskriterium

3. Out-of-Scope
   Liste: Produktiv-Datenbank-Schreibzugriffe, bewusste DoS-Effekte
   während Geschäftszeiten, Drittparteien-Systeme ohne Vertrag.

4. Abbruchkriterien
   Nummeriert: erfolgreicher Zugriff auf Produktiv-Kunden-Daten,
   Privileged-Account-Kompromittierung, unerwartete Verfügbarkeits-
   Auswirkung, Confirmed-Path-Datenexfiltration.

5. Eskalations-Pfade
   Bei Abbruchkriterium → Test-Stop + Senior-CISO + DORA-Beauftragter +
   Vorstand-Notifikation.

6. Compliance-Bezug
   DORA-Artikel, EBA-RTS, BSI-C5, ENISA.

7. Unsicherheiten
   [[UNSICHER: …]] bei mehrdeutigen Scope-Fragen.

# Format
Markdown, Tabellen für Scope und Szenarien.

# Verbote
KEINE Test-Szenarien ohne institutsspezifische Threat-Anknüpfung
  (kein generischer OWASP-Top-10 ohne Bezug).
KEINE Out-of-Scope-Liste zu kurz — Produktiv-Risiken explizit
  ausschließen.
KEINE weichen Abbruchkriterien — konkrete, prüfbare Auslöser.
KEINE Eskalations-Lücke beim DORA-Beauftragten.
08

So sieht der Sachverhalt aus

Pseudonymisierter Eingabetext

Asset-Inventar nach Pseudonymisierung. System-Namen als Platzhalter; Threat-Model in Klartext für Szenario-Drafting; Vorjahres-Findings bewusst nicht beigefügt.
Asset-Inventar (Auszug) — Stand 2026-05-13
Kritische Funktion 1: Online-Banking ([[System-a3f9]])
Kritische Funktion 2: SEPA-Instant-Gateway ([[System-b2e7]])
Kritische Funktion 3: SWIFT-Connectivity ([[System-c4d1]])
Kritische Funktion 4: Kartenzahlungs-Netz ([[System-d5f3]])
Kritische Funktion 5: Kernbankensystem ([[System-e8a2]])

Threat-Model (Auszug; aus UC-V-FIN-PAY-003-Synthese):
 - Credential-Stuffing gegen Online-Banking (Hoch)
 - API-Abuse Open-Banking-Endpunkte (Mittel)
 - SWIFT-Trusted-Relationship-Angriff (Mittel)
 - Phishing → Lateral Movement → SWIFT-Operator (Hoch)

Vorjahres-Findings (Kurz-Zusammenfassung; Klasse A → nicht weitergegeben
an KI):
 - 12 Findings Q1/2025-Test (intern bekannt)
09

So liefert anymize zurück

Der Antrags-Entwurf

KI-Output (Beispiel). System-Namen re-identifiziert; Test-Szenarien institutsspezifisch durch Threat-Model-Anknüpfung; Abbruchkriterien konkret.
# DORA-Penetration-Testplan — Entwurf

## Scope
| Kritische Funktion | System | Test-Methodik | Frequenz |
|---|---|---|---|
| Online-Banking | [[System-a3f9]] | Web-App-Pen-Test + API-Test | jährlich |
| SEPA-Instant-Gateway | [[System-b2e7]] | API-Pen-Test + Network-Test | jährlich |
| SWIFT-Connectivity | [[System-c4d1]] | Konfigurations-Audit + Auth-Test | jährlich |
| Kartenzahlungs-Netz | [[System-d5f3]] | Spezialisierter Pen-Test (PCI-DSS-konform) | jährlich |
| Kernbankensystem | [[System-e8a2]] | Dedizierte Code-Review + Black-Box-Test | dreijährlich (mit jährlichem Schwachstellen-Scan) |

## Test-Szenarien
| Szenario | MITRE-Phase | Methodik | Erfolgskriterium |
|---|---|---|---|
| Credential-Stuffing Online-Banking | TA0006 Credential Access | OWASP-Auth-Bypass + Brute-Force | Block-Schwelle hält; Rate-Limit greift |
| API-Abuse Open-Banking | TA0009 Collection | OWASP API Top-10 | keine unautorisierten Daten-Abflüsse |
| SWIFT-Operator-Phishing-Chain | TA0001 Initial Access → TA0008 Lateral | Social Engineering + Endpoint-Test | Detection durch SIEM in <15 min |
| SEPA-Instant-Latenz-Stress | TA0040 Impact (Stress-Test) | Performance-Stress + Fail-over | Fall-back auf SEPA-CT funktioniert |
| Kartenzahlungs-PCI-Test | dediziert | PCI-DSS Penetration Testing | PCI-Compliance-Standards erfüllt |

## Out-of-Scope
- Produktiv-Datenbank-Schreibzugriffe (nur Read-Only-Tests).
- Bewusste DoS-Effekte auf Produktiv-Online-Banking während
  Geschäftszeiten.
- Drittparteien-Systeme ohne expliziten Vertrag.

## Abbruchkriterien
1. Erfolgreicher Zugriff auf Produktiv-Kunden-Daten.
2. Erfolgreicher Privileged-Account-Kompromittierung.
3. Auswirkung auf Produktiv-Verfügbarkeit (unerwartete Service-
   Degradation).
4. Datenexfiltration-Möglichkeit (Confirmed-Path).

## Eskalations-Pfade
- Bei Abbruchkriterium 1–4: sofortige Test-Stop, Senior-CISO,
  DORA-Beauftragter, Vorstand-Notifikation.
- Bei sonstigem Critical Finding: Tier-2-Eskalation Red-Team-Lead + SOC.
- DORA-Klassifikations-Check bei jedem Critical (UC-V-FIN-PAY-001).

## Compliance-Bezug
- DORA Art. 24 — Test-Programm.
- DORA Art. 25 — Test-Tooling und Methodologie.
- BaFin DORA-Aufsichtsmitteilung 08.07.2024 — Test-Erwartungen.
- BSI C5 / AIC4 — Cloud-Komponenten.

## Unsicherheiten
1. [[UNSICHER: SWIFT-Operator-Phishing-Test — Reichweite bei Test-
   Mitarbeitern abgleichen]]
10

Was das Berufsrecht verlangt

Pflichten — und wie anymize sie abdeckt

DORA Art. 24/25 (SRC-0128)

Test-Programm-Pflicht mit methodischen Anforderungen. BaFin-Mängelfeststellungen bei generischem Testplan ohne institutsspezifische Threat-Anknüpfung sind häufig.

BaFin DORA-Aufsichtsmitteilung (SRC-0123)

Konkrete Test-Erwartungen; bei BaFin-Vor-Ort-Prüfung wird der Testplan als Vorlage verlangt.

BaFin Orientierungshilfe IKT-Risiken KI (SRC-0119)

Die KI im Test-Programm-Tool ist IKT-Asset und gehört ins KI-Inventar (UC-V-FIN-PAY-017).

§ 25b KWG (SRC-0107)

Pen-Test-Provider sind Auslagerungen; Vertrag und AVV im Auslagerungs-Register (UC-V-FIN-PAY-002).

BSI C5 + AIC4 (SRC-0145, SRC-0146)

Cloud-Komponenten der Test-Umgebung müssen BSI-C5- und ggf. AIC4-Standards erfüllen.

ENISA AI Framework (SRC-0147)

Methodischer Standard für KI-gestützte Resilience-Tests; Konfidenz-Disziplin und Quellen-Triangulation.

11

Datenschutz und Vertraulichkeit

So funktioniert das mit anymize

Testplan-Drafting ist typisch Klasse B (System-Namen, Threat-Model). Test-Ergebnisse mit Schwachstellen-Details werden später Klasse A — die gehören nicht in den Drafting-Workflow. anymize pseudonymisiert das Asset-Inventar; Vorjahres-Findings bleiben offline. Verarbeitung in deutschen Rechenzentren (Hetzner), AVV nach Art. 28 DSGVO und § 25b KWG. Rechtsgrundlage: Art. 6 Abs. 1 lit. c DSGVO (DORA-Pflicht).

Was anymize konkret leistet

  • Pseudonymisiert System-Namen und IP-Bereiche im Asset-Inventar.
  • Hält Vorjahres-Findings (Klasse A) außerhalb des Drafting-Workflows.
  • Re-identifiziert den Testplan-Entwurf für die interne Verteilung.
  • Verarbeitung in deutschen Rechenzentren (Hetzner). AVV im Standardvertrag.
  • Zuordnungstabelle bleibt im Haus.
12

Sicherheitscheck vor der Einreichung

Was anymize liefert — was Sie souverän entscheiden

Vor dem KI-Aufruf

  • Asset-Inventar aktuell?
  • Vorjahres-Findings NICHT im Input?
  • Threat-Model aus TIBER-DE-Vorbereitung verfügbar?
  • Pseudonymisierungs-Spot-Check?
  • Klasse-Entscheidung B?

Nach der KI-Antwort

  • Scope-Konsistenz mit Threat-Model?
  • Out-of-Scope-Liste vollständig (Produktiv-Risiken)?
  • Abbruchkriterien konkret und prüfbar?
  • Eskalations-Pfad mit DORA-Beauftragten?
  • MITRE-Mapping korrekt?

Vor Test-Beginn

  • Provider-Vertrag und AVV abgeschlossen (UC-V-FIN-PAY-002)?
  • Notfall-Kontakte etabliert?
  • Vorstand IT bei kritischen Funktionen informiert?
  • Test-Pause-Protokoll für Critical Findings vorbereitet?

Typische Fehlermuster — und wie anymize gegensteuert

  • Generischer OWASP-Top-10-Test ohne Institut-Kontext — Prompt verlangt Threat-Anknüpfung.
  • Out-of-Scope-Liste zu kurz (Produktiv-Risiken nicht ausgeschlossen) — Prompt-Verbot.
  • Abbruchkriterien zu weich („auffällig viele”) — Prompt verlangt konkrete Auslöser.
  • Eskalations-Pfad ohne DORA-Beauftragten — Prompt-Verbot.
  • Vorjahres-Findings versehentlich im Input — Klasse-A-Bruch.
13

Rechtsgrundlagen

Normen, Urteile, Belege

Primärnormen Aufsichtsrecht

  • DORA Art. 24/25 — Test-Programm
  • BaFin DORA-Aufsichtsmitteilung 08.07.2024
  • § 25b KWG — Auslagerung

Methodische Rahmen

  • Penetration Testing Execution Standard
  • OWASP Testing Guide / ASVS
  • Open Source Security Testing Methodology Manual
  • MITRE ATT&CK Framework
  • ENISA AI Framework

BaFin und Standards

  • BaFin Orientierungshilfe IKT-Risiken KI 18.12.2025
  • BSI C5
  • BSI AIC4

Sekundärquellen

  • PwC KI-Finanzsektor 2025
  • BaFin KI-Cyber-Warnung
  • FSB AI Stability

Stand: · Nächste Überprüfung:

Hinweis zur Nutzung

Zur Orientierung — nicht als Mandatsersatz

Diese Anleitung beschreibt einen Arbeitsablauf, den Sie mit anymize umsetzen können. Sie ist zur Orientierung gedacht und ersetzt weder die anwaltliche Würdigung im Einzelfall noch eine fachanwaltliche Prüfung. Welche Rechtsprechung einschlägig ist, wie der Sachverhalt rechtlich zu bewerten ist, welche Anträge in Ihrem konkreten Mandat richtig sind — das bleibt selbstverständlich bei Ihnen.

KI-Outputs müssen vor jeder Verwendung anwaltlich geprüft werden. Insbesondere Urteils-Aktenzeichen, Norm-Verweise und Fristen sind gegen Primärquellen zu verifizieren. anymize gewährleistet die Vertraulichkeit der Mandantendaten gegenüber dem KI-Anbieter; die fachliche Richtigkeit des Outputs liegt in Ihrer Verantwortung.

Jetzt starten.
14 Tage kostenlos testen.

Alle Modelle. Alle Features. Keine Kreditkarte.

Wir sind überzeugt von anymize. Und wir wissen: Bei einem KI-Werkzeug, das Mandanten-, Patienten- oder Mitarbeiter-Daten berührt, reicht ein Demo-Video nicht. Deshalb 14 Tage voller Zugang – alle Modelle, alle Features, keine Kreditkarte. Genug Zeit, um sicher zu sein, bevor du uns vertraust.

Dein KI-Arbeitsplatz wartet.