DORA ICT Compliance

EU financial firms and their ICT providers moved from theory to enforcement when DORA became fully applicable on 17 January 2025, and compliance now depends on proving ICT risk management, incident handling, resilience testing, and third-party oversight through evidence captured in your ITSM and ITOM systems. DORA also covers 20 different types of financial entities plus ICT third-party service providers, which means your service desk, operations tooling, vendor records, and testing workflows have become part of the compliance boundary.

Most CIOs already understand the regulation at a headline level. The gap is operational. Policy documents say you need governance, reporting, testing, and vendor control. Auditors and regulators will ask where that evidence lives, who owns it, how it is reviewed, and whether your tooling can reproduce it consistently.

That's where DORA ICT programmes usually stall. Teams write policies in one place, manage incidents in another, track vendors in spreadsheets, and store resilience evidence in email threads or shared folders. That setup doesn't hold up when you need a regulator-ready register, a tested exit approach for critical providers, or a clean trail from alert to incident to remediation.

What Is DORA and Why Does It Impact Your ICT Team

DORA changes the workload of ICT teams because it turns operational resilience into something regulators, customers, and auditors can inspect through records, workflows, and control evidence. For CIOs, that shifts DORA from a legal topic to a service management and tooling problem.

For teams running ServiceNow, HaloITSM, CMDBs, monitoring stacks, and supplier registers, the impact is immediate. Incident classification, service mapping, change approvals, vendor dependencies, testing records, and reporting timelines all need to stand up to external review. A policy statement on its own does not do that. A time-stamped record with ownership, linked assets, approvals, and remediation history does.

Why DORA lands with ICT operations, not just compliance

DORA reaches ICT teams because the regulation examines how financial entities prevent disruption, respond to incidents, test resilience, and control third-party risk in practice. Those activities sit inside day-to-day IT operations. If your organisation supports EU-regulated financial clients from the GCC or Europe, your delivery model can still fall inside customer assurance reviews, contractual obligations, and audit requests.

That creates a different standard of proof.

An operations lead now has to show where a critical service is defined, which CI or business service it depends on, which supplier supports it, how incidents are escalated, who approved a risky change, and whether a resilience test produced tracked remediation actions. In mature environments, that evidence should come from the platforms your teams already use, not from spreadsheets built a week before an audit.

Why many ICT teams underestimate the impact

The common mistake is to read DORA as a governance exercise owned by risk or legal. In delivery terms, it is also a configuration exercise.

If ServiceNow is your primary platform, you need to look at business services, CMDB relationships, Vendor Risk Management data, incident categorisation, major incident workflows, change models, exception handling, and dashboard evidence. If you run HaloITSM, the same logic applies through ticket fields, service structures, approval flows, asset relationships, supplier records, and reporting packs. Different products, same requirement. Your controls must be repeatable, reviewable, and easy to evidence.

That is why DORA matters to ICT teams even when the board discussion sounds abstract. The board asks whether the firm can classify a major ICT incident correctly. Your toolset has to prove the trigger, timestamps, decision path, communications, and closure record. The board asks whether critical providers are controlled. Your systems need linked contract data, service dependency records, risk reviews, and an exit plan that is more than a paragraph in a procurement file.

What changes for the CIO office

DORA raises the standard from "we have a process" to "show me the operating evidence." In practice, I see four areas come under pressure first:

Board question	What ICT must show
Which services are critical or important?	A maintained service model with supporting assets, dependencies, and owners
Can we report and review serious ICT incidents properly?	Classification criteria, timestamps, escalation history, communications, and post-incident actions
Are resilience tests controlled and followed up?	Scheduled tests, approvals, scope, results, findings, and remediation tracking
Do we control third-party ICT risk?	Supplier records, linked services, contract obligations, subcontractor visibility, and exit planning evidence

Weak operating models get exposed quickly. Teams often store service data in one place, supplier data in another, and test evidence in email or shared folders. That structure creates gaps the moment a regulator, internal audit team, or financial client asks for a full trail.

