DORA, the Digital Operational Resilience Act, is the EU regulation designed to strengthen digital operational resilience across the financial sector. It requires financial entities and many of their ICT third-party providers to improve how they manage cyber risk, monitor vendors, report incidents, test resilience, and document critical ICT relationships.

For many organizations, DORA compliance is not just about meeting a regulatory deadline. It is about building an ongoing operational resilience strategy that covers third-party risk, ICT governance, testing, incident response, and documentation. In this guide, we break down the core DORA requirements and cover related topics such as the Register of Information, questionnaires, gap analysis, vulnerability management, and vendor risk management.

“The financial entity must fully monitor the ICT subcontracting chain and document it.”

– JC 2023 67 27 November 2023 Consultation Paper on Draft Regulatory Technical Standards

Why is DORA Needed?

The DORA regulation was a response to a few different evolutions in the financial industry. First, the 2018 financial crisis demonstrated the need for better resilience against both financial and operational risk. For example, financial services did not have strong disaster recovery plans in place in the event of a cybersecurity or other type of disaster, and they could not handle the spike in trades during the crisis. Second, these financial services were increasingly relying on the outsourcing of services and third parties, making them much more vulnerable to cyberattacks and security incidents. The lack of effective disaster recovery plans and the ability to continue to deliver business continuity were especially true of ICT-related services. Finally, the integration of new technologies such as cryptocurrency, mobile payments and cloud technologies introduced more vulnerabilities into supply chains. 

In the past, Information and Communication Technologies (ICT) risks were managed through different financial supervisors in different member states, leading to inconsistency, duplicated rules and ineffective results. A more unified approach was necessary to both address new technologies and better manage and monitor third-party risks.

Key Objectives of DORA

This unified approach was developed with several goals in mind: 

  • Strengthening operational resilience. Financial services must be better prepared in the event of a cyberattack or other disaster. This includes requiring operational resilience testing annually of ICT tools and subsequent reports and remediation plans to be shown to the relevant authorities. 
  • Faster incident reporting. Financial services are required to report any incidents to the proper authorities according to the timeline of the relevant geographic authority. Since DORA unifies the approach to incident reporting, it enables a faster flow of information to meet these deadlines.  
  • More effective third-party risk management. DORA requires ICT risk management to become a core feature of EU-centered financial services’ business strategy, governance and operational execution. This is a holistic rather than a separate approach.
  • Improve cybersecurity measures. DORA requires financial services to implement practices such as encryption, multi-factor authentication and the sharing of threat intelligence within the community.

DORA’s Global Impact Beyond the EU

Although DORA focuses on the financial service industry in the EU, it also affects organizations headquartered outside the region if they serve EU customers or support EU financial entities through third-party services. For example, DORA is relevant to organizations dealing with cross-border transactions that process, store or transmit sensitive data belonging to EU customers. This is particularly relevant for cryptocurrency providers outside the EU and other organizations that rely on ICT providers for new technologies such as AI and cloud computing. In addition, non-EU-based companies must work with EU-based organizations to meet deadlines regarding incident reporting and to quickly detect and mitigate cybersecurity incidents that impact EU organizations.

For a deeper look at how DORA affects global organizations, cross-border providers, and multinational vendor ecosystems, read our article on DORA’s global impact.

Which Organizations Must Comply with the DORA Requirements?

The regulation lists 21 types of financial services organizations defined together by three different European supervisory authorities: the EBA (European Banking Authority), EIOPA (European Insurance and Occupational Pensions Authority), and ESMA (European Securities and Markets Authority).

Here are examples of the types of financial services and ICT third-party service providers that must comply with DORA:

Who Needs to Meet DORA Compliance?

Financial service entitiesICT third-party service providers
BanksCloud services
Insurance companiesData centers
Credit institutionsTelecom systems
Payment institutionsInformation systems 
Electronic money institutionsRisk management and compliance systems
Investment firmsMobile banking applications
Credit rating agenciesCMS systems
Crypto-asset service providersOperational and incident management systems
Central securities depositoriesCybersecurity systems
Trading venuesTrading platforms

DORA Compliance Requirements: The Five Core Areas

There are five areas of compliance that DORA covers. Although the overarching goal of these requirements is to strengthen the operational resilience of financial services organizations in the European Union, it is also to build greater trust in the financial institutions of that region as well.

The five areas include:

1) ICT Risk Management and Governance

Financial service organizations will be expected to adopt a risk management framework for their ICT technologies. This should include the mapping of all ICT systems as well as the relationship between systems, assets and providers.

