EU DORA Regulation

The EU DORA regulation became fully applicable on 17 January 2025, and noncompliance can expose firms to fines of up to 2% of worldwide annual turnover. If you run financial IT in the EU, or support it through ICT services, this is now an operations problem, not a policy exercise.

You're probably looking at a service desk, a CMDB, a pile of change records, and a handful of resilience test reports that don't quite line up. That's where teams get trapped. They treat DORA like a legal checklist, then discover regulators want proof that incidents, changes, dependencies, and third-party controls are wired together.

What EU DORA Regulation Actually Means for Financial IT

The Digital Operational Resilience Act (DORA) is an EU regulation for the financial sector that entered into force on 16 January 2023 and became fully applicable on 17 January 2025. It creates a harmonised operational-resilience framework across the European market, so the rules are no longer fragmented by country. For financial IT leaders, that means one standard for how you govern ICT risk, respond to incidents, test resilience, and control suppliers. EIOPA's DORA overview is the cleanest starting point if you need the regulatory baseline.

What changed for IT leaders

The practical shift is simple. DORA is not a one-off compliance project. It is an operating model that expects evidence you can keep producing under pressure.

If you led an assessment during the two-year implementation window, you already know the primary work was never the regulation text. The primary work was getting incident routing, asset visibility, test scheduling, and vendor oversight into the same control fabric. That is why this article treats eu dora regulation as a service management and operations design problem first.

Practical rule: If your ITSM and ITOM stack cannot show what happened, when it happened, who approved it, and what changed downstream, your DORA story is incomplete.

For a deeper regulatory summary aimed at IT leaders, the most useful internal reference is the DORA EBA summary from DataLunix. For legal interpretation gaps, teams often pair that with an AI legal chatbot so policy owners can sanity-check language before it reaches the board.

Who Falls Inside the Scope of DORA

DORA applies across 20 different types of financial entities and ICT third-party service providers, and the commonly cited scope is over 22,000 financial entities across the EU (Regulation DORA scope overview). That number matters because it tells you this is not a niche banking rule. It reaches banks, insurers, investment firms, payment institutions, and the ICT providers that keep them running.

A quick scope check

Entity Category	Example Firms	DORA Tier
Banks	Retail, commercial, and investment banks	In scope financial entity
Insurers	Life, non-life, and reinsurance firms	In scope financial entity
Payment Institutions	PSPs and payment processors	In scope financial entity
Investment Firms	Brokers, asset managers, trading firms	In scope financial entity
ICT Third-Party Providers	Cloud, managed service, and SaaS providers	In scope provider
Critical ICT Providers	Providers supporting systemic services	Highest oversight burden

If your firm serves EU-regulated customers from outside the EU, scope can still bite through contracts, supplier flow-downs, and service dependencies. GCC-based providers often miss that point until procurement or legal asks for resilience evidence. By then, the remediation work is already late.

How to read the risk tier

The heaviest burden sits with critical ICT third-party providers, because they face direct oversight and the strongest enforcement posture. The same is true for firms whose digital services are embedded deep inside financial supply chains. If you support recovery, logging, segmentation, or testing for those clients, you are already part of their DORA evidence chain.

For a formal view of how technical standards are framed, DataLunix's DORA technical standards reference is useful for teams mapping control ownership across legal, security, and operations.

The Five DORA Pillars Mapped to ITSM and ITOM

DORA becomes manageable when you stop reading it as law and start reading it as platform configuration. The five pillars line up cleanly with the systems your CIO already owns, or should own.

Where the pillars land in the stack

• ICT risk management maps to configuration governance, CMDB quality, and service mapping. If you cannot see critical dependencies, you cannot claim control.

• ICT incident reporting maps to incident management and major incident workflows. The regulator wants disciplined classification, timestamps, escalation, and closure evidence.

• Digital operational resilience testing maps to test planning, scenario execution, and controlled evidence capture. The testing record matters as much as the test itself.

• ICT third-party risk management maps to vendor registers, contract reviews, and supplier assurance. Third-party oversight is not a spreadsheet exercise.

