Martin BeckerSecurity19 min read
Cloud Email Archiving: Security, Sovereignty, and Compliance

Cloud Email Archiving: Security, Sovereignty, and Compliance

Cloud-based email archiving has become the default choice for organizations replacing ageing on-premises infrastructure. The operational case is compelling: no hardware to maintain, predictable per-seat pricing, automatic scaling, and off-site redundancy without a second data centre. For most organizations, the question is no longer whether to move archiving to the cloud, but which cloud, under which legal framework, and with which contractual protections.

Those questions are not procurement formalities. For CISOs, IT Directors, and Data Protection Officers, they carry direct legal exposure. The cloud service model shifts data outside the organization's direct control, and European law imposes specific obligations that determine where archived email can be stored, under what conditions it can be accessed by foreign governments, and what rights you retain when you want to leave your provider.

This article works through the regulatory framework systematically: GDPR international transfer rules, the EU Data Act's new switching rights, NIS2 security requirements for cloud providers, and encryption baselines. It closes with a practical assessment of why EU-based infrastructure materially reduces compliance burden.

Data Sovereignty: Where Are Your Archived Emails Stored?

Data sovereignty refers to the principle that data is subject to the laws of the jurisdiction in which it is physically stored and processed. For email archives, which routinely contain commercially sensitive correspondence, personal data of employees and customers, and legally privileged communications, the jurisdiction of storage is a compliance variable with direct consequences.

The question "where is my data stored?" has three distinct layers that must each be answered:

Physical location of storage. Which data centres hold the data, and in which countries? Cloud providers operating globally maintain data centres across multiple regions, and without explicit contractual restrictions, data may be replicated across jurisdictions as part of availability architecture.

Legal jurisdiction of the provider. A cloud provider incorporated in the United States is subject to US law regardless of where its data centres are located. The Cloud Act 2018 permits US authorities to compel US-incorporated providers to produce data stored in foreign data centres, including EU facilities, subject to the provider challenging the order under the Act's comity review process. An EU-incorporated provider operating exclusively EU infrastructure is not subject to this regime.

Subprocessor chains. Most cloud services rely on subprocessors for infrastructure components - CDN, monitoring, backup, support tooling. Each subprocessor may introduce additional jurisdictions. Data processing agreements must identify all subprocessors and their locations.

For regulated industries - financial services, healthcare, legal, public sector - these questions are not optional. Sector-specific regulation in many EU member states imposes explicit data residency requirements. German public sector bodies, for example, face sovereignty requirements under state-level IT security policies that in practice require EU-incorporated providers operating EU infrastructure.

Even outside regulated industries, the growing corporate governance expectation from enterprise customers is that personal data and commercially sensitive archives remain within EU jurisdiction. The argument that US adequacy decisions resolve the issue is addressed in the next section - it is more qualified than commonly assumed.

GDPR Articles 44-49: International Transfers and What They Actually Require

Chapter V of the GDPR governs transfers of personal data to third countries. Articles 44-49 establish a framework that applies whenever personal data leaves the European Economic Area - which includes any situation where a cloud provider with US or other non-EEA incorporation processes EU personal data, regardless of server location.

The Transfer Prohibition and Its Exceptions

Article 44 establishes the baseline: transfers to third countries are only permitted where the conditions of Chapter V are met. The permitted mechanisms are:

Adequacy decisions (Article 45). The European Commission may decide that a third country ensures an adequate level of data protection. Adequacy decisions currently in force include decisions for the UK, Switzerland, Japan, South Korea, New Zealand, Israel, and several others. The EU-US Data Privacy Framework (DPF) received an adequacy decision from the Commission in July 2023.

Standard Contractual Clauses (Article 46(2)(c)). The Commission's 2021 SCCs provide a contractual mechanism for transfers where no adequacy decision exists, or as a supplement to adequacy decisions. They impose obligations on the data importer regarding security, access by public authorities, and data subject rights.

Binding Corporate Rules (Article 47). Available for intragroup transfers where an enterprise group has implemented consistent data protection rules approved by a lead supervisory authority.

Article 49 derogations. Narrow exceptions including explicit consent, contract performance, and vital interests. These are not suitable for systematic, ongoing archiving operations.

