DORA EU Regulation: 2026 Guide for IT Leaders
Updated: 4 hours ago
The DORA EU Regulation is a binding framework for the EU financial sector that has applied since 17 January 2025. It standardises ICT risk management, incident reporting, resilience testing, and third-party oversight for financial firms and the technology providers they depend on.
That matters far beyond Europe. PwC estimates that around 22,000 EU-regulated financial entities must comply with DORA, which means a large number of banks, insurers, and investment firms now need suppliers that can prove operational resilience with auditable evidence, not just broad security claims (PwC on DORA).
For CIOs in the GCC, this changes the commercial test. If your teams deliver managed services, cloud operations, service desk support, infrastructure monitoring, or application support into an EU financial environment, clients will ask for more than an ISO certificate and a policy pack. They'll want service maps, control ownership, incident workflows, subcontractor visibility, and recoverability evidence that stands up under scrutiny.
What Is the DORA EU Regulation
The DORA EU Regulation is the EU's single harmonised framework for digital operational resilience across financial services. It moved the market away from fragmented national expectations and into one operating model for ICT risk, resilience, and third-party control.
The regulation was published in the Official Journal on 27 December 2022 and entered into application on 17 January 2025. The Central Bank of Ireland notes that DORA applies to 20 different types of financial entities and to ICT third-party service providers, including banks, insurers, and investment firms, which makes it one of the broadest operational resilience regimes in European financial services (Central Bank of Ireland DORA overview).
Why CIOs should treat DORA as an operating model
DORA isn't just a legal requirement for compliance teams. It forces firms to answer operational questions with evidence:
What assets support critical services
Which suppliers and subcontractors are involved
How incidents are classified and escalated
Whether resilience testing reflects real dependency risk
How exit and recovery plans work
If you run IT or digital operations, these aren't abstract policy topics. They sit inside CMDB quality, service ownership, event correlation, incident process design, vendor records, and testing discipline.
Practical rule: If a control can't be traced to a service, system, owner, and recovery expectation, it usually won't satisfy DORA in practice.
Many programmes stall because organisations try to “document for DORA” instead of fixing the operational plumbing DORA exposes. Better outcomes come from treating the regulation as a framework for service resilience, then using compliance artefacts as a by-product of that work.
Why it matters outside the EU
A GCC-based provider can't assume geography keeps it outside the conversation. If you support an EU-regulated financial customer's ICT estate, your operating model may need to align with DORA-facing requirements through contracts, oversight routines, and evidence requests.
For a useful external view on baseline obligations, understanding DORA compliance is a solid companion read. For a platform and delivery perspective, DataLunix also breaks down what the DORA EU Regulation is and who needs to comply.
Who Falls Under DORA's Scope
DORA covers two broad groups. First, regulated financial entities in the EU. Second, ICT third-party providers that support those entities.
That second category is where many non-EU firms misread the situation. They assume DORA is relevant only to European headquarters or only to hyperscale cloud firms. In practice, the commercial impact reaches managed service providers, systems integrators, offshore support centres, SaaS vendors, and specialist operations partners whenever they support regulated financial services.
Which organisations are directly in the frame
The direct in-scope population includes a wide set of EU financial institutions. You don't need to memorise the legal taxonomy to make the right operational decision. If your client is an EU-regulated bank, insurer, investment firm, or similar financial institution, assume DORA will shape what they ask from your team.
For providers, the more useful question is this: does your service become part of the customer's critical ICT dependency chain?
That can happen when you provide:
Managed operations for infrastructure, platforms, or applications
Service desk and support functions tied to important business services
Monitoring and event handling for production environments
Integration and change delivery in regulated technology estates
Outsourced delivery centres supporting availability, security, or recovery
How a UAE or GCC provider gets pulled into the picture
One of the least well-covered practical issues is cross-border applicability. Upwind highlights that DORA explicitly covers third-party ICT providers supporting EU financial entities, including providers outside the EU where there is a nexus to EU services, and notes that for AE-region vendors the primary question is not what DORA is, but which contracts, delivery models, and evidence packs make a non-EU provider operationally usable under DORA (Upwind on DORA and third-party ICT providers).
That “operationally usable” point is exactly right.
A Dubai-based MSP may not be supervised in the same way as an EU bank, but it can still face DORA-driven expectations such as:
Contract changes covering audit, cooperation, incident handling, and exit support
Control evidence requests for resilience, dependencies, and governance
Subcontractor transparency across offshore and hybrid delivery
Faster notification obligations when ICT incidents affect regulated services
The practical threshold isn't where your company is incorporated. It's whether your service affects an EU financial entity's ability to operate safely and recover quickly.
Why criticality matters commercially
Some providers will be more material than others. If your service sits close to core transactions, customer access, claims handling, investment operations, or essential support systems, clients will apply more scrutiny. The difference shows up in diligence depth, reporting expectations, and contract language.
This is why service catalogues alone aren't enough. Buyers increasingly want proof of service decomposition, operational ownership, and fallback arrangements. If you need a broader industry lens, DataLunix has a helpful explainer on what DORA Europe is and how it impacts financial institutions.
What Are DORA's Five Core Pillars
Five pillars sit at the centre of DORA, but they do not operate as five separate workstreams. In practice, they function as one operating model for resilience. If a firm cannot connect assets to services, incidents to business impact, tests to remediation, and suppliers to supported functions, compliance evidence will stay fragmented.
For non-EU providers, especially MSPs, SaaS vendors, and outsourcing firms in the GCC, that point matters. EU clients will not ask whether your internal framework uses DORA headings. They will ask for proof that your service management, monitoring, supplier controls, and customer communications produce DORA-ready outcomes. The firms that respond fastest usually build on existing ITSM, ITOM, and CSM workflows instead of starting from a blank page.
ICT risk management
This pillar sets the baseline. Firms need a clear view of ICT assets, supported business services, ownership, dependencies, and control performance.
The operational test is simple. Can the organisation show which systems support a regulated service, who owns them, what risks apply, what changes are in flight, and which third parties sit in the chain? If the answer lives across static spreadsheets, disconnected CMDB records, and email approvals, the control may exist on paper but it will be hard to defend under scrutiny.
What usually works:
Service-to-asset mapping tied to live configuration data
Named ownership for services, systems, controls, and risk acceptance
Change records linked to service impact and approval evidence
Dependency mapping across infrastructure, applications, data flows, and suppliers
What usually fails:
Inventories no one maintains
Risk registers with no link to operational services
Policies that cannot be traced to technical or process evidence
For a GCC provider serving EU financial clients, this is often the first commercial hurdle. Clients want to know whether your internal control environment can support their own DORA obligations without creating a reporting gap.
ICT-related incident management, classification, and reporting
DORA raises the bar on incident handling because regulators and regulated firms need consistency, speed, and evidence. A ticket closure note is not enough. Teams must be able to classify incidents, assess materiality, document decisions, and support reporting within defined timelines.
The practical problem is data quality. Many organisations already run incident processes, but the record often misses the fields that matter most under DORA: affected business service, customer impact, geographic scope, supplier involvement, recovery actions, and escalation decisions. If those fields are optional, they will be empty when the pressure is highest.
A workable model includes:
Structured classification criteria tied to service impact
Defined escalation paths across SOC, service desk, operations, legal, and account teams
Time-stamped evidence for decisions, actions, and communications
Supplier participation in triage, updates, and root-cause follow-up
ServiceNow and HaloITSM can materially reduce effort. If incident forms, major incident workflows, on-call escalation, and customer communication records are already in the platform, firms can improve control evidence without rebuilding the process from scratch.
Digital operational resilience testing
Testing separates documented resilience from actual resilience. It shows whether teams can restore service, make decisions under pressure, and recover dependencies in the right sequence.
Poor testing stays narrow. A backup restore succeeds in the lab, yet production recovery still fails because identity services were excluded, network dependencies were undocumented, or the supplier team needed for a key hand-off was never involved. Good testing reflects how the service really runs.
Strong programmes usually combine:
Scenario-based exercises for cyber events and service outages
Recovery validation across applications, infrastructure, data, and support teams
Dependency testing to expose hidden single points of failure
Tracked remediation so findings become funded actions, not workshop notes
The detail behind testing expectations sits in the technical standards as well as the regulation itself. Teams building test plans should review the DORA regulatory technical standards for financial institutions alongside their existing resilience calendar.
Managing ICT third-party risk
This pillar is where many non-EU providers feel DORA first. Even if the regulation does not apply to your company directly, your EU client may still require contract changes, control attestations, incident notification commitments, subcontractor visibility, and exit support.
The main trade-off is depth versus overhead. A regulated client wants service-specific assurance. Providers want a repeatable model that does not create a custom control pack for every customer. The answer is usually a tiered supplier governance approach linked to service criticality, with standard evidence packs, maintained subcontractor records, and a clear process for handling client diligence requests.
Mature firms can answer questions such as:
Which regulated service does this supplier support?
Which subcontractors are involved?
What are the concentration or substitution risks?
How quickly can incidents be escalated to the client?
What happens if the service must transition or exit?
Procurement data alone will not answer those questions. The record has to connect contracts, services, dependencies, and operational ownership.
Information-sharing arrangements
This pillar is voluntary, but it still has operational value. Threat intelligence only helps if it changes monitoring rules, response playbooks, patch priorities, or customer advisories.
The firms that get value from information sharing treat it as an input to operations, not a mailing list exercise. Security teams review incoming intelligence, assess relevance to supported services, and push the outcome into existing workflows. That may mean a detection rule change in the SOC, a problem record for recurring exposure, or a customer communication for a regulated client affected by the same threat pattern.
For CIOs and service providers, the broader lesson is straightforward. DORA's five pillars are not five policy chapters. They are five proof points regulators and financial entities will test in day-to-day operations. If your platforms already manage configuration items, incidents, changes, suppliers, and customer interactions, the fastest route to compliance is usually to tighten data quality, ownership, and reporting across those workflows.
What Is the DORA Compliance Timeline and Supervisory Regime
The timeline matters because it explains why many firms treated DORA as a major transformation programme rather than a routine policy update.
Skadden notes that DORA was adopted in December 2022, firms had until 17 January 2025 to comply, and the second batch of standards was published on 17 July 2024, leaving only six months for final implementation before go-live (Skadden on the DORA implementation timeline).
Why the timeline created operational pressure
A little over two years sounds generous until you break the work down. DORA implementation often required firms to:
Review and amend supplier contracts
Improve asset and dependency records
Refresh incident reporting workflows
Set up or mature testing routines
Align governance across legal, risk, security, operations, and procurement
That's why many organisations found the hardest part wasn't reading the regulation. It was coordinating the operating model changes behind it.
Who supervises and why providers should care
DORA supervision sits across European supervisory structures and national competent authorities, with added oversight arrangements for critical ICT providers. CIOs at non-EU service firms don't need to become regulatory lawyers, but they do need to understand one practical point. Oversight can travel through client expectations, contractual rights, audit access, and evidence demands.
If you support EU-regulated customers, the supervisory regime shapes the questions clients will ask:
Can you demonstrate control execution
Can you support testing and audit activity
Can you evidence subcontractor governance
Can you cooperate during incident escalation
Those are operational obligations long before they become legal disputes.
For a more technical look at implementation detail, DataLunix has a useful guide on DORA regulatory technical standards for financial institutions.
How Can You Create a Practical DORA Compliance Roadmap
The best DORA programmes don't start with policy writing. They start with service reality. Which services matter, what they depend on, where evidence lives, and who owns the controls.
Start with a gap analysis that uses real services
Don't assess DORA at the level of broad control statements alone. Pick a sample of important services and walk them end to end.
Your checklist should cover:
Identify critical services and the business owner for each.
Review control evidence for risk, incident handling, testing, and supplier oversight.
Locate process breaks where ownership is unclear or data quality is weak.
Prioritise remediation based on service criticality and delivery risk.
A poor gap analysis produces a red-amber-green heatmap. A good one produces an executable backlog.
Build ICT asset and service mapping that people trust
Many firms already have a CMDB, asset register, discovery tool, or architecture repository. The problem is usually not tool absence. It's fragmented ownership and uneven data quality.
Focus on practical traceability:
Service to application
Application to infrastructure
Infrastructure to support team
Support team to supplier
Supplier to contract and exit approach
If one of those links is weak, the evidence chain breaks.
Field advice: Don't try to perfect the entire estate first. Make the critical-service slice reliable, then expand.
Update policies through workflows, not documents alone
DORA-facing policies need to exist, but policy refresh without process redesign won't hold. For each policy area, ask what workflow proves it operates.
Examples:
Incident policy should map to ticket classification, escalation, and reporting fields.
Third-party policy should map to onboarding, review cadence, and issue management.
Testing policy should map to a calendar, approvals, execution records, and remediation tracking.
Operational compliance teams often benefit from broader regulatory compliance monitoring insights that focus on continuous oversight rather than one-off audits.
Implement testing and contract review in parallel
Testing and third-party review should move together because they expose each other's weaknesses. A resilience exercise often reveals that support boundaries, notification duties, or recovery expectations are vague in supplier agreements.
Use a combined workstream:
Run scenario tests against important services
Record supplier dependencies discovered during the exercise
Update contracts and schedules where obligations are too vague
Assign remediation owners with deadlines and closure evidence
A mature programme then moves into continuous monitoring, issue governance, and recurring assurance. DataLunix covers the broader transformation discipline well in its article on mastering digital operational resilience.
How Do ITSM and ITOM Platforms Support DORA Compliance
ITSM and ITOM platforms are often the fastest route to practical DORA progress because they already sit where evidence is generated. If configured properly, they connect services, assets, incidents, changes, alerts, vendors, and requests into one operational picture.
That matters because DORA is difficult to prove from disconnected tools. A policy in SharePoint, a contract in legal storage, incidents in one platform, and infrastructure data in another can still leave you unable to answer a simple question about a disrupted service.
Where platforms make the difference
ServiceNow, HaloITSM, Freshservice, and similar platforms can support DORA-aligned outcomes when you use them beyond ticket logging.
Examples include:
CMDB and service mapping for asset lineage and dependency visibility
Incident management for classification, timeline capture, and escalation evidence
Change management for operational governance and risk review
Vendor and contract records for third-party accountability
Monitoring and event integration for faster detection and cleaner audit trails
Knowledge and workflow automation for repeatable response actions
The trade-off is straightforward. Buying a platform module doesn't create compliance. Configuring data relationships, ownership, and evidence outputs does.
Mapping DORA requirements to ITSM and ITOM platforms
DORA Pillar | Required Capability | Relevant Platform Module | How DataLunix Helps |
|---|---|---|---|
ICT Risk Management | Service and asset traceability | ServiceNow CMDB, Service Mapping, HaloITSM asset records | Configures service models, ownership structures, and cross-platform data alignment |
Incident Management and Reporting | Consistent classification and escalation evidence | Incident Management, Major Incident workflows, alert integrations | Designs workflows, required fields, approval logic, and reporting-ready records |
Resilience Testing | Test planning, execution records, and remediation tracking | Change, Project, task workflows, knowledge, configuration records | Builds practical operating workflows that tie tests to services, assets, and owners |
ICT Third-Party Risk | Supplier visibility and contractual accountability | Vendor records, contract repositories, service ownership mapping | Connects vendor data to service impact and operational dependencies |
Information Sharing | Structured intake and distribution of threat intelligence | Knowledge, cases, requests, event and security integrations | Helps turn external intelligence into usable workflows and internal action paths |
What usually works and what usually fails
What works:
Using the CMDB as a service context engine, not just an inventory dump
Making mandatory incident fields meaningful, not bureaucratic
Linking vendor records to services, not storing them as isolated procurement objects
Automating evidence capture during normal operations
What fails:
Over-customisation that nobody can maintain
Manual reporting layers built outside the platform
Separate compliance workflows that teams bypass under pressure
Poor service ownership even when the tooling is strong
For teams exploring AI-assisted governance workflows, this guide to AI compliance transformation is useful as a thought starter, especially when paired with disciplined workflow design rather than chatbot hype.
If you're evaluating ServiceNow specifically, DataLunix has a relevant perspective on compliance with ServiceNow. The bigger point is the platform's advantage. DORA compliance gets easier when your existing ITSM and ITOM investments become evidence engines for resilience, instead of separate systems that only support day-to-day operations.
FAQ
What should a GCC or UAE service provider do first if an EU financial client raises DORA
Start with the operating model, not the contract wording. Identify which services support the client's regulated operations, who owns those services, which subcontractors are involved, and what evidence you can already produce from your ITSM, ITOM, security, and vendor management tools.
For non EU providers, the first gap is usually not policy. It is proving control execution in a way an EU client, auditor, or regulator can follow. That means clear incident records, service dependencies, change history, testing evidence, and supplier records that tie back to a business service.
Does DORA apply directly to companies in the GCC
Usually, DORA applies directly to EU financial entities and creates indirect but real obligations for many non EU providers that serve them. In practice, a bank or insurer in the EU will push DORA requirements into contracts, due diligence, reporting expectations, exit planning, and audit rights.
That is why GCC providers need to treat DORA as a delivery requirement, not just a legal question.
What evidence do EU clients usually ask non EU providers to produce
They normally ask for evidence that shows how the service is run under pressure. Common requests include incident logs, severity criteria, major incident communications, service continuity and recovery testing, change approvals, asset and configuration relationships, vulnerability handling, supplier oversight, and control exceptions.
The trade off is straightforward. Teams can gather this manually for one client, but that approach breaks down fast across multiple regulated customers. A better approach is to capture evidence inside day to day workflows so reporting does not become a separate project every quarter.
Can ServiceNow or HaloITSM reduce the cost of DORA compliance
Yes, if the platform is configured around control evidence rather than ticket volume alone. Service mapping, CMDB relationships, incident workflows, change governance, request records, knowledge, and supplier workflows can all support DORA related obligations when they are tied to service ownership and reporting needs.
I usually advise clients to avoid building a parallel compliance layer outside the platform. Costs rise, records drift out of sync, and audit preparation turns into reconciliation work.
How is DORA different from standard ISO or internal IT controls
DORA puts more weight on operational resilience in a regulated financial context. The question is not only whether a control exists. The question is whether the provider can support a financial entity through disruption, report incidents consistently, manage concentration and subcontractor risk, and show that testing and governance work in practice.
Many GCC providers already have pieces of this in place. The gap is often integration, traceability, and client ready evidence.
If you need to turn DORA requirements into working processes inside ServiceNow, HaloITSM, Freshservice, or a hybrid delivery model, DataLunix is a strong partner to evaluate. Their team helps CIOs and IT leaders connect compliance goals to real service workflows, platform configuration, managed operations, and evidence-ready reporting across GCC and European environments.