DORA, the Digital Operational Resilience Act, is a new legislation aimed at protecting networks and information systems (e.g., information and communication technology or ICT)in the financial industry. With more expansive supply chain attacks such as the MOVEIt attack that hit European banks such as ING Bank, Postbank, and Comdirect, the European Union sought to strengthen the digital operational resilience of the financial sector within the European Union and mitigate their impact in the future.

Unlike other regulations, however, DORA also requires compliance from third-party providers of EU financial service organizations (or those that have customers in the EU) and their subcontractors.

“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 ability to continue to deliver business continuity was 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, this 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 Compliance: Global vs. EU Perspective

Although DORA focuses on the financial service industry in the EU, it includes organizations that may have headquarters in other geographic regions, but EU customers or third-party service providers. For example, DORA is relevant to organizations dealing with cross-border transactions that process, store or transmit sensitive data of 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.

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
  • banks
  • Insurance companies
  • credit institutions
  • payment institutions
  • electronic money institutions
  • investment firms
  • credit rating agencies
  • crypto-asset service providers
  • central securities depositories
  • trading venues
  • cloud services
  • data centers
  • telecom systems
  • information systems
  • risk management and compliance systems
  • mobile banking applications
  • CMS systems
  • operational and incident management systems
  • cybersecurity systems
  • trading platforms

What are the DORA Compliance Requirements?

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 of 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 a 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 ICT’s, leveraging questionnaires and documentation requests and identify third, fourth and fifth parties which may represent potential concentration risk.
  • Register of information. Categorize third party ICT relationships that support critical and important functions and report them to the Supervisory Authority. Identify third, fourth and fifth parties which 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 cyber security 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.

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?

Although the DORA regulations will only go into effect January 17, 2025, organizations that want to meet compliance by the deadline without suffering consequences should start preparing now.

The amount of preparation you can do, however, is limited, because the details are still being finalized. “In order to send out a DORA third-party security questionnaire, you have to know which security controls DORA requires,” explains Dov Goldman, VP Risk Strategy at Panorays and a third-party risk expert.

In addition, many people are making the reasonable assumption that DORA will align with the European NIS2 directive. Although these directives are more conceptual than practical, it is thought that NIS2’s security controls will reflect an evolution of the nearly universally adopted ISO 27001/2 control framework. In other words, although you can’t fully prepare now, you might end up aligned with at least some of the controls required, with the need for a few adjustments along the way.

“But, there are many ways you can prepare now,” he says.

Creating 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 exactly what are the inherent and material risks of these business relationships.

You must determine the criticality of the provider to the CIFA and the “sensitiveness” of 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 upcoming Shared Assessments 2025 SIG. In addition, assess suppliers’ attack surface to validate questionnaire responses, and to find security control failures.

“Shared Assessments is a member-driven organization known for best practices education and questionnaire content. Their SIG questionnaire library is an excellent source for third-party risk managers charged with ensuring vendor compliance with security control frameworks and regulations,” says Dov. “They plan to release their DORA-mapped SIG 2025 later this year.”

3) Identify fourth and fifth parties and potential concentration risk

Identify your third, fourth and fifth-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.

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 to revenue.

The Major Challenges of DORA Compliance and TPRM

For a number of 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 ICT’s. 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 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.”

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 n-th 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.

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