The EU-US Data Privacy Framework: Adequate but Conditional

The EU-US DPF adequacy decision means that US organizations self-certified under the DPF can receive EU personal data without SCCs. However, three qualifications matter for cloud archiving decisions.

First, DPF certification is voluntary and self-attestation-based. Controllers transferring data to US providers must verify that the specific provider is actually certified and maintains active certification. The DPF certification list is public and should be checked at contract signing and periodically thereafter.

Second, the DPF has a political risk dimension. Its predecessor frameworks - Safe Harbour (invalidated in Schrems I, C-362/14, 2015) and Privacy Shield (invalidated in Schrems II, C-311/18, 2020) - were both struck down by the CJEU following legal challenges. A third challenge to the DPF is already before the courts. Organizations that have built compliance architectures on the assumption that DPF adequacy is permanent are taking a legal risk that EU-based infrastructure eliminates entirely.

Third, even with DPF adequacy, US surveillance law remains in place. Foreign Intelligence Surveillance Act (FISA) Section 702 permits collection of communications involving non-US persons from US electronic communications service providers. The DPF includes commitments from the US government on proportionality and a Data Protection Review Court for EU individuals, but it does not remove the legal authority for collection - it layers review mechanisms over it. For organizations with high-sensitivity archives, this distinction matters.

Standard Contractual Clauses: Not a Free Pass

Where SCCs are used as the transfer mechanism - or as a supplementary safeguard alongside DPF - the Schrems II judgment imposes a transfer impact assessment (TIA) obligation. Controllers must assess, prior to transfer, whether the legal framework of the destination country permits the data importer to comply with the SCCs in practice.

A TIA for a US-based cloud provider processing EU email archives must address US surveillance law, the Cloud Act, and the practical likelihood that the provider could be compelled to produce data. Where the TIA concludes that effective compliance is not possible without supplementary measures, encryption with keys held exclusively by the EU controller is the primary technical measure cited by the EDPB's Recommendations 01/2020.

This creates a specific architectural requirement: if archived email is processed by a US-incorporated provider, end-to-end encryption with EU-controlled keys is not merely good practice - it is the technical supplement that makes the transfer lawful. Controllers that rely on SCCs with a US cloud provider and do not implement key control are in a legally uncertain position.

EU Data Act: Switching Rights and Protection Against Unlawful Access

Regulation (EU) 2023/2854 (the EU Data Act) entered into force in January 2024 and has been applying in phases since September 2025. It introduces two categories of requirements directly relevant to cloud email archiving decisions.

Chapter IV: Switching Rights and Vendor Lock-In

Chapter IV of the EU Data Act establishes mandatory switching rights for cloud customers. The core obligations on cloud service providers are:

Removing barriers to switching (Article 25). Providers may not impose technical, contractual, financial, or commercial barriers that hinder a customer's ability to switch to a different provider or port data to an on-premises environment. This includes contractual clauses that make switching economically prohibitive or technically complex without legitimate justification.

Data portability and interoperability (Article 26). Providers must ensure that all data - including data generated through use of the service, configuration data, and metadata - can be exported in interoperable formats. For email archives, this means archived messages, retention metadata, search indices, and access logs must be exportable in standard formats on request.

Switching assistance (Article 26(4)). Providers must offer adequate technical and organizational assistance to facilitate switching, including maintaining the previous service in parallel during a transition period where technically feasible.

Zero egress charges from September 2027 (Article 25(2)). From September 2027, cloud providers must not charge for data egress when a customer switches providers or ports data out of the service. Until that date, charges must be reduced to cost-level only from September 2025.

For organizations evaluating cloud archiving providers, the EU Data Act's switching provisions establish a legal floor that applies to all providers operating in the EU market. However, practical compliance varies. The safest procurement approach remains contractual specificity: require data export in documented formats (MBOX, EML, PST with defined metadata schemas), define transition assistance obligations, and test export procedures before committing to a provider.

Chapter V: Protection Against Unlawful Third-Country Government Access

Chapter V of the EU Data Act addresses the specific risk that non-EU governments may attempt to access cloud data through extraterritorial legal demands targeting the cloud provider rather than the data controller.

