Definition
DORA Controls-Mapping verbindet regulatorische Anforderungen mit konkreten Prozessschritten und Entscheidungspunkten – sodass Evidenz während des Betriebs entsteht (Freigaben, Ausnahmen, Change Logs) statt im Audit nachträglich rekonstruiert zu werden.
- Kontrollen an **Entscheidungspunkte** mappen (Freigaben, Gateways, Übergaben) – nicht an ganze Prozesse.
- Evidenz als Nebenprodukt: Freigaben + Ausnahmen + Versionsänderungen erzeugen automatisch Trails.
- Mapping mit Publish-Workflow (Draft → Review → Freigabe → Publikation) und Drift-Scorecards aktuell halten.
- Conformance Checking nutzen, um Abweichungen zwischen Ist und dokumentiertem Control-Pfad zu erkennen.
Warum Controls-Mapping bricht (und Audits schmerzhaft werden)
Controls-Mapping scheitert meist aus einem Grund: Es ist nicht mit Veränderung verbunden.
Typischer Ablauf in regulierten Operations:
- Eine Kontrolle wird einem Prozess zugeordnet (oft nur einem High-Level-Block).
- Der Prozess ändert sich durch Upgrade, Digitalisierung oder Rollout.
- Das Mapping wird nicht aktualisiert, weil niemand den Lifecycle besitzt.
- Im Audit wird Evidenz mühsam rekonstruiert und Ausnahmen werden erklärt.
Die Lösung ist nicht „mehr Dokumentation“. Die Lösung ist Evidence by Design:
- Kontrollen an Entscheidungspunkte mappen
- Evidence Points an Freigaben und Übergaben hängen
- Ausnahmen als strukturierte Events erfassen
- Versionsänderungen auf Change Request oder Incident zurückführen
Eine Kontrolle ist erst gemappt, wenn sie Evidenz erzeugt
Wenn Ihr Controls-Mapping keinen Evidence Trail während normaler Arbeit erzeugt, wird es unter Druck scheitern. Designen Sie zuerst den Trail – dann skalieren Sie.
Praktisches Pattern: Control Statement → BPMN-Entscheidungspunkt → Evidenz
Nutzen Sie ein wiederholbares 3-Layer-Pattern:
1) Control Statement
Kontrolle so formulieren, dass sie testbar und evidenzierbar ist:
- „Zugriff auf System X wird nur nach Freigabe durch Rolle Y gewährt und alle N Tage überprüft.“
2) BPMN-Entscheidungspunkt
Kontrolle genau dort mappen, wo sie wirkt:
- Gateway/Decision Node
- Approval Task
- Übergabe zwischen Teams/Systemen
3) Evidence Artifact
Definieren, was beweist, dass die Kontrolle passiert ist:
- Freigabe-Record (wer/wann/warum)
- Exception-Record (Klassifikation + Lösung)
- Log-Event (immutables Event-ID)
So werden Audits wiederholbar: Sie queryen den Evidence Trail statt Dokumente zu jagen.
Evidenz leicht halten – aber querybar
Bevorzugen Sie strukturierte Events (IDs + Metadaten) statt Screenshots und E-Mail-Threads. Wenn Anhänge nötig sind, nutzen Sie Evidence-Templates mit Pflichtfeldern.
Governance-Lifecycle, der das Mapping aktuell hält
Controls-Mapping ist ein lebendes Asset. Es braucht einen Lifecycle wie Software:
- Draft: Prozessänderung vorgeschlagen
- Review: Process Owner + Control Owner validieren Impact
- Freigabe: Publikation mit Evidence-Erwartung
- Run: Operations erzeugt Evidence Trails automatisch
- Monitor: Scorecards zeigen Drift/Decay
Ownership explizit definieren:
- Model Owner (BPMN-Lifecycle)
- Control Owner (Design + Evidence der Kontrolle)
- Data Owner (Logs/Evidence-Quellen)
Third-Party/Outsourcing: Abhängigkeiten als Prozesse modellieren – nicht als Vendor-Liste
DORA erhöht den Fokus auf Drittparteien und Resilienz.
In der Praxis sind Vendoren nicht die beste Analyse-Einheit. Abhängigkeiten sind:
- Systeme und Schnittstellen
- Workflows über Grenzen hinweg
- Oversight-Checkpoints und Freigaben
- Evidenz für laufendes Monitoring
Eine Prozesssicht macht Oversight greifbar:
- Wo hängt ein kritischer Service von externen Systemen ab?
- Was passiert bei Ausfall?
- Welche Kontrollen sind menschliche Freigaben vs automatisierte Detection?
Operational-Resilience-Testing: den Prozess *des Testens* definieren
Resilienz ist kein Dokument – sondern ein wiederholbarer Prozess.
Modellieren Sie Ihre Test-Workflows:
- Szenario-Definition
- Ausführungsschritte und Rollen
- Evidence Collection (Logs, Outcomes, Remediations)
- Post-Mortem und Change Requests
Wenn Testing ein Prozess mit Ownership und Evidenz wird, lässt es sich global skalieren und über Regionen konsistent halten.
Conformance Loop: Divergenzen zwischen dokumentierter Kontrolle und Realität erkennen
Controls-Mapping wird falsch, wenn sich die Realität ändert.
Fügen Sie einen Conformance Loop hinzu:
- „Soll“-Pfad aus BPMN + Evidence Points definieren
- Event Logs auf Schritte mappen (Systeme, Freigaben, Ausnahmen)
- Drift messen: fehlende Freigaben, Bypässe, verspätete Übergaben, Rework
- Fixes nach Impact priorisieren (Risiko + Volumen + Severity)
So wird Controls-Mapping zu einem Monitoring-System – nicht zu einem Jahresprojekt.
Weiterführend:
Häufige Fehler, die Sie vermeiden sollten
Lernen Sie von anderen, um dieselben Fallstricke zu vermeiden.
Kontrollen nur High-Level-Boxen zuordnen
Traceability geht verloren, Evidenz wird unklar.
Kontrollen an Entscheidungspunkte + Evidence-Artefakte mappen.
Evidenz als Screenshots und E-Mail-Threads
Nicht querybar, nicht skalierbar, bricht bei Change.
Strukturierte Event-Evidenz mit IDs + Pflichtmetadaten nutzen.
Keine Ownership für Mapping-Health
Mapping verfällt still bis zur Audit-Saison.
Model-/Control-/Data-Owner festlegen und Scorecards publizieren.
Experten-Insights
Was die Experten sagen
"Ziel ist nicht das perfekte Mapping-Spreadsheet. Ziel ist, dass Evidenz automatisch entsteht, wenn die controls-relevante Entscheidung passiert."
Operational-Risk-Beratung
Regulierte Operations
Handeln Sie
Ihre Aktions-Checkliste
Wenden Sie das Gelernte mit dieser praktischen Checkliste an.
10 Controls wählen, die den größten Audit-Pain erzeugen
Jede Kontrolle an einen BPMN-Entscheidungspunkt mappen (Freigabe/Übergabe/Gateway)
Pro Kontrolle ein querybares Evidence-Artefakt definieren
Model Owner, Control Owner und Data Owner festlegen
Publish-Workflow + Drift-Scorecard implementieren
Conformance Loop für High-Risk Journeys ergänzen