Geist
Book a demo
← All posts
doraoperational-resilienceprocess-intelligencefinancial-servicesict-risk-management

DORA and operational resilience: why process maps must stay live

DORA has applied since 17 January 2025. For financial entities, resilience evidence depends on live dependency maps, incident workflows, recovery playbooks, and audit trails.

Michael Glück

DORA is already live. EIOPA says the Digital Operational Resilience Act entered into application on 17 January 2025 and is meant to help banks, insurance companies, investment firms, and other financial entities withstand, respond to, and recover from ICT disruption such as cyberattacks and system failures.

That is a strong topic for finance, insurance, and public-sector-adjacent enterprise sales. It also needs discipline. The public claim should not be “Geist makes you DORA compliant.” That is too broad, and legal teams will not buy it.

The defensible claim is sharper:

DORA readiness needs live operational evidence. Geist can help financial entities keep process dependency maps, incident workflows, recovery playbooks, third-party links, dashboards, approvals, and audit records tied to how work actually runs.

A one-time model is weak evidence. A live model that changes when systems, incidents, vendors, and recovery paths change is much closer to what resilience teams need.

The pressure point: static maps decay

EIOPA summarizes DORA around ICT risk management, ICT third-party risk, resilience testing, ICT-related incidents, information sharing, and oversight of critical ICT third-party providers.

The legal text makes the mapping problem more concrete. Article 8 requires financial entities to identify, classify, and document ICT-supported business functions, roles, responsibilities, information assets, and ICT assets. It also requires mapping critical information and ICT assets, including links and interdependencies, identifying processes dependent on ICT third-party service providers, and updating inventories periodically and after major changes.

That is the opening. DORA turns process maps from documentation into operational evidence.

If the map only reflects a workshop from last quarter, it is already suspicious. The useful question is whether the organization can show the current dependency chain:

  • Which critical or important function is affected?
  • Which process step depends on which application, data source, cloud service, facility, provider, team, or approval?
  • Which customer, account, claim, payment, trade, policy, or case is exposed?
  • Which fallback path applies?
  • Who owns containment, communication, recovery, and restart?
  • Which evidence proves what happened before, during, and after disruption?

What process intelligence can support

Process intelligence does not replace legal advice, ICT risk governance, security operations, business continuity management, third-party risk management, or supervisory reporting. It can make the evidence work less brittle.

01Dependency map

Critical function, process step, ICT asset, provider, owner, and fallback route.

02Incident workflow

Detection, classification, escalation, containment, recovery, root cause, and control update.

03Recovery playbook

Minimum viable path, owners, backup systems, communication route, test result, and defect.

04Third-party exposure

Provider, contract, service level, region, subservice, continuity impact, and alternative path.

05Learning loop

New evidence, drift, weak recovery paths, proposed changes, approvals, and audit history.

1. Live dependency maps for critical functions

DORA’s Article 8 language is a gift for the process-intelligence category. The buyer does not need another flat system inventory. They need a map that connects ICT assets to business functions and live work.

Useful evidence includes:

  • Business function and process.
  • Process step and owner.
  • Application, data source, integration, queue, cloud service, or provider.
  • Criticality of the process or function.
  • Known single points of failure.
  • Upstream and downstream dependencies.
  • Manual workaround and recovery path.
  • Last observed change.

Geist’s fit: BPMN models, process mining, variants, conformance checks, org ownership, import/connectors, and world signals can sit on the same process-native map. The value is a dependency map that can be challenged by new evidence.

2. Incident workflows tied to process impact

Article 17 requires financial entities to define and implement an ICT-related incident management process. It also requires recording all ICT-related incidents and significant cyber threats, consistent monitoring and follow-up, root-cause documentation, early warning indicators, procedures to track, log, categorize, and classify incidents, roles and responsibilities, escalation, communication, senior-management reporting, and response procedures.

That reads like a workflow.

