Regulatory Gap-Analysen: Methodik zur Identifikation von Compliance-Lücken

Bei neuen Regulierungen (DORA, Basel IV, ESG-Vorschriften) ist eine Regulatory Gap-Analyse der erste kritische Schritt zur Compliance. Sie identifiziert systematisch Lücken zwischen regulatorischen Anforderungen und dem IST-Zustand des Instituts und bildet die Grundlage für Umsetzungsroadmaps. Ohne strukturierte Gap-Analyse drohen Institute, wesentliche Anforderungen zu übersehen oder Ressourcen ineffizient zu allokieren.

Was ist eine Regulatory Gap-Analyse?

Definition und Zielsetzung

Regulatory Gap-Analyse:

Systematischer Vergleich regulatorischer Anforderungen (SOLL) mit dem aktuellen Umsetzungsstand im Institut (IST) zur Identifikation, Bewertung und Priorisierung von Compliance-Lücken.

Ziele:

1. Vollständigkeit: Alle Anforderungen erfasst (keine Blindspots)
2. Priorisierung: Kritische Lücken identifiziert (Risk-Based Approach)
3. Roadmap: Umsetzungsplan mit Meilensteinen, Ressourcen, Budget
4. Transparenz: Geschäftsleitung und Aufsicht informiert (Readiness-Status)

Anwendungsfälle

Regulierung	Gap-Analyse-Trigger	Deadline	Komplexität
DORA	EU-Verordnung veröffentlicht (2022), finale RTS (2024)	17. Januar 2025	Sehr hoch
Basel IV (Final)	CRR3/CRD6 in Umsetzung	1. Januar 2025	Hoch
ESG (CSRD, EU-Taxonomie)	Schrittweise Anwendung ab 2024	2024-2028	Hoch
BAIT 7.0	Anpassung an DORA (erwartet 2025)	2025/2026	Mittel
NIS2-Richtlinie	Umsetzung in nationales Recht	17. Oktober 2024	Mittel
MaRisk-Novelle	BaFin-Rundschreiben (regelmäßig)	Variabel	Mittel

Gap-Analyse-Prozess: 6 Phasen

Phase 1: Requirement Mapping (Anforderungserfassung)

Schritt 1.1: Regulatorische Texte strukturieren

Ziel: Alle regulatorischen Anforderungen in prüfbare Items zerlegen

Beispiel: DORA Art. 5-16 (IKT-Risikomanagement)

DORA-Anforderungen strukturiert:

Art. 5: IKT-Risikomanagement-Rahmen
├─ REQ-DORA-001: Dokumentiertes IKT-Risikomanagement-Framework
│   ├─ Sub-REQ-001-01: Governance (Rollen, Verantwortlichkeiten)
│   ├─ Sub-REQ-001-02: IKT-Risikostrategie (Board-approved)
│   └─ Sub-REQ-001-03: IKT-Risiko-Taxonomie (Klassifizierung)
├─ REQ-DORA-002: Vollständiges IKT-Asset-Inventar
│   ├─ Sub-REQ-002-01: Alle IKT-Systeme erfasst (inkl. Abhängigkeiten)
│   └─ Sub-REQ-002-02: Inventar regelmäßig aktualisiert (mindestens jährlich)
└─ REQ-DORA-003: Schutz und Prävention
    ├─ Sub-REQ-003-01: Multi-Faktor-Authentifizierung (MFA) für kritische Systeme
    ├─ Sub-REQ-003-02: Verschlüsselung im Transit und im Ruhezustand
    └─ Sub-REQ-003-03: Network Segmentation

Art. 6: IKT-Systeme, -Protokolle und -Tools
├─ REQ-DORA-004: Kontinuierliche Überwachung (24/7)
│   ├─ Sub-REQ-004-01: SIEM-System implementiert
│   └─ Sub-REQ-004-02: SOC (intern oder extern) etabliert
└─ REQ-DORA-005: Protokollierung und Nachvollziehbarkeit
    └─ Sub-REQ-005-01: Logs mindestens 12 Monate aufbewahrt

... (insgesamt ~150 einzelne Requirements aus DORA)

