DORA and Email Compliance for Financial Services

The Digital Operational Resilience Act (Regulation (EU) 2022/2554, known as DORA) has applied directly across all EU Member States since 17 January 2025. For financial services organisations, DORA is not a future obligation to be planned for. It is current law, and supervisory authorities have begun scrutinising compliance postures.

Email infrastructure sits at the intersection of several DORA requirements. It is a critical information asset, it is frequently delivered via third-party SaaS providers, and its failure or compromise qualifies as an ICT-related incident subject to mandatory classification and reporting. This article examines what DORA requires, where email systems are implicated, and how a well-implemented email archiving programme supports the resilience posture DORA demands.

Scope: Who Is Covered

DORA applies to a broad set of financial entities as defined in Article 2. The list includes:

Credit institutions (banks and savings institutions)
Payment institutions and e-money institutions
Investment firms, UCITS management companies, and AIFMs
Insurance and reinsurance undertakings
Crypto-asset service providers
Central counterparties and trade repositories
Credit rating agencies and audit firms (for systemic-risk purposes)
ICT third-party service providers designated as critical under Articles 31-44

The Regulation applies to entities authorised and operating within the EU. For groups with non-EU parents, EU-regulated subsidiaries fall within scope regardless of where their ICT systems are physically operated.

Smaller entities benefit from a proportionality principle under Article 4: competent authorities may apply requirements in a simplified form to certain categories. However, the core obligations on ICT risk management, incident reporting, and third-party risk apply to all in-scope entities.

Article 6-16: ICT Risk Management and Email as a Critical Information Asset

Chapter II of DORA establishes the ICT risk management framework. Article 6 requires financial entities to have in place a comprehensive ICT risk management framework as an integral part of their overall risk management system. That framework must be documented, approved at board level, and reviewed at least annually.

Email is a critical information asset. Article 8 requires financial entities to identify all ICT assets (hardware, software, data, and third-party services) and map their dependencies. The identification must cover the complete information asset inventory and classify assets according to their criticality. Business email, whether self-hosted or delivered via a SaaS provider, is a primary communication channel for client instructions, transaction confirmations, regulatory filings, and internal governance. Its unavailability or compromise directly affects business functions that DORA treats as critical.

Protection requirements under Article 9 include the implementation of ICT security policies covering confidentiality, integrity, and availability of all information assets. For email, this translates to requirements for encryption, access controls, and anti-tampering measures. An email archiving system that preserves messages with cryptographic integrity, preventing deletion or modification after storage, directly supports the integrity and availability requirements of Article 9.

Backup and recovery under Article 12 is particularly relevant. DORA requires financial entities to have in place backup policies specifying the frequency of backups, the nature of data covered, storage location, and recovery time objectives. Article 12(1) is explicit: backups must be tested. Article 12(4) requires that backup copies are stored in a location physically and logically separate from primary systems. Email archives that are independent of the primary mail server satisfy this separation requirement and provide the recovery capability DORA mandates.

Logging and audit trail requirements under Article 9(4)(h) require financial entities to implement mechanisms that generate logs and enable detection and reconstruction of ICT events. An email archive creates an immutable, searchable log of all email communications, supporting both post-incident forensic investigation and the continuous monitoring DORA requires.

DORA Article	Requirement	Email Relevance
Art. 8	ICT asset identification and classification	Email must be catalogued as a critical information asset
Art. 9	ICT security policies - confidentiality, integrity, availability	Email encryption, access controls, tamper-proof storage
Art. 12	Backup policies and recovery testing	Email backup independent of primary mail server
Art. 9(4)(h)	Log generation and audit trail	Immutable email archive as an event log
Art. 13	Business continuity plans covering ICT	Email availability as a continuity requirement

Articles 28-30: Third-Party Risk and Mandatory Contractual Provisions

A substantial portion of financial entities deliver email via third-party SaaS providers. Whether that is Microsoft 365, Google Workspace, or a specialist email archiving service, DORA imposes specific obligations on the financial entity as the contracting party.

Article 28 establishes the framework for managing ICT third-party risk. Financial entities must maintain a register of all ICT third-party service providers and must document the contractual arrangements with each. Where a function supported by a third party qualifies as critical or important, the entity must notify its competent authority.

Is email archiving a critical or important function? Under Article 28(3), a function is critical or important if its disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or compliance with applicable law. Email retention for regulatory purposes (including the retention of client communications required by MiFID II, MAR, and EMIR) falls directly within that definition. Regulators have made clear that the loss of client communication records is a serious compliance failure. Email archiving that supports those obligations should be classified as critical.

Article 30 sets out the minimum content of contractual arrangements with ICT third-party service providers. For email archiving SaaS agreements, the following provisions are now legally required:

