DORA Compliance: What Changes for Financial IT Providers

A regional bank’s IT provider called me in February: ‘Are we subject to DORA?’ They had 12 employees and managed the infrastructure for three credit institutions. The answer was yes. This scenario is not isolated. Many small and medium-sized IT companies operating in the financial sector are navigating a rapidly evolving regulatory landscape, often without full awareness of the impacts. The Digital Operational Resilience Act (DORA), effective from January 17, 2025, is not just another bureaucratic directive. It represents a radical shift in how banks, insurance companies, and their IT providers manage cyber risk and operational continuity. The goal is to strengthen the digital operational resilience of the European financial sector, ensuring that ICT disruptions do not compromise financial stability.

DORA Compliance: Who is Truly Subject to the Regulation

DORA extends its reach far beyond directly regulated financial institutions (banks, insurance companies, funds, etc.). The regulation explicitly includes third-party ICT service providers offering services to these entities. This means if your company provides software, cloud services, network connectivity, data centers, or any other technological service that supports the critical functions of a bank or insurance company, you are subject to DORA. Your company’s size is irrelevant; the critical impact of the service provided is the determining factor.

According to a Financial Stability Board analysis, cyber incidents in the financial sector increased by 10% year-on-year in 2024, with an average cost of €18 million per breach (FSB, 2025). DORA aims to mitigate these risks.

ICT providers are classified as ‘critical’ or ‘non-critical’ depending on the potential impact a failure could have on the financial entity. This classification is crucial because critical providers will be subject to direct monitoring by European authorities (ESAs).

The Chain of Responsibility: From CIO to Third-Tier Cloud Provider

One of DORA’s most significant innovations is the extension of responsibility. Financial entities can no longer fully delegate ICT operational risk to their providers. The ultimate responsibility remains with the financial entity, which must ensure its providers meet the same resilience standards. This directly impacts Service Level Agreements (SLAs) and requires continuous due diligence.

This means a bank’s CIO or CISO must have visibility and control not only over direct providers but also over sub-providers. If your cloud service relies on a third-party data center, that data center also falls within the DORA chain of responsibility. Mapping the ICT supply chain therefore becomes a fundamental exercise.

Example of a DORA-compliant contractual clause that will be required:

contract_clauses:
  - clause_id: "DORA-ICT-001"
    description: "Obligation of compliance with DORA Regulation (EU) 2022/2554 for ICT services provided."
    requirements:
      - "Implementation of a DORA-compliant ICT Risk Management Framework."
      - "Notification of severe ICT incidents within established timelines (4 hours)."
      - "Participation in digital operational resilience testing (e.g., penetration testing).">
      - "Right of access, inspection, and audit for the financial entity or designated third parties."
      - "Exit strategy and data portability plans in case of service termination."

ICT Risk Management: What Providers Must Document

ICT service providers, especially critical ones, must implement a robust ICT risk management framework. This includes identifying, classifying, protecting, detecting, responding to, and recovering from ICT incidents. DORA requires detailed documentation of all these activities, including:

Policies and procedures for ICT risk management.
Mapping of ICT assets and critical dependencies.
Business Impact Analysis (BIA) and risk assessment.
Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP) regularly tested.
Data backup and restoration strategies.
Security awareness programs for staff.

The lack of adequate documentation can result in non-compliance and penalties, in addition to compromising a company’s ability to obtain or retain contracts with financial entities. A PwC report from 2024 indicated that only 35% of IT SMEs serving the financial sector had a mature ICT risk framework (PwC, 2024).

Incident Reporting: The 4 Hours That Change Everything

This is one of DORA’s most stringent aspects. ICT service providers detecting a severe incident must notify the financial entity within a maximum of 4 hours from initial detection. Subsequently, intermediate and final notifications are required. This compels providers to have proactive monitoring systems, 24/7 incident response teams (CSIRT or SOC), and clear, rapid communication processes.

To manage these timelines, it is essential to implement SIEM/EDR solutions that automate event detection and correlation, along with incident response playbooks that guide the team step-by-step. Automation is key to meeting DORA’s deadlines.

Example of pseudo-code for an automated notification system:

import datetime

def notify_dora_incident(incident_id, severity, description, affected_systems):
    timestamp = datetime.datetime.now()
    message = f"DORA Incident Notification - ID: {incident_id}, Severity: {severity}"
    message += f"\nDescription: {description}"
    message += f"\nAffected Systems: {', '.join(affected_systems)}"
    message += f"\nTimestamp: {timestamp}"

    # Log the incident internally
    log_incident(incident_id, message)

    # Send notification to financial entity (e.g., via API, secure email)
    send_secure_email(financial_entity_contact, "DORA Incident Alert", message)

    print(f"Incident {incident_id} notified to financial entity.")