If you need the legal baseline before configuring workflows and evidence models, DataLunix's summary of the DORA regulation is a useful starting point. The harder part is translating that baseline into fields, relationships, approvals, reports, and control ownership inside the ITSM and ITOM tools your teams already run.

The Five Pillars of DORA Translated for ICT Operations

The legal framing is useful, but ICT teams need an operating translation. The five pillars of DORA become service management tasks, workflow design choices, and evidence requirements.

How each pillar shows up in day-to-day operations

ICT risk management means your governance model can't sit outside operations. Risks need ownership, treatment actions, review cadence, and links to actual services, assets, and changes.

Incident reporting means incident records need more than priority and assignment group. You need fields, triggers, timelines, and evidence for determining whether an event escalates into a major ICT-related incident.

Resilience testing means test activity must be planned, approved, executed, and evidenced. This is not a once-a-year exercise hidden in a security team folder.

Third-party risk management means vendor records must connect to the services they support, the subcontracting chain, the contract terms, and the exit approach for critical or important functions.

Information sharing means threat intelligence and lessons learned need a governed route into operations, not an informal exchange in chat channels.

What this means for ITSM teams

Many teams already have the building blocks. The problem is fragmentation.

• Service desk teams need incident categories and decision trees that support DORA classification, not just SLA routing.

• Change managers need links between test findings, change records, and post-implementation validation.

• Application owners need business service context so they can identify which systems support critical or important functions.

• Supplier managers need structured records for contract obligations, assurance reviews, and exit dependencies.

A mature programme doesn't create a separate “DORA process” for everything. It extends existing ITIL-aligned processes so evidence is generated as work happens.

DORA becomes manageable when you stop treating it as a legal workstream and start treating it as a service operations design problem.

Where many organisations misread the five pillars

The common failure pattern is over-indexing on policy and under-investing in system design. Teams write a risk framework, publish an incident procedure, and assume they're covered. They aren't, unless the tools force consistent execution.

That's why operational resilience work often overlaps with broader service modernisation. If you're redesigning service management anyway, DataLunix's guide to digital operational resilience is relevant because it frames resilience as an operating capability rather than a compliance document.

What works is embedding the pillars into the lifecycle of tickets, assets, vendors, tests, and changes. What doesn't work is storing “proof” after the fact.

Mapping DORA Controls to Your ITSM and ITOM Platform

DORA ICT stops being a regulation and becomes a platform configuration programme.

In ServiceNow, HaloITSM, Freshservice, and ManageEngine, the core job is similar. Map regulatory obligations to records, workflows, approvals, schedules, and reports. The naming differs by platform. The implementation logic doesn't.

A practical control mapping model

DORA requirement	ITSM or ITOM implementation
ICT risk management	Risk register linked to business services, CIs, owners, and remediation tasks
Incident reporting	Major incident model, classification criteria, mandatory timestamps, escalation workflow
Resilience testing	Test calendar, change approvals, evidence attachments, remediation backlog
Third-party risk	Vendor inventory, service dependency mapping, contract obligations, review tasks
Evidence and oversight	Dashboards, audit trails, document links, exception reporting

How to configure this in real tools

ServiceNow is usually strongest when you need tight linkage across CMDB, Incident, Change, Vendor Risk, and reporting. The trap is overbuilding. Don't start with a custom app for everything. Start with data model discipline. Define critical services, connect them to supporting CIs and vendors, then add DORA-specific classification and evidence fields only where they change decisions.

HaloITSM works well for organisations that want lighter-weight workflow control with strong service desk practicality. Use custom fields and rule-based automation for incident categorisation, approvals, and evidence collection. Keep the service catalogue and supplier records clean. Halo becomes difficult when teams try to replicate enterprise GRC complexity inside tickets alone.

