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.
“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.