8 min read

How to meet DORA compliance

With its abundance of transactions and data exchanges, the financial sector has always been a prime target for cyber-attacks. 

Bolstering the resilience and security of financial entities across the European Union, the Digital Operational Resilience Act (DORA) is a crucial regulatory framework designed to ensure that organizations are both protected and prepared for potential security incidents. 

DORA seeks to augment the digital operational resilience of financial entities through a series of stipulations and requirements, thereby safeguarding and ensuring the robustness of the entire financial system.

What is the Digital Operational Resilience Act (DORA)?

DORA, or Regulation (EU) 2022/2554, represents a shift in how EU financial entities manage operational risk and resilience. Prior to DORA, financial institutions primarily managed major operational risk categories through capital allocation, without an encompassing management of all operational resilience components. 

DORA introduces new rules pertaining to the protection, detection, containment, recovery, and repair capabilities against ICT related incidents. It meticulously outlines regulations concerning ICT risk management, incident reporting, operational resilience testing, and ICT third-party risk monitoring.

DORA applies across all EU Member States, making compliance mandatory from 17th January 2025.

Who does DORA apply to?

As stated in Article 2, DORA applies to all financial entities in all EU Member States. 

The Regulation defines financial entities in a broad and self-inclusive way. The financial institutions mentioned include, but are not limited to: 

  • Credit institutions
  • Payment institutions
  • Investment firms
  • Trading venues
  • Data reporting service providers
  • Insurance and reinsurance undertakings
  • Insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries.

The relationship between the NIS 2 Directive and DORA

In September 2023, the Commission unveiled guidelines clarifying the overlap between the NIS 2 Directive and DORA with the purpose of guiding entities on their regulatory commitments. 

When sector-specific rules (such as DORA) provide cybersecurity protocols that are the equivalent to, or stronger than, those in the NIS 2 Directive, these specific regulations take the lead. For entities not encompassed by such specific regulations, the NIS 2 Directive remains applicable. 

A central tenet of these guidelines is the emphasis on the 'all-hazard approach', advocating for comprehensive safeguards against a broad spectrum of both digital and physical threats. Designed specifically for the financial sector, DORA's detailed provisions are set to supersede the NIS 2 Directive, prompting Member States to sidestep imposing overlapping regulations on these financial entities.

Protecting data under DORA

Article 9 of DORA, titled ‘Protection and prevention’, places great importance on the robust security and proper functioning of ICT systems within financial entities. Organizations must continually monitor systems, with a focus on minimizing the risk impact through the adoption of fit for purpose ICT security tools, policies, and procedures. 

DORA requires institutions to design and employ ICT security measures that:

  • Ensure the security of the means of transfer of data
  • Minimize the risk of corruption or loss of data, unauthorized access and technical flaws that may hinder business activity
  • Prevent the lack of availability, impairment of the authenticity and integrity, breaches of confidentiality and the loss of data
  • Ensure data is protected against risks arising from data management, including poor administration, processing-related risks, and human error.

Furthermore, entities are mandated to put in place a comprehensive ICT risk management framework. As part of this framework, financial entities must:

“implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes”

Is your email secure according to DORA?

Our most relied upon method of communication and data sharing, email is inherently insecure and poses some great challenges in meeting regulations such as DORA. 

Standard email traffic is not encrypted, making it susceptible to interception and unauthorized access. As a result, email does not guarantee the confidentiality of sensitive data. 

While the TLS protocol was designed to bolster email security through encryption, it is essentially optional and depends on the configurations of both the sending and receiving servers. If misconfigured, emails are sent unencrypted. TLS provides encryption without ensuring that the email is relayed to the correct server, leaving it open to Man-in-the-Middle attacks. 

The DANE protocol offers a solution to this by authenticating email servers using DNSSEC. However, its global adoption is less than 50%. Critically, even if DANE is universally adopted, it doesn't ascertain the actual sender or the authorized reader of the email. The lack of two-factor authentication (2FA) for email only amplifies this risk. While 2FA is a common security measure in many services, it is rarely implemented in email communication, leading to potential unauthorized access and data breaches, and falling short of DORA's stringent security mandates.

How to meet DORA compliance

Organizations can enhance their email clients with intuitive, secure-by-design solutions to meet the requirements of DORA. Here’s how: 

  1. Human error prevention: Email alone does not prevent the leading causes of data loss incidents - human error. Mistakes including misuse of Bcc, incorrect recipients, or the accidental disclosure of sensitive data to the wrong person regularly see data end up in the wrong hands. Powered by machine learning, data loss prevention tools, embedded into email clients, can alert employees to potential mistakes, enabling the them to take action to correct errors or encrypt emails before they hit 'send'.   
  2. Securing data in transit: Email lacks the required encryption protocols to ensure data is protected in transit. With the application of advanced, zero-access encryption tools, users can protect every email ensuring it is shielded from potential interceptions and unauthorized access.
  3. 2FA: It's a familiar protocol to all of us and now it must be applied to email. With 2FA, users can utilize single use codes and passwords to ensure emails are accessed by only the intended recipient. 
  4. Mistake mitigation: In the instance that a mistake is made or an employee needs to gain control over an email containing sensitive data, users must be able to recall it, or set expiration controls in accordance with company policies. Access to data to identify who has opened emails also allows users to identify if data incidents have occurred or avoided.
  5. Striking the balance between usability and security: Employees will only use tools they want to use; ensuring they understand the benefits of a solution, as well as making it easy to use (through seamless integration with their existing productivity and communication tech) means they are far more likely to utilise it!

As data regulations and frameworks continue to evolve, financial institutions must fortify their email security to ensure compliance, and protect their clients, employees, and reputations.

The DORA framework underscores the pressing need for enhanced digital resilience in the financial sector, and demonstrates the security vulnerabilities in our digital communications platforms. It’s time to enhance email with the introduction of advanced security solutions.

Find out how Zivver can empower your organization to align with stringent EU regulations, including DORA, and prevent the leading causes of data incidents. Get in touch to learn more.

First published -
Last updated - 09/04/24
Free demo
Free demo
Free demo

Ready for a deeper dive? So are we.