GDPR in the Cloud: A Complete Guide for Microsoft Azure and Dynamics

GDPR and Cloud Act: understanding legal issues

The GDPR in a nutshell: the key principles for the cloud

The General Data Protection Regulation (RGPD, EU Regulation 2016/679) imposes a strict framework for any processing of personal data of European residents. Its fundamental principles (legality of processing, data minimization, purpose limitation, security by design) fully apply in the cloud.

In this context, several articles are particularly applicable:

• Articles 44 to 50 regulate data transfers outside the EU: they are not prohibited, but require appropriate guarantees.
• Article 28 defines the obligations of the subcontractor vis-à-vis the data controller that you are.
• Article 32 imposes technical and organizational security measures that are proportionate to the risk.

When you use Dynamics 365 to manage your customer data, you remain responsible for treatment within the meaning of the RGPD. Microsoft is acting as a subcontractor and must provide you with contractual guarantees of compliance. The GDPR does not prohibit the cloud, but imposes specific guarantees when data is hosted outside the EU or accessible by actors subject to extraterritorial legislation.

The Cloud Act: what are we really talking about?

The Cloud Act (Clarifying Lawful Overseas Use of Data Act, United States, 2018) allows American authorities to access data stored by American companies, even if this data is physically hosted outside the United States. That's where the worry comes in.

Attention, the Cloud Act only applies in the context of criminal investigations, with a judicial warrant, for serious crimes. This is not permanent and discretionary access to your business data. The text also provides for a dispute mechanism if the request violates the laws of the hosting country, and Microsoft is committed to challenging abusive or disproportionate requests.

The RGPD/Cloud Act tension: real or imagined risk?

The legal tension is real because the RGPD aims to protect the personal data of Europeans, while the Cloud Act allows, under certain conditions, access by foreign authorities. It is on this point that the CNIL and the EDPS (European Data Protection Board) have alerted, and that the Schrems II judgment of 16 July 2020 of the Court of Justice of the EU has invalidated Privacy Shield.

For all that, The problem is not specific to Microsoft, or even to American companies. Similar laws exist in the United Kingdom, France, China, and other countries. No host, regardless of nationality, can guarantee absolute zero risk. So the real question is not “should the American cloud be banned?” but well: “what additional guarantees should be put in place to meet RGPD requirements? ”

Note that protection mechanisms exist such as standard contractual clauses, additional technical measures, data localization.

Microsoft guarantees for GDPR compliance

Data location and residence in Europe

In 2019, Microsoft opened two Azure regions in France: France Central (Paris) and France South (Marseille). Microsoft also operates an extensive network of Azure regions in Europe (Ireland, Netherlands, Germany, Sweden, Poland, Spain, Switzerland, Norway, Italy, etc.) in Europe (Ireland, Netherlands, Italy, etc.) When creating your Azure, Dynamics 365, or Power Platform environments, you can explicitly choose the hosting region.

Concretely, when you create a Dynamics 365 environment by selecting France Central, your customer data is stored physically in French datacenters and does not leave the country without instructions to the contrary from you. Data at rest stays in the selected region, the data in transit is encrypted and no automatic replication outside the EU is carried out without your consent.

Be aware that some metadata and logs may transit through other regions and certain functionalities such as Copilot or specific AI services may involve transfers to be analyzed on a case-by-case basis. This choice of region is often final, in fact, migrating data between regions after the fact is very difficult. Might as well do it right from the start.

Microsoft's contractual commitments (Data Processing Addendum)

The Data Processing Addendum (DPA) from Microsoft is a binding contract that Microsoft enters into as a GDPR subcontractor. It defines specific obligations: process data only on instructions from the customer, ensure security and confidentiality, notify data breaches, allow audits, and make the use of subsequent subcontractors subject to your prior authorization.

The DPA integrates the Standard Contractual Clauses (CCT) of the EU, i.e. the transfer mechanism validated by the European Commission for data outside the EU. Following the Schrems II ruling, Microsoft reinforced these commitments with additional measures: strengthened encryption, minimization of data transfers outside the EU, and a formalized process for challenging government access requests.

Also noteworthy is the gradual deployment ofEU Data Boundary : Microsoft is gradually deploying this program designed to limit the storage and processing of European customer data within the European Union for the majority of its cloud services (Azure, Microsoft 365, Power Platform, Dynamics 365).

Microsoft's resistance to government access requests

Faced with access requests from government authorities, Microsoft has adopted a clear policy: systematically challenge requests that are too broad, vague, or disproportionate, and notify the customer concerned unless explicitly prohibited by law. These commitments are documented each year in Transparency Reports published by Microsoft, which detail by country and by type the number of requests received, the information actually disclosed and the denials opposed.

Microsoft has also already contested some requests for access to data in court, in particular in the case Microsoft Corp. v. United States concerning data stored in Ireland, a procedure whose debate directly contributed to the adoption of the Cloud Act in 2018. Microsoft cannot challenge a valid court order, but it can limit its scope.

Technical configurations to ensure GDPR compliance in the Microsoft cloud

Choosing the right hosting region for your environments

The first step towards GDPR compliance is also the simplest: deliberately choose a European accommodation region as soon as your environments are created. For Azure, each resource is configured individually (France Central, West Europe, etc.). For Dynamics 365 and Power Platform, the choice is made during the provisioning of the environment.