Hilfsmittel:

• Regulatorische Texte: Original-Verordnungen, RTS, EBA/ESMA-Leitlinien
• Compliance-Checklisten: Von Verbänden (BdB, DSGV, BVR) bereitgestellt
• Externe Berater: Big 4 (Deloitte, PwC, KPMG, EY) bieten Gap-Analysen an
• GRC-Software: Compliance-Mapping-Tools (z.B. MEGA HOPEX)

Schritt 1.2: Anforderungen kategorisieren

Kategorisierung nach:

1. Themenbereich

   • Governance, Strategie, Organisation
   • Prozesse, Kontrollen
   • Technologie, IT-Systeme
   • Reporting, Dokumentation

2. Kritikalität

   • Must-Have: Zwingend erforderlich (harter Compliance-Verstoß)
   • Should-Have: Stark empfohlen (Best Practice)
   • Nice-to-Have: Optional (über Mindestanforderungen hinaus)

3. Aufwand (erste Schätzung)

   • Niedrig: < 100 Stunden, < €50k
   • Mittel: 100-500 Stunden, €50k-200k
   • Hoch: > 500 Stunden, > €200k

Phase 2: IST-Aufnahme (Current State Assessment)

Schritt 2.1: Datenerhebung

Methoden:

1. Dokumentenanalyse

• Bestehende Policies, Prozessbeschreibungen, Richtlinien
• IT-Dokumentation (Architekturdiagramme, Systemlandkarte)
• Audit-Reports (Interne Revision, externe Prüfer)
• Incident-Reports (Vorfälle der letzten 12 Monate)

2. Interviews mit Stakeholdern

Interview-Matrix:

Thema: IKT-Risikomanagement (DORA)

Interviewpartner:
├─ CIO: Governance, IKT-Strategie, Ressourcen
├─ CISO: IT-Sicherheit, SIEM, Incident Management
├─ Leiter IT-Betrieb: Monitoring, Change Management
├─ Compliance-Officer: Bestehende IKT-Policies
├─ Risk Manager: IKT-Risikoanalyse, ICAAP
└─ Leiter Interne Revision: Letzte IT-Prüfungen, Findings

Fragen (Beispiel):
1. Existiert ein dokumentiertes IKT-Risikomanagement-Framework?
   → Ja, aber nicht DORA-konform (erstellt 2020, basierend auf BAIT)
2. Gibt es ein vollständiges IKT-Asset-Inventar?
   → Teilweise (Hauptsysteme erfasst, aber Cloud-Services unvollständig)
3. Wird 24/7-Monitoring durchgeführt?
   → Ja, SIEM vorhanden (Splunk), aber SOC nur 8/5 (nicht 24/7)

3. System-Assessments

• Technische Prüfungen (z.B. MFA-Abdeckung: Welche Systeme haben MFA?)
• Vulnerability Scans (aktuelle Sicherheitslage)
• Penetrationstests (letzte Ergebnisse)

4. Workshops

• Cross-funktionale Workshops (IT, Risk, Compliance, Business)
• Brainstorming: Wo sind Lücken? Wo fehlt Wissen?

Schritt 2.2: IST-Stand bewerten

Bewertungsschema (Maturity-Level):

Level	Bezeichnung	Beschreibung	DORA-Konformität
0	Non-existent	Anforderung nicht erfüllt, kein Ansatz vorhanden	Kritische Lücke
1	Initial / Ad-hoc	Anforderung teilweise erfüllt, aber nicht dokumentiert/strukturiert	Hohe Lücke
2	Defined	Anforderung dokumentiert, aber nicht vollständig implementiert	Mittlere Lücke
3	Managed	Anforderung implementiert und funktionsfähig, aber nicht optimiert	Geringe Lücke
4	Optimized	Anforderung vollständig erfüllt, kontinuierliche Verbesserung	Konform

Beispiel-Bewertung:

REQ-DORA-001: Dokumentiertes IKT-Risikomanagement-Framework

