How financial institutions can comply with DORA using M365

The Digital Operational Resilience Act (DORA), or Regulation (EU) 2022/2554, is a critical regulation in the EU designed to bolster the cybersecurity infrastructure of the financial sector. 

With the increasing reliance on digital communication, particularly email, the need for stringent security measures is paramount. DORA entered into force on 16 January 2023 and will apply as of 17 January 2025, and demands robust security protocols to ensure the resilience and integrity of email systems.

As such, financial entities across the EU are reassessing their cybersecurity strategies to ensure they meet the requirements of the new legislation, including evaluating the capabilities of existing tools such as Microsoft 365 (M365). In the context of DORA, financial institutions must recognise the limitations of M365 to adequately protect sensitive information via email, and explore supplementary solutions for email data protection.

Email encryption and M365

DORA mandates organizations to:

“ensure the security of the means of transfer of data’, ‘implement [..] strong authentication mechanisms, based on relevant standards’ and ‘protection measures [..] whereby data is encrypted based on results of approved data classification and ICT risk assessment processes”.

Email, in its default state, does not come with built-in encryption or authentication features. To ensure secure transmission of emails, it's essential to implement transport encryption and verify the email server of the recipient. 

One method to achieve this is through DANE (DNS-based Authentication of Named Entities), widely regarded as the most secure email protocol. While Microsoft 365 (M365) currently supports DANE, it falls short in providing an alternative security protocol when DANE is unavailable at the recipient's end. This is also the case when using alternatives such as TLS or MTA-STS. 

This limitation in M365 means that organizations are faced with a dilemma: they must either send emails with reduced security, risking non-compliance with DORA and the security of their information, or risk having emails rejected and returned, disrupting communication flows. Consequently, this can lead to crucial messages not being securely or promptly delivered, adversely affecting both business operations and compliance with regulatory requirements.

Approved data classification under DORA

DORA stipulates that data protection must be based on ‘approved data classification’. However, setting up automatic classification in M365 can be complex. Plus, M365’s limited classification tools rely primarily on basic methods such as word matching and regular expression (regex) patterns, methods that are insufficient for effective classification due to their inability to accurately identify and categorize the nuanced and varied types of sensitive information typical in the financial sector.

Automated processing of emails

Utilizing Purview Message Encryption for sending emails, either manually or through a DLP-rule, also presents challenges. If a recipient responds to an encrypted message, their reply is also encrypted using Purview Message Encryption. However, systems employed by many large organizations for automatic message processing (e.g. Salesforce) are incompatible with these encrypted responses. 

Consequently, established workflows are disrupted, and the message must be manually opened, transferred and processed.

Reducing employee compliance risk

DORA's Article 9 emphasizes the importance of preventing sensitive financial data from being unintentionally shared or accessed via email:

“(...) ensuring that data is protected from (...) human error.” DORA Article 9

While M365 does include some data loss prevention (DLP) features, it lacks effective functionalities required to prevent the biggest cause of data leaks: sending the wrong information to the wrong person. 

M365 does not detect unusual sharing patterns by employees, providing only the most basic security functions such as warning users they are ‘sending information outside of (the) organization’. 

Sending emails securely with M365

Beyond these three key limitations, M365 lacks other essential functionalities for preventing data leaks and unauthorized access to emails:

• Recipient multi-factor authentication: NIS2 specifies the need for multi-factor authentication for recipients in certain scenarios, a feature not supported by M365.
• Revoking access to messages: With M365, you can only revoke messages when using Purview Advanced Message Encryption, and only for recipients outside the Microsoft ecosystem.
• Secure file transfer: Purview only supports encrypting messages if file size does not exceed 25MB. Large files are left unencrypted. 
• Zero-access encryption: Purview offers advanced functionality such as Double Key Encryption, however, this cannot yet be applied to email encryption via Outlook.
• Recipient-friendly access: Purview allows easy message access through Microsoft accounts. However, outside of the Microsoft ecosystem, access to encrypted messages is less user friendly. 

Financial institutions can cover these gaps by supplementing M365 with integrated solutions that provide advanced encryption, rigorous authentication protocols, and enhanced DLP capabilities.

Enter Zivver.

Recognized by Gartner, and working in close collaboration with Microsoft, Zivver supports financial institutions to meet their requirements under DORA with seamless integration with M365.

Learn how Zivver fills the security gaps in M365 and empowers financial institutions to meet their compliance regulations with effortless, advanced security tools.