EBA DORA
- 9 hours ago
- 9 min read
The critical shift in EBA DORA isn't that the rule exists. It's that supervision has already moved beyond policy into live oversight. The European Banking Authority says DORA became applicable on 17 January 2025, and authorities are now using aggregated registers of ICT third-party providers for the first time, giving supervisors system-wide visibility of dependency risk across the EU financial sector (XBRL summary of the EBA update).
If you're a CIO or IT Director, treat that as your operational brief. DORA isn't a legal memo. It's a demand for faster incident handling, cleaner supplier data, tighter contracts, and ITSM workflows that can withstand scrutiny.
What Is the EBA DORA Regulation in 2026?
EBA DORA is the European Banking Authority's supervisory framework around the EU's Digital Operational Resilience Act. In practice, it gives financial entities one EU-wide model for managing digital operational resilience, with direct consequences for how you run IT, vendors, incidents, and evidence.
The mistake I still see is treating DORA like another controls catalogue. It isn't. It changes how supervisors see your organisation. Once aggregated registers are in use, regulators can spot concentration risk, common dependencies, and weak governance patterns across firms, not just inside one firm.
That means your internal data model matters. Your contract inventory matters. Your service classification logic matters.
Why 2026 is different
By 2026, DORA is fully in the operational phase. The European Banking Authority has set the framework, and national supervisors are already turning that framework into dated reporting obligations. For example, the Dutch supervisor requires the register of information to be reported by 20 March 2026 using xBRL-CSV, while the Central Bank of Ireland requires submission during 2–31 March 2026 based on a 31 December 2025 reference date (Dutch central bank reporting notice).
If your teams are still debating ownership, you're late. If your supplier records live in spreadsheets owned by procurement, legal, security, and IT separately, you have a design problem, not a documentation problem.
Practical rule: Build DORA around operational systems of record, not around slide decks and policy binders.
A useful starting point is to align your resilience programme with a broader Digital Resilience Act overview, then map it into your actual service operations model.
What CIOs should take from this
You need to read EBA DORA as a management system with four immediate implications:
Your resilience programme must be auditable. Regulators won't be satisfied by intent.
Your supplier estate must be structured. Contracts, services, dependencies, and criticality must tie together.
Your incident process must be timed. Classification and evidence capture can't wait for committee review.
What Are the Five Pillars of DORA Compliance?
The easiest way to make DORA operational is to treat it as five workstreams. Don't let legal language blur execution. Assign an owner, a platform, and evidence requirements to each pillar.
ICT risk management
This is your baseline discipline. You need governance, risk identification, controls, service mapping, and recovery thinking that reflect how your environment operates in practice.
For most firms, the failure point isn't policy. It's fragmentation. Security has one view, infrastructure another, and service operations a third. DORA punishes that split because resilience depends on a single operational picture.
ICT-related incident management and reporting
This pillar forces speed and consistency. Your organisation needs clear major incident criteria, escalation paths, approval logic, and timestamped evidence.
A core issue is decision latency. If it takes hours to determine ownership, severity, or affected services, your compliance posture has already weakened.
Digital operational resilience testing
Testing under DORA is about proving that controls and recovery arrangements work in practice. Tabletop exercises help, but they're not enough on their own. You need evidence that important services, suppliers, communications paths, and recovery dependencies have been challenged.
Testing should target business-critical scenarios, not just technical components in isolation.
Managing ICT third-party risk
Many firms underestimate the workload. DORA expects supplier governance to extend from due diligence to contract terms, ongoing oversight, dependency visibility, and exit planning.
That pulls procurement, legal, security, architecture, and IT operations into the same operating model. If one function works in isolation, your third-party controls will drift.
Information and intelligence sharing
This pillar is often treated as the soft one. That's a mistake. It's about institutional learning. You need ways to capture threat, incident, and control intelligence and feed it back into risk decisions and operational improvements.
Here's a simple operating view:
Pillar | What leadership should focus on |
|---|---|
ICT risk management | Service criticality, control ownership, recovery design |
Incident management | Classification, escalation, evidence, regulatory workflow |
Resilience testing | Real-world scenario coverage and remediation tracking |
Third-party risk | Register quality, contracts, concentration, exit readiness |
Information sharing | Repeatable learning loops across teams |
If you want a more practical bridge from regulation to delivery, this digital operational resilience guide is a useful companion to platform and process planning.
How Does EBA DORA Change ICT Incident Reporting?
It changes incident management from an internal service discipline into a regulator-timed control. Manual processes won't hold up.
Under DORA, firms must notify the competent authority within 4 hours of classifying an incident as major, and no later than 24 hours after first becoming aware. That is followed by an intermediate report within 72 hours and a final report within one month (summary of DORA incident-reporting timelines).
Those deadlines change your operating model immediately. They force three capabilities:
Rapid triage
Defensible severity scoring
Reliable timestamp capture
Why traditional service desks struggle
Most service desks were designed for resolution efficiency, not regulatory evidence. Analysts can work around missing fields, inconsistent categorisation, and fragmented updates in a normal ITIL environment. Under DORA, those gaps become reporting risk.
You need workflows that do the following as standard:
Capture awareness time when the organisation first knew of the issue
Separate technical impact from regulatory significance so major incident classification is consistent
Trigger parallel actions across service owners, security, legal, and compliance
Preserve an audit trail of who decided what, and when
A mature incident management workflow in Freshservice can support this kind of structure, but only if you configure it for decision control rather than just ticket routing.
What to change now
Don't start with reporting templates. Start with operational mechanics.
Define major incident criteria clearly. Keep the logic short enough for responders to use under stress.
Embed mandatory timestamps. Awareness, classification, escalation, authority notification, and closure must be structured fields.
Automate stakeholder mobilisation. Don't rely on analysts remembering who to call.
Create regulatory evidence packs. Build incident records so reporting data can be assembled without manual hunting.
If a major incident still depends on people copying updates between email, chat, and tickets, your process isn't DORA-ready.
Why Is Third-Party Risk Management Critical Under DORA?
Because DORA treats the supplier relationship as an operational control, not a procurement artefact. That's the shift many leadership teams still haven't internalised.
The EBA states that every ICT service contract must include mandatory clauses covering security, audit rights for both the financial entity and competent authorities, provider incident-notification duties, and exit strategies. The EBA also uses the Register of Information to supervise these dependencies (EBA DORA oversight and third-party requirements).
That means your contract estate is now part of your control environment.
The contract is now a control surface
A weak supplier contract is no longer just a legal gap. It can become a resilience gap, an audit gap, and a supervisory gap at the same time.
Here's where firms usually fail:
Procurement stores the contract, but not service context
Security assesses controls, but not exit feasibility
IT knows the dependency, but not the audit rights
Vendor managers track renewals, but not subcontracting exposure
That fragmented model doesn't work under DORA. You need one joined-up view of supplier, service, criticality, obligations, and fallback options.
What a better operating model looks like
A practical model connects supplier governance to service management:
Control area | Operational requirement |
|---|---|
Supplier inventory | One authoritative list of ICT providers and related services |
Contract obligations | Structured fields for audit rights, notifications, exit, and service levels |
Dependency mapping | Link vendors to business services, systems, and owners |
Ongoing oversight | Review cadence, issue logging, remediation, and evidence retention |
Use a dedicated third-party risk management approach that joins procurement, legal, security, and ITSM. If those teams work from separate records, your register quality will deteriorate quickly.
Choose ICT partners the same way you choose critical infrastructure. Their governance becomes part of yours.
How Can You Use ITSM and AI for DORA Compliance?
Use your ITSM platform as the operational backbone for DORA. Don't create a parallel compliance universe. ServiceNow, HaloITSM, and similar platforms already contain the objects you need. Services, configuration items, incidents, changes, vendors, tasks, approvals, and knowledge can all be adapted into a DORA operating model.
Use the CMDB and service catalogue properly
Your CMDB shouldn't be a technical inventory only. For DORA, it should support service context and dependency logic.
A strong design links:
Business services to criticality and owners
Applications and infrastructure to supporting components
Vendors and contracts to the services they enable
Recovery and exit information to operational records
That creates a more defensible basis for a register of information than disconnected spreadsheets.
Automate the parts that fail under pressure
Major incidents expose every weak handoff in your organisation. Use workflow automation to remove avoidable delay.
Practical configurations include:
Major incident playbooks that create parallel tasks for security, compliance, legal, and service owners
Classification forms with required impact data before status progression
Escalation rules that trigger on service criticality and incident attributes
Evidence templates that standardise what responders capture
AI can help, but only inside a controlled process. Use it for summarisation, triage support, related-ticket clustering, and draft root cause narratives. Don't let it make unreviewed regulatory decisions.
For teams evaluating controlled AI assistance inside service operations, the SupportGPT AI platform is one example of how AI can support service workflows without replacing governance.
Build one compliance data model
At this juncture, most programmes either become sustainable or collapse under manual effort. Put DORA data into systems that already run daily operations.
A workable pattern looks like this:
CMDB for assets, services, and dependencies
Vendor records for providers, obligations, and reviews
Incident records for time-bound reporting evidence
Knowledge and runbooks for standardised response
Dashboards for leadership oversight
One practical route is to use a compliance and service design partner that understands both platform architecture and operational governance. DataLunix works in that space by connecting HaloITSM, ServiceNow, Freshservice, and related workflows to compliance and risk operating requirements.
What DORA Risks Are Global Service Providers Overlooking?
The biggest mistake outside Europe is assuming DORA stops at the EU border. It doesn't.
The EBA's oversight framework applies to critical ICT third-party providers that support the EU financial sector, regardless of where the provider is headquartered. That makes UAE and wider GCC service desks, MSPs, and implementation partners relevant to DORA scope even when they operate from outside the EU (EBA DORA oversight scope).
The GCC delivery model now needs DORA logic
If you deliver managed services, cloud operations, application support, or service desk functions into EU financial entities, your location doesn't reduce the buyer's regulatory exposure. The buyer still needs evidence about controls, contracts, incidents, auditability, and dependency structure.
That has direct implications for global service providers:
Your service descriptions must be precise. Buyers need register-ready clarity.
Your incident process must be escalation-ready. Slow internal approvals create customer reporting risk.
Your subcontracting chain must be visible. Hidden delivery layers create governance problems.
Your contract posture must support oversight. Audit and notification language can't be negotiated as an afterthought.
A second blind spot is scope expansion
Many firms still frame DORA as an ICT-only story. That's too narrow. The EBA's 2025 revisions extend third-party risk guidance across the full third-party lifecycle and to non-ICT services as well, including providers supporting critical or important functions, with a two-year transition period for existing arrangements while new arrangements fall under the rules immediately once they enter into force (Deloitte legal briefing on the EBA's 2025 public hearing).
That matters because many provider organisations still separate “cyber compliance” from broader supplier governance. Buyers won't. They'll ask about subcontracting, exits, critical service support, contractual remediation, and operational evidence.
If you want a useful non-regulatory lens on how software and delivery risk accumulates, this founder's blueprint for software risk is worth reading alongside formal control frameworks.
The practical conclusion is simple. If you support EU financial entities from the GCC or any other non-EU market, build your operating model as if DORA scrutiny can reach your delivery chain. Because from your customer's perspective, it already has.
FAQ
What does EBA DORA mean for CIOs in practice?
It means digital resilience is now a supervised operating discipline, not just an internal control topic. CIOs need structured supplier data, timed incident workflows, and auditable service governance.
Is EBA DORA only relevant to banks inside the EU?
No. It directly affects in-scope financial entities in the EU, and it also matters to critical ICT providers supporting that sector from outside the EU. That includes GCC-based delivery teams serving EU financial clients.
How should I store DORA register information?
Use an operational system of record where services, vendors, contracts, owners, and dependencies can be linked and maintained. A spreadsheet may help at the start, but it won't support ongoing governance well.
Can ITSM tools help with EBA DORA compliance?
Yes. ServiceNow, HaloITSM, and similar platforms can support incident workflows, vendor records, service mapping, approvals, audit trails, and evidence capture. The value comes from configuration discipline, not from buying a tool and hoping for compliance.
What is the first step for EBA DORA readiness?
Start with a gap assessment across incident management, third-party governance, contract metadata, and service dependency visibility. Then redesign the operating model in the platforms your teams already use daily.
If you need to turn EBA DORA requirements into workable service operations, DataLunix can help you assess your current state, structure your register and supplier data, and configure platforms such as ServiceNow and HaloITSM around evidence, workflow, and resilience controls.