# Example usage (triggered by SIEM alert)
# notify_dora_incident(
#     incident_id="DORA-2026-001",
#     severity="CRITICAL",
#     description="Major network outage affecting core banking services",
#     affected_systems=["CoreBanking-DB", "OnlineBanking-API"]
# )

Critical Third Parties: The IT Supply Chain Challenge

DORA places particular emphasis on managing critical third parties. Financial entities must identify these third parties, assess associated risks, and implement adequate mitigation measures. For ICT providers, this means expecting audits, inspections, and requests for detailed information on their security and operational resilience.

Furthermore, DORA requires contracts with critical third parties to include specific clauses guaranteeing the financial entity’s right to monitor compliance, conduct tests, and, if necessary, initiate exit plans. This impacts contract negotiation and the need for unprecedented transparency regarding one’s security posture. I don’t have a definitive answer on how smaller providers will handle the auditing requirements, as this is still being clarified by national authorities.

How to Prepare if You are an ICT Provider for Financial Entities

DORA compliance is not an option but a requirement for operating in the financial sector. Here are the key steps to prepare:

Gap Analysis: Conduct a thorough assessment of your current ICT risk management capabilities, operational resilience, and incident response processes against DORA requirements.
Supply Chain Mapping: Identify all your dependencies on third parties and sub-providers, evaluating their criticality level.
Contractual Update: Review and update your contracts with financial entities and your sub-providers to include DORA-specific clauses.
ICT Risk Management Framework: Implement or strengthen a robust ICT risk management system, documenting policies, procedures, and controls.
Incident Response: Develop and test incident response plans, ensuring you can meet the 4-hour notification deadlines. Invest in SIEM/EDR, automation, and team training.
Resilience Testing: Actively participate in digital operational resilience tests required by financial entities, including penetration testing and stress tests.
Training: Ensure all relevant personnel are trained on DORA requirements and ICT security procedures.

Common Errors and Troubleshooting

The most common error I have encountered is underestimating DORA’s impact on small and medium-sized enterprises. Many assume it only concerns cloud giants or large banks. However, a small software provider managing a critical accounting application for a bank is equally involved.

Another mistake is not integrating DORA with other existing regulations like GDPR or NIS2. Although they have different focuses, there are many synergies. For example, a good incident response plan for GDPR can serve as a basis for DORA, but with tighter deadlines and specific requirements for ICT incidents.

Troubleshooting: If you realize you are behind on compliance, the first action is a rapid gap analysis and identification of critical providers. In parallel, initiate transparent dialogue with your financial clients to understand their expectations and timelines. Often, it is possible to define a joint remediation plan.

FAQ — Frequently Asked Questions

What is the difference between DORA and NIS2?

NIS2 applies to a broader range of sectors and focuses on the security of network and information systems. DORA is specific to the financial sector and focuses on digital operational resilience, with more detailed requirements for ICT risk management, incident reporting, and third-party management. There are overlaps, but DORA is more prescriptive for financial entities and their ICT providers.

Does DORA apply to non-European ICT providers?

Yes, the DORA regulation has extraterritorial reach. If an ICT provider is based outside the EU but provides services to financial entities within the EU, it is subject to DORA requirements. This is a crucial aspect for global providers and their European clients.

What are ‘critical ICT services’ under DORA?

Critical ICT services are those whose disruption could have a significant impact on the continuity of a financial entity’s essential functions, its financial stability, or market confidence. Classification depends on the risk assessment conducted by the financial entity and supervisory authorities.

What are the penalties for DORA non-compliance?

Specific penalties will be established by individual national competent authorities, but DORA stipulates that they can be significant and proportionate to the severity of the violation. In addition to fines, non-compliance can lead to contract termination and severe reputational damage. For official details, refer to the Official Journal of the European Union for DORA Regulation (EU) 2022/2554.

Conclusions with Operational Takeaways

DORA is a challenge but also an opportunity. For IT providers, it means significantly raising security and resilience standards, becoming even more reliable partners for the financial sector. Do not wait until January 17, 2025: preparation requires time and resources. Start immediately with a gap analysis, map your dependencies, and strengthen your ICT Risk Management and incident response processes. Proactivity will set you apart in the market, ensuring the continuity of your services and the trust of your clients.

Updated: June 2026