Proactive risk management policies should be considered, such as data governance and protection. Risk management should also include the implementation of technical tools such as firewalls, encryption technologies, and the regular identification and patching of security vulnerabilities. This should also involve the development of a disaster recovery and backup plan for preparation in the event of an attack.

The risk management framework adopted by the organization must also include a strategy for implementing third-party ICTs.

2) ICT Incident Reporting and Response

“Financial entities shall define, establish, and implement an ICT-related incident management process to detect, manage, and notify ICT-related incidents.”

– DORA Regulation

Financial service organizations must put proper systems in place to monitor, report, classify, manage and log ICT-related incidents. However, the details on exactly how this should be done are a work in progress. The European Supervisory Authority (ESA) may even create a new body to standardize the manner in which financial service organizations put these systems into place. When relevant, financial service organizations must report incidents to the supervisory authorities in their respective countries.

3) Continuous Digital Operational Resilience Testing

The ICTs must be tested to evaluate their resilience and determine whether any optimization is necessary. These tests should be done on a regular basis to ensure that your cybersecurity posture assessment is as current as possible.

These tests include:

  • Vulnerability assessment testing. At a minimum, annual assessments should be conducted to determine any risk posed by the ICT systems. 
  • Threat-led penetration testing (TLPT). The standards for TLPT are still being determined, but will most likely be based on an EU framework of threat-intelligence-based ethical red team testing known as TIBER-EU. DORA increases the requirements for TLPT to additional financial services organizations than previously required. 
  • ICT-risk assessments. Regular identification of risks in an organization’s ICT systems that includes assessment of the business impact of operational disruption from different scenarios. Based on the results, they can set their risk tolerance accordingly. 
  • Scenario-based testing. Evaluate how ICT systems respond to different scenarios, such as operational disruptions and cybersecurity attacks, through red team testing.

4) ICT Third-party Risk Management

“Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system, which enables them to address ICT risk quickly, efficiently and comprehensively and to ensure a high level of digital operational resilience.”

– DORA, Article 6(1)

Third-party services are also required to adhere to all DORA standards. That means that financial service organizations must enforce contracts with their third parties so that they comply with the six pillars of DORA third-party risk management:

  • ICT-risk management framework. In practical terms, this might be the adoption of an ISMS (Information Security Management System), a security control framework similar to ISO 27001/2.
  • Strategy for managing third-party risk. The framework should designate third-party ICT services that support critical functions, determine the criticality and “sensitiveness” of the data shared, and identify the ICT service in the terms DORA requires. It should also assess the ICTs, leveraging questionnaires and documentation requests, and identify third, fourth, and fifth parties that may represent potential concentration risk.
  • Register of information. Categorize third-party ICT relationships that support critical functions and report them to the Supervisory Authority. Identify third, fourth, and fifth parties that may represent potential concentration risk.
  • Exit strategy. Plan how a third-party relationship should end while also ensuring the resiliency of your business, whether or not that third party fails or succeeds.
  • Contractual provisions. Enforce the implementation and operation of the security controls required by DORA through the terms of your contracts with third-party ICTs.
  • Incident reporting. When required, breaches and other cybersecurity incidents must be reported to the relevant Supervisory Authority. Reports are required depending on the financial impact, duration of the attack, its effect on operational disruption, and the number of users affected.

In the future, the ESA may either recommend or require a standardized contract to ensure DORA compliance with third parties.

5) Information and Intelligence Sharing

This final area of DORA compliance isn’t required, but strongly encouraged. It also isn’t unique to DORA, but encouraged in many regulations. Sharing intelligence and information related to threats, however, is one of the best methods for strengthening security not only in your organization but across the entire supply chain.

For a more detailed breakdown of each pillar, read our guide to the five pillars of DORA compliance.

What are the Penalties for DORA Non-Compliance?

Penalties for DORA non-compliance include fines of up to 2% of the organization’s annual revenue, and continue to pay penalties until they comply. The total fine is dependent on the scale of the violation and how willing the financial service organization is to cooperate with the relevant authorities.

In addition, organizations that fail to meet DORA compliance may suffer reputational repercussions and lose potential business. In some instances, they may be asked to stop operations as a result of non-compliance.

When Will the DORA Regulations Go into Effect?

The DORA regulations officially went into effect on January 17, 2025. Because the regulation is now live, financial entities and ICT third-party service providers must be in full compliance to avoid significant penalties.

While the primary framework and major Regulatory Technical Standards (RTS) are finalized, DORA is designed to be dynamic. Organizations must remain vigilant as supervisory authorities continue to issue updated guidance on emerging threat-led penetration testing (TLPT) scenarios and evolving incident reporting templates. Compliance is no longer a “preparation” phase but an active, ongoing operational requirement that includes maintaining a live Register of Information and performing regular resilience testing.