• Information sharing maps to threat intelligence handling, risk communications, and audit trails of what was shared and when.

That model makes DORA a configuration problem inside the service stack. If your ITSM process is mature but your ITOM layer is weak, you'll still fail evidence checks because regulators look for operational truth, not process theatre.

Senior guidance: fix the CMDB and incident model before you buy another governance overlay. Most DORA failures come from missing operational evidence, not missing policy language.

Teams using the DataLunix IT service management solutions overview usually need to align service desk workflows with asset and dependency visibility before anything else. If that foundation is broken, every other control becomes harder to prove.

Key Obligations, Testing Cycles, and Penalty Exposure

The hard edges of DORA are the testing and penalty rules. Firms must perform annual basic resilience testing, and entities deemed critical to the financial system must run threat-led penetration testing (TLPT) every three years (IBM's DORA guidance). That alone changes how you schedule work, budget assurance, and brief the board.

What regulators expect to see

• Annual testing evidence showing that ICT systems supporting critical or important functions were tested.

• TLPT outputs for critical entities, with scope, remediation, and retest evidence.

• Third-party contracts that include resilience and oversight obligations.

• Logging and recovery evidence that proves systems can be monitored, restored, and segmented.

• Exit and continuity artefacts for providers that support financial supply chains.

If you only test once a year and then file the report away, you're missing the point. Regulators want a repeatable control loop, not a ceremonial exercise.

DORA's penalty framework is serious. Industry summaries report fines of up to 2% of total annual worldwide turnover for firms and €1,000,000 for individuals, while Grant Thornton also reports up to €5,000,000 for designated critical ICT third-party providers and €500,000 for an individual (Grant Thornton summary). That is board-level exposure, not a compliance footnote.

How to prioritise the non-negotiables

• Incident reporting first: If timestamps, routing, and severity classification are messy, fix that before you expand the control programme.

• CMDB and dependency maps second: Without accurate service relationships, you cannot defend criticality.

• Test evidence third: Build repeatable testing records, then harden into TLPT where required.

• Third-party governance last, but not late: Contracts, logs, and assurance packs need hard deadlines, not vague reminders.

For teams building out resilience test practices, the DataLunix digital operational resilience testing guide helps translate testing obligations into usable workflow design. If your controls are scattered, a HIPAA business compliance framework can also be a useful comparison point for evidence discipline, even though the regulation itself is different.

Choosing the Right ITSM and ITOM Platform for DORA

A DORA programme falls apart fast if the platform cannot produce clean evidence. CIOs and CTOs should start with the basics, incident timelines, change records, CMDB accuracy, problem records, and test outputs. If the tool cannot show who did what, when they did it, what changed, and which services were affected, it is a weak fit for DORA.

What to look for in each platform

• HaloITSM: Strong fit if you want structured incident, change, and knowledge workflows with lighter-weight configuration. It still needs disciplined CMDB governance if you want DORA-grade dependency evidence.

• HaloPSA: Useful where service operations and delivery tracking sit close together. It is more natural for managed service models than for deep financial-control orchestration.

• Freshservice: Good for teams that need quick adoption and clean workflows. You still need careful design around dependency mapping and evidence retention.

• ManageEngine: Broad coverage across IT operations functions, with useful options for incident and asset management. Expect integration work if you want a fully joined-up compliance evidence chain.

• ServiceNow: The strongest option when you need mature workflow orchestration, CMDB depth, and extensibility across large estates. It also tends to demand the most governance discipline to avoid configuration sprawl.

The right choice depends on how much operational discipline you already have. A platform will not fix weak taxonomy, poor ownership, or missing dependency data. It will only expose those problems faster.

How I would shortlist

Start with the operating model, then choose the tool. If your team already runs incident, change, problem, and configuration management with clear ownership, you can use a broader platform and standardise the evidence flow. If the data is messy, pick the system that your teams can administer without creating another layer of exceptions.

For many firms, the practical question is whether the current stack can be configured to support control evidence without turning into a custom build. The DataLunix ITSM solutions page is useful for comparing platform fit against your internal licensing, delivery footprint, and support model. If you want to use automating compliance with AI, keep it in the evidence-triage and knowledge-retrieval layer, not in control ownership or approvals.

Choose the platform that improves auditability first. Portal polish comes after that.

Common Gaps Between Today's ITSM and DORA Readiness

A DORA readiness review usually breaks in the same places. The failures are predictable, and they show up again and again: incomplete CMDBs, inconsistent incident classification, manual approvals, weak third-party registers, and thin testing evidence. None of that is new. DORA forces you to prove what your ITSM and ITOM processes do.

The usual failure pattern

An incomplete CMDB means you cannot prove which critical services depend on which applications, databases, or suppliers. Inconsistent incident classification breaks reporting discipline, especially when teams use local labels instead of a common taxonomy. Manual change approvals create segregation-of-duties problems because the approver, implementer, and verifier sit too close together.

Weak third-party registers are more dangerous still. If supplier ownership is split between procurement, security, and operations, nobody can produce a single authoritative view. Thin resilience testing evidence usually points to under-investment in automation, not lack of effort.

Operational truth: configuration debt looks like a tool issue until the audit starts. Then it becomes a governance issue.

What this means for GCC and European mid-market firms

Mid-market firms often have enough tooling, but not enough discipline around data quality. They bought the platform, not the operating model. That gap is where DORA exposure sits, because regulators care less about the software name and more about the evidence trail it produces.

Fix the ownership model first. If your service desk, asset register, and supplier records are maintained by different teams with different standards, use a change management readiness assessment to force clarity on who owns approvals, who updates records, and who signs off evidence. Technology follows process, not the other way around.

A 90-Day DORA Remediation Roadmap for CIOs

Days 1 to 30, discover and confirm gaps

Start with asset inventory, risk assessment, and a direct gap review against the five DORA pillars. Name an accountable owner for incident management, CMDB, vendor governance, and resilience testing.

Good at day 30 looks like this:

• Single list of critical services with named owners.

• Evidence of current control gaps ranked by risk.

• Board-ready summary that separates legal exposure from operational remediation.

Days 31 to 60, configure and integrate

Update policies, tighten workflows, and connect monitoring and third-party records to the systems your teams already use. Review supplier clauses in parallel, because contracts take longer than dashboards.

Good at day 60 looks like this:

• Incident and change workflows aligned to DORA evidence needs.

• Third-party records updated with resilience and exit obligations.

• Monitoring and logging tied to critical functions.

Days 61 to 90, test and assure

Run initial testing, prepare evidence packs, and package the board reporting layer. Don't wait for a perfect programme. Deliver a working one.

Good at day 90 looks like this:

• Test results that can be reproduced.

• Audit evidence pack ready for supervisory review.

• Steering committee cadence with clear actions, owners, and deadlines.

DataLunix typically sits in the discovery and delivery lane here, helping teams compress the first three months with readiness assessments, workflow design, and service-management implementation across HaloITSM, Freshservice, ManageEngine, and ServiceNow.

Frequently Asked Questions About DORA Compliance

Does DORA apply to non-EU firms serving EU customers?Yes, it can, especially through contractual flow-down and supplier dependencies. If your services support in-scope EU financial entities, you should assume you'll be asked for resilience evidence.

How is TLPT different from a standard penetration test?TLPT is more scenario-driven and focused on critical functions, not just technical vulnerabilities. It looks at how the business withstands realistic attack paths and operational disruption.

What is the minimum evidence pack for an audit?You need current incident records, test outputs, dependency visibility, third-party assurance, and a clear remediation trail. If those artefacts live in different systems, the audit pack will feel stitched together.

Do smaller financial entities have lighter obligations?Not by default in any way that helps you ignore the work. The extent of testing and oversight still depends on your role, criticality, and service footprint.

---

You don't need to rebuild your whole operating model to get DORA-ready, but you do need to fix the evidence chain fast. Visit DataLunix if you want a practical assessment of your ITSM and ITOM stack, a gap review against DORA, and a remediation plan your CIO can take straight into steering committee.