Freshservice is useful when speed matters and the organisation already runs lean operations. It can support DORA evidence if you're disciplined about forms, change templates, asset relationships, and approval paths. It becomes weaker if supplier governance remains outside the platform.

ManageEngine can support DORA programmes where operations and asset governance are already centralised there. The main implementation challenge is consistency. If business services, assets, and vendors are maintained by different teams without common ownership, your evidence chain will break.

TLPT and evidence design

Critical services must undergo threat-led penetration testing at least every three years, according to IBM's DORA explainer. In practical terms, your ITSM and ITOM stack needs to schedule testing, track approvals, log findings, and show remediation closure with timestamps and ownership.

That usually means:

• Scheduling in a governed calendar: Build recurring test plans with accountable owners.

• Converting findings into controlled work: Route findings into change, problem, or defect workflows.

• Linking remediation to production reality: Attach implementation evidence, validation notes, and retest outcomes.

If your DORA scope includes cloud-hosted critical functions, it helps to review how external providers structure resilience responsibilities. For cloud sourcing due diligence, lists of certified AWS cloud partners can help you identify delivery models and support capabilities relevant to contract and operating risk reviews.

Implementation test: Pick one critical service. If you can't show its incidents, recent changes, key vendors, resilience tests, and current risks in one connected view, your platform model isn't ready.

A lot of organisations need a fit-gap workshop before they configure anything. DataLunix has published a practical view of ServiceNow for compliance operations, focused on mapping regulatory obligations to working records rather than abstract controls. The same implementation approach can be adapted for HaloITSM and other platforms.

Building Your DORA ICT Compliance Dashboard

A dashboard for DORA ICT isn't a vanity layer. It's the control surface that proves your programme is alive.

Most failed dashboards have the same problem. They report activity, not resilience. Ticket counts, open changes, and generic SLA views don't answer DORA questions. Auditors and executives need to see whether critical controls are executed, whether evidence is current, and where exposure sits.

What data the dashboard should pull

Start with the minimum evidence set:

• Incident records: Including classification, impact, timeline fields, escalations, and closure notes

• Change and release data: Especially changes linked to resilience findings or critical services

• Risk records: Ownership, treatment plans, overdue actions, accepted risks

• Vendor and contract records: Criticality, service dependency, assurance reviews, exit readiness status

• Testing records: Resilience exercises, penetration test findings, validation status

• Configuration and service maps: Which technologies and suppliers support critical functions

What to measure instead of generic IT metrics

Use metrics that help a reviewer understand control performance.

Dashboard area	Useful measure
Major incident readiness	Time from detection to formal classification
Evidence health	Records missing mandatory attachments or approvals
Resilience testing	Open remediation items from recent test cycles
Third-party control	Critical vendors with incomplete assessments or exit documentation
Governance cadence	Overdue review tasks for risks, contracts, or service assurance

These don't need to become public benchmarks. They need to become management signals.

How to avoid dashboard theatre

Don't build one giant executive screen first. Build three views.

Operational view for service owners. They need exceptions, missing evidence, overdue remediation, and critical dependencies.

Control owner view for risk, compliance, and supplier managers. They need attestation status, review cycles, and documentation completeness.

Executive view for the CIO and board committees. They need concentration of risk, unresolved exposure, and trend direction in control execution.

A useful implementation pattern is to keep source-of-truth data in ITSM and ITOM, then visualise through your BI layer or native analytics. The dashboard should never become the place where people manually “fix” compliance status.

If you're designing a dashboard around digital evidence rather than static reporting, DataLunix's perspective on digital DORA operating models is relevant because it focuses on integrating operational data across fragmented tools.

Implementing Governance and Change Management for DORA

Tooling alone won't carry DORA. Governance decides whether your workflows are trusted, whether ownership is clear, and whether evidence is kept clean under pressure.

The pressure point is record-keeping. Regulators have already begun standardising incident oversight through DORA-related reporting, which raises the bar on incident logs, resilience test records, and third-party assessments, as highlighted by ESMA's update on the first report on DORA major ICT-related incidents.

