All Azure Technologies @ one Place

This article delves into the crucial distinction between the physical location of your data and the legal authority permitted to access it. These are separate issues, and conflating them can lead to compliance complications down the line.

Understanding Key Concepts: Data Residency vs. Data Sovereignty

Data residency pertains to location, whilst data sovereignty concerns authority. A service provider may guarantee that your data remains within the EU but still be subject to external jurisdiction. Thus, location should not be confused with control.

The Controversy: The US CLOUD Act

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a federal law enacted in the USA in 2018. It grants US law enforcement the right to compel American tech companies to release data held overseas, irrespective of its actual location. Importantly, this pertains to “American companies.” If your service provider is incorporated in the United States, the CLOUD Act applies to their data centres everywhere, including those in Frankfurt, Amsterdam, and Dublin.

This means that when companies like Microsoft, Google, or Amazon assure you that your data remains within the EU, they share a truth about its location while omitting nuances about jurisdiction. The data is indeed stored in the EU, yet a US warrant can still reach it.

What the CLOUD Act enables: US authorities can issue warrants to US-based providers for data stored abroad without the need for cooperation from the respective country, bypassing local judicial review, and without notifying impacted users or EU regulators. This completely circumvents Mutual Legal Assistance Treaties (MLATs).

The GDPR Implications

Article 48 of the GDPR explicitly states that court orders from third countries (like the US) can only facilitate the transfer of EU personal data if acknowledged through an international agreement such as an MLAT. Since the CLOUD Act operates without MLATs, it is unilateral.

This poses a real legal conundrum for enterprises relying on US-based cloud providers:

• ⚖️Comply with a US warrant. The provider releases the data, but the organisation risks facing enforcement actions under GDPR for the unauthorised transfer of data to a third country.
• ⚖️Refuse a US warrant. The provider could face repercussions in the US, yet large providers seldom refuse.
• ⚖️Utilise the “quash or modify” clause. This allows providers to contest warrants that conflict with foreign laws, but this option is complex, discretionary, and rarely exercised.

The European Data Protection Board has made it clear that service providers bound by EU law cannot transfer data to the US based solely on CLOUD Act requests. However, while GDPR safeguards individual data rights, it does not directly tackle what the US government may require from a US company. The gap between these jurisdictions is where sovereignty truly resides.

Microsoft’s Initiatives

To their credit, Microsoft has taken heed of these issues. Over recent years, they have introduced tangible technical and contractual measures to address sovereignty concerns. It’s crucial to understand these innovations as they represent real progress in a challenging area, although they do not fully resolve the CLOUD Act’s implications.

The EU Data Boundary

Microsoft’s EU Data Boundary is a commitment to store and process customer and personal data for their enterprise online services (Azure, Dynamics 365, Power Platform, and Microsoft 365) within EU and EFTA countries. EFTA nations include Switzerland, Norway, Iceland, and Liechtenstein, alongside the 27 EU member states.

By February 2025, this will encompass:

• ✅Data at rest and in processing. Your actual stored content resides within EU/EFTA data centres.
• ✅Pseudonymised system-generated logs. All personal data in operational logs must be pseudonymised prior to leaving the EU Data Boundary. This includes techniques like encryption, masking, tokenisation, and data blurring.
• ✅Professional Services Data at rest. Data from consulting and support engagements is stored within this boundary.

Important Note: The EU Data Boundary has documented exceptions. Certain situations may necessitate transferring Customer Data beyond the established boundary. Microsoft provides detailed information regarding these exceptions on the EU Data Boundary documentation site. It is essential for architects to review the specific services they utilise, as the coverage may vary across Azure capabilities.

Microsoft Cloud for Sovereignty

The EU Data Boundary addresses residency concerns, while Microsoft Cloud for Sovereignty tackles the broader sovereignty issues, presented in three tiers:

The Sovereign Landing Zone (SLZ) is a reference architecture provided by Azure, equipped with policies aligned with sovereignty from the start. If you’re designing a sovereign-compliant environment on Azure, start with the SLZ rather than building governance from scratch.

Operational Access Controls

Microsoft has committed to strict controls regarding who can access your data for operational purposes. For European Microsoft Cloud services, operational access requires approval from European personnel, with all access tracked in tamper-evident logs. Additionally, customers can manage their own encryption keys through hardware security modules, ensuring that even Microsoft cannot decrypt data without consent from the customer.

This is significant—if Microsoft cannot technically access your data, fulfilling a CLOUD Act warrant demanding that data becomes much more complicated. “We cannot access it” forms a strong technical defence, beyond just a contractual promise.

