Digital Resilience Act: Your 2026 CIO Compliance Roadmap

The Digital Resilience Act, known in practice as the EU's DORA, became fully applicable on 17 January 2025. That means financial entities and critical ICT providers serving the EU/EEA market now need demonstrable operational resilience, and the enforcement date has already passed.

If you're a CIO with operations in the UAE, wider GCC, or Europe, this is no longer a policy exercise. It is an operating model issue. DORA reaches into incident handling, service continuity, resilience testing, supplier governance, and the way your ITSM and ITOM platforms produce evidence.

Most firms don't fail because they misunderstand the regulation. They fail because legal obligations stay in PDFs while operations continue in ServiceNow, HaloITSM, Freshservice, ManageEngine, spreadsheets, email approvals, and fragmented vendor records. The practical move is to translate DORA into workflows, configuration standards, and auditable records.

What Is the Digital Resilience Act and Who Must Comply

The digital resilience act most CIOs need to pay attention to is the EU Digital Operational Resilience Act (DORA). It entered into application on 17 January 2025 and applies broadly to financial institutions serving the EU/EEA market, including banks, insurance companies, investment firms, and other financial entities, as outlined by EIOPA's overview of DORA.

For GCC and AE-based organisations, the mistake is assuming geography protects you. It doesn't if you serve European customers, support regulated group entities, or provide cross-border banking, insurance, payments, asset management, or fintech services into Europe. In those cases, DORA becomes part of your operational reality.

Why CIOs should treat DORA as an operating issue

DORA is designed to ensure covered financial entities can withstand, respond to, and recover from ICT disruptions such as cyberattacks and system failures. That sounds regulatory, but the work lands squarely in technology and operations.

That means your teams need to answer practical questions such as:

• Service criticality: Which services support regulated or business-critical functions?

• Dependency visibility: Which platforms, vendors, integrations, and support teams sit in the delivery chain?

• Control evidence: Can you show not just that a control exists, but that it was executed, reviewed, and improved?

A lot of organisations already have continuity and disaster recovery material. The problem is that these assets are often broad, static, and not wired into day-to-day service management. A useful companion read is CloudOrbis's guide to business continuity, especially for aligning resilience language with operational continuity practice.

Practical rule: If your control can't be evidenced from the systems your teams actually use, auditors and regulators will treat it as weak, no matter how polished the policy looks.

Who is in scope in practice

From a CIO viewpoint, scope usually falls into three layers:

• Regulated financial entities: The legal entity itself is directly in scope.

• Shared services and group technology: Internal platforms may become critical because they support the regulated entity.

• External ICT providers: Cloud, SaaS, managed service, and service desk dependencies can become part of your DORA exposure.

This is why governance, risk, and compliance work can't sit apart from operational tooling. A mature approach links policy to asset records, incidents, changes, test plans, and supplier controls. That is the same discipline discussed in cyber governance, risk, and compliance, but under DORA the evidence threshold is sharper and more operational.

What Are the Key Obligations Under DORA

DORA compliance usually fails in the handoff between policy and operations. The regulation is organised into five obligation areas, but for a CIO the question is simpler: can the organisation prove, from its live systems of record, that resilience controls are defined, operating, and owned?

How the five pillars translate for IT leaders

ICT risk management requires a governed operating model for resilience. In practice, that means your CMDB, service catalog, risk register, and ownership model need to align. If a critical business service has no named technical owner, no mapped dependencies, or no review cycle in the platform, the control is weak no matter what the policy says.

ICT-related incident management requires incidents to be classified in a way that supports escalation, impact assessment, and regulatory reporting. Service desk teams need structured fields for affected service, criticality, root cause class, and reporting threshold. Free-text tickets and inconsistent priority rules create reporting gaps fast.

Digital operational resilience testing requires evidence that resilience controls are exercised, not just documented. That includes scenario testing, recovery validation, and test records tied back to the services and assets that matter most. In ITSM and ITOM terms, test plans should sit alongside configuration items, change history, and known failure points.