How to Build a DORA Compliance Checklist for TPRM

Here’s how you can get started with a DORA compliance checklist in just a few steps:

1) Identify and categorize third-party ICTs

Many organizations aren’t fully aware of which third-party ICT providers they rely on for critical and important functions, and what the inherent and material risks of these business relationships are.

You must determine the criticality of the provider to the CIFA and the “sensitivity” of the data they will process. With this information, you can tier your third parties according to their inherent risk. At the same time, identify and categorize each third-party ICT according to the DORA Register of information data points.

2) Assess your third parties

Evaluate third-party ICTs for compliance with the DORA security control requirements. A good way to do this will be with questionnaire content derived from the Shared Assessments 2025 SIG. In addition, assess suppliers’ attack surface to validate questionnaire responses and to find security control failures.

3) Identify fourth and fifth parties and potential concentration risk

Identify your third, fourth, and Nth-party digital technology relationships, which may be suppliers and subcontractors (and even suppliers to the subcontractors). This should be done regularly as supply chains are dynamic. 

With a third-party risk management platform such as Panorays, you can also deliver questionnaires to suppliers that gather information about the inherent risk of each supplier. These questionnaires also help specify the DORA “rank” of the supplier, enabling optimal cybersecurity monitoring and reporting. In addition, Panorays reports identify concentration risk in the supply chain as well.

4) Register of Information

If you’ve performed all of these steps thoroughly, you’ll be well prepared to report on your third-party ICTs in the required DORA Register of Information format to your regulator, the Supervisor Authority. Warning: You will be expected to identify subcontractors and their suppliers (commonly known as fourth and fifth parties) and the concentration risk they present to your business.

To go deeper on reporting requirements, see our guide to the DORA Register of Information.

5) Prepare for incident reporting

Map the different threats and cybersecurity events to your digital supply chain so that you are alerted to potentially significant risks to your business as early as possible. You’ll know which third parties to communicate with, even if the event occurred at the fourth or fifth party level, and avoid hefty fines, reputational damage, and potential loss of revenue.

If your focus is third-party oversight, see our guide to DORA vendor risk management for practical steps financial institutions can take.

Common DORA Compliance Challenges in TPRM

For several reasons, a DORA-compliant organization must map out third, fourth, and fifth parties supporting critical and important functions (CIFA), even if only indirectly.  

After doing so, they’ll still have additional obstacles to overcome:

  • Understanding the potential concentration risk. DORA specifically addresses the subcontractors of ICT third-party providers who supply a critical or important function to the organization. “You must map out concentration risk, such as a fourth party providing hosting services for multiple third-party ICTs. This can be challenging, as third parties may not report all of their subcontractors, or may change subcontractors without informing you. Worse, it is even more difficult to know who the fifth parties are,” says Dov.
  • The ability to report incidents quickly. “Not only is it challenging to manage the concentration risk in three different layers (third parties, subcontractors, and subcontractors’ suppliers), but it’s also difficult to report incidents in a timely fashion, because you may not even be aware that the affected company is in your supply chain.”

For a broader view of how DORA fits alongside other major frameworks, read our guide to DORA, NIS2, and GDPR through centralized third-party risk management.

How Panorays Can Help You Manage Third-Party Risk

Panorays comprehensive cybersecurity assessments deliver the best business-contextual detection of security risk in the digital supply chain. In addition, the Panorays “Risk DNA” process helps to categorize and analyze third, fourth, and fifth parties that play a role in supporting your critical and important functions.

Its platform modules include:

  • Supply Chain Discovery and Mapping. Gain visibility of your full threat landscape by detecting hidden third, fourth and Nth parties in your supply chain.
  • Risk DNA Assessments. Combine and cross-match internal and external assessments, breach history and AI-based risk prediction with business impact and risk appetite to get the most accurate, holistic cyber risk rating that evolves based on the unique properties of each third-party relationship.
  • Continuous Threat Detection. Get early indications of breaches and vulnerabilities from a wide variety of integrated threat intelligence sources, prioritized according to criticality.
  • Remediation and Collaboration. Generate customized security plans for each vendor based on critical findings, ratings, important questions and business impact. Then calculate the least number of steps and effort to reach the desired level of protection, focusing on the most critical tasks first.

For a deeper look at specific DORA topics, explore these related guides from Panorays:

Want to learn more about how Panorays can help you manage third-party risk and prepare you for DORA compliance? Get a demo today.