For DORA work, incident evidence should answer:

  • Which process or critical function did the incident affect?
  • Which services, customers, transactions, or counterparties were impacted?
  • Which role was activated?
  • When was the event detected, classified, escalated, contained, and recovered?
  • Which action was approved, rejected, or delayed?
  • Which root cause was found?
  • Which control changed afterward?

Geist’s fit: operational events, alert intelligence, process-bound findings, action proposals, approval-gated tasks, notifications, and audit handoffs are the right shape for incident response evidence. The model becomes the routing surface for the incident.

3. Recovery playbooks that can be tested

Article 11 covers response and recovery. It requires ICT business continuity policy and response and recovery plans, including activation of plans for containment, communication, and recovery. It also points to testing business continuity and response plans, and keeping accessible records before and during disruption events when those plans are activated.

Article 12 covers backup, restoration, and recovery procedures.

The sales point is simple: a recovery playbook is only useful when it is attached to the real process it recovers.

Good DORA evidence should show:

  • The process that must continue.
  • The minimum viable process path during disruption.
  • Recovery-time and recovery-point assumptions where the organization tracks them.
  • Owner, deputy, escalation route, and communication path.
  • Required systems and backup systems.
  • Manual fallback route.
  • Test date, test result, defect, and remediation.
  • Change history after the test.

Geist’s fit: living BPMN models, model versions, variants, owner graph, action history, auto-updated charts, and test-result feedback can keep the recovery path attached to the operating model. This is much stronger than “we have a PDF in SharePoint.”

4. Third-party ICT risk as a process dependency

Article 28 requires financial entities to manage ICT third-party risk as part of their ICT risk framework. It covers ICT services that run business operations, critical or important functions, dependency criticality, potential continuity impact, a strategy for ICT third-party risk, and a register of information for contractual arrangements with ICT third-party service providers.

That makes vendor risk a process question.

For each provider, the practical questions are:

  • Which process and function does this provider support?
  • Is the function critical or important?
  • Which contracts, service levels, regions, and subservices matter?
  • Which alternative route exists if the provider fails?
  • Which customer-facing service degrades first?
  • Which internal owner receives the alert?
  • Which playbook activates?

Geist’s fit: process maps, org ownership, location and world context, third-party links, live signals, and action proposals can connect provider status to affected work. A third-party register is useful. A third-party register tied to process impact is much more useful.

5. Post-incident learning that updates the model

DORA also demands improvement after disruption. Article 6 says the ICT risk management framework must be documented, reviewed periodically and after major ICT-related incidents, and improved based on lessons from implementation and monitoring. Article 13 adds post-incident reviews and continuous incorporation of lessons into ICT risk assessment.

This is where a live process model beats a workshop model.

The useful loop is:

  1. Import new evidence from systems, incidents, logs, providers, and external signals.
  2. Compare it with affected process models.
  3. Flag drift, missing dependencies, weak recovery paths, and repeated incident patterns.
  4. Suggest model updates, control changes, charts, and owner actions.
  5. Feed accepted changes back into the operating model and audit trail.

Geist’s fit: agents can analyze new data, compare it against affected process models, suggest updates or warnings, create charts for easy review, and keep those charts updated as new evidence arrives. The claim should stay grounded: this depends on configured data access and review. It is still a huge step above “model from a prompt, immediately outdated.”

DORA-relevant data sources

The strongest product story is live evidence from internal systems and external signals, with clear provenance.

Internal sources:

  • ERP and finance systems such as SAP event logs, payment status, procurement events, invoice events, and master data changes.
  • CRM and case systems such as Salesforce, HubSpot, claims queues, support cases, and customer-impact records.
  • ITSM and incident platforms, including incident, change, problem, and postmortem records.
  • CMDB and asset inventory, including application-to-infrastructure dependencies.
  • SIEM, endpoint, IAM, and audit logs for security-relevant events.
  • Monitoring and APM data for service health, latency, downtime, and error spikes.
  • File and document systems for recovery plans, contracts, evidence packs, and test reports.