What good governance looks like in practice

Strong governance is usually boring. That's a good sign.

• Named ownership: Every critical service, control area, and evidence set has a business owner and an operational owner.

• Review cadence: Risks, vendor assessments, and resilience findings are reviewed on a defined cycle.

• Decision records: Exceptions, risk acceptance, and control gaps are documented with approvers.

• Workflow enforcement: Mandatory fields and approval steps sit inside the platform, not in a slide deck.

Why change management matters more than teams expect

The hard part isn't adding fields to an incident form. The hard part is changing behaviour across service desk, infrastructure, security, procurement, and application teams that already feel overloaded.

What works:

• Train by scenario: Show teams how a supplier outage or cyber event should move through the workflow.

• Use service examples: Anchor decisions around one or two critical business services first.

• Audit the record, not the meeting: Check whether evidence is captured in the ticket, task, or vendor record itself.

What doesn't work:

• Policy-only rollouts: People won't memorise legal language during an outage.

• Spreadsheet side systems: They create parallel truths and broken audit trails.

• Unowned governance forums: If nobody owns follow-up actions, dashboards become decoration.

Governance for DORA is operational discipline with named owners, not a quarterly presentation.

For organisations formalising roles, controls, and escalation structures, a broader governance, risk, and compliance framework helps tie DORA obligations back to established decision rights and operating routines.

Your Phased Roadmap for DORA ICT Resilience in 2026

Organisations that already run mature ITSM tooling usually have more of the foundation than they think. The problem is rarely a missing platform. It is weak service mapping, inconsistent records, and evidence that sits across inboxes, spreadsheets, procurement files, and team chat instead of inside the operational system.

Phase 1 Assess and gap analysis

Start with one question. Can your team show, from system records alone, which business services support EU-regulated activity, which ICT services and suppliers support them, and who owns the response when something fails?

In practice, this first phase exposes basic operational gaps. CMDB relationships are often incomplete. Service catalogues describe offerings in commercial language, while resolver groups work against technical components. Supplier ownership is split across procurement, security, and operations. That disconnect matters because DORA evidence depends on traceability across all three.

Focus the assessment on:

• Service scope: Which business services support regulated activity and which technical services sit underneath

• Evidence location: Where incidents, risks, contracts, test results, and remediation actions are stored

• Data quality: Which CI, service, supplier, and ownership records are missing or unreliable

• Classification decisions: Whether any digital, cloud, data, or support service has been treated as out of scope without a documented basis

A common failure point is ICT service classification. Teams exclude services because they sit inside a broader product or managed offering, then discover later that the financial entity still expects those services in the register, contract review, and oversight model. Katten's note on the European Commission clarification is a useful reference for that boundary question.

Phase 2 Prioritise and plan

Once the gaps are visible, sequence the work by evidence value, not by whichever team has budget first.

I usually recommend this order because it creates an audit trail quickly and improves daily operations at the same time:

1. Critical service mapping

2. Major incident criteria and workflow configuration

3. Supplier inventory linked to services and contracts

4. Resilience testing records and remediation tracking

5. Management reporting and exception visibility

This phase should produce a design pack that operations teams can build from. In ServiceNow, that means table changes, form layouts, relationship rules, assignment logic, report definitions, and integration points. In HaloITSM, it means ticket types, custom fields, workflow steps, approval rules, supplier associations, and dashboard widgets. If those design decisions stay in workshop notes, the programme stalls when build starts.

Phase 3 Implement and integrate

Configure the tools you already run before adding another layer of governance software.

For ServiceNow, the high-value work is usually in CSDM-aligned service relationships, incident categorisation, vendor records, risk links, and reporting logic. For HaloITSM, the quickest gains often come from mandatory evidence fields, incident and problem workflow updates, linked assets and suppliers, and automation that forces closure checks before a record can move forward. Freshservice and ManageEngine can support the same outcome if you standardise categories, approval paths, service references, and reporting tags early.

