DORA (Digital Operational Resilience Act)

What Are DORA's Five Pillars?

DORA organizes its requirements into five pillars, and the third-party risk pillar spans more articles than any other. Each pillar covers a distinct part of operational resilience:

1. ICT risk management: A framework for identifying, protecting against, detecting, and recovering from ICT risk.
2. Incident management and reporting: Rules for classifying ICT-related incidents and reporting them to authorities.
3. Resilience testing: A testing program that includes threat-led penetration testing for significant entities.
4. ICT third-party risk management: The obligations set out in Articles 28 to 44.
5. Information sharing: A voluntary pillar under Article 45 for exchanging threat intelligence.

Which Organizations Must Comply With DORA?

DORA's Article 2 lists 20 types of financial entities, and it reaches the ICT providers that serve them through contracts and oversight. The in-scope entities span financial services from banking and payments to insurance and market infrastructure, including:

• Banking and payments: Credit institutions, payment institutions, and electronic money institutions.
• Investment and markets: Investment firms, trading venues, central counterparties, and central securities depositories.
• Insurance: Insurance and reinsurance undertakings, along with insurance intermediaries.
• Newer financial services: Crypto-asset service providers and data reporting service providers.

ICT providers fall under DORA in two ways. Every provider serving an in-scope entity inherits contractual obligations, and providers designated as critical come under direct supervision.

What Does DORA Require for ICT Third-Party Risk?

DORA requires financial entities to manage ICT third-party risk inside their ICT risk framework, with specific obligations for documenting, contracting, and exiting provider relationships. The core requirements are:

Register of information 

A continuously maintained record of every ICT third-party contractual arrangement under Article 28(3), submitted to national competent authorities.

Mandatory contract terms

Provisions under Article 30 covering service descriptions, data locations, audit and access rights, exit assistance, subcontracting rules, and termination. Article 30(2) applies to every ICT contract, and Article 30(3) adds further terms for services supporting critical or important functions.

Exit strategies 

Plans under Article 28(8) so a critical service can move to another provider or back in-house.

Concentration risk management

Oversight of cases where several critical functions depend on a single provider.

The Register Feeds Supervisory Designation Decisions

The register doubles as the regulator's map of the sector's dependencies. National authorities had to report financial entities' registers to the European Supervisory Authorities (ESAs) by April 30, 2025. The ESAs used that data to assess which ICT providers should be designated as critical. Gaps in a register carry straight into the picture supervisors use for that decision.

What Are Critical ICT Third-Party Providers Under DORA?

Critical ICT third-party providers (CTPPs) are technology providers the ESAs designate as systemically important to the EU financial sector, which places them under direct EU oversight. Under Article 31, designation weighs the systemic impact of a provider's failure and the systemic importance of the entities that rely on it. It also weighs how much those entities depend on the provider for critical functions and how easily it could be replaced.

In November 2025, the ESAs published the first list of 19 designated CTPPs, including major cloud platforms. Each is supervised by a lead overseer, which is the EBA, EIOPA, or ESMA, with powers to request information, run investigations, and conduct on-site inspections.

Provider Oversight Leaves Customer Duties Intact

ESA oversight of a critical provider doesn't replace the financial entity's own obligations. A bank using a designated cloud provider still has to manage that relationship under DORA itself. Shared dependence on the same few providers is also where concentration risk builds across the sector.

How Does DORA Incident Reporting Work?

DORA requires financial entities to report major ICT-related incidents to their competent authority in three stages, on a clock that starts when an incident is classified as major. Classification weighs criteria such as the number of clients affected, the duration, data losses, geographic spread, the criticality of the services involved, and the economic impact. Once an incident qualifies, the deadlines are:

• Initial notification: Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it.
• Intermediate report: Within 72 hours of the initial notification, with updates whenever the incident's status changes significantly.
• Final report: No later than one month after the latest intermediate report, including the root cause analysis.

DORA also requires major incidents to be reported internally to senior management and the management body.

Provider Incidents Start the Same Clock

Major incidents can start at an ICT provider. A financial entity's four-hour window depends on learning about the provider's incident fast enough to classify it. That's why Article 30 includes provider cooperation during incidents among its contract terms, and why contracts should set provider notification timelines short enough for the entity to meet its own.

What Does DORA Resilience Testing Require?

DORA requires a digital operational resilience testing program, with basic testing every year and threat-led penetration testing (TLPT) every three years for significant entities. TLPT simulates the tactics of real attackers against live production systems. Critical ICT providers are expected to take part when their services are in scope. The European Central Bank updated its TIBER-EU red-teaming framework in January 2025 to align it with DORA's TLPT standards.

What Penalties Does DORA Carry?

Member states set DORA's penalties for financial entities, and the regulation requires them to be effective, proportionate, and dissuasive. Competent authorities can also require remedial action, issue public notices, and impose restrictions on management. For critical ICT providers, the lead overseer can impose periodic penalty payments of up to 1% of average daily worldwide turnover for each day of non-compliance, for a maximum of six months.

How Is DORA Different From NIS2?

DORA is a regulation written for the financial sector, while NIS2 sets cybersecurity requirements across a broader range of sectors. DORA was published as Regulation (EU) 2022/2554, so it applies directly in every member state. As a directive, the NIS2 Directive takes effect through each member state's national law. Both make organizations accountable for the security of the third parties they rely on.

Black Kite's 2026 Europe Cyber Risk Report reads the region's ransomware data through that accountability lens. It found that ransomware incidents from January to April 2026 ran 55.1% above the same months of 2025, and that 64 European organizations were pulled into ransomware or data extortion incidents through a third party.

Where Do DORA Programs Fall Short?

Recurring gaps sit between what a contract or register says and what a financial entity can actually do with it. Practitioner guidance on DORA oversight points to contracts with full audit rights but no working process for requesting an audit. It also points to exit strategies that have never been tested against a realistic migration.

Register reviews surface their own recurring problems, including incomplete legal entity identifiers, missing function identifiers, and subcontractor chains that were never mapped. A complete register still says little about how exposed each provider is. That takes continuously gathered evidence about the providers themselves.

How Does Black Kite Support DORA Third-Party Requirements?

Black Kite supports DORA's third-party requirements with DORA among its built-in assessment frameworks, continuous monitoring of ICT providers, and visibility into the supply chains behind each one. Its custom cyber risk assessment frameworks include DORA among more than 20 built-in frameworks, and an AI-powered parser maps vendor documentation to those controls and flags gaps.

Black Kite's continuous monitoring tracks each provider's cyber posture as it changes. For the supply chain behind each ICT provider, its supply chain risk monitoring maps fourth, fifth, and Nth-party relationships and identifies concentration risk. Black Kite positions that capability for enterprise teams managing DORA compliance.

See also: DORA in 4 Questions: Automate Vendor Compliance