DORA-Anforderungen auf ICT-Controls mappen
Pflicht auf wirksames Control: DORA-Artikel oder BAIT-Ziffer, kritischer Service, Control-ID, Test, Evidence Owner und Drittpartei — kein Namensabgleich im Wiki.
Begriffe vor dem Lesen
- Governance-, Risiko- und Compliance-Software — Governance, Risk & Compliance: Tools oder Prozesse für Richtlinien, Risiken, Kontrollen und Nachweise. Governance-, Risiko- und Compliance-Software ersetzt keine fachliche Entscheidung.
- BAIT — Bankaufsichtliche Anforderungen an die IT: aufsichtsrechtliche IT-Erwartungen für Banken, heute immer mit DORA und MaRisk einzuordnen.
Ein Mapping auf Control-Namen beweist weder Coverage noch Wirksamkeit. DORA-Governance scheitert, wenn der Artikel im Policy-Katalog steht, der Zahlungsverkehr aber ohne Service-Scope, Durchsetzung-Punkt und Test bleibt — und der ICT-Drittanbieter nur als Logo in der Vendor-Liste auftaucht.
Dieser Teil bindet Pflicht, kritischen Service und Evidenz — nach den Datenverträgen aus Teil 3 und bevor Incident Evidence dieselbe Control-ID braucht.
Vorher: Datenverträge für Modellrisiko. Weiter: Incident Evidence im Betrieb.
Ansatz
Jede materielle DORA- oder BAIT-Pflicht erhält vor dem Aufsichtsnachweis:
- eine Pflicht-ID (DORA-Artikel oder BAIT-Ziffer) mit verbindlichem Wortlaut;
- den kritischen oder wichtigen Service im Scope — nicht die ganze Bank als eine Zeile;
- eine Control-ID plus Durchsetzung-Punkt (wo die Config tatsächlich greift);
- einen Test, einen Evidence Owner und eine Frequenz;
- den ICT-Drittpartei-Pfad, wenn der Service beim Anbieter liegt, plus einen Ausnahmeweg mit Ablaufdatum.
CISO oder benannter ICT Control Owner ist accountable. Der Warehouse-Admin setzt Flags um; er entscheidet nicht, ob der Zahlungsverkehr unter die Pflicht fällt.
ICT-Mapping-Workflow
1. Pflicht und Service schneiden
Der Owner wählt eine Pflicht und genau einen kritischen Service (Zahlungsverkehr, Kernbank, Meldeplattform). Ein Artikel auf „alle Systeme“ ist kein Scope.
2. Control-ID binden
Die Control-ID muss in Governance, Risk & Compliance (Governance, Risk & Compliance (GRC)), CMDB und Durchsetzung-Punkt dieselbe Sache bezeichnen. Ein ähnlicher Name im Wiki ist kein Mapping.
3. Durchsetzung-Punkt benennen
Wo greift das Control — IAM, Logging, Change, Backup, Vendor-Zugang? Ohne Punkt bleibt die Pflicht eine Folie.
4. Test und Evidence Owner
Wirksam heißt: bestandener Test plus Export der wirksamen Konfiguration. Der Evidence Owner ist namentlich, nicht „das ICT-Team“.
5. Drittpartei einziehen
Liegt der Service beim ICT-Drittanbieter, gehört dessen Control-Evidenz in denselben Vertrag — Register, Vertragsklausel, Testfrequenz. Ein Logo in der Vendor-Liste reicht nicht.
6. Remapping verankern
Architektur-, Vendor- oder Servicewechsel erzeugen ein Remapping, keine still überschriebene Zeile. Incident-Ketten aus Incident Evidence im Betrieb müssen dieselbe Control-ID treffen.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| CISO / ICT Control Owner | ICT-Steward | Pflicht-ID plus Service-Scope und Control-Ziel |
| Steward | ICT-Custodian | Control-ID, Durchsetzung-Punkt, Testartefakt |
| CISO | Vendor / Third-Party Owner | Drittpartei-Evidenzpflicht und Frequenz |
| Steward | Incident Commander | Control-ID für die Ereigniskette |
| Custodian | Internal Audit / Aufsichtskoordination | Export der wirksamen Konfiguration plus Test |
Anti-Patterns
- DORA-Mapping als Namensliste ohne Service-Umfang und Test
- Kritischen Service und Rest der Landschaft unter einer Kontroll-ID vermischen
- ICT-Drittanbieter nur in der Dienstleister-Liste führen, ohne Nachweis verantwortliche Person
- Warehouse-Admin als ICT-verantwortliche Person der Pflicht einsetzen
- Grünes ICT-Dashboard ohne Kontroll-ID als Wirksamkeitsnachweis zeigen
Erster Umsetzungsschnitt
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Eine DORA-Pflicht und genau einen kritischen Service wählen (zum Beispiel Zahlungsverkehr).
- Control-ID, Durchsetzung-Punkt und Evidence Owner schriftlich binden; Wiki-Namen danebenlegen und Differenzen dokumentieren.
- Einen Wirksamkeits-Test plus Config-Export für den Standardbetrieb durchführen.
- Den ICT-Drittpartei-Pfad für denselben Service prüfen: Vertrag, Testfrequenz, Exception mit Ablaufdatum.
Tools und Quellen
Governance in banking and insurance
Part 4 of 5
View series