A clear and complete description of all functions and services to be provided, specifying whether subcontracting of critical functions is permitted and, if so, on what conditions
The locations where functions are performed and where data is processed, including the storage location of all data (the contract must identify the specific jurisdictions in which email data is stored)
Provisions on availability, authenticity, integrity, and confidentiality of data, including data at rest and in transit
Full access, inspection, and audit rights for the financial entity, its competent authorities, and the European Supervisory Authorities; a right to audit your email archiving provider must be contractually guaranteed
Service level agreements specifying response and resolution times for ICT incidents
Requirements on the ICT third party to assist the financial entity in the event of an ICT incident related to the services provided
Termination rights and exit strategies including data portability; the contract must ensure that archived email data can be exported and migrated on termination without unreasonable delay or cost

For financial entities currently operating under legacy email archiving contracts, a compliance review against Article 30's minimum content list is a practical starting point. Contracts that predate DORA's entry into force and do not contain these provisions will require renegotiation or replacement.

Articles 31-44: Critical ICT Third-Party Provider Oversight

Chapter V establishes an EU-level oversight framework for ICT third-party providers that are designated as critical. Designation decisions are made jointly by the three European Supervisory Authorities (EBA, ESMA, and EIOPA), applying criteria set out in Article 31, including the number of financial entities relying on the provider, the systemic importance of those entities, and the substitutability of the service.

An email archiving provider serving a significant portion of EU financial institutions could in principle be designated as a critical ICT third-party provider. In practice, the initial designations under DORA have focused on large cloud infrastructure providers, but the framework is designed to expand as the ESA joint oversight mechanism matures.

For financial entities, the practical implication of Articles 31-44 is due diligence on provider concentration. Article 29 requires entities to assess concentration risk in their ICT third-party arrangements. Reliance on a single provider for both primary email delivery and email archiving creates a concentration risk that competent authorities will scrutinise. A purpose-built archiving solution that is operationally independent of the primary email platform reduces that concentration and supports a defensible ICT risk management posture.

Chapter III (Articles 17-23) establishes DORA's incident management and reporting regime.

Article 17 requires financial entities to define and implement an ICT-related incident management process. Incidents must be classified according to criteria including the number of clients or counterparties affected, the duration of the incident, the geographic spread, the criticality of affected services, and the economic impact.

Email incidents fall squarely within this framework. The following scenarios require classification and potential reporting:

Extended unavailability of email systems affecting client communication
Unauthorised access to email accounts or the email archive
Ransomware encrypting or destroying email data including the archive
Accidental or deliberate deletion of archived communications required for regulatory compliance
Data exfiltration from the email archive

Article 19 establishes the mandatory reporting timeline for major ICT-related incidents to competent authorities. The reporting follows a three-stage structure: an initial notification within four hours of classifying the incident as major (or at most 24 hours from awareness), an intermediate report within 72 hours, and a final report within one month of resolution.

An email archive supports this reporting obligation in two ways. First, it provides the forensic record needed to reconstruct the incident timeline: what messages were sent, when, to whom, and what they contained. Second, the archive itself is evidence that the entity maintained the records required for regulatory compliance, demonstrating ongoing operational resilience.

Article 20 requires financial entities to report significant cyber threats to competent authorities even where no incident has materialised. A targeted phishing campaign against an institution's email infrastructure, for example, qualifies as a significant cyber threat. The email archive provides the evidence base for assessing the scope and impact of such threats.

Digital Operational Resilience Testing

Chapter IV (Articles 24-27) requires financial entities to establish a comprehensive programme of digital operational resilience testing.

Article 24 mandates a risk-based testing programme covering ICT tools and systems. At a minimum, entities must conduct annual vulnerability assessments and testing of ICT systems supporting critical functions.

Article 25 requires advanced testing through threat-led penetration testing (TLPT) for significant financial entities. TLPT must cover production systems and must be performed by qualified testers following the TIBER-EU framework.

Email infrastructure, including archiving systems, should feature in resilience testing programmes. Relevant test scenarios include:

Failover to backup email infrastructure following primary server failure
Recovery of archived messages within the timeframes defined in the ICT business continuity plan
Access to the email archive following a primary system compromise, confirming that the archive remains available and unaffected
Data portability testing confirming that archived messages can be exported and imported into an alternative system within acceptable recovery time objectives

Article 26 requires financial entities to maintain documentation of all tests performed and their results, and to address identified vulnerabilities. Test results and remediation actions for email resilience testing should be incorporated into the entity's ICT risk management documentation.

How Email Archiving Supports DORA Compliance

A purpose-built email archiving solution maps directly onto DORA's requirements across multiple articles:

Immutability and integrity. DORA's Article 9 requirement for integrity controls is met by archives that use write-once storage or cryptographic hashing to prevent modification or deletion of archived messages after storage. This also supports MiFID II Article 16 and MAR Article 11 obligations to preserve client communication records in their original form.

Availability and resilience. An archive that is operationally independent of the primary mail server, hosted on separate infrastructure in a geographically distinct location, satisfies both DORA's Article 12 separation requirement and provides a recovery path when primary email systems are unavailable. In a ransomware incident affecting the primary mail platform, the archive remains accessible.