IST-Analyse:
├─ Vorhanden: IT-Sicherheitsrichtlinie (2020, basierend auf BAIT)
├─ Lücken:
│   ├─ Nicht explizit auf DORA ausgerichtet (fehlt: IKT-Risiko-Taxonomie)
│   ├─ Governance-Rollen unklar (kein dedizierter IKT-Risiko-Officer)
│   └─ Keine explizite IKT-Risikostrategie (nur generelle IT-Strategie)
└─ Maturity-Level: 2 (Defined, aber nicht DORA-konform)

Gap: MITTEL (Anpassung erforderlich, aber Basis vorhanden)

REQ-DORA-004: Kontinuierliche Überwachung (24/7)

IST-Analyse:
├─ SIEM: Splunk vorhanden (seit 2022)
├─ SOC: Nur 8/5 (Montag-Freitag, 08:00-17:00 Uhr)
├─ Lücke: Keine 24/7-Abdeckung (Wochenenden, Nächte unüberwacht)
└─ Maturity-Level: 2 (Managed, aber nicht 24/7)

Gap: HOCH (DORA fordert explizit kontinuierliche Überwachung)

REQ-DORA-003-01: MFA für kritische Systeme

IST-Analyse:
├─ MFA vorhanden: VPN, Admin-Zugänge (100%)
├─ MFA fehlend: Einige Fachanwendungen (z.B. Kernbankensystem-Admin)
├─ Abdeckung: 80% der kritischen Systeme
└─ Maturity-Level: 3 (Managed, aber nicht vollständig)

Gap: GERING (Nachbesserung für restliche 20%)

Phase 3: Gap-Identifikation (SOLL vs. IST)

Gap-Matrix erstellen

Gap-Matrix (Auszug):

| REQ-ID | Anforderung | SOLL (DORA) | IST (Bank) | Maturity | Gap-Schwere | Priorisierung |
|--------|-------------|-------------|------------|----------|-------------|---------------|
| DORA-001 | IKT-Risikomanagement-Framework | Dokumentiert, Board-approved | Basis vorhanden, nicht DORA-konform | 2 | MITTEL | P2 |
| DORA-002 | IKT-Asset-Inventar | Vollständig, inkl. Cloud | Unvollständig (Cloud-Services fehlen) | 2 | HOCH | P1 |
| DORA-003-01 | MFA kritische Systeme | 100% Abdeckung | 80% Abdeckung | 3 | GERING | P3 |
| DORA-004 | 24/7-Monitoring | Kontinuierlich (24/7) | Nur 8/5 (SOC) | 2 | HOCH | P1 |
| DORA-005 | Log-Aufbewahrung | 12 Monate | 6 Monate | 2 | MITTEL | P2 |
| DORA-006 | Incident-Reporting | 4h Erstmeldung | Kein standardisierter Prozess | 1 | KRITISCH | P1 |

Priorisierung:
├─ P1 (Kritisch/Hoch): Sofortige Umsetzung, bis Q1 2025 (DORA-Deadline)
├─ P2 (Mittel): Umsetzung bis Q2 2025
└─ P3 (Gering): Umsetzung bis Q3 2025

Gap-Bewertung nach Risiko

Gap-Score = Compliance-Risiko × Umsetzungsaufwand

Beispiel: REQ-DORA-006 (Incident-Reporting)

Compliance-Risiko (1-5):
├─ Regulatorische Sanktion: 5 (DORA-Kernforderung, Meldepflicht an ESAs)
├─ Reputation: 4 (verspätete Meldung würde auffallen)
├─ Finanzielle Auswirkung: 4 (Bußgelder möglich)
└─ Score: 5 (KRITISCH)

Umsetzungsaufwand (1-5):
├─ Prozess: 3 (Prozess neu definieren, Rollen klären)
├─ IT: 2 (Templates, Meldesystem)
├─ Schulung: 3 (alle relevanten Mitarbeiter)
├─ Zeitbedarf: 4 Monate
└─ Score: 3 (MITTEL)

Gap-Score: 5 × 3 = 15 (HÖCHSTE PRIORITÄT)

