DORA: Establishing a Shared Understanding Across ICT, Risk, Internal Audit and External Assessors

A Landmark Moment for DORA

On 18 November 2025, the European Supervisory Authorities (EBA, EIOPA and ESMA) formally designated the first Critical ICT Third-Party Providers (CTPPs) under Article 31(9) of the Digital Operational Resilience Act — a landmark moment in the DORA timeline and a significant evolution in how the EU will oversee the digital backbone of the financial sector.

According to the official list published by the ESAs, the designated CTPPs (in alphabetical order) are:
Accenture plc; Amazon Web Services EMEA Sarl; Bloomberg L.P.; Capgemini SE; Colt Technology Services; Deutsche Telekom AG; Equinix (EMEA) B.V.; Fidelity National Information Services, Inc.; Google Cloud EMEA Limited; International Business Machine Corporation; InterXion HeadQuarters B.V.; Kyndryl Inc.; LSEG Data and Risk Limited; Microsoft Ireland Operations Limited; NTT DATA Inc.; Oracle Nederland B.V.; Orange SA; SAP SE; Tata Consultancy Services Limited.

The designation of these providers is more than symbolic — it marks the beginning of direct EU-level oversight, including supervisory inspections, information requests, remediation expectations and pan-European coordination.

What designation does not mean for financial entities (FEs):

  • It does not relieve FEs of responsibility for ICT risk management (Articles 5–15).

  • It does not replace due diligence, monitoring, contractual governance, or exit strategy planning.

  • It does not guarantee resilience for any FE using a CTPP.


What designation does mean:

  • Systemically important ICT providers will now face EU-level supervision.

  • FEs must understand and incorporate CTPP oversight into their own third-party risk management (Chapter V).

  • FEs should expect more structured expectations around supply-chain transparency, risk reporting, and incident communication.


This development has rightly captured the attention of boards, CIOs, CROs and Internal Audit functions across Europe.



"Yet, working closely with financial institutions throughout 2024–2025, I am seeing a second issue of equal importance emerging — one that receives far less public attention but is now affecting operational resilience programmes every day:

A widening misalignment of interpretation between ICT, Internal Audit, external consultants, Risk, and the management body regarding what DORA actually requires — and how it should be evidenced.

The remainder of this article aims to reset that understanding." Paul C Dwyer

DORA Is Broader Than ICT — and No Single Function Can Cover It Alone

DORA is sometimes assigned to the CIO because of its ICT focus, but the Regulation’s scope is considerably broader.


Article 5 — Management Body Responsibilities

The management body “shall bear the ultimate responsibility for managing the ICT risk of the financial entity.”


This immediately places DORA at the enterprise level, not within a single technological silo.

Articles 6–7 — ICT Governance and Strategy

These Articles require integration of ICT risk into the overall risk management framework, which includes:

  • Risk

  • Compliance

  • Finance

  • Internal Audit

  • Operational leadership

  • Senior executive management


Articles 10–12 — Incident Detection, Response, Recovery

These obligations involve:

  • ICT Security

  • Security Operations

  • Crisis Management

  • Communications

  • Business Continuity

  • Senior leadership engagement


Chapter V — ICT Third-Party Risk

This chapter requires joint involvement from:

  • Procurement

  • Legal

  • Vendor management

  • ICT

  • Risk

  • Compliance


Conclusion:
A CIO cannot reasonably be expected to represent or evidence DORA in its entirety.
DORA is a cross-functional organisational framework with ICT as one important component.

RTS and ITS Are Essential — But Not Prescriptive Checklists

The Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) are crucial.

They provide:

  • classification criteria

  • templates and formats

  • additional detail

  • technical clarifications


However, ESAs consistently describe RTS as:

  • “further specifying” or

  • “supplementing”

  • “providing additional detail to”

the underlying Regulation.

They are not standalone checklists replacing the principle-based structure of DORA.


Why RTS-only assessments create problems

If RTS are treated as a standalone checklist:

  • Broader governance and management-body requirements (Articles 5–7) are under-captured

  • Proportionality (Article 4) is not applied

  • Controls are evaluated for existence, not operational effectiveness

  • The scope can skew toward ICT without capturing organisational context

  • Internal Audit and ICT may assess different things with different assumptions

  • Maturity, repeatability and governance cannot be meaningfully assessed


RTS criteria are essential — but only within a wider framework.


Why Frameworks Such as NIST CSF 2.0 Help Align All Stakeholders

European regulators do not “endorse” a specific cybersecurity framework.
However, NIST CSF appears repeatedly across Level 2 and Level 3 supervisory materials, making it a widely recognised reference.

This matters because it explains why so many financial entities, Internal Audit functions and external assessors use NIST CSF 2.0 to structure DORA evidence.


Where NIST CSF Is Referenced in European Regulatory Materials

A. ESAs – Joint Consultation on ICT Risk Management (2019)

NIST CSF is cited as a widely used cybersecurity framework in the consultation informing the EBA/ESMA/EIOPA ICT Guidelines that evolved into DORA’s RTS.


B. ENISA Guidance

ENISA refer to NIST CSF in:

  • Financial Sector Cybersecurity Good Practices

  • Threat Landscape Reports

  • SME Security Guidance