Audit trail and forensics. DORA requires financial entities to be able to reconstruct ICT events for post-incident analysis. An email archive with complete indexing and audit logging provides the forensic foundation for incident investigation, regulatory reporting, and civil or criminal proceedings arising from email-related incidents.

Third-party risk management. An email archiving provider that offers contractual compliance with Article 30's mandatory provisions (documented SLAs, audit rights, data localisation guarantees, and exit provisions) simplifies the financial entity's third-party risk documentation and supports regulatory examination readiness.

Incident response support. When a major incident under Article 19 triggers a 24-hour reporting clock, having an indexed, searchable archive of all communications accelerates the investigation and reduces the time needed to prepare the initial notification. Without an archive, reconstructing the timeline of a complex incident from fragmented mail server logs is slow and incomplete.

Concentration risk mitigation. Operating an archiving system that is independent of the primary email provider, rather than using the same vendor's built-in archiving feature, reduces the concentration risk that Article 29 requires financial entities to assess and manage.

DORA Requirement	Archiving Capability
Art. 9 - Integrity controls	Immutable, tamper-proof message storage
Art. 12 - Backup and recovery	Independent archive with RTO/RPO documentation
Art. 9(4)(h) - Audit trail	Full index of all messages with access logs
Art. 19 - Incident reporting	Forensic evidence base for incident reconstruction
Art. 28-30 - Third-party risk	Article 30-compliant contract provisions
Art. 24-25 - Resilience testing	Testable failover and data portability
Art. 29 - Concentration risk	Provider independence from primary mail platform

DORA does not operate in isolation. Two further frameworks impose overlapping obligations on email infrastructure in financial services.

NIS2 (Directive (EU) 2022/2555) applies to financial entities as essential entities under Annex I. NIS2 Article 21 requires essential entities to implement risk-management measures covering incident handling, business continuity, supply chain security, and network security. These requirements parallel DORA's ICT risk management framework. The European Commission has noted that for financial entities, DORA constitutes a lex specialis to NIS2, meaning DORA's more specific requirements take precedence, but NIS2 fills any gaps. In practice, a DORA-compliant email resilience posture will satisfy the equivalent NIS2 requirements for the same systems.

GDPR continues to apply in full. Email archives containing personal data of clients, employees, or counterparties must be operated with a valid lawful basis: typically Article 6(1)(c) for archives mandated by financial regulation, and Article 6(1)(f) for archives maintained for litigation preparedness. Retention periods must be defined and enforced, data subject rights must be managed, and appropriate technical measures including encryption must be in place. DORA's Article 9 security requirements and GDPR's Article 32 security requirements are mutually reinforcing: a system compliant with one is likely compliant with both.

Practical Steps for Compliance Officers

The following actions address DORA compliance for email infrastructure specifically:

Classify email in your ICT asset inventory. Article 8 requires it. Assess whether email and email archiving qualify as critical or important functions given your entity's regulatory obligations for communication retention.
Review third-party contracts against Article 30. Audit current email and archiving vendor agreements for the mandatory provisions. Where contracts are deficient, initiate renegotiation. Document the review and its findings.
Assess concentration risk. Under Article 29, document whether your email archiving is operationally independent of your primary email platform. If the same provider delivers both, assess the concentration risk and consider mitigation.
Define email as a critical system in your ICT business continuity plan. Article 13 requires continuity plans for critical ICT systems. Define recovery time objectives and recovery point objectives for both primary email and the archive.
Include email infrastructure in your resilience testing programme. Article 24 requires annual testing. Design test scenarios that verify archive availability and data portability following primary system failure.
Map email incidents to your Article 17 classification criteria. Ensure your incident management process explicitly covers email-related incidents and that classification criteria are applied consistently.
Maintain ROPA entries that reflect DORA's classification. GDPR accountability and DORA's documentation requirements both require accurate records of processing. Ensure your ROPA identifies the regulatory basis for email retention and the security measures applied.

How EasyMailArchive Supports Financial Services DORA Compliance

EasyMailArchive is built for organisations that need a secure, compliant, and auditable email archive independent of their primary mail infrastructure:

Tamper-proof, immutable storage using AES-256 encryption and write-protected archives, satisfying Article 9's integrity requirements and MiFID II's record preservation obligations
EU-only hosting with documented data localisation, enabling the Article 30 contract provisions that require identification of data storage jurisdictions
Contractual audit rights included as standard, meeting the Article 30 requirement that financial entities retain audit access to ICT third-party providers
Configurable retention policies with automated deletion on expiry, supporting both DORA's Article 8 asset management and GDPR storage limitation
Full audit logging of all access, searches, and exports for forensic reconstruction of ICT events under Article 9(4)(h)
Data portability and export in standard formats, supporting Article 30 exit provisions and resilience testing under Article 24
Operational independence from primary mail platforms, reducing the ICT concentration risk that Article 29 requires financial entities to document and manage

Financial services compliance teams can request a DORA compliance assessment and demonstration of how EasyMailArchive addresses the specific requirements of Articles 6-16, 28-30, and the incident reporting framework.