The trade-off is straightforward. A fast build using loose categories gets adoption sooner, but produces weak evidence. A stricter design with mandatory links and controlled picklists takes longer to land, but it gives your CIO, risk lead, and auditors something they can rely on.

For resilience exercise design, a practical disaster recovery testing framework helps teams define scenarios, expected recovery steps, control checkpoints, and post-test evidence in a format operations teams can practically run.

Phase 4 Test and validate

Run the process against a real scenario before a regulator, client, or internal audit asks for proof.

Pick one important service. Simulate a cyber incident, cloud outage, failed release, or supplier disruption. Then test whether the platform can show the full chain without manual reconstruction.

Validation question	Expected evidence
Was the incident classified correctly?	Time-stamped incident record with decision trail
Were stakeholders engaged properly?	Escalation tasks, approvals, communication log
Were supplier dependencies visible?	Linked vendor and service records
Were findings remediated?	Change, problem, or defect records with closure evidence

If teams need to search email threads or ask three managers what happened, the control is not ready. Fix the workflow, field design, ownership model, or integration before scaling the process to more services.

Phase 5 Monitor and optimise through 2026

By 2026, the target is a repeatable operating model that produces evidence as part of daily work. That includes support for recurring reporting, register maintenance, supplier review, and follow-up after incidents and resilience tests, as noted earlier in the article.

The operating cadence should be simple and disciplined:

• Monthly evidence checks: Review incomplete incidents, missing service links, stale supplier records, and overdue remediation tasks

• Quarterly control reviews: Check contract coverage, service-map accuracy, and test completion against plan

• Post-incident and post-test reviews: Confirm that lessons learned became tracked actions inside the platform

• Configuration updates: Adjust forms, automations, and reporting when teams keep failing the same control step

The firms that handle DORA well are usually not the ones with the largest policy set. They are the ones that can open ServiceNow or HaloITSM and show a connected record from business service to incident to supplier to remediation, without a week of cleanup first.

Frequently Asked Questions About DORA ICT Compliance

Does DORA ICT only apply to companies based in the EU

No. DORA is an EU regulation, but it reaches ICT third-party service providers that support in-scope financial entities. If your GCC or international team provides digital, cloud, support, or data services into an EU-regulated financial client, your contracts and operating evidence can fall under scrutiny.

What is the biggest mistake vendors make with DORA ICT

Misclassifying services. DORA uses a broad definition of ICT service, and financial entities must assess each service individually. A vendor may assume its service is outside scope, while the client treats it as in scope for register reporting, contract clauses, and oversight.

How should cloud providers be handled under DORA ICT

Treat cloud services as operational dependencies that need clear mapping to business services, incident processes, contract terms, and exit planning. The right question isn't “is cloud allowed”. The right question is whether your records show governance, testing, and evidence for the cloud-supported critical function.

Can existing ITSM platforms support DORA ICT without buying a new GRC suite

Often, yes. ServiceNow, HaloITSM, Freshservice, and ManageEngine can all support large parts of DORA if you configure service models, incident criteria, evidence capture, and supplier records properly. The missing piece is usually operating design and data discipline, not software ownership.

What should CIOs ask for first in a DORA ICT programme

Ask for one connected view of a critical service. It should show supporting systems, key vendors, incident history, changes, current risks, and recent resilience evidence. If your teams can't produce that view quickly, start there before expanding the programme.

---

If you need to turn DORA from policy language into working incident models, service maps, vendor controls, and regulator-ready evidence, DataLunix can support the fit-gap assessment, workflow design, tool configuration, and adoption work across ServiceNow, HaloITSM, Freshservice, and ManageEngine. The useful starting point is a scoped workshop that identifies which critical services matter, where evidence currently breaks, and which changes in your ITSM and ITOM stack will make the biggest difference fastest.