For a Dynamics 365 CRM hosting European customer data, choose france or Europe as a geographic region. Regularly check the actual location of your data via the Azure portal or the Microsoft Service Trust Portal. And pay attention to additional features (especially the services of AI) that can operate from other regions and require a fully-fledged analysis.

Encryption and control of encryption keys

By default, Microsoft applies encryption at rest (AES-256) and in transit with at least TLS 1.2, with some services now supporting TLS 1.3. To further strengthen sovereignty, you can go further with the Customer Managed Keys (CMK) (also called Bring Your Own Key (BYOK)).

The principle is that you manage your own encryption keys via Azure Key Vault, and Microsoft can't decrypt your data without your key. In concrete terms, even in the event of a request for government access, the encrypted data without the key is unusable. Moreover, the EDPS explicitly recommends this type of additional technical measure in its Recommendations 01/2020 on additional measures for international data transfers, published in the wake of the Schrems II judgment. This is part of a logic of Security by design.

This configuration applies to Azure Storage, Azure SQL, and Dataverse (with some limitations). It involves increased management complexity and additional costs, but for particularly sensitive data, it is a decisive layer of protection.

Microsoft Access Governance and Staff Limitation

A principle that is often overlooked: Microsoft engineers do not have permanent access to your data. The principle of Zero Standing Access (in an approach Zero Trust) means that all access must be temporary, justified, and logged, especially when it comes to customer content.

The functionality Customer Lockbox goes even further: when a Microsoft engineer needs access to your Dynamics 365 environment to resolve an incident, you receive a notification and must explicitly approve this temporary access. Without your approval, access is denied. A complete audit log tracks all these interventions.

On the internal configuration side, access governance is based on the principle of least privilege in Microsoft Entra ID and Dataverse, mandatory MFA for privileged accounts and Conditional Access policies. Note that advanced risk-based features generally require Microsoft Entra ID P2.

Data Loss Prevention (DLP) and Data Classification

Data Loss Prevention (DLP) is the last line of defense: prevent personal data from leaving your GDPR compliance perimeter, even by mistake or malicious behavior by an internal user.

Microsoft Purview Data Loss Prevention allows you to define policies by type of data (personal, financial, sensitive) and to automatically block risky actions: sending emails containing personal data to recipients outside the EU, massive downloading, exporting to unapproved connectors. Power Platform DLP policies, on the other hand, allow you to control which connectors can be used in Power Automate flows, based on the capabilities available in your environment and your administrator licenses.

In addition, the Sensitivity Labels (sensitivity labels) allow you to classify your data manually or automatically, and to associate adapted protections with each sensitivity level. A document classified as “Confidential” can thus be encrypted automatically and not be shared outside the organization without warning.

For organizations that manage a large volume of contractual or HR documents, this classification is naturally linked to a secure EDM strategy.

Going further: sovereignty and alternatives

Microsoft's “sovereign” offerings (Microsoft Cloud for Sovereignty)

For organizations whose sovereignty requirements are the most stringent (public sectors, health, defense, critical infrastructures), Microsoft announced a dedicated offer at Microsoft Ignite in October 2022, a dedicated offer, which has been gradually deployed since then: Microsoft Cloud for Sovereignty.

The latter aims to provide additional control and governance mechanisms for environments subject to high regulatory requirements:

• increased workload isolation;
• strengthened controls over access to data;
• transparency on operations.

This approach can meet certain sovereignty requirements, without constituting a SecNumCloud certification.

This offer is aimed at organizations subject to strong sectoral regulatory constraints. It is not necessary for the majority of traditional B2B use cases, but it exists for the contexts that justify it.

Should we turn to European clouds?

Some European providers such as OVHcloud or Scaleway offer infrastructures operated in Europe, without exposure to the Cloud Act. This is a real advantage, especially for highly sensitive data. Other players such as T-Systems also participate in sovereign cloud offers, sometimes in partnership with Microsoft as part of specific offers for certain countries.

But migrating out of Microsoft means giving up the integrated ecosystem: Dynamics 365, Power Platform, Microsoft 365, native connectors, integrated workflows. This functional cost is concrete. And “European cloud” does not automatically mean “GDPR compliant”: the same good governance practices apply, regardless of the provider. The question is not “Microsoft vs European cloud” but “what guarantees should be put in place to use Microsoft in compliance with GDPR?” ”

Hybrid and multicloud architectures

Between all-cloud-Microsoft and all-cloud-European, a third way exists: hybrid architecture. Sensitive data in a certified cloud or on-premise, applications and services in Azure, secure integration between the two via controlled API and gateway.

A financial institution can thus host its critical customer data in a SecNumCloud certified cloud offer while exploiting Azure for its development environments or non-critical services such as Power BI. The complexity and costs are higher, but this architecture offers maximum flexibility: each data has the level of protection adapted to its real sensitivity.

The tension between GDPR and Cloud Act is real legally, but it's manageable with the right measures in place. Microsoft offers solid guarantees but these protections must be activated, configured, and maintained: they don't apply by default.

Zero risk does not exist, even with 100% European solutions. The objective is not perfection but proportionality: measures adapted to the level of sensitivity of your data and to your regulatory context.

Do you need a GDPR compliance audit of your Microsoft environments or support to secure your cloud migration? Contact the Askware experts for a diagnosis.