Maßnahmen:
├─ Incident-Reporting-Prozess definieren (basierend auf DORA-Vorgaben)
├─ Incident-Kategorisierung (major/minor, Meldefristen)
├─ Reporting-Templates erstellen (Erstmeldung, Zwischenbericht, Abschlussbericht)
├─ IT-Tool: Incident-Management-System (z.B. ServiceNow)
└─ Schulungen: Alle IT-Manager, Compliance, Geschäftsleitung

Phase 4: Maßnahmen-Roadmap

Umsetzungsplan entwickeln

DORA Gap-Closure Roadmap (Beispiel: Mittelgroße Bank)

Q4 2024 (bis 31. Dezember 2024):
├─ Quick Wins (P1-Gaps mit geringem Aufwand)
│   ├─ Log-Aufbewahrung von 6 auf 12 Monate erhöhen (Storage erweitern)
│   ├─ MFA für restliche 20% kritischer Systeme (Rollout)
│   └─ IKT-Asset-Inventar vervollständigen (Cloud-Services erfassen)
├─ Ressourcen: 3 FTE IT, 1 FTE Compliance
└─ Budget: €100k

Q1 2025 (bis 17. Januar 2025 – DORA-Deadline!):
├─ Kritische P1-Gaps schließen
│   ├─ Incident-Reporting-Prozess implementieren (inkl. IT-Tool)
│   ├─ 24/7-SOC etablieren (extern ausgelagert)
│   ├─ IKT-Risikomanagement-Framework überarbeiten (DORA-konform)
│   └─ Notfall-Meldeprozess an ESAs testen (Dry Run)
├─ Ressourcen: 5 FTE IT, 2 FTE Compliance, Externe Berater
└─ Budget: €300k

Q2 2025 (bis 30. Juni 2025):
├─ P2-Gaps schließen
│   ├─ IKT-Drittanbieter-Register aufbauen (alle IKT-Dienstleister erfassen)
│   ├─ Verträge mit kritischen Dienstleistern nachverhandeln (DORA-Klauseln)
│   └─ TLPT vorbereiten (falls designiert als bedeutendes Institut)
├─ Ressourcen: 3 FTE, Externe Unterstützung (Legal)
└─ Budget: €200k

Q3-Q4 2025 (bis 31. Dezember 2025):
├─ P3-Gaps und Optimierungen
│   ├─ Vulnerability-Management-Prozess automatisieren
│   ├─ Threat-Intelligence-Integration (SIEM)
│   └─ Kontinuierliche Verbesserung (Lessons Learned aus ersten Monaten)
├─ Ressourcen: 2 FTE
└─ Budget: €150k

Gesamt-Budget: €750k
Gesamt-Zeitaufwand: ~8.000 Stunden (interner Aufwand)

Priorisierungsmatrix

Gap-Priorisierung (Effort vs. Impact):

Impact (Compliance-Risiko)
    ↑
  5 │ Quick Wins │ Strategisch │ ← P1: Sofort
  4 │            │             │
  3 │ Low Prio   │ Standard    │ ← P2: Mittel
  2 │            │             │
  1 │ Verzichtbar│ Fill-Ins    │ ← P3: Niedrig
    └─────────────────────────→
      1    2    3    4    5
         Aufwand (Effort)

Beispiele:
├─ Quick Wins (High Impact, Low Effort): Log-Aufbewahrung, MFA-Rollout
├─ Strategisch (High Impact, High Effort): 24/7-SOC, Incident-Reporting
├─ Standard (Medium Impact, Medium Effort): IKT-Asset-Inventar
└─ Low Prio (Low Impact, High Effort): Verschieben auf später

Phase 5: Umsetzung und Tracking

Project Governance

DORA-Compliance-Programm:

Steering Committee (monatlich):
├─ Besetzung: CIO, CRO, Compliance-Officer, IT-Security-Manager
├─ Aufgaben: Fortschritt überwachen, Roadmap-Anpassungen, Eskalationen
└─ Reporting: Geschäftsleitung (quartalsweise)

Workstreams (dedizierte Teams):
├─ WS1: IKT-Risikomanagement-Framework (Lead: CRO)
├─ WS2: Incident-Management & Reporting (Lead: IT-Security)
├─ WS3: Third-Party-Risk-Management (Lead: Compliance)
├─ WS4: Testing (Vulnerability, TLPT) (Lead: CISO)
└─ WS5: IT-Systeme & Monitoring (Lead: CIO)