ICT third-party risk requires suppliers to be managed as part of your control environment. The practical shift is significant. Vendor records need to show service dependencies, contract obligations, assurance status, concentration risk, and exit considerations in one place. For many firms, tightening third-party supplier management is the fastest way to close a visible DORA gap.

Information sharing requires a controlled process for handling threat intelligence and vulnerability information. That process should define who receives external intelligence, how it is validated, where it is logged, and how it triggers action in incident, problem, or change workflows.

Where organisations usually struggle

The hardest obligation is often third-party risk because it cuts across legal, procurement, architecture, security, and operations. Most firms already have supplier reviews. Fewer have a system-level view of which external provider supports which important business service, what happens if that provider fails, and which team is accountable for the fallback plan.

The operational trade-off is real. If you ask every supplier for maximum assurance data, the process slows down and teams work around it. If you keep onboarding light, you create blind spots in critical dependencies. The better approach is tiering. Put high-control workflows around providers tied to important or critical services, then configure lighter workflows for low-impact suppliers.

Common weak spots include:

• Fragmented supplier records: Procurement, security, architecture, and operations each maintain separate records, so nobody trusts the full picture.

• Missing service linkage: Teams know the vendor name but cannot show which regulated service, process, or recovery objective depends on it.

• Weak contractual traceability: Evidence of review exists in email and meeting notes, not in the platform that should track obligations and renewals.

• No exit evidence: Contracts mention termination rights, but there is no tested transition plan, no alternate provider logic, and no service-level rollback path.

A strong DORA programme treats these five obligations as build requirements for ITSM and ITOM, not as a legal checklist sitting outside operations. That is where compliance starts to create value. Better service mapping, cleaner incident data, tighter supplier control, and auditable testing records improve resilience whether a regulator asks for evidence or not.

What Are the Practical Implications for Your IT Operations

DORA raises the bar for day-to-day operations. Fast ticket resolution is no longer enough if your service desk cannot show how an incident affected a critical service, which dependencies were involved, what decision was taken, and whether corrective actions were completed. One of the biggest operational pressure points is resilience testing. Entities must perform annual basic ICT testing, and some firms must carry out threat-led penetration testing for ICT services that support critical functions, according to PwC's DORA guidance.

For a CIO, the practical question is simple. Can your ITSM and ITOM platforms produce evidence without a manual scramble?

What changes in service management practice

Incident management needs a tighter design. Priority alone will not satisfy DORA if the record does not capture affected business services, dependency impact, recovery actions, communications, and post-incident remediation. In many environments, the tool can do this already, but the workflow was never configured for regulatory scrutiny.

Change management also needs a different approval lens. If a change touches a critical service chain, the approval should show rollback steps, test evidence, known dependency risks, and named owners across infrastructure, application, and supplier teams. That adds friction, but only where the business impact justifies it. Applying the same controls to every low-risk change will slow delivery and encourage teams to bypass process.

The operational implications usually show up in five places:

• Incident classification: Categories, subcategories, and impact fields must support consistent identification of ICT incidents with regulatory relevance.

• Service mapping: Major incident teams need current upstream and downstream dependency data, not tribal knowledge in chat threads.

• Problem management: Outage findings and test failures need owners, due dates, risk ratings, and evidence of closure.

• Change controls for critical services: Approval workflows should trigger extra checks when a CI or service is marked as important or critical.

• Supplier participation: Providers that support regulated services need to be included in exercises, incident response, and remediation tracking.

A mature DORA operating model is visible in platform data quality, workflow discipline, and audit-ready records.

Why testing becomes the forcing function

Testing exposes weak configuration faster than policy reviews do. If your CMDB is incomplete, scenarios will miss real dependencies. If your problem backlog is full of old corrective actions with no owner, test findings will repeat. If the change calendar is disconnected from resilience testing, one release can invalidate the assumptions behind the exercise.