Article 32 requires cloud providers to take all reasonable legal and technical measures to prevent international transfer or governmental access to non-personal data held in the EU where such transfer or access would conflict with EU or member state law. Where a legally binding non-EU government access request is received, the provider must attempt to obtain review or suspension of the order, and must notify the cloud customer before complying where notification is not prohibited by law.

Article 33 establishes that where a provider is prohibited from notifying the customer, the provider must inform the relevant EU supervisory authority and maintain records of such orders.

For email archives containing personal data, GDPR Chapter V operates in parallel as a stronger protection regime. The EU Data Act provisions are additive, extending similar protections to non-personal data (business correspondence contents may not constitute personal data once pseudonymised or anonymised, but metadata typically retains its personal character).

The practical takeaway: an EU-incorporated provider operating exclusively EU infrastructure is not subject to US Cloud Act demands - there is no US nexus. This is not merely a contractual or procedural protection; it is a structural elimination of the legal route through which foreign governments most commonly seek access to cloud-stored business data.

NIS2 Implementing Regulation: Security Requirements for Cloud Providers

Commission Implementing Regulation (EU) 2024/2690, which entered into force in January 2025, specifies binding technical and organisational security requirements for a defined set of entity types under NIS2, including cloud computing service providers, data centre services, managed service providers, and managed security service providers.

The Implementing Regulation is directly binding on these entity types without national transposition. For cloud email archiving specifically, several requirements have direct implications.

Multi-Factor Authentication

Article 3 of the Implementing Regulation requires that access to systems used to provide the covered service must be protected by multi-factor authentication at all privileged access points. For cloud archiving platforms, this encompasses administrative consoles, API access with elevated permissions, and access to backup and key management infrastructure.

When evaluating a cloud archiving provider's compliance, MFA requirements should be assessed not only for customer-facing interfaces but for provider-side administrative access to the underlying infrastructure. A provider that implements MFA for customer login but allows single-factor access for infrastructure administrators presents a supply chain security risk.

Cryptographic Requirements

The Implementing Regulation requires that data at rest and in transit be protected using current cryptographic standards. ENISA's NIS2 Technical Implementation Guidance (June 2025) maps these requirements to specific algorithms:

  • AES-256 for data at rest
  • TLS 1.3 as the expected standard for data in transit, with TLS 1.2 acceptable with appropriate cipher suite restrictions where legacy systems require it
  • RSA-2048 or ECDSA P-256 as minimums for asymmetric operations, with preference for P-256 or stronger

For email archives, cryptographic requirements apply at multiple layers: the transport channel between the customer's email server and the archive ingest endpoint, the storage of messages within the archive, backups of archive data, and key management infrastructure.

Incident Detection and Logging

The Implementing Regulation requires covered entities to maintain logging and monitoring capabilities sufficient to detect security incidents and support incident investigation. For cloud archiving providers, this translates to requirements for:

  • Comprehensive access logging at the archive level, recording every retrieval, search, and export with authenticated user identity and timestamp
  • Infrastructure-level security logging retained for a minimum period aligned with ENISA's 12-month recommendation
  • Anomaly detection capabilities that can identify unusual access patterns - for example, bulk export attempts or access from unexpected geographic locations

These requirements also inform what customers should demand contractually: the right to receive access logs for their archive data, assurance that the provider's security logging covers the infrastructure supporting their service, and notification obligations if the provider detects a security incident affecting customer data.

Supply Chain Security

Article 7 of the Implementing Regulation requires covered entities to implement supply chain security measures, including assessment of the security practices of direct suppliers and service providers. For cloud archiving providers, this means documented assessment of the security of their infrastructure subcontractors - data centre operators, network providers, and software components.

For customers, this requirement creates a transparency obligation on the provider side. Data processing agreements should require the provider to maintain an up-to-date list of subprocessors, to conduct periodic security assessments of subprocessors, and to notify customers of material changes to the subprocessor chain.

Encryption at Rest and in Transit: Minimum Standards

Encryption is the primary technical control that determines the practical security of an email archive regardless of where it is hosted. The distinction between provider-managed encryption and customer-managed encryption is critical for sovereignty and compliance purposes.