External and platform sources:

  • AWS Health for events affecting AWS resources and accounts.
  • Azure Resource Health for current and past Azure resource health.
  • Google Cloud Service Health for disruptive events and affected resources.
  • ServiceNow CMDB APIs for configuration items and relations.
  • Weather, catastrophe, geopolitical, sanctions, transport, market, and provider-status feeds where they affect critical services.

Geist’s current feature set lines up with this story: Platform Hub for SAP, Salesforce, HubSpot, DATEV, SharePoint, Google Drive, Visio, draw.io, and ARIS; process mining and variant explorer; World Signals and operational events; AI-saved charts; action proposals; approval controls; and audit ledger handoffs.

The careful phrase is “where configured and permitted.” No serious buyer will believe a system magically sees everything. They will believe a system that treats every imported signal as evidence with source, timestamp, owner, and approval path.

Questions buyers should ask

For DORA conversations, enterprise buyers and consultants should ask harder questions than “Do you support operational resilience?”

Ask this:

  • Can you map critical business functions to process steps and ICT dependencies?
  • Can you update that map from live system evidence?
  • Can you show which process is affected by a cloud, provider, application, or data issue?
  • Can incident workflows activate the right owner, escalation, communication, and recovery route?
  • Can you show records before and during a disruption?
  • Can recovery tests update the process model and playbook?
  • Can third-party risk be viewed by business function and process impact instead of vendor name alone?
  • Can new evidence create warnings, charts, and proposed changes without waiting for a manual modeling workshop?
  • Can humans review and approve changes before they touch operational models or actions?
  • Can auditors see what changed, who approved it, and why?

Those questions expose the difference between a static repository and a living resilience layer.

Where Geist fits

For DORA work, evaluate Geist on this practical question:

Digital operational resilience depends on live process evidence. Geist can help teams keep critical/important-function maps current, connect incidents to affected processes, bind recovery playbooks to real dependencies, track third-party ICT exposure, and preserve an audit trail from warning to action to model update.

GRC tools can track policies and controls. ITSM tools can track tickets. CMDBs can track assets. Process intelligence can show how disruption moves through work.

Geist is useful where that loop matters: live imports and signals, process models, agents, warnings, charts, approvals, recovery actions, and audit history feeding back into the model.

Sources

Answers

Quick answers

Short buyer answers linked to this article.
Process intelligence for DORADORA work needs living evidence of how critical operations depend on ICT systems, third parties, controls, incidents, and recovery actions. Process intelligence helps keep those process maps, owners, logs, playbooks, and audit evidence current.Open answer →Process intelligence for EU AI ActEU AI Act readiness depends on knowing where AI touches business processes, which humans supervise decisions, what data and controls apply, and which logs prove what happened. Process intelligence can turn that into a living process view.Open answer →Process intelligence platform comparisonA useful comparison starts with the process you need to improve, not the analyst chart. Score each platform on ingestion, mining, modeling, ownership, AI controls, action workflow, audit, security, and rollout effort.Open answer →

FAQ

Frequently asked questions

Common buyer questions, answered directly.

4 questions
01Can process intelligence make a company DORA compliant?

No. DORA compliance depends on the financial entity, ICT services, contracts, controls, competent authority expectations, testing, incident handling, and legal interpretation. Process intelligence can support the evidence layer: live dependency maps, incident workflows, recovery playbooks, third-party links, logs, and audit history.

02Why are live process maps relevant to DORA?

DORA requires financial entities to identify ICT-supported business functions, map critical ICT assets and interdependencies, manage ICT-related incidents, maintain response and recovery plans, and manage ICT third-party risk. Static process maps go stale as systems, providers, risks, and recovery paths change.

03Which DORA topics fit process intelligence best?

ICT-supported business-function mapping, dependency mapping, incident classification, response workflows, recovery playbooks, testing evidence, third-party ICT service mapping, audit records, and post-incident improvement.

04Where does Geist claim an advantage?

Geist's advantage is live operational evidence: BPMN models, event-log process mining, connector/import data, world signals, agent-suggested model updates, auto-updated charts, action proposals, approval workflows, and audit trails in one process loop.