That is why DORA should be built into the systems your teams already use. Configure your ITSM and ITOM stack so critical services have mandatory dependency maps, incident forms require business impact fields, major incident workflows create linked problem records automatically, and test exercises produce auditable tasks through to closure. Done well, compliance work improves service reliability, reporting accuracy, and executive visibility instead of creating a parallel control structure.

The same principle applies to supplier risk. If you want to secure your business ecosystem, supplier records need to be linked to business services, contracts, resilience obligations, and exit actions inside the platform, not buried in procurement files and email chains.

For a broader operating model view, see this guide to operational resilience. Under DORA, the test is whether that resilience model is configured into your workflows, data model, approvals, and reporting.

Your CIO Compliance Checklist for the Digital Resilience Act

A useful DORA checklist is simple. If you can't answer “yes” with evidence, assume there is a gap. The objective isn't to create paperwork. It's to expose where your control design and operational reality still diverge.

Governance and risk questions

Ask your leadership team:

• Framework ownership: Do we have a formally documented ICT risk framework with named owners and review cadence?

• Critical service clarity: Have we identified the services and business processes that matter most to resilience?

• Board visibility: Can executives see current resilience risks, unresolved findings, and dependency exposure in one place?

Incident, supplier, and testing questions

Ask your operations and vendor teams:

• Incident structure: Can our ITSM tool classify ICT incidents consistently enough to support regulatory scrutiny?

• Major incident discipline: Do our workflows capture timeline, impact, affected services, root cause, and remediation actions in a repeatable way?

• Third-party control: Have we identified all critical ICT suppliers and linked them to the services they support?

• Contract readiness: Do our supplier records show the practical controls, obligations, and review points needed for oversight?

• Testing evidence: Can we prove that annual testing exists, that critical services were exercised appropriately, and that weaknesses were tracked to closure?

Watch for this gap: Many organisations have an incident process and a supplier process. Far fewer have both linked to the same service model.

For leaders tightening their ecosystem controls, secure your business ecosystem is a useful outside perspective on how third-party risk becomes an operational issue rather than a contract filing exercise.

A Step-by-Step DORA Readiness Roadmap

DORA readiness works best as a phased programme. Trying to fix policies, service models, contracts, testing, and tooling all at once usually creates motion without control. A better pattern is to sequence the work so each phase produces usable evidence and cleaner operational data.

Phase 1 through Phase 3

1. Assess your scope Identify regulated entities, critical services, important business processes, and ICT dependencies. Include external providers early. If your service map is incomplete, document assumptions and fix the model before you over-engineer controls.

2. Define policy and process expectations Translate legal requirements into process rules. Decide what must be recorded for incidents, changes, tests, and supplier reviews. The strongest teams turn obligations into mandatory fields, approval points, and evidence records.

3. Implement in platforms and operating rhythm Configure the workflows where work already happens. This includes category structures, risk review tasks, remediation registers, vendor review cadences, and exception handling. Then train managers on what “good evidence” looks like.

Phase 4 and Phase 5

1. Run resilience testing and close findings Exercise the services that matter. Make sure test plans, participants, dependencies, outputs, and lessons learned are recorded. Weak teams run tests as one-off events. Strong teams turn them into recurring improvement cycles.

2. Monitor and optimise continuously DORA isn't a one-time attestation. It requires sustained control operation. Review stale actions, recurring incident types, supplier drift, and untested dependencies. Use dashboards, but don't confuse dashboards with governance.

A practical roadmap should also define who owns each workstream:

• Risk and compliance teams define control expectations.

• IT operations executes workflow changes and evidence capture.

• Enterprise architecture or platform owners maintain service and dependency models.

• Procurement and legal align supplier records and contractual oversight.

• Executive sponsors resolve conflicts when resilience work competes with delivery pressure.

How to Map DORA into Your ITSM and ITOM Processes

The digital resilience act either becomes manageable or remains abstract. The strongest CIO teams don't build a separate DORA universe. They map DORA requirements into the tools already running operations, especially ServiceNow, HaloITSM, Freshservice, and ManageEngine.