Provider-Managed Encryption

The default model for most cloud services is that the provider manages encryption keys. The provider encrypts data at rest using keys stored in a key management service the provider controls. Customers benefit from encryption against third-party attackers who might breach the provider's storage layer, but the provider itself - and anyone with legal authority over the provider - can access the plaintext.

This model is adequate for many threat models and satisfies the baseline technical requirements of GDPR Article 32 and NIS2. However, it does not address the scenario where the provider is compelled to produce data by a foreign government, because the provider holds the keys required to produce readable data.

For organizations whose threat model includes foreign government access - public sector bodies, defence contractors, legal services firms, financial institutions, healthcare providers - provider-managed encryption is insufficient.

Customer-Managed Encryption Keys

Under a customer-managed key (CMK) model, the customer holds the master key material and the provider cannot decrypt data without the customer's active involvement. Architecturally, this typically means the customer operates a key management service (a hardware security module or cloud KMS in a jurisdiction the customer controls) and the provider's system fetches a session key for each operation.

A CMK model means that even if the provider receives a legally valid government access demand, it cannot produce readable message content - it can only produce encrypted data that requires the customer's key to decrypt. If the key is held in an EU-controlled KMS, a US Cloud Act demand against a US provider cannot yield readable content.

The EDPB's Recommendations 01/2020 on supplementary measures explicitly identifies "encryption by the data exporter prior to transmission to the data importer" with keys exclusively under the exporter's control as a technically effective supplementary measure for US-destination transfers under SCCs.

Minimum Cryptographic Standards for Compliant Archiving

Drawing together the GDPR Article 32 adequacy requirement, ENISA NIS2 guidance, and ISO 27001:2022 Annex A control A.8.24 (use of cryptography), the minimum baseline for a compliant cloud email archive is:

  • AES-256 for stored message content and attachments
  • TLS 1.3 for all data-in-transit paths (ingest, retrieval, API, administrative access)
  • Documented key management procedures covering key generation, storage, rotation, and destruction
  • Separate encryption of index data and metadata from message content where the archive exposes search functionality to provider-side infrastructure
  • Annual review of cryptographic standards against current ENISA and BSI guidance (the BSI's Technical Guideline TR-02102 is the authoritative German reference)

Providers should be able to produce documentation of their cryptographic implementation on request. Vague commitments to "industry-standard encryption" without specification of algorithm, key length, and key management architecture are not adequate for a compliance assessment.

Choosing EU-Based Infrastructure: Compliance Advantages

The compliance arguments for EU-based cloud archiving infrastructure are not primarily about marketing positioning. They translate to concrete reductions in legal exposure and compliance workload.

No Chapter V Transfer Analysis Required

Where the cloud provider is incorporated in an EU member state and operates exclusively EU data centres, no Chapter V GDPR analysis is required. There is no transfer, therefore no need for an adequacy decision, SCCs, or TIA. This eliminates the single most time-consuming element of GDPR compliance for cloud procurement - the transfer impact assessment - and removes the ongoing monitoring obligation triggered by the DPF's uncertain legal durability.

No US Cloud Act Exposure

An EU-incorporated provider with no US nexus - no US parent, no US-incorporated subsidiaries, no US infrastructure - is outside the jurisdictional reach of the Cloud Act. Foreign access demands would need to go through mutual legal assistance treaty (MLAT) processes, which are slower, subject to EU judicial review, and typically limited to serious criminal investigations. The structural elimination of Cloud Act exposure is not replicated by contractual provisions or encryption alone - it requires the absence of a US legal nexus.

Alignment with Sector Regulation

For organizations in regulated sectors, EU-based infrastructure simplifies regulatory conversations. German public sector bodies operating under the BSI IT-Grundschutz framework, healthcare organizations under the DSGVO-Anwendungshinweis, and financial institutions under DORA's ICT third-party risk provisions all face regulators who are increasingly explicit about EU infrastructure preferences. Demonstrating that archived email never leaves EU jurisdiction is a simpler compliance position than explaining adequacy decisions, TIA findings, and encryption supplementary measures to a supervisory authority.

GDPR Accountability Documentation

Article 5(2) GDPR requires that controllers be able to demonstrate compliance with the GDPR's principles - the accountability principle. Where EU-based infrastructure is used, the documentation burden for the data transfer compliance component is minimal: a record that no transfer occurs, and the contractual documentation of EU data processing. Compared to maintaining a current TIA for a US provider, tracking DPF certification status, and documenting SCCs, this is substantially simpler.

Subprocessor Management

EU-based providers that confine their infrastructure to EU data centres have a materially simpler subprocessor chain from a data transfer perspective. When evaluating subprocessors, the relevant question is whether any subprocessor introduces a non-EU jurisdiction. A provider operating AWS EU regions, Azure EU regions, or dedicated EU data centres must still assess whether the US-incorporated parent company of those cloud platforms creates a transfer - a nuanced question. A provider operating dedicated EU infrastructure through EU-incorporated data centre operators eliminates this ambiguity.

Choosing a Cloud Email Archiving Provider: Compliance Checklist

For CISOs and DPOs evaluating cloud archiving solutions, the following checklist covers the compliance-critical questions derived from the frameworks discussed above.

Data sovereignty:

  • Where are data centres located? Are all processing locations within the EEA?
  • Is the provider incorporated in an EU member state?
  • Does the provider have any US-incorporated parent, subsidiary, or infrastructure provider that could create a Cloud Act nexus?
  • What is the complete subprocessor list, and are all subprocessors EU-based?

GDPR transfer compliance:

  • If any transfer occurs, what is the legal mechanism (adequacy decision, SCCs, BCRs)?
  • Has a transfer impact assessment been conducted for any non-EEA subprocessors?
  • Are SCCs included in the data processing agreement, or only referenced?

EU Data Act switching rights:

  • In what formats can the full archive be exported (messages, metadata, retention data)?
  • What is the export process and timeline? Has it been tested?
  • What transition assistance does the provider contractually commit to?
  • What are the egress charges, and how do they align with the EU Data Act schedule?

NIS2 and security:

  • Is the provider a covered entity under NIS2 or the Implementing Regulation (EU) 2024/2690? If so, can they demonstrate compliance?
  • Is MFA mandatory for all access paths, including provider administrative access?
  • What encryption algorithms are used for data at rest and in transit?
  • Are customer-managed keys available?
  • What access logging is provided to customers, and for how long are logs retained?
  • What is the incident notification timeline for security events affecting customer data?

ISO 27001:

  • Is the provider ISO 27001:2022 certified? For which scope?
  • When was the last certification audit? Is the certificate publicly verifiable?

EasyMailArchive: EU-Hosted Cloud Archiving Built for Compliance

EasyMailArchive is hosted exclusively in EU data centres and operated by an EU-incorporated entity, eliminating GDPR Chapter V transfer analysis and Cloud Act exposure for your email archive.

The platform implements AES-256 encryption at rest and TLS 1.3 in transit for all archived data. Every message is stored with cryptographic integrity protection, providing the tamper-proof audit trail required for NIS2 incident response and regulatory inspections. Access to the archive is fully logged - every search, retrieval, and export - with logs retained and available to customers.

On switching rights, EasyMailArchive supports standard EML and MBOX export formats with full metadata, designed to satisfy EU Data Act Chapter IV portability requirements and to give customers genuine control over their data at every stage of the relationship.

For organizations that need to demonstrate EU data sovereignty to regulators, enterprise customers, or their own board, the combination of EU infrastructure, EU corporate structure, and documented compliance with GDPR Article 28 data processing requirements provides a defensible compliance position without the complexity of transfer mechanisms and supplementary measures.

If you are currently assessing your cloud archiving options - or reviewing an existing provider arrangement against the requirements discussed in this article - start a free trial to evaluate how EasyMailArchive integrates with your email infrastructure and what compliance documentation we can provide for your DPA or regulatory file.

Marketing: with your consent we pass the click id of a ChatGPT or Google ad and the start of your trial from our server to OpenAI (USA) and Google (Ireland/USA). No ad scripts, no ad cookies. Legal basis: consent (Art. 6(1)(a), Art. 49(1)(a) GDPR, § 25 TDDDG). Privacy Policy