Tracking-Tool:
├─ Jira/Asana: Task-Management (alle Maßnahmen als Tickets)
├─ Weekly Status Reports (Red/Amber/Green)
└─ Dashboard für Geschäftsleitung (Gesamtfortschritt in %)

KPIs für Gap-Closure

KPI	Ziel	Aktuell (Q4 2024)	Status
% Gaps geschlossen	100% bis 17. Januar 2025	65%	🟡 Amber
% Budget verbraucht	< 100%	75%	🟢 Green
Kritische Gaps offen	0	2	🔴 Red
Verzögerung (Tage)	0	15	🟡 Amber

Eskalation: Bei Red-Status sofortige Eskalation an Geschäftsleitung

Phase 6: Dokumentation und Reporting

Gap-Analyse-Bericht

Mindestinhalte:

Regulatory Gap Analysis Report: DORA

Executive Summary:
├─ Anzahl Anforderungen: 150 (aus DORA + RTS)
├─ Gaps identifiziert: 45 (30% der Anforderungen)
│   ├─ Kritisch: 5 (z.B. Incident-Reporting, 24/7-SOC)
│   ├─ Hoch: 12
│   ├─ Mittel: 18
│   └─ Gering: 10
├─ Geschätzter Aufwand: €750k, 8.000 Stunden
├─ Umsetzungszeitraum: Q4 2024 - Q4 2025
└─ Readiness-Status: 65% (per 1. Dezember 2024)

Detailanalyse (je Gap):
├─ Anforderung (REQ-ID, Beschreibung)
├─ IST-Stand (Maturity-Level, Bewertung)
├─ Gap-Beschreibung (Was fehlt genau?)
├─ Gap-Score (Risiko × Aufwand)
├─ Maßnahmen (konkret, mit Verantwortlichen)
├─ Kosten und Zeitbedarf
└─ Status (offen/in Arbeit/geschlossen)

Roadmap:
├─ Phasen mit Meilensteinen
├─ Ressourcenallokation
├─ Budget-Plan
└─ Risiken und Abhängigkeiten

Anhänge:
├─ Detaillierte Requirement-Liste
├─ Interview-Protokolle
└─ System-Assessment-Reports

Reporting an Aufsicht

BaFin/EZB-Kommunikation:

Bei größeren Regulierungen (z.B. DORA) erwarten Aufsichtsbehörden proaktive Information:

Selbstauskunft an BaFin (freiwillig, aber empfohlen):

Betreff: DORA-Umsetzungsstand – [Bankname]

Sehr geehrte Damen und Herren,

im Rahmen der Vorbereitung auf die DORA-Verordnung (gültig ab 17. Januar 2025)
möchten wir Sie über unseren Umsetzungsstand informieren:

1. Gap-Analyse durchgeführt: September 2024
2. Identifizierte Gaps: 45 (davon 5 kritisch)
3. Umsetzungsstand: 65% (per 1. Dezember 2024)
4. Kritische Gaps:
   ├─ Incident-Reporting (in Umsetzung, Abschluss 15. Januar 2025)
   └─ 24/7-SOC (extern ausgelagert, Vertrag unterzeichnet, Betrieb ab 10. Januar 2025)
5. Erwartete Konformität: 17. Januar 2025

Wir halten Sie über den Fortschritt informiert.

Mit freundlichen Grüßen
[Compliance-Officer / CRO]

---

Fazit: Regulatory Gap-Analysen sind der kritische erste Schritt bei neuen Regulierungen. Eine strukturierte Analyse (Requirement Mapping → IST-Aufnahme → Gap-Identifikation → Roadmap) sichert Vollständigkeit, Priorisierung und rechtzeitige Umsetzung. Institute, die Gap-Analysen professionell durchführen, vermeiden Last-Minute-Stress, unvollständige Compliance und aufsichtsrechtliche Eskalationen. Mit DORA, Basel IV und ESG-Regulierungen werden Gap-Analysen zur Daueraufgabe – ein robustes Framework ist unverzichtbar.