Evaluating Claims: Marketing vs. Reality

Several major US cloud providers now advertise offerings branded with “sovereign.” It’s vital to clarify what these actually entail, as the term is often broadly interpreted and deserves careful examination.

• □Microsoft 365 EU Data Boundary. A genuine commitment to data residency in EU/EFTA. Coupled with customer-managed keys and European operational access approvals, this offering stands out among US hyperscalers. Although the CLOUD Act still applies at the corporate level, these technical controls mitigate practical access.
• □Amazon European Sovereign Cloud. AWS has launched a European Sovereign Cloud aimed at operating separately from AWS commercial operations, with data stored in Germany and managed by EU employees. Though it alters the operational landscape, the parent company is still a US entity, leaving the CLOUD Act questions unresolved.
• □“Sovereign cloud” as a marketing expression. This term often appears alongside architectures that haven’t fundamentally changed. Data residency within an EU data centre operated by a US company without customer-managed encryption or distinct operational control only addresses data residency—it lacks true sovereignty from a legal standpoint.

Sovereignty is not merely a marketing tagline; it is a legal fact. If your provider is under US jurisdiction, your data may not be secure, even when stored within the EU. Wire Security Blog, July 2025

Implications for Azure Architects

When designing solutions in Azure for public sector clients within the EU, as well as regulated industries or those requiring strict sovereignty, it’s clear that the framework has advanced but still necessitates careful design choices. Here are some guiding principles:

• □Use customer-managed keys for sensitive workloads. If Microsoft cannot access your data, the CLOUD Act’s leverage is considerably weakened. Implement Azure Key Vault with customer-managed keys, or Bring Your Own Key (BYOK) stored on hardware security modules to ensure compliance.
• □️Utilise the Sovereign Landing Zone for stated sovereignty requirements. Avoid custom governance designs from scratch. The SLZ provides pre-configured Azure Policies for alignment with sovereignty, regional restrictions, and operational controls. Start here and adapt it to your regulatory context.
• □Review the EU Data Boundary exceptions pertaining to your services. Not all Azure services are equally covered. Verify specific services’ data practices with Microsoft’s EU Data Boundary documentation before making claims to clients regarding data locations.
• □Consider a Sovereign Private Cloud for classified or intensely regulated contexts. If the demand is for “no US entity to be compelled to access this data,” the enhanced controls of the public cloud may not suffice. An Azure Local deployment in a national facility, or a national partner cloud operated by a non-US entity, will better meet that requirement.
• □Understand the implications of MLATs. When faced with a US legal request, EU organisations should refer the matter through the Mutual Legal Assistance Treaty process, which involves EU judicial supervision and complies with GDPR safeguards. Familiarise yourself with this process before an urgent situation arises.

Good news for Azure architects: The available tools have genuinely improved. Features like customer-managed keys, European operational access approvals, tamper-evident logs, the EU Data Boundary commitment, and the Sovereign Landing Zone collectively form a robust architecture for most regulated EU workloads. The combination of technical controls and contractual commitments has strengthened since 2020. Although the CLOUD Act remains in effect, its practical reach has been curtailed for organisations that design their architecture thoughtfully.

Final Thoughts

Digital sovereignty is an area where terminology can breed unwarranted confidence. Phrases like “EU Data Boundary” may appear definitive, and “Microsoft Cloud for Sovereignty” might suggest that all gaps have been closed. However, the reality is more nuanced.

The CLOUD Act is a concrete constraint. It hasn’t been abrogated, and the EU-US Data Privacy Framework, which serves as a replacement for Privacy Shield, has already encountered legal challenges. Organisations that rely on their provider’s marketing assurances to resolve jurisdictional issues are potentially exposing themselves to risk.

Conversely, dismissing Microsoft’s sovereign cloud efforts as mere marketing fails to appreciate their tangible progress. Initiatives like customer-managed encryption, separate operational control, and the EU Data Boundary commitment are technical assurances that reshape what is feasible under legal demands.

The critical perspective for architects is: leverage existing tools, understand their capabilities and limitations, and tailor the architecture to meet genuine regulatory needs. For most commercial EU workloads with GDPR responsibilities, a combination of the EU Data Boundary, customer-managed keys, and the Sovereign Landing Zone will position you defensively. For scenarios involving government or classified data, where the requirement is total avoidance of foreign jurisdiction, resorting to a national partner cloud or private deployment by a non-US operator is necessary. This latter requirement demands different architectural considerations.