Issue

Syensqo decided to have only one tenant for M365 platform in Europe region.
The Microsoft EU Data Boundary is a solution that stores and processes public sector and commercial customer data within the EU and European Free Trade Association (EFTA) regions. This includes data for Microsoft 365, Dynamics 365, Power Platform, and most Azure services.

Syensqo has to comply with complex regulations, like Export control and dual use. (Dual-use items are goods (including products, software, and technology) that can be used for both civilian and military use due to their technical specifications.)

The M365 environment is a standard platform to be used by any Syensqo users, which does not comply with specific complex regulations.

Recommendation

Deploy MultiGeo on specific scope where data residency matter, like Composite Material US and UK before the mass migration in order to avoid change management later on due to URL change.

• Default data location for end user service OneDrive, Outlook, Chats.
• Propose default storage location for Sharepoint site.

MultiGeo will not solve data regulation like dual use, ITAR, CUI, but may benefit on data residency requirements.

Background & Context

• Syensqo is migrating from Google Workspace to Microsoft M365, without MultiGeo in the default design  for Day 1.
• GWS is not compliant with Export control and dual use documents.
• M365 is not compliant as is with export control and dual use documents.
• Syensqo has limited solution to store
  • CUI data : CMMC enclave
  • ITAR in NTT and Secure SharePoint
  • ITAR shared with external in RegDox
• End users have data on their devices while there is no storage location complying with specific regulation.

M365 provides a capability covered by MultiGeo license to store data from Exchange, OneDrive, Sharepoint, Teams in a specific geographical region.

enabling MultiGeo prior to migrate the user or some SharePoint may help for data residency requirements.

Syensqo Owns 900+ Multi Geo licenses, and purview eDiscovery Premium from E5 and F5 capabilities which is required to cover multi region eDiscovery.

South Korea, Japan, Singapore, Malaysia, Hong Kong Special Administrative Region

APC

Australia

AUS

Austria

AUT

Brazil

BRA

Canada

CAN

Chile

CHL

France, Netherlands, Ireland, Norway, Switzerland, Austria, Finland, Sweden, Germany

EUR

France

FRA

Germany

DEU

India

IND

Indonesia

IDN

Israel

ISR

Italy

ITA

Japan

JPN

Korea

KOR

Malaysia

MYS

Mexico

MEX

New Zealand

NZL

Norway

NOR

Poland

POL

Qatar

QAT

South Africa

ZAF

Spain

ESP

Sweden

SWE

Switzerland

CHE

Taiwan

TWN

United Arab Emirates

ARE

United Kingdom

GBR

United States

NAM

Multi Geo Study

Question marks to be addressed

• is MultiGeo improving regulation exposure if we store US data in the US?
• Can we setup GBU GM USA and UK to be on the USA and UK data centres from day one?
  • What are the technical implications?
  • Can this be done prior to the mass migration to avoid double migration for people.
  • Impact on user experience?
  • Do we store data from user citizenship or GBU main regulated country?

MultiGeo capabilities

Multi-Geo allows to store data in multiple Geographies to satisfy data residency requirements, while retaining single-tenant administration and full-fidelity collaboration experiences between users as necessary.

Multi-Geo allows to manage and store in-scope data at a user level for Microsoft 365 Core Services including Exchange Online, SharePoint/OneDrive, Microsoft Teams, and Microsoft 365 Copilot and Copilot Chat. In addition, Multi-Geo can be used with shared resources including SharePoint sites, Microsoft 365 Groups, Shared Mailboxes, eDiscovery, or Microsoft Teams teams.

PDL stands for Prefered Data Location : by default stored in Europe.

MultiGeo capabilities: 

• Sharepoint com site : the PDL is defined at the SharePoint creation (but requires 5% of active users being covered by the MultiGeo licenses)
• Team site with M365 group : will follow the PDL of the M365 group owner at the creation.
  • • if the PDL of the owner changes after this will not modify the PDL of the M365 Group
    • If we change the PDL of the M365 group after the creation, this will not modify the PDL of the SharePoint site. (not migrating the data) 
    • Teams channel : follows the M365 group PDL, if changed, this will triger a migration of the data (channels and discussions) in the target PDL.
    • if a change of PDL is required, the change on Owner, SharePoint and M365 Group must be coordinated
• Exchange / outlook : user or shared mailbox follow the PDL of the owner
• OneDrive : will be on user PDL (impact if the PDL is changed afterwards on windows machine to be checked) 
• Teams chat : will follow the PDL of the user who initiated the chat

Options considered

Option 1: MultiGeo for CMMC (CUI data & ITAR)

• It has been decided to store CUI data inside a CMMC enclave in a dedicated GCC High tenant.
• ITAR data are remaning in NTT data center which is ITAR compliant

Option 2: MultiGeo for Dual Use

• Dual Use requires more than just data residency, but also the operational processes and access being compliant.
• the user "personal data" like outlook , chat, and OneDrive can be automatically stored inside a predefined region.
  • the PDL can be forced to another region than the user citizenship
  • Multiple Sharepoint can be setup to cover various local data residency requirement
• The tenant operation will still be centrally managed (ENTRA ID for the identity and RBAC, M365 services , INTUNE for endpoint)
• Option:
  • Purview DLP rules per regions
  • Purview Data retention per local regulation
  • Purview eDiscovery (premium) for multi region ediscovery

Option 3: Deploy Multi Geo for performance

• While using a single tenant all the data will reside in Europe, and may cose some latency for the users being in remote location. 
• the limitation will be on the services covered and the licenses being available to cover all users.
• a Network assessment ongoing to identify the need

Option 4 : do not deploy MultiGeo

See also

The following section describes relevant documentation: