DORA und operative Resilienz: warum Prozesskarten lebendig bleiben müssen
DORA gilt seit dem 17. Januar 2025. Für Finanzunternehmen hängt Resilienz-Evidenz an lebendigen Dependency Maps, Incident Workflows, Recovery Playbooks und Audit Trails.
DORA gilt bereits. EIOPA sagt, dass der Digital Operational Resilience Act seit dem 17. Januar 2025 anwendbar ist und Banken, Versicherungen, Investmentfirmen und andere Finanzunternehmen dabei unterstützen soll, ICT-Störungen wie Cyberangriffe oder Systemausfälle zu überstehen, darauf zu reagieren und sich davon zu erholen.
Das ist ein starkes Thema für Finance, Insurance und Public-Sector-nahe Enterprise Sales. Es braucht aber Disziplin. Die öffentliche Aussage sollte nicht lauten: “Geist macht euch DORA-compliant.” Das ist zu breit, und Legal Teams werden es sofort auseinandernehmen.
Die belastbare Aussage ist schärfer:
DORA-Readiness braucht lebendige operative Evidenz. Geist kann Finanzunternehmen helfen, Prozess-Dependency-Maps, Incident Workflows, Recovery Playbooks, Third-Party-Links, Dashboards, Freigaben und Audit Records an die tatsächliche Ausführung von Arbeit zu binden.
Ein einmaliges Modell ist schwache Evidenz. Ein lebendiges Modell, das sich ändert, wenn Systeme, Incidents, Anbieter und Recovery-Pfade sich ändern, ist näher an dem, was Resilience Teams brauchen.
Der Druckpunkt: statische Maps verfallen
EIOPA fasst DORA über ICT Risk Management, ICT Third-Party Risk, Resilience Testing, ICT-bezogene Incidents, Information Sharing und Oversight kritischer ICT Third-Party Provider zusammen.
Der Gesetzestext macht das Mapping-Problem konkreter. Artikel 8 verlangt, dass Finanzunternehmen ICT-gestützte Business Functions, Rollen, Verantwortlichkeiten, Information Assets und ICT Assets identifizieren, klassifizieren und dokumentieren. Er verlangt auch, kritische Information Assets und ICT Assets samt Links und Interdependenzen zu mappen, Prozesse mit Abhängigkeit von ICT Third-Party Service Providers zu identifizieren und Inventare regelmäßig sowie nach größeren Änderungen zu aktualisieren.
Das ist der Einstieg. DORA macht Prozesskarten von Dokumentation zu operativer Evidenz.
Wenn die Map nur einen Workshop vom letzten Quartal abbildet, ist sie bereits verdächtig. Die nützliche Frage ist, ob die Organisation die aktuelle Dependency Chain zeigen kann:
- Welche critical oder important function ist betroffen?
- Welcher Prozessschritt hängt von welcher Anwendung, Datenquelle, Cloud Service, Facility, welchem Provider, Team oder Approval ab?
- Welcher Kunde, Account, Claim, Payment, Trade, Vertrag oder Case ist exponiert?
- Welcher Fallback Path gilt?
- Wer besitzt Containment, Kommunikation, Recovery und Restart?
- Welche Evidenz belegt, was vor, während und nach der Störung passiert ist?
Was Process Intelligence unterstützen kann
Process Intelligence ersetzt keine Rechtsberatung, ICT Risk Governance, Security Operations, Business Continuity Management, Third-Party Risk Management oder aufsichtsrechtliches Reporting. Sie kann die Evidenzarbeit weniger brüchig machen.
Critical Function, Prozessschritt, ICT Asset, Provider, Owner und Fallback Route.
Detection, Classification, Escalation, Containment, Recovery, Root Cause und Control Update.
Minimaler Prozesspfad, Owner, Backup-Systeme, Kommunikationsroute, Testergebnis und Defect.
Provider, Contract, Service Level, Region, Subservice, Continuity Impact und Alternative Path.
Neue Evidenz, Drift, schwache Recovery Paths, vorgeschlagene Änderungen, Freigaben und Audit-Historie.
1. Lebendige Dependency Maps für kritische Funktionen
DORAs Artikel 8 ist ein Geschenk für die Process-Intelligence-Kategorie. Käufer brauchen kein weiteres flaches Systeminventar. Sie brauchen eine Map, die ICT Assets mit Business Functions und laufender Arbeit verbindet.
Nützliche Evidenz enthält:
- Business Function und Prozess.
- Prozessschritt und Owner.
- Anwendung, Datenquelle, Integration, Queue, Cloud Service oder Provider.
- Kritikalität des Prozesses oder der Funktion.
- Bekannte Single Points of Failure.
- Upstream- und Downstream-Abhängigkeiten.
- Manueller Workaround und Recovery Path.
- Letzte beobachtete Änderung.
Geist-Passung: BPMN-Modelle, Process Mining, Varianten, Conformance Checks, Org Ownership, Import/Konnektoren und World Signals können auf derselben prozessnativen Map liegen. Der Wert liegt in einer Dependency Map, die durch neue Evidenz angegriffen werden kann.
2. Incident Workflows mit Prozess-Impact
Artikel 17 verlangt, dass Finanzunternehmen einen ICT-related Incident Management Process definieren und implementieren. Er verlangt auch die Aufzeichnung aller ICT-related Incidents und significant cyber threats, konsistentes Monitoring und Follow-up, Root-Cause-Dokumentation, Early Warning Indicators, Verfahren zum Tracken, Loggen, Kategorisieren und Klassifizieren von Incidents, Rollen und Verantwortlichkeiten, Eskalation, Kommunikation, Senior-Management-Reporting und Response Procedures.
Das liest sich wie ein Workflow.
Für DORA-Arbeit sollte Incident-Evidenz beantworten:
- Welcher Prozess oder welche kritische Funktion war betroffen?
- Welche Services, Kunden, Transaktionen oder Counterparties waren betroffen?
- Welche Rolle wurde aktiviert?
- Wann wurde das Event erkannt, klassifiziert, eskaliert, contained und recovered?
- Welche Aktion wurde freigegeben, abgelehnt oder verzögert?
- Welche Root Cause wurde gefunden?
- Welche Kontrolle hat sich danach geändert?
Geist-Passung: Operational Events, Alert Intelligence, prozessgebundene Findings, Action Proposals, approval-gated Tasks, Notifications und Audit Handoffs haben die richtige Form für Incident-Response-Evidenz. Das Modell wird zur Routing-Oberfläche für den Incident.
3. Recovery Playbooks, die testbar bleiben
Artikel 11 behandelt Response and Recovery. Er verlangt ICT Business Continuity Policy und Response and Recovery Plans, inklusive Aktivierung von Plänen für Containment, Kommunikation und Recovery. Er verweist auch auf Tests von Business-Continuity- und Response-Plänen sowie auf zugängliche Records vor und während Disruption Events, wenn diese Pläne aktiviert werden.
Artikel 12 behandelt Backup, Restoration und Recovery Procedures.
Der Sales Point ist einfach: Ein Recovery Playbook ist nur nützlich, wenn es an den echten Prozess gebunden ist, den es wiederherstellen soll.
Gute DORA-Evidenz zeigt:
- Den Prozess, der weiterlaufen muss.
- Den minimalen Prozesspfad während der Störung.
- Recovery-Time- und Recovery-Point-Annahmen, wo die Organisation sie trackt.
- Owner, Deputy, Eskalationsroute und Kommunikationspfad.
- Benötigte Systeme und Backup-Systeme.
- Manuellen Fallback.
- Testdatum, Testergebnis, Defect und Remediation.
- Änderungshistorie nach dem Test.
Geist-Passung: Lebendige BPMN-Modelle, Modellversionen, Varianten, Owner Graph, Action History, auto-aktualisierte Charts und Feedback aus Testergebnissen können den Recovery Path am Operating Model halten. Das ist deutlich stärker als “wir haben ein PDF in SharePoint.”
4. ICT Third-Party Risk als Prozessabhängigkeit
Artikel 28 verlangt, dass Finanzunternehmen ICT Third-Party Risk als Teil ihres ICT Risk Frameworks managen. Er behandelt ICT Services, die Business Operations ausführen, critical oder important functions, Kritikalität von Dependencies, möglichen Impact auf Continuity, eine Strategie für ICT Third-Party Risk und ein Register of Information für vertragliche Arrangements mit ICT Third-Party Service Providers.
Damit wird Vendor Risk zur Prozessfrage.
Für jeden Provider zählen diese Fragen:
- Welchen Prozess und welche Funktion unterstützt dieser Provider?
- Ist die Funktion critical oder important?
- Welche Verträge, Service Levels, Regionen und Subservices zählen?
- Welche alternative Route gibt es, wenn der Provider ausfällt?
- Welcher kundennahe Service degradiert zuerst?
- Welcher interne Owner bekommt den Alert?
- Welches Playbook wird aktiviert?
Geist-Passung: Prozesskarten, Org Ownership, Location- und World-Kontext, Third-Party-Links, Live Signals und Action Proposals können Provider-Status mit betroffener Arbeit verbinden. Ein Third-Party Register ist nützlich. Ein Third-Party Register mit Prozess-Impact ist viel nützlicher.
5. Post-Incident Learning, das das Modell aktualisiert
DORA geht über Aufzeichnung hinaus. Artikel 6 sagt, dass das ICT Risk Management Framework dokumentiert, regelmäßig und nach größeren ICT-related Incidents geprüft und auf Basis von Lessons aus Implementation und Monitoring verbessert werden muss. Artikel 13 ergänzt Post-Incident Reviews und die laufende Übernahme von Lessons in das ICT Risk Assessment.
Hier schlägt ein lebendiges Prozessmodell ein Workshop-Modell.
Die nützliche Schleife:
- Neue Evidenz aus Systemen, Incidents, Logs, Providern und externen Signalen importieren.
- Mit betroffenen Prozessmodellen vergleichen.
- Drift, fehlende Dependencies, schwache Recovery Paths und wiederholte Incident Patterns flaggen.
- Modellupdates, Control Changes, Charts und Owner Actions vorschlagen.
- Akzeptierte Änderungen zurück ins Operating Model und den Audit Trail führen.
Geist-Passung: Agenten können neue Daten analysieren, sie gegen betroffene Prozessmodelle vergleichen, Updates oder Warnungen vorschlagen, Charts für Review erstellen und diese Charts aktualisieren, wenn neue Evidenz einläuft. Die Aussage muss geerdet bleiben: Das hängt von konfiguriertem Datenzugriff und Review ab. Es ist trotzdem ein großer Schritt über “Modell aus Prompt, direkt wieder veraltet” hinaus.
DORA-relevante Datenquellen
Die stärkste Produktstory ist lebendige Evidenz aus internen Systemen und externen Signalen, mit klarer Provenienz.
Interne Quellen:
- ERP- und Finance-Systeme wie SAP Event Logs, Payment Status, Procurement Events, Invoice Events und Master-Data-Änderungen.
- CRM- und Case-Systeme wie Salesforce, HubSpot, Claims Queues, Support Cases und Customer-Impact Records.
- ITSM- und Incident-Plattformen, inklusive Incident, Change, Problem und Postmortem Records.
- CMDB und Asset Inventory, inklusive Application-to-Infrastructure Dependencies.
- SIEM-, Endpoint-, IAM- und Audit Logs für security-relevante Events.
- Monitoring- und APM-Daten für Service Health, Latency, Downtime und Error Spikes.
- Datei- und Dokumentensysteme für Recovery Plans, Contracts, Evidence Packs und Test Reports.
Externe und Plattformquellen:
- AWS Health für Events, die AWS Resources und Accounts betreffen.
- Azure Resource Health für aktuellen und früheren Azure Resource Health.
- Google Cloud Service Health für disruptive Events und betroffene Resources.
- ServiceNow CMDB APIs für Configuration Items und Relations.
- Wetter-, Katastrophen-, Geopolitik-, Sanctions-, Transport-, Markt- und Provider-Status-Feeds, wenn sie kritische Services betreffen.
Das aktuelle Geist-Feature-Set passt zu dieser Story: Platform Hub für SAP, Salesforce, HubSpot, DATEV, SharePoint, Google Drive, Visio, draw.io und ARIS; Process Mining und Variant Explorer; World Signals und Operational Events; AI-saved Charts; Action Proposals; Freigabekontrollen; und Audit-Ledger-Handoffs.
Die saubere Formulierung lautet “wo konfiguriert und erlaubt”. Kein ernsthafter Käufer glaubt, dass ein System magisch alles sieht. Käufer glauben eher einem System, das jedes importierte Signal als Evidenz mit Quelle, Zeitstempel, Owner und Approval Path behandelt.
Fragen, die Käufer stellen sollten
Für DORA-Gespräche sollten Enterprise-Käufer und Consultants härter fragen als “Unterstützt ihr operative Resilienz?”
Bessere Fragen:
- Könnt ihr kritische Business Functions auf Prozessschritte und ICT Dependencies mappen?
- Könnt ihr diese Map aus Live-Systemevidenz aktualisieren?
- Könnt ihr zeigen, welcher Prozess von einem Cloud-, Provider-, Application- oder Data-Issue betroffen ist?
- Können Incident Workflows den richtigen Owner, Eskalations-, Kommunikations- und Recovery-Pfad aktivieren?
- Könnt ihr Records vor und während einer Disruption zeigen?
- Können Recovery Tests das Prozessmodell und Playbook aktualisieren?
- Kann Third-Party Risk nach Business Function und Prozess-Impact betrachtet werden statt allein nach Vendor Name?
- Kann neue Evidenz Warnungen, Charts und vorgeschlagene Änderungen erzeugen, ohne auf einen manuellen Modeling Workshop zu warten?
- Können Menschen Änderungen prüfen und freigeben, bevor sie operative Modelle oder Aktionen berühren?
- Können Auditoren sehen, was sich geändert hat, wer es freigegeben hat und warum?
Diese Fragen zeigen den Unterschied zwischen einem statischen Repository und einer lebendigen Resilience Layer.
Wo Geist passt
Für DORA-Arbeit sollte Geist an dieser praktischen Frage geprüft werden:
Digitale operative Resilienz hängt von lebendiger Prozess-Evidenz ab. Geist kann Teams helfen, Critical/Important-Function Maps aktuell zu halten, Incidents mit betroffenen Prozessen zu verbinden, Recovery Playbooks an echte Dependencies zu binden, ICT Third-Party Exposure zu verfolgen und den Audit Trail von Warnung zu Aktion zu Modellupdate zu erhalten.
GRC Tools können Policies und Controls tracken. ITSM Tools können Tickets tracken. CMDBs können Assets tracken. Process Intelligence kann zeigen, wie Störung durch Arbeit läuft.
Geist ist nützlich, wenn diese Schleife zählt: Live-Imports und Signale, Prozessmodelle, Agenten, Warnungen, Charts, Freigaben, Recovery Actions und Audit-Historie fließen zurück ins Modell.
Quellen
- EIOPA: Digital Operational Resilience Act (DORA)
- EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector
- Gartner: Process Mining Platforms, transitioning to Process Intelligence Platforms
- AWS: AWS Health Documentation
- Microsoft Learn: Azure Resource health REST API
- Google Cloud: Service Health API
- ServiceNow: CMDB Instance API
- Geist: Das lebendige Betriebsmodell
- Verwandt: Process Intelligence für EU-AI-Act-Readiness
- Verwandt: Die Prozess-Kontextschicht: Was Enterprise AI braucht, bevor sie handelt
Antworten
Schnelle Antworten
Kurze Käuferantworten, passend zu diesem Artikel.FAQ
Häufige Fragen
Direkte Antworten auf die wichtigsten Kauf- und Vergleichsfragen.
01Kann Process Intelligence ein Unternehmen DORA-compliant machen?
Nein. DORA-Compliance hängt vom Finanzunternehmen, den ICT-Services, Verträgen, Kontrollen, Erwartungen der Aufsicht, Tests, Incident Handling und rechtlicher Auslegung ab. Process Intelligence kann die Evidenzschicht unterstützen: lebendige Dependency Maps, Incident Workflows, Recovery Playbooks, Third-Party-Links, Logs und Audit-Historie.
02Warum sind lebendige Prozesskarten für DORA relevant?
DORA verlangt, dass Finanzunternehmen ICT-gestützte Business Functions identifizieren, kritische ICT Assets und Interdependenzen mappen, ICT-bezogene Incidents managen, Response- und Recovery-Pläne pflegen und ICT Third-Party Risk steuern. Statische Prozesskarten veralten, sobald Systeme, Provider, Risiken oder Recovery-Pfade sich ändern.
03Welche DORA-Themen passen am besten zu Process Intelligence?
Mapping ICT-gestützter Business Functions, Dependency Mapping, Incident-Klassifizierung, Response Workflows, Recovery Playbooks, Test-Evidenz, Mapping von ICT Third-Party Services, Audit Records und Post-Incident Improvement.
04Wo sieht Geist den Vorteil?
Geist-Vorteil ist lebendige operative Evidenz: BPMN-Modelle, Eventlog Process Mining, Connector-/Importdaten, World Signals, agentische Modellupdates, auto-aktualisierte Charts, Action Proposals, Freigabe-Workflows und Audit Trails in einer Prozessschleife.