It is presented as a commonly used framework across the EU.


C. ECB – Cyber Resilience Oversight Expectations (CROE)

CROE states alignment with:

  • NIST Cybersecurity Framework

  • CPMI-IOSCO cyber guidance

  • ISO/IEC standards

CROE is widely used by NCAs to interpret operational resilience maturity.


D. National Competent Authorities

  • Central Bank of Ireland — references NIST CSF in supervisory speeches as an established framework for ICT risk management.

  • DNB (Netherlands) — references NIST CSF in sectoral cyber guidelines.

  • BaFin (Germany) — references NIST CSF in digital resilience commentary.


These references show that NIST CSF is legitimately and safely used by financial entities, auditors and assessors to structure ICT resilience.


Why NIST CSF 2.0 Specifically Helps

NIST CSF 2.0 adds a new top-level function:


GOVERN (GV)

This aligns directly with:

  • Article 5 (management-body accountability)

  • Articles 6–7 (governance and integration)

  • Chapter V (oversight and outsourcing governance)

  • Article 12 (resilience and continuity governance)

The remaining functions — Identify (ID), Protect (PR), Detect (DE), Respond (RS), Recover (RC) — map cleanly to Articles 6–15 and the RTS on ICT risk management.


Frameworks such as NIST CSF do not replace the RTS.

 They provide a:

  • structured

  • maturity-based

  • internationally recognised

  • governance-aligned

way of interpreting DORA in a manner that ICT, Risk, Internal Audit and the Board can all understand consistently.

Proportionality: Central to DORA and Often Misunderstood

Proportionality appears repeatedly throughout DORA — particularly in:

  • Article 4, and

  • the RTS on ICT Risk Management


However, DORA does not prescribe how proportionality should be calculated. A structured approach helps all stakeholders (ICT, Risk, IA, external assessors, management body) align.


Example: Applying Proportionality in Practice

Fictitious Financial Entity: EuroPay Digital Services (EDS)

EDS is:

  • a mid-sized payment institution

  • operating in two Member States

  • cloud-hosted

  • reliant on two ICT providers

  • exposed to fraud and credential-theft risk

  • providing near-real-time services


Proportionality Model (4 Levels → 4 NIST CSF Tiers)

Step 1 — Assess inherent ICT risk

Using factors such as criticality of services, operational complexity, threat exposure, dependency on ICT third-party providers, and potential impact of disruption, a financial entity is assigned one of four inherent risk levels:

Level 1 — Low inherent ICT risk

Level 2 — Moderate inherent ICT risk

Level 3 — High inherent ICT risk

Level 4 — Critical inherent ICT risk

This provides a clear, evidence-based baseline for proportionality decisions (Article 4).

Step 2 — Map inherent ICT risk level directly to the four NIST CSF 2.0 Implementation Tiers

Inherent ICT Risk Level Mapped NIST CSF 2.0 Implementation Tier Meaning
Level 1 (Low) Tier 1 — Partial Ad-hoc, limited governance, inconsistent execution
Level 2 (Moderate) Tier 2 — Risk-Informed Defined processes, growing repeatability
Level 3 (High) Tier 3 — Repeatable Governance established, processes consistently executed
Level 4 (Critical) Tier 4 — Adaptive Continuous improvement, advanced resilience capabilities

This creates a simple, defensible proportionality model aligned with the structure of NIST CSF and consistent with the principle-based design of DORA.

The Three Lines Model: How Each Line Aligns With DORA and Why Frameworks Help

DORA’s multi-domain structure fits naturally into the Three Lines Model.

First Line: Operational Management (ICT, Ops, Vendor Mgmt.)

Responsible for:

  • operating ICT controls

  • monitoring incidents

  • managing third-party relationships

  • executing resilience tests

  • implementing recovery plans

How NIST CSF helps:
Provides a roadmap of capabilities (GV, ID, PR, DE, RS, RC) that the First Line must operate.

Second Line: Risk and Compliance

Responsible for:

  • defining risk appetite

  • overseeing ICT risk management

  • challenging proportionality

  • monitoring third-party risk

  • ensuring governance integration

How NIST CSF helps:
Provides maturity criteria to assess whether First Line controls match inherent risk.

Third Line: Internal Audit

Responsible for:

  • independent assurance

  • reviewing proportionality

  • validating governance and oversight

  • assessing completeness and accuracy of reporting

How NIST CSF helps:
Gives IA a neutral, structured basis for evaluating capability and maturity — beyond binary RTS criteria.

A Shared Understanding Is Essential for DORA Success

With the designation of CTPPs now in effect, the supervisory landscape is evolving rapidly.

However, true resilience — the kind DORA intends — depends on consistent interpretation across ICT, Risk, Compliance, Internal Audit, external assessors and the management body.


Achieving that requires:

  • recognising that DORA is enterprise-wide, not ICT-only

  • using RTS as detailed guidance, not as standalone checklists

  • applying internationally recognised frameworks such as NIST CSF 2.0 for structure and maturity

  • adopting a clear, defensible proportionality method

  • aligning each of the Three Lines of Defence to shared expectations


This approach creates clarity, reduces friction, strengthens governance, and ensures that financial entities can confidently demonstrate digital operational resilience — not just compliance.