DORA
Regulation (EU) 2022/2554 — Digital Operational Resilience Act
EU financial-services operational resilience regulation. ICT third-party LLM providers and agent runtimes are in scope; the agent itself is an ICT system.
Who does it apply to?
- EU financial institutions: banks, insurers, investment firms, payment institutions, crypto-asset providers, fund managers, market infrastructure operators.
- Critical ICT third-party providers (CTPPs) — including LLM providers (OpenAI, Anthropic, Google) once designated by ESAs.
- Any EU financial firm running an agentic AI workflow that performs material business operations — credit decisions, treasury operations, fraud detection.
Two-minute explainer
The Digital Operational Resilience Act (DORA) became effective on 17 January 2025. It’s the EU’s first comprehensive, cross-financial- sector regulation for ICT (Information and Communication Technology) operational resilience. For agentic AI builders in EU financial services, DORA matters in two distinct ways:
As an ICT system. Your agent is an ICT system under DORA’s definition. The same obligations that apply to your core banking platform — risk management framework (Article 5), incident handling and reporting (Articles 17–23), operational resilience testing (Articles 24–27), digital operational resilience strategy and tools — apply to your agent. The agent isn’t carved out because it’s AI.
As an ICT consumer of third parties. The LLM provider behind your agent (OpenAI, Anthropic, Google) is an ICT third-party. The GCP services your agent depends on (Vertex, Firestore, GCS) are ICT third-parties. DORA Articles 28–44 cover ICT third-party risk management, including a structured register (EBA register format) maintained at the firm level and the European Supervisory Authorities’ oversight regime for Critical ICT Third-Party Providers (CTPPs).
The Regulus DORA profile covers both sides. Operationally:
- The kill-switch plugin is the agent’s circuit breaker for ICT incidents. Dual-control engagement produces a structured incident event that triggers the DORA notification timeline. The audit chain captures both Principals, the reason, the operational state at the moment of engagement.
- The audit plugin provides the 24-month-retained hash-chained event stream that DORA Article 5 expects as the substrate for risk management. (DORA’s register-keeping requires longer — 5 years for some artefacts — which is your storage layer’s job; Regulus’s default retention is the agent’s operational evidence window.)
- The model-risk plugin maintains the LLM-provider concentration
view. When inference usage exceeds a configurable threshold against
a single provider, the plugin emits a
CONCENTRATION_THRESHOLD_BREACHevent suitable for the ICT third-party register. - The governance-evidence plugin routes register-updates and concentration-risk events to your GRC adapter — ServiceNow IRM has a DORA module; OneTrust IRM is adding one; the generic webhook works against an internal register.
What DORA doesn’t reduce to runtime: the operational resilience strategy (Article 6), the identification of critical functions (Article 8), the annual ICT internal audit (Article 6(5)). These are governance artefacts. Regulus provides the runtime evidence those artefacts reference.
For multinational financial firms, the DORA profile composes with
gdpr (personal data flowing through ICT systems is in scope of
both), with eu-ai-act (AI agent in financial services typically
high-risk Annex III), and with nis2 (NIS2 covers cybersecurity for
essential entities; many financial firms are dual-regulated).
What it actually requires of an engineer
- The agent is an ICT system under DORA. Same operational resilience expectations as your core banking platform: change management, incident handling, testing, third-party oversight.
- Major ICT incidents must be reported to the regulator within tight windows. Initial notification within 4 hours of classification as 'major', intermediate report within 72 hours, final report within 1 month.
- ICT third-party register required. Every external service the agent depends on — LLM provider, GCP services, GRC tools — must be registered with the EBA register format, including concentration risk indicators.
- Operational resilience testing is mandatory. At least annual basic testing; threat-led penetration testing every three years for significant institutions. Test results are evidence the regulator can request.
- Concentration risk on LLM providers is explicit. Over-reliance on a single ICT third party (e.g. one LLM provider for all agent inference) triggers DORA Article 28 concentration-risk obligations.
What Regulus does for you
| Regulus control | Delivers |
|---|---|
RegulusKillSwitchPlugin | Major ICT incident response — dual-control kill switch produces a structured incident event that feeds the DORA notification timeline. Initial-4-hour deadline is realistic with a kill-switch trigger. |
RegulusAuditPlugin | Article 5 ICT risk-management framework evidence — 24-month retention default aligns with DORA's record-keeping expectations. Hash chain provides the immutable substrate. |
RegulusGovernanceEvidencePlugin | ICT third-party register entries auto-populated from the model-risk registry (LLM providers) and the configured GCP services. Updates surface to the GRC adapter on every relevant event. |
RegulusModelRiskPlugin | Concentration-risk classification — the Model Registry tags primary vs. fallback LLM providers, surfaces concentration alerts when usage exceeds configurable thresholds. |
RegulusDataResidencyPlugin | Operational resilience under failure scenarios — residency rules support a documented failover region without silently exporting data. |
Saves you ~14 engineer-weeks
Estimate based on the following honest assumptions:
- Greenfield major-incident notification automation (3 weeks).
- ICT third-party register integration with EBA format export (3 weeks).
- Concentration-risk monitoring + thresholds (2 weeks).
- Operational resilience test evidence emission (2 weeks).
- Audit retention aligned to DORA's 5-year register-keeping (1 week — Regulus default is 24 months; DORA's longer register-keeping is your storage layer's job).
- ICT incident classification logic (3 weeks — requires sector-specific calibration).
What an auditor will ask
The questions you'll see in a real walkthrough — and where to point them.
-
Show me your ICT third-party register and concentration-risk indicators.
Generate the EBA-formatted register:
regulus dora register export > dora-register.csv. Concentration indicators live in the Model Registry; the export shows primary-vs-fallback distribution per LLM provider. -
Walk me through your incident response for the last major ICT incident.
Filter the audit chain by
event_type = KILL_SWITCH_ENGAGED OR event_type = INCIDENT_DECLARED. Each event shows the engaging Principals, the reason, the initial-notification trigger, the timeline. -
How are you evidencing the annual operational resilience test?
Regulus tags test invocations in the audit chain with
tags contains 'resilience-test'. Test results are aggregated by quarter; the annual rollup is one report. -
What's your concentration risk exposure to GenAI third parties?
The Model Registry's concentration metric (regulus.model-risk.concentration) shows usage % per provider. The audit chain captures every model invocation with provider attribution; aggregate by month.
What this doesn't cover
- Non-ICT operational resilience — Regulus targets the AI agent's ICT-side obligations; broader operational resilience (people, premises, third-party non-ICT services) is your operational-risk function's job.
- DORA register-keeping for non-AI ICT services — Regulus profiles the AI agent; your other ICT third parties (Salesforce, Workday, etc.) need their own register entries.
- Threat-led penetration testing — Regulus emits evidence of resilience under normal operation; pen testing is a separate exercise.
- Cross-border resolution and recovery — Regulus enforces residency at runtime; resolution-plan documentation is a separate governance artefact.
Citations
Activate this profile in your agent
regulus init my-agent --profiles=dora