If we take the scenario below which we see frequently (based on a real customer but not the real name or product) - we really need to consider in our solution design where the data will reside (in our case this would be in which Microsoft Data Region) and under which rules will it be held there:
ZOIG International is a famous manufacturer, distributor and retailer of golf buggies globally. With operations on 4 continents across multiple legal entities they are now looking to stream line operations and improve their customer offering. The have decided that now is the right time to introduce a single cohesive system that operates across their business in the areas of Accounting, Manufacturing, Supply Chain and Retailing. They have selected Microsoft as the sole vendor for this new system.
Whilst at first glance reading the above its tempting as a solution architect to immediately rattle off a semi-sensible base design utilizing Microsoft's depth of applications (D365 Finance for global accounting, with D365 Supply Chain for the Inventory & Logistics handling tied into D365 Commerce for the consumer sided activities - with a call centre delivered via D365 Customer Service and a golf buggy maintenance & repair scheme managed using D365 Field Service) …. one element that needs to be defined early on is where the organisations data will reside and which data can move across geographical/legal boundaries:
Here it's key to understand the difference between Data Sovereignty and Data Residency.
Data Sovereignty is where laws state that all data is subject to the laws of the country in which it is collected or processed in and must remain within that countries legal borders.
At the time of writing the following countries have such laws: (please confirm any legal topics, this information is only added for illustration purposes)
Russia
China
Indonesia
Germany & France
The GDPR requires that all data collected on citizens must be either stored in the EU, so it is subject to European privacy laws, or within a jurisdiction that has similar levels of protection.
Data Residency is where an organisation decides that their data will be stored in a specific geographic location. An example of this would be where an organisation with operations in France, Germany and the UK decided to store all its data for all 3 countries inside the one data centre located in France. There were no laws in the UK preventing this but there were the implications of the GDPR to consider.
So considering the information above we will need to work with ZOIG International to identify if they want to take advantage of the different privacy and security protections available according to where geographically the data centres are located for their D365 data. When a customer requires that you operate your solution from multiple data centres for these reasons then you will not be able to operate on a 'single instance' basis, this may impact the 'semi-sensible' solution components mentioned earlier or at least how they will work together.
In addition we know that Microsoft Dynamics 365 Apps are generally available to support data residency in specific geographies. However not all data regions support all applications functions, features or capabilities. So you must take that into account when considering your solution design.
Data Protection Impact Assessments (DPIA)
Article 35 of the GDPR formally introduced the concept of a Data Protection Impact Assessment (DPIA)
"A DPIA is a process designed to describe the processing, assess its necessity and proportionality and help manage the risks to the rights and freedoms of natural persons resulting from the processing of personal data, by assessing them and determining the measures to address them."
When working on large scale multi-national projects this is an activity that sometimes gets 'decided' in the background, but that approach is not something we suggest. The guidance provided clearly warns us that:
"Under the GDPR, non-compliance with DPIA requirements can lead to fines imposed by the competent supervisory authority. Failure to carry out a DPIA when the processing is subject to a DPIA (Article 35(1) and (3)-(4)), carrying out a DPIA in an incorrect way (Article 35(2) and (7) to (9)), or failing to consult the competent supervisory authority where required (Article 36(3)(e)), can result in an administrative fine of up to 10M€, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher
Whilst a DPIA can be mandatory from an EU perspective we have found benefits in this exercise in relation to many other non-EU jurisdictions.
Microsoft's guidance on DPIA's can be found here: Data protection impact assessments - Microsoft GDPR | Microsoft Learn
We asked BING Chat to provide us with a framework that can be used to create an effective DPIA:
A Data Protection Impact Assessment (DPIA) should include the following key elements:
Identify the need for a DPIA: Determine whether a DPIA is necessary for the processing activity.
Describe the processing: Detail the nature, scope, context, and purposes of the data processing.
Consider consultation: Decide whether to consult with individuals (data subjects) and other stakeholders.
Assess necessity and proportionality: Evaluate whether the data processing is necessary and proportionate to the purpose.
Identify and assess risks: Identify the risks to individuals’ rights and freedoms and assess their severity and likelihood.
Identify measures to mitigate the risks: Determine what actions could be taken to reduce or eliminate identified risks.
Sign off and record outcomes: Obtain necessary approvals and document the DPIA outcomes.
After sign-off, you should integrate the outcomes from your DPIA back into your project plan, and keep your DPIA under review.
The Cloud Act (United States)
One topic that customers should be made aware of when choosing Microsoft to host their data, regardless which data region is selected is the potential impact of the US Cloud Act.
The CLOUD Act states that companies operating in the US must provide information properly requested by US law enforcement “regardless of whether such communication, record, or other information is located within or outside of the United States. This is enabled through the provision of bilateral executive agreements between the US and other foreign governments. The UK has such an agreement in place as reported here: https://www.lawfaremedia.org/article/applying-cloud-act-us-uk-bilateral-data-access-agreement#:~:text=On%20Oct.%203%2C%20the%20United%20States%20and%20the,countries%20for%20the%20purpose%20of%20aiding%20criminal%20investigations.
To finish off this short pointer to the topics of Data Sovereignty, when we do have to place data into multiple regions all is not lost from a 'single cohesive system' perspective. For example, you can use Azure SQL Database geo-replication to create readable secondary databases in different regions. You can also use Azure Cosmos DB to replicate your data globally across any number of Azure regions. However, you should be aware of the data transfer costs and the latency implications of cross-region data sharing in addition to any legal boundaries.