A simple example. If DORA requires structured incident handling, don't answer with a policy statement alone. Answer with incident category design, priority matrices, mandatory impact fields, resolver group workflows, and automated post-incident review tasks in the platform.

What good mapping looks like in practice

In ServiceNow, this often means using incident, problem, change, CMDB, vendor, and IRM capabilities together. In HaloITSM or Freshservice, the same principle applies even if the modules differ. The target state is consistent. One service model, one chain of evidence, and one operational record from event to remediation.

Typical platform actions include:

• Incident management: Add ICT incident classifications, critical service flags, and escalation rules.

• Problem management: Force root cause, workaround, permanent fix, owner, and due date fields for resilience findings.

• Change control: Require resilience impact assessment for changes affecting critical services.

• Asset and service modelling: Link applications, infrastructure, vendors, and business services.

• Vendor management: Track supplier criticality, review dates, dependencies, and control evidence.

• Testing governance: Record test scope, participants, findings, retest dates, and closure status.

If your auditors ask for evidence and your teams start exporting spreadsheets from five systems, your DORA design is still immature.

For organisations using ServiceNow as the backbone for risk and operations, ServiceNow IRM is often the connective layer that brings policy, risk, incidents, and control tasks into one workflow model.

Mapping DORA Requirements to ITSM Platform Actions

DORA Requirement	Affected ITSM/ITOM Process	Key Action in Platform	Compliance Evidence to Generate
ICT risk management	Risk register, service portfolio, CMDB	Link critical services to assets, owners, and dependencies	Approved risk records, ownership records, review history
ICT-related incident management	Incident and major incident management	Configure incident categories, impact fields, escalation paths, and post-incident reviews	Timestamped incident records, classification logs, action history
Digital operational resilience testing	Change, problem, test coordination	Create test plans, remediation tasks, retest checkpoints, and closure workflows	Test scope documents, findings register, remediation closure records
ICT third-party risk	Vendor management, contract oversight, service mapping	Mark supplier criticality, connect vendors to supported services, schedule reviews	Supplier inventory, review tasks, dependency evidence, approval history
Information sharing	Knowledge, security operations, governance workflows	Define controlled intake and dissemination process for threat intelligence	Shared advisories, review records, acknowledgement trails

The best implementations keep the model lean. Overdesign is common. Teams add too many custom fields, too many parallel workflows, and too many approval layers. That usually weakens compliance because staff route around the process.

Achieve DORA Compliance with DataLunix

DORA compliance is hard because it sits across legal interpretation, operational design, platform configuration, and organisational change. Most internal teams are strong in one or two of those areas, but not all four at once. That's why many programmes stall after the gap assessment.

A useful partner should do more than explain the regulation. They should help you turn DORA into working controls inside the systems your teams use every day. That means discovery workshops to confirm scope, fit-gap assessments across ITSM and ITOM processes, and implementation plans that prioritise evidence-producing controls first.

For organisations running or evaluating ServiceNow, HaloITSM, Freshservice, or ManageEngine, the practical challenge is configuration quality. Incident workflows, service models, supplier records, risk registers, and remediation processes need to align. If they don't, the platform becomes a reporting burden instead of a resilience engine.

DataLunix is well positioned for this kind of work because it operates at the intersection of transformation strategy, platform delivery, and managed operations. It supports GCC and European organisations with discovery-led engagements, readiness assessments, change management, optimisation services, and implementation capability across the core ITSM and ITOM platforms many DORA programmes rely on. Where ServiceNow is part of the target architecture, compliance on ServiceNow becomes especially important because governance and operational evidence need to live in the same environment.

The firms that handle DORA well usually take a practical approach:

• They simplify scope first

• They configure evidence into workflows

• They test critical service chains realistically

• They treat supplier governance as an operational control

• They keep improving after the initial compliance push

That is what turns DORA from a reactive burden into a stronger operating model.

---

If you're preparing your digital resilience act roadmap and need a partner who can connect DORA requirements to real ITSM and ITOM execution, DataLunix can help you move from policy interpretation to platform-ready controls, evidence design, and sustainable operational resilience.