Teil 1
Governance im Risk Management
Begriffe vor dem Lesen
- Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
- verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
- technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
- Nachweis — Prüfbarer Nachweis, der für Audit, Kontrolle, Aufsicht oder interne Freigabe verständlich bleibt.
KMU — eine Loss-Event-Liste und ein Key Risk Indicator (KRI)-Contract mit einem Risk Owner. Mid-Market — Control Library mit getrenntem Control Owner, RCSA-Zyklus mit Steward. Enterprise — föderierte Taxonomie, Key Risk Indicator (KRI)-Versionierung und unabhängiger Control Owner neben Tool-Admin.
Risk-Governance beginnt nicht mit einem Heatmap-Dashboard. Sie beginnt mit Ereignissen, Controls und Schwellen, die Remediation, Kapital und Aufsichtsfragen binden.
Typische Fragen sind:
- Welches Loss-Event gilt für welchen Identifier und welche Periode?; Welche Kontroll-ID war wirksam, als der Test lief?; Welche Key Risk Indicator (Risikokennzahl)-Formel und welche Grundgesamtheit galten am Stichtag?; Wer akzeptiert Restrisiko — verantwortliche Person im Risk-Bereich oder kontrollverantwortliche Person?; Welcher RCSA-Zyklus darf eine Bewertung schließen?
Wenn Loss-Liste, Control Library und Key Risk Indicator (KRI)-Report Scope und Datum nicht teilen, startet Remediation auf der falschen Grundlage. Risk schreibt Kommentare, Analytics färbt Kacheln, und das Spreadsheet der letzten RCSA bleibt die Wahrheit. Das Problem ist nicht das Dashboard. Es ist der fehlende Vertrag zwischen Ereignis, Control, Kennzahl und Zyklus.
Gute Risk-Governance macht Toleranz ausführbar — Loss, Control, Key Risk Indicator (KRI) und RCSA an denselben Identifier und dieselbe Periode, nicht an die neueste Heatmap.
Risk ist eine Peer-Karte in Erweiterte Funktions-Governance — nicht das zweite Kapitel von Legal.
Nachbar-Karten: ← Legal · Risk (diese Seite) · Customer Service →
Konzept halten — Last-Säulen: Access und Verantwortung tragen diese Kette; KPI ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.
Orientierung — Exception und Incident ohne Risk- und Compliance-Suite
| Problem im Alltag | Einstieg | Verantwortung / Beratung / Umsetzung | Einbinden | Ergebnis / Nachweis | Nicht so |
|---|---|---|---|---|---|
| Exceptions ohne Ablauf | Übergabe | Verantwortung: Ageing. Beratung: Risk- und Compliance-Tool | Risk Owner | Ablauf+Eskalation an einer Exception | Register ohne Review |
| Incidents ohne Produkt | Einstiegsangebot | Verantwortung: Produktbezug | Steward + DE | Incident-ID am Product | ITSM ohne Grain |
| Risikoakzeptanz ohne Authority | Einstiegsangebot | Verantwortung: Authority-Zeile | Sponsor | Akzeptanz mit Named A | Chat-OK als Akzeptanz |
Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation
Produkte und Entscheidungen
Risk braucht nicht „eine Governance, Risk & Compliance (Governance, Risk & Compliance (GRC))-Datenbank“, sondern geschnittene Produkte.
Loss-Event
Dieses Produkt beschreibt:
- Event-ID; Taxonomie-Knoten; Identifier (Einheit, Produkt, Periode); Betrags-fachliche Ebene; Quelle; Entdeckungsdatum; verantwortliche Person; Status gegenüber Incident.
Entscheidungen:
- Ist das Ereignis ein Loss, ein Near-Miss oder nur ein Incident-Ticket?; Welches fachliche Ebene gilt für den Betrag (brutto, netto, gebucht)?; Wer darf das Event schließen oder nachbuchen?
Control Library
Ein Control ist keine Checkbox in der RCSA-Folie. Es ist Ziel, Test und Evidenzort.
Es benötigt:
- Kontroll-ID; Ziel; kontrollverantwortliche Person; Frequenz; Testverfahren; Evidenzort; verknüpfte Systeme; Review-Datum.
Entscheidungen:
- Welche Aussage prüft das die Kontrolle wirklich?; Wer ist kontrollverantwortliche Person — nicht der Tool-Admin, der das Flag setzt?; Wann gilt ein Test als bestanden gegenüber einer dokumentierten Absicht?
Key Risk Indicator (KRI)-Contract
Die Key Risk Indicator (KRI) ist keine rote Kachel. Sie ist eine zertifizierte Formel mit Population und Version.
Entscheidungen:
- Welches fachliche Ebene (Event, Loss, Kontrollregel Failure, Exposure) gilt für diese Familie?; Wer darf Schwelle und Formel ändern?; Welche Arbeitsmappe-Neuberechnung zählt als Abweichung, nicht als Feature?
RCSA-Cycle
Der Zyklus bewertet inherent und residual gegen Control-IDs — befristet, mit Freigabe.
Entscheidungen:
- Welcher Zyklus (Einheit, Periode, Umfang) ist offen?; Wer darf residual akzeptieren — verantwortliche Person im Risk-Bereich, nicht der Facilitator?; Welche Kontroll-IDs müssen existieren, bevor die Zeile geschlossen wird?
Wo Governance hängt
Zwischen Loss-Liste und RCSA-Zeile
Ein Event ohne Periode und Einheit ist in der RCSA eine andere Sache. Ohne gemeinsames Grain bewertet das Komitee eine Folie, nicht den Bestand.
Zwischen Control-ID und Testort
Eine Library-Zeile ohne Test und Evidenzort ist Theater. Der Custodian braucht einen auffindbaren Nachweis, nicht nur den Control-Namen.
Zwischen Key Risk Indicator (KRI)-Dashboard und Contract
Das Workbook, das die Population neu schneidet, ist keine zertifizierte Key Risk Indicator (KRI). Version und Formel müssen zum Stichtag reproduzierbar sein.
Zwischen Risk Owner und Control Owner
Wer das Restrisiko akzeptiert, designed nicht automatisch das Control. Genau eine Rolle akzeptiert residual; die andere trägt Wirksamkeit.
Zwischen Incident-Ticket und Loss-Event
Nicht jedes Ticket ist ein Loss. Ohne Regel wird die Incident-Queue zur Schatten-Loss-Liste — oder echte Verluste bleiben unsichtbar.
Zwischen Tool-Admin und Schwelle
Wer die rote Linie in BI verschieben kann, ist nicht berechtigt, Toleranz zu ändern.
Rollen-Mapping
Data Owner (Risk)
CRO, Head of Operational Risk oder benannter Risk Owner ist accountable für Zweck der Risk-Datenprodukte, akzeptiertes Restrisiko, Schwellen und Freigabe zentraler Nachweise. Der Owner entscheidet nicht die Warehouse-Modellierung.
Control Owner
Process Owner oder benannter Control Owner trägt Design, Testfrequenz und Wirksamkeit. Control Owner ist nicht der Risk- und Compliance-Tool-Admin und nicht automatisch der Risk Owner.
Data Steward
Risk Operations oder Risk Control Unit prüft nachträgliche Verlustmeldungen, pflegt Kontroll-IDs und Versionen der Risikokennzahlen, überwacht RCSA-Fristen und eskaliert widersprüchliche Grundgesamtheiten.
Data Product Owner
Priorisiert Verlustdaten, Kontrollverzeichnis und zertifizierte Risikokennzahlen. Nutzen und Lieferbarkeit — nicht die Risikoakzeptanz.
Data Architect
Schützt die fachliche Ebene der Daten: Ein Vorfall, ein finanzieller Verlust und ein Risikoexposure sind nicht dieselbe Sache. Außerdem hält der Architect fest, woher die Formel einer Risikokennzahl kommt und welche Änderungen bestehende Auswertungen brechen würden.
Data Custodian
Zugriffsverwaltung, Plattform und Reporting setzen Formel, Zugriff und gespeicherte Stichtagsstände um. Wer ein System konfigurieren kann, entscheidet damit nicht über Risikotoleranz.
Data Consumer
Risk Committee, Internal Audit, Finance, Aufsichts-Koordination und Analytics nutzen die Zahlen. Abweichungen laufen über denselben Intake — keine stillen Risikokennzahlen in privaten Workbooks.
Mini-Fall
Anwendungsbeispiel (Lehrfall, keine Kundendaten).
Symptom: Ein Kontrollversagen steht nur in einem Incident-Ticket. Die Verlustliste nennt den Vormonat. Im Kontrollverzeichnis steht zwar eine ID, aber kein Ort, an dem der Testnachweis liegt. Die Risikokennzahl im Arbeitsmappe zeigt Grün, weil dort weniger Fälle gezählt werden als in der offiziellen Definition.
Typischer Fehlstart: Eine Governance-, Risiko- und Compliance-Software-Software kaufen und im Katalog risk-owned=true setzen, ohne die Risikokennzahl, den Testort und die Beziehung zwischen Vorfall und Verlust sauber zu vereinbaren.
Vereinbarung: Jedes Verlustereignis bekommt ID, Periode, Einheit und Betragslogik. Jede Kontrolle bekommt verantwortliche Person, Test und Evidenzort. Jede Risikokennzahl bekommt Formelversion, Grundgesamtheit und Schwellenwert. Eine RCSA-Zeile darf nur schließen, wenn die referenzierten Kontrollen wirklich existieren.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Risk Owner / CRO | Steward | Verlustereignis mit Identifier, Periode und Betragslogik |
| Control Owner | Steward | Control-Library-Eintrag mit Test und Evidenzort |
| Steward | Plattform-Custodian | Formel, Quelle, Validierung und Stichtagsstand der Risikokennzahl |
| Steward | Architect / Engineering | Regel, wann aus Vorfall, Verlust und Risikokennzahl dieselbe fachliche Aussage wird |
| Risk Manager | Risk Owner | Threshold-Exception mit Ablauf und Remediation Owner |
| RCSA-Facilitator | Risk Owner | Zyklus-Pack: inherent/residual, Control-IDs, Freigabe |
| Custodian | Risk Owner | Stichtagsstand der Risikokennzahl mit Formelversion, Grundgesamtheit und Kontrolltest-Nachweis für den offenen Zyklus |
Anti-Patterns
- Incident-Ticket als Verlustereignis ohne fachliche Ebene und Nachbuchungsregel
- Kontrollverzeichnis ohne Testort, nur als RCSA-Dropdown
- Schwelle einer Risikokennzahl im Arbeitsmappe neu rechnen und als offizielle Serie zeigen
- verantwortliche Person im Risk-Bereich und kontrollverantwortliche Person in einer Person vermischen, ohne die zwei Entscheidungen zu trennen
- RCSA-Spreadsheet ohne offenen Zyklus und ohne Freigabe-Datum
- Tool-Admin ändert die rote Linie, weil die UI es hergibt
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.
Schritt 1: Rahmen und Entscheidung klären
Einen laufenden oder jüngsten Loss- oder Control-Fail wählen. Event-ID, Periode, Einheit, Incident-Ticket, Control-IDs und Key Risk Indicator (KRI)-Snapshots aufnehmen. Loss-Event-Produkt mit fünf Einträgen schneiden.
Schritt 2: Control und Nachweis umsetzen
Einen Key Risk Indicator (KRI)-Contract (Formel, Population, Version, Schwelle) produktiv schalten. Einen Control-Library-Eintrag mit Test und Evidenzort verbinden. Negativtest: Workbook-Neuberechnung weicht von der zertifizierten Formel ab und darf nicht als Key Risk Indicator (KRI) gelten.
Schritt 3: Testen und Ausnahmen sichtbar machen
Einen RCSA-Zyklus für eine Einheit mit Owner-Freigabe durchspielen. Eine Threshold-Exception mit Ablauf und Remediation Owner dokumentieren. Residual-Akzeptanz bleibt beim Risk Owner.
Schritt 4: Messen und begrenzt ausrollen
Aufwand und Lücken messen. Nur bestandene Muster (Loss-Grain, Control-Evidenz, Key Risk Indicator (KRI)-Version) auf einen zweiten Risiko-Typ oder eine zweite Rechtseinheit übertragen.
Exit-Kriterien
- Loss-Event hat Identifier, Periode, Betrags-fachliche Ebene und verantwortliche Person.
- Kontrollverzeichnis nennt Test und Evidenzort, nicht nur den Namen.
- Key Risk Indicator (Risikokennzahl)-Vereinbarung hat Version, Grundgesamtheit und Schwellen-verantwortliche Person.
- RCSA-Cycle schließt nur gegen existierende Kontroll-IDs.
- verantwortliche Person im Risk-Bereich und kontrollverantwortliche Person sind getrennte Entscheidungen.
- technischer Betreiber liefert Konfigurationsnachweis ohne mündliche Brücke.
Weiterlesen
- Extended Functions Deep Dive
- Functions Hub — Risk
- Risk-Taxonomie und KRIs als Data Vereinbarungen
- Audit Nachweis Operating