Zahlungsverkehr und Operations
Recovery- und Resolution-Test-Dokumentation (DORA RTS)
anymize hält System-Namen und ggf. Kunden-Bezüge aus dem Cloud-LLM heraus, während das Frontier-Modell aus Test-Logs und Asset-Inventar eine DORA-Art.-11/12-konforme Recovery-/Resolution-Test-Dokumentation drafted. RTO-/RPO-Werte kommen aus Logs — keine LLM-Halluzinationen.
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.
Anwendungsbereich
Worum geht es hier?
DORA Art. 11/12 verlangt von Instituten ein ICT-Business-Continuity-Programm einschließlich Recovery-/Resolution-Tests. RTS spezifiziert Frequenz, Methodik, Dokumentations-Anforderungen. Manuelle Dokumentations-Erstellung 12–20 h. anymize beschleunigt — RTO/RPO-Werte stammen aus realen Test-Logs, nicht aus LLM-Halluzinationen.
Für wen passt das?
Zielgruppe und Kontext
- Rolle
- DORA-Beauftragter, BCM-Lead, IT-Sicherheit, Operations-Leiter, Treasury-Operations.
- Seniorität
- Senior — Recovery-Tests sind Vorstands-Thema.
- Kanzleigröße
- Alle DORA-pflichtigen Institute.
- Spezifische Kontexte
- Jahres-Recovery-Test, Disaster-Recovery-Site-Wechsel, Major-Release mit RTO-Implikation, BaFin-Vorhalt.
Die Situation in der Kanzlei
So bringen Sie Tempo und Sorgfalt zusammen
Recovery-/Resolution-Tests müssen vollständig dokumentiert werden: Test-Plan, Test-Durchführung, RTO-/RPO-Ist-Werte je kritischer Funktion, Findings, Mitigation, Vorstands-Information. Manuelle Dokumentations-Erstellung 12–20 h. Wer Test-Logs direkt in ChatGPT lädt, kann bei Real-Betrieb-Tests Klasse-A-Daten übertragen (Kunden-Bezüge in Recovery-Logs). anymize pseudonymisiert; die KI strukturiert; Test-Ergebnisse aus Logs übernehmen — keine Glättung.
Was Sie davon haben
Zeit, Wert, Vertraulichkeit
Zeit pro Dokumentation
8–15 h
Test-Szenario, RTO/RPO-Tabelle, Findings, Lessons-Learned, Maßnahmen-Plan strukturiert. RTO/RPO aus Logs, nicht aus KI.
BaFin-Vorhalt
DORA Art. 11/12
Strukturierte Dokumentation mit Compliance-Bezug; bei Vor-Ort-Prüfung sofort vorlagebereit.
Beschönigungs-Schutz
Prompt-Verbot
RTO-Überschreitungen werden klar markiert; keine „Glättung” durch LLM.
Vertraulichkeit
Klasse B (System-Namen)
System-Namen werden pseudonymisiert. Bei Real-Betrieb-Test (mit Kunden-Daten in Logs) wird Klasse A gesondert behandelt.
So gehen Sie vor
In 5 Schritten zum Antrag
Test-Plan-Erstellung (ergänzt UC-V-FIN-PAY-013). Test-Durchführung mit Logging: RTO-/RPO-Messungen, Findings, Rollback-Erfolgs-Logs. Asset-Inventar-Auszug bereithalten.
Sie + Tool
DORA Art. 11 · Test-Programm
Klasse-Entscheidung. Test-Logs ohne Kunden-Daten = Klasse B. Test-Logs mit Kunden-Bezug (bei Realbetrieb-Test) = Klasse A → vorher pseudonymisieren.
anymize + Sie
DSGVO
Frontier-KI drafted. Mit dem CRAFT-Prompt fragen Sie Test-Szenario-Beschreibung, RTO/RPO-Tabelle (Soll vs. Ist), Test-Schritte mit Zeitstempeln, Findings (priorisiert), Rollback-Verfahren, Lessons-Learned und Maßnahmen-Plan ab.
GPT / Claude / Gemini in anymize
Strukturierung
Bewertung Test-Erfolg/-Misserfolg manuell durch BCM-Lead. RTO/RPO-Werte gegen Logs validieren — keine Halluzinationen. Lessons-Learned-Workshop mit Operations.
Sie
Letztverantwortung
Sign-off DORA-Beauftragter; Vorstands-Information (UC-V-FIN-PAY-018). Bei wesentlichen RTO-/RPO-Verfehlungen Vorstand IT-Befassung. Re-Test im Folgequartal bei Wesentlichkeit.
Sie
Aufsichtsrecht · BaFin
Womit Sie arbeiten
So setzen Sie anymize konkret ein
Was anymize tut
- Pseudonymisiert System-Namen im Asset-Inventar.
- Bei Real-Betrieb-Test mit Kunden-Bezügen pseudonymisiert anymize zusätzlich Kunden-Daten.
- Re-identifiziert die Test-Dokumentation für die interne Verteilung.
- Verarbeitung in deutschen Rechenzentren (Hetzner). AVV im Standardvertrag.
Was Sie als BCM-Lead/DORA-Beauftragter tun
- RTO/RPO-Werte aus realen Test-Logs nehmen — KI darf nicht „glätten“.
- Findings priorisiert (kritisch/wesentlich/nachrangig) mit Mitigations-Plan.
- Lessons-Learned-Workshop mit Operations und IT-Sicherheit.
- Bei wesentlichen RTO-Verfehlungen Vorstand IT-Befassung.
Daten-Input
Test-Plan, Test-Logs (RTO-/RPO-Messungen mit Zeitstempeln), Findings, Rollback-Erfolgs-Status, Asset-Inventar-Auszug mit Kritikalitäts-Markierung.
Output-Kontrolle
Pseudonymisierte Test-Daten gehen an die KI. Re-identifizierte Test-Dokumentation (Test-Szenario, RTO/RPO-Tabelle, Test-Schritte, Findings, Rollback, Lessons-Learned, Maßnahmen-Plan) kommt zurück.
Freigabeprozess
Sie behalten die Hoheit: Test-Plan-Erstellung, Logging-Disziplin, RTO/RPO-Validierung gegen Logs, BCM-Lead-Bewertung, DORA-Beauftragter-Sign-off, Vorstands-Information. anymize ist der Anonymisierungs-Layer.
Die KI-Anweisung
Prompt zum Kopieren
So nutzen Sie diesen Prompt:
1. Test-Logs und Asset-Inventar in anymize einfügen — System-Namen werden zu Platzhaltern.
2. Bei Real-Betrieb-Test zusätzliche Pseudonymisierung von Kunden-Bezügen.
3. Diesen Prompt kopieren und an die pseudonymisierten Daten anhängen.
4. In anymize unter „Tools → Reasoning„ auf ”Thinking-Modus„ stellen.
# Rolle
Du bist BCM-Dokumentations-Assistenz mit Kenntnis DORA Art. 11/12,
BCBS Operational Resilience Principles, BSI-200-4, ENISA-Resilience-
Standards.
Rechtsstand: <heutiges Datum — bitte aktuell ermitteln und hier einsetzen>.
# Aufgabe
Drafte die Recovery-/Resolution-Test-Dokumentation nach DORA Art. 11/12.
Input: Test-Plan, Test-Logs (RTO/RPO), Findings, Rollback-Erfolgs-Status,
Asset-Inventar-Auszug. System-Namen pseudonymisiert.
# Inhalt
1. Test-Szenario
4–6 Sätze: was wurde getestet, wann, mit welcher Methodik.
2. RTO/RPO-Tabelle
Spalten: Kritische Funktion | RTO-Soll | RTO-Ist | RPO-Soll | RPO-Ist
| Status (im Soll / über Soll)
Werte AUS Logs ÜBERNEHMEN — NICHT erfinden.
3. Test-Schritte
Nummeriert mit Zeitstempeln.
4. Findings
Tabelle: Finding | Priorität (kritisch/wesentlich/nachrangig) |
Beschreibung
5. Rollback-Verfahren
Erfolg/Misserfolg, Dauer, Datenverlust ja/nein.
6. Lessons-Learned
Nummeriert, institutsspezifisch.
7. Maßnahmen-Plan
Nummeriert mit Owner und Frist.
8. Unsicherheiten
[[UNSICHER: …]]
# Format
Markdown, Tabellen.
# Verbote
KEINE "Glättung" von RTO-Überschreitungen.
KEINE Findings ohne Owner und Frist.
KEINE generischen Lessons-Learned ohne institutsspezifischen Bezug.
KEINE Funktionen aus Asset-Inventar ausgelassen.So sieht der Sachverhalt aus
Pseudonymisierter Eingabetext
Recovery-Test 2026-Q1 — durchgeführt 2026-03-15
zwischen 22:00 und 04:00 CET
Getestete kritische Funktionen:
1. Kernbankensystem [[System-a3f9]]
2. Online-Banking-Frontend [[System-b2e7]]
3. SEPA-Instant-Gateway [[System-c4d1]]
Test-Szenario: simulierter Ausfall Primär-Rechenzentrum;
Wechsel auf DR-Site.
Logs (Auszug):
22:00 — Test-Start, Simulations-Trigger
22:02 — DR-Site-Wechsel initiiert
22:14 — Kernbankensystem auf DR aktiv (RTO 14 min, Soll 30 min)
22:21 — Online-Banking-Frontend auf DR (RTO 21 min, Soll 30 min)
22:38 — SEPA-Instant-Gateway auf DR (RTO 38 min, Soll 30 min)
← Überschreitung
23:45 — Funktions-Validierung bestätigt (alle Systeme)
03:30 — Rollback zu Primär initiiert
04:00 — Rollback erfolgreich; alle Systeme auf Primär
RPO-Werte:
- Kernbanken: RPO 2 min (Soll 5 min) ← gut
- Online-Banking: RPO 1 min (Soll 5 min) ← gut
- SEPA-Instant: RPO 4 min (Soll 5 min) ← knapp im Soll
Findings:
- SEPA-Instant-RTO-Überschreitung (38 vs. 30 min Soll)
- Eine Funktion (Reconciliation) im Wechsel-Window nicht getestet —
nachholenSo liefert anymize zurück
Der Antrags-Entwurf
# Recovery-Test 2026-Q1 — Dokumentation
## Test-Szenario
Simulierter Vollausfall des Primär-Rechenzentrums mit geplantem Wechsel
auf DR-Site, durchgeführt 2026-03-15 zwischen 22:00 und 04:00 CET.
Getestet: Kernbankensystem [[System-a3f9]], Online-Banking-Frontend
[[System-b2e7]], SEPA-Instant-Gateway [[System-c4d1]]. Rollback
ebenfalls geplanter Bestandteil.
## RTO/RPO-Werte
| Kritische Funktion | RTO-Soll | RTO-Ist | RPO-Soll | RPO-Ist | Status |
|---|---|---|---|---|---|
| Kernbankensystem [[System-a3f9]] | 30 min | 14 min | 5 min | 2 min | im Soll |
| Online-Banking-Frontend [[System-b2e7]] | 30 min | 21 min | 5 min | 1 min | im Soll |
| SEPA-Instant-Gateway [[System-c4d1]] | 30 min | 38 min | 5 min | 4 min | **RTO über Soll** |
## Test-Schritte
1. 22:00 — Test-Start, Simulations-Trigger.
2. 22:02 — DR-Site-Wechsel initiiert.
3. 22:14 — Kernbankensystem aktiv.
4. 22:21 — Online-Banking-Frontend aktiv.
5. 22:38 — SEPA-Instant-Gateway aktiv (RTO-Überschreitung).
6. 23:45 — Funktions-Validierung bestätigt.
7. 03:30 — Rollback initiiert.
8. 04:00 — Rollback erfolgreich abgeschlossen.
## Findings
| Finding | Priorität | Beschreibung |
|---|---|---|
| F-2026-Q1-1 | wesentlich | SEPA-Instant-RTO-Überschreitung 38 vs. 30 min Soll |
| F-2026-Q1-2 | nachrangig | Reconciliation-Funktion im Wechsel-Window nicht getestet |
## Rollback-Verfahren
Rollback erfolgreich von 03:30–04:00 CET ohne Datenverlust. Alle Systeme
auf Primär-Rechenzentrum wiederhergestellt.
## Lessons-Learned
1. SEPA-Instant-Failover braucht zusätzliche Vorab-Warm-up-Sequenz, um
30-min-RTO zuverlässig zu treffen.
2. Test-Scope-Definition zukünftig: alle in Asset-Inventar als
"kritisch" markierten Funktionen einschließen (Reconciliation
fehlte).
3. Funktions-Validierungs-Suite erweitern, um Reconciliation-Path im
Wechsel-Window mit zu testen.
## Maßnahmen-Plan
1. **F-2026-Q1-1 SEPA-Instant-Warm-up-Sequenz** — Owner: SEPA-Operations
+ IT-Sicherheit, Frist: 2026-09-30. Re-Test im DR-Test Q3.
2. **F-2026-Q1-2 Reconciliation in Test-Scope** — Owner: BCM-Lead,
Frist: vor Q3-Test.
3. **Test-Scope-Doku gegen Asset-Inventar abgleichen** — Owner:
DORA-Beauftragter, Frist: 2026-06-30.
## Unsicherheiten
Keine — Logs eindeutig.Was das Berufsrecht verlangt
Pflichten — und wie anymize sie abdeckt
DORA Art. 11/12 (SRC-0128)
ICT-Business-Continuity-Pflicht; Test-Programm jährlich. Bei Mängeln Bußgelder bis 10 Mio. EUR oder 5 % Umsatz.
BaFin DORA-Aufsichtsmitteilung (SRC-0123)
Konkrete Erwartungen an Test-Dokumentation und Vorstand-Berichterstattung. Beschönigung ist aufsichtsrechtlich problematisch.
BaFin Orientierungshilfe IKT-Risiken KI (SRC-0119)
Die KI im Recovery-Testing-Workflow ist IKT-Asset und gehört ins Inventar (UC-V-FIN-PAY-017).
MaRisk AT 9 (SRC-0115)
Auslagerungsbezogene BCM-Aspekte; bei externem DR-Provider Auslagerung nach § 25b KWG (UC-V-FIN-PAY-002).
BSI C5 + AIC4 (SRC-0145, SRC-0146)
Cloud-Komponenten der DR-Site müssen BSI-C5- und ggf. AIC4-Standards erfüllen.
ENISA AI Framework + BCBS Operational Resilience (SRC-0147, SRC-0206)
Methodische Rahmen für Recovery-Tests; internationale Standards als Best Practice.
Datenschutz und Vertraulichkeit
So funktioniert das mit anymize
Test-Logs ohne Kunden-Daten sind Klasse B. Bei Real-Betrieb-Tests mit Kunden-Bezügen (z. B. Stichproben-Validierung mit echten Daten) Klasse A — anymize pseudonymisiert. 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 im Asset-Inventar.
- Bei Real-Betrieb-Test zusätzliche Pseudonymisierung von Kunden-Bezügen.
- Re-identifiziert die Test-Dokumentation für die interne Verteilung.
- Verarbeitung in deutschen Rechenzentren (Hetzner). AVV im Standardvertrag.
- Zuordnungstabelle bleibt im Haus.
Sicherheitscheck vor der Einreichung
Was anymize liefert — was Sie souverän entscheiden
Vor dem KI-Aufruf
- Test-Logs vollständig?
- Bei Real-Betrieb-Test Kunden-Bezüge pseudonymisiert?
- RTO/RPO-Soll-Werte aus Test-Plan?
- Asset-Inventar-Auszug aktuell?
- Klasse-Entscheidung B (mit A-Vorprüfung)?
Nach der KI-Antwort
- RTO/RPO-Werte gegen Logs validiert (keine Halluzinationen)?
- Findings vollständig erfasst?
- Maßnahmen mit Owner und Frist?
- Lessons-Learned institutsspezifisch?
- Keine Beschönigung von RTO-Überschreitungen?
Vor Vorstands-Information
- BCM-Lead-Sign-off?
- DORA-Beauftragter-Sign-off?
- Bei wesentlichen Verfehlungen Vorstand IT-Befassung?
- Re-Test-Termin im Folgequartal?
Typische Fehlermuster — und wie anymize gegensteuert
- →KI „glättet” RTO-Überschreitungen — Prompt-Verbot greift.
- →Findings ohne Owner/Frist — Prompt-Auflage zwingt Eintrag.
- →Lessons-Learned generisch statt institutsspezifisch — Prompt-Verbot.
- →Reconciliation- oder Niche-Funktionen im Scope vergessen — Asset-Inventar-Vollständigkeits-Check.
- →RTO/RPO-Werte vom LLM erfunden — Werte aus Logs übernehmen.
Rechtsgrundlagen
Normen, Urteile, Belege
Primärnormen Aufsichtsrecht
- DORA Art. 11/12 — Business Continuity
- BaFin DORA-Aufsichtsmitteilung 08.07.2024
- § 25b KWG
- BaFin MaRisk 8. Novelle (AT 9)
BaFin und Standards
- BaFin Orientierungshilfe IKT-Risiken KI 18.12.2025
- BSI C5
- BSI AIC4
- ENISA AI Framework
Sekundärquellen
- PwC KI-Finanzsektor 2025
- BCBS Operational Resilience Principles
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.