Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings

Published Oct 18 2019 09:00 AM 50.8K Views

There is an update to this article found at:




This article has been replaced by the update and will be removed shortly.



This article is the second of a series in the Microsoft Tech Community Public Sector Blog and touches on several  key principles for compliance, including data residency versus data sovereignty.  For the first article in the series, please refer to History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government.

We will focus on each of the US-based cloud offerings from Microsoft and compare the differences in compliance.  In order to keep this article concise, I will refrain from repeating  content from the first article.


Microsoft 365 Commercial


Compliance Chart - Commercial.png


FedRAMP in Commercial

You can demonstrate compliance with the FedRAMP Moderate Impact Level in Microsoft 365 Commercial.  It is even more impressive to note that you can demonstrate compliance with FedRAMP High in Azure Commercial.  We do have accreditation from the Department of Health and Human Services (DHHS) for “Microsoft - Office 365 Multi-Tenant & Supporting Services”.  This Provisional Authority to Operate (P-ATO) is for a GCC tenancy, but GCC is a data enclave of Commercial, effectively extending the accreditation to the whole of the Commercial cloud.

Note: For context of what a ‘data enclave’ is, please refer to the History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government  

We advertise that we have FedRAMP Moderate ‘equivalency’ in Microsoft 365 Commercial.  Microsoft validates the controls for Microsoft 365 into FedRAMP holistically because we operate all instances of Office 365 employing a consistent control framework and uniform implementations of controls based on NIST 800-53 (a requirement of FedRAMP).

A word about FedRAMP in Commercial and how it relates to CUI

I often get pulled into customer conversations  on suitability for Controlled Unclassified Information (CUI) in the Commercial cloud.  The common misconception by many is regarding FedRAMP.  Yes, you can demonstrate compliance with FedRAMP Moderate in Microsoft 365 Commercial.  However, not all FedRAMP / NIST 800-53 implementations are the same.  The way Microsoft implements FedRAMP Moderate in Commercial is not the same as  other Cloud Service Providers (CSP’s).  Ultimately, FedRAMP Moderate is not the high bar for compliance with any CSP.  It does not guarantee fulfillment of US Persons nor US Citizenship requirements, nor does it confer data residency in the Continental United States (CONUS).

However, customers think they are getting something that they are not, just from that label.

Commercial was not built for the regulations and standards that govern CUI.  Thus, in the table above, you can observe that CUI is presented as ‘No’.

The way I frame this out for customers is this: your higher bar for compliance to gain coverage of CUI is in alignment with other controls above and beyond FedRAMP.  If you are affiliated with law enforcement and the criminal justice system, you will likely require CJIS adjudication from the FBI or from the US State you are in.  If you are affiliated with the Internal Revenue Service or Department of Revenue, you will likely require IRS 1075 for coverage of Federal Tax Information.  If you are affiliated with U.S. Defense or Military, you will likely require export controls that include the International Traffic in Arms Regulation (ITAR) and Export Administration Regulations (EAR).  Each one of these  require screened US persons and data residency/sovereignty in CONUS.  These are what will direct you to our Government cloud solutions and diminish Commercial as an option.

Commercial has ‘Maybe’ for NIST 800-171?

This is for the Defense Industrial Base (DIB) including aerospace and defense contractors of the US Department of Defense (DoD).  To contract with the DoD, you must demonstrate compliance with the Defense Federal Acquisition Regulation Supplement 252.204-7012 (DFARS).  DFARS mandates the implementation of NIST 800-171 and FedRamp Moderate Impact Level for Commercial clouds.  It is a set of controls that are used to secure Non-Federal Information Systems (commercial systems). NIST 800-171 is derived from NIST 800-53.  Think of it as a subset of the controls that apply to the DIB.  Given Microsoft uniformly implements NIST 800-53 in all of our clouds, undoubtedly, we have coverage for NIST 800-171 controls in Commercial.  However, there are differences in the System Security Plan (SSP) Organizational Defined Values (ODV’s) for Commercial than you will find in our Government cloud solutions.  Namely, the ODV’s in Commercial are designed for a global service.  There are control differences that make supporting DFARS clause 252.204-7012 sub-paragraphs (c)-(g) much less tenable in Commercial. Log retention is not in compliance across all services in Commercial; tenant guidance for log configurations differs, incident response times differ and other ODV’s differ that contribute to how we could enable support for (c)-(g).  We say ‘Maybe’ because it’s not completely out of the question that you could supplement our service, such as log retention in a customer managed Security Information and Event Management (SIEM) solution (e.g. Azure Sentinel, Splunk, etc.).  However, Microsoft does not demonstrate compliance with NIST 800-171 out-of-the-box in Commercial.

Commercial will not recognize US Government requirements

As I mentioned, there are guidance, operational and support differences between the services provided for Commercial as opposed to those built for the US Government.  There is no way to identify a government tenant within the Commercial service. 

This is a painful learning curve when a customer  discovers this post sale/deployment while  in the middle of an incident. I have been on calls assisting such customers that were routed through our global support staff and were frustrated that ‘Microsoft’ did not understand that they had US Government requirements and shouldn’t have been routed to offshore support personnel in Asia. That is how the Commercial service works.  If you have requirements for screened US Persons, Microsoft built services exclusively for the US Government that are suitable to sovereignty requirements.


Microsoft 365 Government Community Cloud (GCC)


Compliance Chart - GCC.png


Scope of Services in GCC

GCC is a data enclave of Commercial.  A data enclave in this context is a logically segregated environment, with servers residing in regional Azure data centers.  In the case of GCC, the data enclave is in CONUS.  There is a contractual commitment to ensure data residency for the primary Office workloads administered by screened US Persons for access to customer data.  This includes data processing specific to the covered workloads (e.g. Exchange Online Protection).


The service description for all Microsoft 365 US Government offerings may be found at http://aka.ms/o365usgovservicedescription

At the time of this writing, the service availability for GCC covered workloads are:

  • Exchange Online & Exchange Online Protection
  • SharePoint Online & OneDrive for Business Online
  • Skype for Business Online
  • Teams & Voice (Phone System & Audio Conferencing)
  • Office 365 ProPlus & Office for the Web
  • and more as documented in the US Government Service Description


Given GCC is a data enclave of Commercial, there are several shared services.  These shared services may have data processing Outside the Continental United States (OCONUS) and leverage a global follow-the-sun support model.  Most notably, this includes a global network and a global directory.  For example, Azure Active Directory (AAD) in Commercial is shared with GCC.  AAD replicates globally and may have data processing (authentication) occur OCONUS along with service management by global support personnel. For this reason, Microsoft will not contractually commit to export controls in GCC.

As a result, you may observe a ‘No’ in the column for ITAR & EAR for GCC.

There is an outstanding benefit for the shared services with Commercial.  GCC has ubiquitous access to the global catalog of integrated applications, including the AAD App Gallery and the Azure Marketplace in Commercial.  The best illustration of this benefit is access to Microsoft solutions to include Visual Studio Online, the Microsoft Developer Network (MSDN) and Azure DevOps in Azure Commercial.  This is not the case with the US Sovereign Cloud.  Consequently, tenants in the US Sovereign Cloud must deploy Commercial or GCC tenants to provide access into these Commercial services that are not deployed into the US Sovereign Cloud accreditation boundary.


DFARS Yes, but No Flow-Downs in GCC

In GCC covered workloads, we can demonstrate support for DFARS clause 252.204-7012 sub-paragraphs (c)-(g).  We have an auditor’s attestation letter that shows on two pages summarizing how those sub-paragraphs are supported, but we will not sign a contractual flow-down.  Why? Because we did not build GCC (nor Commercial) for this purpose.  You will not get a contractual agreement from Microsoft to support DFARS in GCC, nor to demonstrate DFARS compliance with your customers, vendors and partners.  The primary gap includes the scope of services that fall outside the covered workloads for GCC.


Controlled Unclassified Information is a Maybe in GCC

The NIST 800-60 Volume 2 registry is rather large.  There are 20 CUI categories as of the latest revision, to include many information types.  The question is, which CUI category is in scope?  Several categories may not require data sovereignty, such as Privacy, Legal, etc.  Is it permissible to rely on data residency in GCC?  Maybe.  However, many of the CUI categories to include Defense, Export Control, Nuclear, etc.   undoubtedly require the US Sovereign cloud and are not appropriate for storage within GCC.  Ultimately, customers are responsible for ensuring that they review the relevant regulations and Microsoft's offering prior to determining which Microsoft Government Cloud Service is the best fit to support their obligations for CUI.


Criminal Justice Information Services in GCC

The most predominant tenant populations in GCC include State and Local Government (SLG) entities, such as highway patrol, sheriff, local law enforcement, etc. that require CJIS.  The CJIS security policy provides 13 areas that should be evaluated to determine if cloud services can be used and are consistent with CJIS requirements. These areas correspond closely to the NIST 800-53 control implementation for FedRAMP Moderate with a security policy aligning with CJIS.

Microsoft will sign the CJIS Security Addendum in states with CJIS Information Agreements. These tell state law enforcement authorities responsible for compliance with CJIS Security Policy how Microsoft's cloud security controls help protect the full lifecycle of data and ensure appropriate background screening of operating personnel with access to CJI. Microsoft continues to work with state governments to enter into CJIS Information Agreements.

Microsoft has assessed the operational policies and procedures of Microsoft Azure Government, Microsoft Office 365 U.S. Government, and Microsoft Dynamics 365 U.S. Government, and will attest to their ability in the applicable services agreements to meet FBI requirements for the use of in-scope services.

Download the CJIS implementation guidelines for Microsoft Government Cloud Services

CJIS status in the United States

Microsoft CJIS States.png

37 states and the District of Columbia with management agreements, highlighted on the map in green include:

Alabama, Alaska, Arkansas, Arizona, California, Colorado, Florida, Georgia, Hawaii, Illinois, Indiana, Iowa, Kansas, Kentucky, Maine, Massachusetts, Michigan, Minnesota, Missouri, Montana, New Jersey, New York, Nevada, North Carolina, Oklahoma, Oregon, Pennsylvania, Rhode Island, South Carolina, Tennessee, Texas, Utah, Vermont, Virginia, Washington, Washington D.C., West Virginia, Wisconsin.

Microsoft's commitment to meeting the applicable CJIS regulatory controls allows Criminal Justice organizations to implement cloud-based solutions and be compliant with CJIS Security Policy V5.7.

Current as of 04/18/2019


Microsoft 365 Government (GCC High)


Compliance Chart - GCC High.png


ITAR in GCC High

This service was built for export controls in the US, to include ITAR and EAR.  I have customers interpret that GCC is suitable for export controls.  I've even had customers decide that Commercial is sufficient.  I tell them that I am not a lawyer, and I cannot give you legal counsel, but I think that is extremely unwise.  I can't stop you from leveraging Commercial or GCC for CUI categorized as Export Control, especially for ITAR. I hope you take advantage of every data protection feature that we offer you!  GCC High was created to give you a contractual assurance for export controls in the US.  This includes a US Sovereign Cloud accreditation boundary encompassing all services attached to GCC High.  For example, the network is sovereign and constrained to CONUS.  The directory services with AAD are provided by Azure Government and are sovereign to the US.

DoD CC SRG Impact Level 4 Equivalency in GCC High

We have evolved the US Sovereign Cloud to include PII protections.  PII protections are now all the way up to IL4 in GCC High.  This is significant.  If you know you will have PII on a contract and going after new business, are you going after it with IL4, or just IL2?  This can be a competitive advantage if you can demonstrate IL4.  There is a good likelihood that your customer will be more IL4 oriented, or already consuming our IL4 and IL5 clouds.

NIST 800-171 and DFARS with Flow-Downs in GCC High

Microsoft will sign a contractual Flow-Down for DFARS in GCC High.  This translates to a contractual commitment where we demonstrate DFARS compliance in the US Sovereign Cloud.  This includes DFARS alignment with NIST 800-171 in a shared responsibility model with the Customer.  Given that Microsoft uniformly implements NIST 800-53 in all of our clouds, the SSP ODV’s for FedRAMP High in GCC High are designed to demonstrate compliance with DFARS.

GCC High complies with DFARS clause 252.204-7012 sub-paragraphs (c)-(g), except as follows:

  • (c) Cyber incident reporting requirement. Microsoft will report security incidents to the Customer in accordance with Incident Response processes and definitions detailed in the DoD CC SRG accreditation requirements. The customer will be responsible for reporting the incident to DoD, if required.
  • (e) Media preservation and protection. Microsoft shall preserve and protect all relevant forensic data of known affected information systems in support of an incident. Any relevant monitoring/packet capture data must be gathered and retained by the Customer.
  • (f) Access to additional information or equipment necessary for forensic analysis.  Upon request by Customer, Microsoft will provide appropriate additional access to any relevant forensic information.

FedRAMP High in GCC High

At the time of this writing, GCC High currently has a FedRAMP Agency ATO at the Moderate Impact Level from the Department of Justice (DOJ) and successfully completed two FedRAMP High Impact Level audits.  We have several Federal Agencies actively deployed in GCC High, demonstrating compliance with FedRAMP High.  The FedRAMP High ATO is pending finalization in the FedRAMP Marketplace.

Today, you can demonstrate compliance with FedRAMP High in GCC High and in Azure Government.  However, the High Impact Level is not a requirement for DFARS Compliance.  FedRAMP Moderate is specifically required for DFARS.  And for that, we do have an Agency ATO currently in place covering GCC High.


NERC and FERC in GCC High

Microsoft has engaged with multiple entities obligated to demonstrate compliance requirements of the North American Electric Reliability Corporation (NERC) and/or the Federal Energy Regulatory Commission (FERC).  They find M365 GCC High and Azure Government to be the closest match of Microsoft cloud service offerings to fulfill their requirements. Due to the dynamic scope of applicability that an entity may define, we recommend you request explicit support from your Microsoft account team if you have compliance requirements in this area.

Microsoft 365 Government (DoD)


Compliance Chart - DoD.png


If you are not in the DoD, don't worry about it.  You're not getting into the service.  Only the DoD and those approved by them (such as service providers or entities authorized by the DoD) are allowed into the IL5 environment.




Please follow me here and on LinkedIn. Here are my additional blog articles:



Blog Title

Aka Link

Accelerating CMMC compliance for Microsoft cloud (in depth review)


Updated! Microsoft CMMC Acceleration Program Update – January 2021


History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government


Gold Standard! Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings (This One)


The Microsoft 365 Government (GCC High) Conundrum - DIB Data Enclave vs Going All In


Microsoft US Sovereign Cloud Myth Busters - A Global Address List (GAL) Can Span Multiple Tenants


Microsoft US Sovereign Cloud Myth Busters - A Single Domain Should Not Span Multiple Tenants


Microsoft US Sovereign Cloud Myth Busters - Active Directory Does Not Require Restructuring


Microsoft US Sovereign Cloud Myth Busters - CUI Effectively Requires Data Sovereignty


New! Microsoft expands qualification of contractors for government cloud offerings




Senior Member

Thank you for these blog posts.  This is the most detailed explanation on the different tenants I have seen. 


FedRAmp Moderate Equivalency Question.

The chart and article states that Office 365 is FedRamp Moderate "equivalency" in Microsoft 365 Commercial.  On the FedRamp website for Office 365 Multi-Tenant and Supporting Services for Public Cloud it states that it is FedRamp Authorized.  Why is Microsoft calling it equivalent and not authorized?  When a customer is looking for FedRamp authorized services this is the source they would use. 




Thanks @Terry Hebert !

Good question. The reason I have always pushed for us to use the term 'equivalency' are due to two reasons: First; that the Commercial service has differing values for a number of ODVs across the control scope and Second; that customers really need to understand how they might be treated differently as a tenant of the Commercial vs Government services i.e. if we declare an incident for the Commercial service all entities within would be treated to the Commercial (not Government) Incident Response practices and requirements. So I use equivalency (amongst other tactics) as an attempt to incent customers to look deeply at these differences before making such choices. As you and I have discussed over the years; I am fine if a customer makes a choice to accept a risk; as long as that was a well-informed decision and I've done my job contributing to the 'well informed' aspect of that decision ;) 

Senior Member

GCC Data Enclave of Commercial Question


The Export Control requirements for ITAR and EAR is based on the data.  A foreign national is not allowed to access export controlled data and export controlled data can only reside CONUS.  


The GCC article states:  "There is a contractual commitment to ensure data residency for the primary Office workloads administered by screened US Persons for access to customer data...to the covered workload." and  "shared services may have data processing Outside the Continental United States (OCONUS) and leverage a global follow-the-sun support model. Most notably, this includes a global network and a global directory."  


Is Microsoft suggesting a global directory as "data processing"?


I understand that Microsoft Support uses the commercial Azure AD for authentication and authorization for GCC but just because there is a shared authentication service does not mean a GCC customer is not compliant with Export Control.  It would not be uncommon for  on-premise AD account to include both US persons and unconfirmed US persons.  It is prudent for a company to appropriately authorize access to Export Controlled data to only US Persons but there is not a requirement for separate AD infrastructures


@Terry Hebert 


Excellent points but this was not about directory (though some customers do have concerns there). Support remains an issue that deserves awareness to avoid spillage to processes outside the accreditation boundary. More important is that GCC takes dependency on Azure Commercial; where it has attained FedRAMP High which is excellent; but as discussed elsewhere FedRAMP <> US Person/Citizen. Due to the potential for the SaaS layer to take on a dependency at the PaaS / IaaS layer where compensating control may be discretionary instead of mandatory; this in turn results in a level of residual risk I do not support when it comes to contractual support for export data in GCC. GCCH on the other hand was designed for dependency on Azure Government which does provide for US Citizen/Persons. I have had customers make decisions that GCC provides sufficient protections to meet their export requirements; and I am fine with that as long as they and their counsel feel they have made a well informed decision. However as a service provider I would not provide contractual support for a class of data that the service was not explicitly designed to support. Hope that helps clarify further. 

Senior Member

NIST 800-171 (Maybe)?


The article states: "DFARS mandates the implementation of NIST 800-171 AND FedRamp Moderate Impact Level for Commercial clouds."


The DFAR 252.204.7012 rule does not state NIST 800-171 AND Fedramp Moderate impact. DFAR rule states "If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information in performance of this contract, the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline" 



Most understand that there is a shared responsibility for security implementation of DFARS 7012 rule.  The DoD customer has a responsibility to properly configure their tenant to meet "our" requirement for 800-171. Where is Microsoft obtaining information suggesting that both FedRamp and 800-171 are required from cloud commercial service providers?


@Terry Hebert 


Generally I see two ways. First I have a hard requirement to demonstrate the equivalancy clause in sub paragraph (D) that you mention. I am also required to meet 800-171 in the context that I must enable a tenant to do so. This occurs through the extension of my control implementation to the tenant as well as capabilities provided within the service. In another context if I work in the industry as contractor and not just service provider; I would also be required to comply. Really though as the preface makes clear 800-171 is a subset and simplification of 800-53 along the Confidentiality dimension. Now personally (and deserving of a whole other blog) I think it may have been just as effective to focus on a subset of 800-53 rather than write 800-171. Selfishly it would have made my role as service provider far easier requiring far less translation between -171 and -53! I think as we assess movement towards CMMC (yet another good topic to address) we will continue to assess the parallelisms between CSPs and tenants and the regulations each implements. Great questions and observations Terry - thank you. 

Senior Member

Continued GCC Data Enclave (Export Control/US Persons)


OK, so there is a small risk that Foreign Nationals could access Export Controlled data.   "Certain government entities extend beyond the accreditation with regulations such as CJIS and IRS 1075 that require screened US Persons to support the service." This risk is acceptable for other organizations requiring US Persons (CJIS and IRS 1075) but the risk is too high for Export Control? 


If LockBox is enabled does that mitigate most of the risk for accidental access to data by Foreign Nationals?


Terry; yes. A small risk. Possible; yes, Probable; no. Good call on Lockbox as it is a great assurance feature/tool but I always try to be very transparent about it. It definitely helps a customer demonstrate control over access to their data. And, since our engineering staff almost never accesses customer data you may purchase this tool and never get a request from us! So while the risk is very small; and LockBox is a nice assurance complement; for me it boils down to two core things. 1) Being a service provider and needing to provide for a diverse range of potential solutions and risk appetites (while being clear on what is (and isn't) supported) and 2) Having discretionary vs mandatory control over dependencies. All that said, we know that risk is a very subjective discipline and many regulations purposefully leave room for flexible interpretation to achieve objectives different ways. In turn our services provide a myriad blend of features that help tenants add depth and breadth of data protections in addition to what the baseline service offers. You call out some great questions that can help customers explore the contrasts we are trying to highlight with this article so they might determine where their level of comfort is. Thank you. 

Frequent Visitor

@Shawn_Veney Good points as always!  I know you and I have talked about this previously but figured I would comment here.  One major challenge that I see is for global companies that have users in multiple countries who also have valid export licenses. It seems that this use-case keeps getting missed. It would be unrealistic to put all user accounts into GCC-High as you now risk bringing non-US controlled military data into the US (think Eurofighter for example).  The employee working on a Eurofighter program may also be working on F35 data in the UK under a valid license.  The company would potentially run afoul of foreign export regulations and risk "ITAR taint" by putting that data on US servers. 


It appears that customers are unable to setup a "split-tenant" with a subset of users in GCC-High and other users in GCC or Commercial.  At least with Commercial you can turn on multi-geo to keep the data resident to the appropriate country, then turn Lockbox on to remove the "potential access" risk.  Per DoS guidance a few years back, if you have actual access records, then potential access is no longer considered an export.  From everything I have seen, the recordkeeping in O365 would easily be able to meet that threshold. 





Great to hear from you Jonathan. Excellent point. Not the most common scenario but definitely a valid one and you are correct: Organizations with multi-geo footprints, valid export licenses and complex private/public sector business streams require some additional deliberation. There are a few key factors to consider here when I'm speaking with such customers. #1: If bifurcation between services appears viable, how might this impact (or complement) the organizations existing AD design, data classification, business group policies, etc. #2: Are operational costs clearly understood regarding complexity managing different services, collaboration between them and the policy/governance necessary to ensure avoidance of spillage between different services and #3: Given our compliance in other geographies how can we help the customer demonstrate assurances to regional regulations by sharing our compliance artifacts with the customer relevant to each region. So yes; definitely a good point. Such deployments are possible; they just deserve significant analysis and planning commensurate with their complexity.


Howdy @Jonathan_Priganc!  You hit on a topic that our team at Microsoft encounters frequently within the Defense Industrial Base.  Virtually every large DIB entity has missions OCONUS, and in service of other sovereign defense requirements outside the U.S..  It's a very nuanced set of topics.  There are data sovereignty requirements for export controls in the U.S. working with the U.S. DoD (e.g. ITAR & EAR) that may include export licenses for foreign user populations, such as foreign locations and/or subsidiaries.  At the same time, there may be data sovereignty requirements for export controls in other countries, such as those imposed by the U.K. MoD or AU DoD.  Often times, the same person may have obligations to both sets of export controls at the same time.  They are in direct competition with one another.  It often translates to that person having access into multiple data enclaves in each sovereign location.  Then the question becomes, where you do locate the person's Mailbox, OneDrive for Business and Team's account?  Do they need multiple?  Do you need to isolate one from another?  And in all transparency, will a Geo of the Commercial Office 365 offering even fit the export control requirements for the foreign defense entity in question?  There is no definitive answer.  We've seen customers go in multiple directions.  I've come up with several reference architectures that we share to help address "Cross-Sovereign" deployments of Office 365.  We are happy to share with you.  At the end of the day, Microsoft will accommodate multiple solutions, to include a multi-cloud approach.  But it will be a decision your organization will wrestle with, especially as the compliance bar shifts.

Occasional Contributor

@RichardWakeman: Thanks for your reply to Jonathan. We, as a partner, are running into scenarios where our manufacturing customers (primarily HQ'd in Michigan) are primarily focused on supporting the automotive sector (and in some cases, the aerospace sector) and may only have 50% or less of their overall business, employees, and/or data being impacted, in some capacity, under ITAR as a defense contractors. These aren't typically enterprise-size customers and typically fall into the SMC-C segment.


Due to the "limitations" on product availability and functionality within Office 365 GCC (including the lack of Office 365 GCC High in CSP today and added complexity of AOS-G (for less than 500 users) and EA (for more than 500 users)), we're continually running into the debate on what direction to advise them to go with: Office 365 GCC High, Office 365 GCC, Office 365 Commercial - and then, "all in" a specific tenant or the split-tenant model. As mentioned, the complexity comes in for the IT-led management and governance as well as the adoption and change management (including end-user awareness and training) headaches for 2 different tenant types with potential different configurations and product/service capabilities.


I'd be curious what your guidance is for these kind of customers and what your reference architectures are (just for awareness if they don't all apply to my referenced scenario). Thanks!


@Justin Coffey This challenge of providing guidance for the tenant topology a commercial customer has is less than trivial.  In fact, I wrote an article on it found here: The Microsoft 365 US Government (GCC High) Conundrum - DIB Data Enclave vs Going All In


Even if the majority of the company's business is not subject to data handling of CUI/CDI, they can put any data that is non-classed into GCC High.  We always recommend keeping to a single tenant if at all possible.  The collaborative experience is much better in a single tenant, plus it reduces complexity over having to straddle two or more tenants.  Microsoft will close the gap on feature parity challenges, such as B2B Guest access in the 2020 timeframe.  However, we do have reference architecture for those scenarios where a many-tenant topology is required.  They are not published publicly at this point, as it contains some NDA content.  We are happy to share it with you, if you reach out directly.  We can setup a working session to cover them.

Occasional Visitor
This is exactly what my organization was looking for and clears up a lot of the confusion between the different environments. Our organization initially set up O365 in GCC with an EA purchased through Microsoft when it was a new thing, and at the time it satisfied some of our security requirements, but the feature parity was not quite there yet. We opted to move back to Commercial due to this and have been using it for a few years. Now that CMMC requirements are being developed, we have to meet DISA IL4 standards to store and process CUI. This obviously cannot be done in O365 Commercial and we figured that since GCC has matured a little, we would begin the planning for a migration between Commercial and GCC. When I called Microsoft support for GCC to verify whether this tenant satisfied the IL4 requirements, me and my managers and coworkers were extremely confused to hear that our previously purchased EA with Microsoft in GCC was really a Commercial tenant, but this blog post clears up a lot of questions we had about what we were initially sold from Microsoft. This isn't explicitly detailed in writing on any of the documentation that is publicly available from Microsoft and I am so grateful to have come across this post. Again, thanks so much for the write-up on this and it gives us an easier way to move forward when we talk to our Indirect CSP.
Senior Member

To ClassANetwork:

The DISA Impact Levels are not a requirement when unclassified  data (CUI/CDI) data is stored, process, or transmitted  in a covered contractor information system in "support of the performance" of a contract.   DISA requirements are required only when "processing data on behalf of DoD".  


The DISA Impact Levels includes requirements for Availability and Integrity versus the 800-171 which is mostly concerned about Confidentiality.  When using a cloud service provider such as Office 365 the DFARS 252.204-7012 is the authority for requirements which states:


"The contractor “shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline (https://www.fedramp.gov/resources/documents/) and that the cloud service provider complies with requirements in paragraphs (c) through (g) of this clause for cyber incident reporting, malicious software, media preservation and protection, access to additional information and equipment necessary for forensic analysis, and cyber incident damage assessment."


Microsoft will provide an attestation letter for GCC and GCC high for the c-g requirements.  All quotes are sourced from the DoD Procurement Toolbox.




Howdy @Terry Hebert !


You would be surprised at the number of DIB asking for a DOD SRG IL4/5 environment.  If I were to break it down, we can typically differentiate a DIB from any other commercial customer by 1 of three different topics.  1) We need your ITAR compliant offering.  2) We have requirements for an IL5 environment (and they are not a DoD entity), and of course 3) Do you cover DFARS 7012 (now CMMC)?  It's an extremely nuanced conversation, but we often have to rationalize the need for, and how we satisfy the requirements the DIB have for the SRG.  Much of the time, that does distill down to GoCo (Gov't owned, Contractor operated) environments where a hard SRG Impact Level actually does exist.  But I can say this.  Topics like JSIG PL5, FOUO markings and DD 254 do not help the cause.  That's why we articulate where we have an actual DoD SRG P-ATO versus where there is 'equivalency'  Most DIB are satisfied that we have the same controlset implementation in GCC High to be IL4/5 compliant, as it's a twin environment to the DoD. 


Not to take away from the essence of your comment... DIB need a FedRAMP ATO with DFARS 7012 c-g, NIST 800-171 coverage, ITAR sovereignty, and now looking for CMMC.

New Contributor

@RichardWakemanThis (blog post) may be the single greatest resource that Microsoft has made available to the small business (sub-500) GCC High customers, current and potential. Well, other than GCC High itself. I think I reference this weekly when fielding questions about whether GCC High is even necessary.

What's the practical step for getting Microsoft to sign a DFARS flow down? Is that already in the GCC High license agreement? Or is this something customers would have to do on a case-by-case basis?



Howdy @andrewgsauer!  Thank you!!!

DFARS 7012 is an amendment to the Microsoft Enterprise Agreement.  You can find more information here: https://docs.microsoft.com/en-us/microsoft-365/compliance/offering-dfars?view=o365-worldwide

There is an actual 2-page flow-down letter you can also get from Microsoft by request (case-by-case).  However, it's typically only required by ISV's that need to produce a flow-down to their customer when running their SaaS product on Azure Government or M365 GCC High.

Regular Visitor

Much of the above conversation focuses on the more stringent ITAR, IL4/5....but as a commercial contractor working with DoD CUI expecting to meet CMMC IL 1/2 and maybe 3 in the next year, but NEVER needing IL4/5 or ITAR, can we remain in M365 commercial Business/Enterprise and avoid M365 GCC?  My understanding is that 800-171 does require the CONOS data center and US personnel support that ITAR and others do require.


@ThiryDB    I've never recommended Commercial for customers that have requirements to demonstrate protection of government data. I've always taken the stance that I recognize this is a customer decision; but one that I cannot support. Remember; as a Commercial customer for example you cannot be treated in accordance with government requirements. Perhaps you have a justifiable absence of need for your service provider to demonstrate support for (c)-(g) of 7012; or you have no concerns about your service provider executing incident response activities that impact your tenant in accordance with 800-53; 800-171; or DFARs; etc. These are customer decisions because that unique context; and the impact of that decision; remains appropriately the customers. It might help to know that most of the entities that I know that decided on Commercial at some point changed their mind and migrated a portion, or all, of their users to GCC &/or GCCH. Those that I know with a remaining presence in Commercial tend to have larger, more complex organizations where it makes sense to have multiple tenants. For most tenants the bright line between Commercial and GCC is that the latter commits to personnel screening requirements that support their tenant needs.

New Contributor

@RichardWakeman, thanks for the very helpful article and sheet! I am curious why GCC High isn't suitable for FBI CJIS work though. Is there any possibility that will happen? That would be helpful for companies who support the DoD and the FBI.


@RogueAgent, interestingly enough, the agency itself is homed in M365 GCC High.  While they are the authority for their deployment in GCCH, it does not apply to the States.  Each State has an adjudication for CJIS, as described in the article above.  Given the States will not deploy into GCCH, they will not likely adjudicate GCCH directly.  Microsoft cannot make claims that CJIS is supported in GCCH, especially at the State level.

Established Member

I have a local Government customer purchased a GCC Exchange online  E1 Suite License.


The customer needs to leverage file requests from OneDrive. This feature is not available for Office 365 Government, Office 365 operated by 21Vianet, or Office 365 Germany.


  • Is there a manual workaround to accomplish file request?
  • Will this feature be added to GCC?

Any advice?


@Slyclouduser, File requests is a new feature for OneDrive.  Any new features must become generally available in Commercial before getting ported over to the sovereign clouds.  A general rule of thumb, is a feature for an existing product that is already within the accreditation boundary will take 3-6 months after GA to release in the sovereign clouds. There are exceptions to the rule, such as requirements for FedRAMP assessments.  At the end of the day, there is a public roadmap for such features found at http://aka.ms/m365roadmap.  That said, I do not see this feature in particular.  

New Contributor

@RichardWakeman Is there a process that we can use to ask questions regarding the roadmap? I'm interested in knowing the status of Autopilot for GCC High, but it isn't on the roadmap. This MS documentation article (Last updated 10/30/2019) states that planning for Autopilot is underway, but that is all I could find.


Thank you for the great content and being so responsive to us!

Community Manager

Hello @RogueAgent , 


I'm the Community Manager for the Public Sector Community. Windows Autopilot for GCC-High customers is high priority for us and we are currently working on a plan. We will be able to provide more information around Fall 2020. If you would like to give feedback, we would recommend posting in the Microsoft 365 Uservoice here: https://office365.uservoice.com/ 

Senior Member

In my organization I find that there's a lot of confusion and concern surrounding CUI, CMMC (L3-L5 requirements), and the rationale for choosing "GCC High" over "Commercial" 365 licensing.


Here's a comment I received from a colleague just the other day:


Is it Micosoft's directing to industry that in order to obtain CMMC level 3 certification in a Microsoft Cloud environment, it will require both Azure Government and M365 GCC High implementation?  ... if you read the DOD Instruction 5200.48, NOFORN is a distribution marking which may be added to CUI, C, S, TS, TS/SCI.  CUI is not NOFORN by definition plus not all ITAR Defense Information is CUI - a significant portion of ITAR Defense Information is held commercial as Corporate Proprietary Information.  I hold ITAR informatrion by virtue of my service in the army, nuclear weapon construction and Joint C4I System engineering by ITAR Definition the know-how in my head is ITAR Controlled.
The pursuit of the CMMC L3-5 in the current atmosphere is like traveling the Yellow Brick Road to get an audience with the Great Wizard, OZ to ask for a miracle.  I'm the 'Scarecrow' in the 'Wizard of Oz,' as I need more brains than I've got if I'm going to pose answers to chicken and egg scenarios like the above from my colleague. 
Like the Tin Man who's lacking heart, I'm more concerned about ensuring that the work we do to prepare for CMMC L3 is going to pay off, as we are implementing the various controls to the best of our abilities, and know-how. It's discouraging to imagine that all our good work can go down the drain and need to be reworked in a new O365 tenant and a new Azure tenant based on "GCC High" and in "Gov cloud."
To round it out, I'm the 'Cowardly Lion' in need of courage such that I am able to provide guidance that sets forth a mandated line in the sand. As a cowardly lion bolstered by confidence in my sources, I will create vetted road map that leads us safely down the yellow brick information super-highway keeping us safe from the wicked witch of chicken and egg debates. 
Oh Great Oz, (Ozes?), what are the sources of guidance that give us small DIB contractors brains, heart, and courage enough to create a standards-based approach to CUI, O365 licensing, and Azure landing zone type (gov cloud) such that we can achieve CMMC L3 compliance? Oh, while avoiding the chicken-and-egg witches out there.
Thanks in advance for granting me an audience.

I came to this page trying to understand the architecture of Azure ("commercial" and "government") and its impact on our planned implementations of MS Teams/InTune as well as on compliance to CJIS for our Office 365 and for our new backup solution (which the vendors are telling us could use either Azure commercial or government).  Anyone at Microsoft: please correct me if i am wrong in my reading of this article. As an SLTT:

  1. our Azure AD is in the Azure Commercial (it is) as it should have been 
  2. building out virtual servers for InTune in Azure GCC is wrong since it cannot use our existing Azure AD (we are being told this, but it seems like it would work from what I read here)
  3. establishing an organizational root CA should be done now for both MS Teams (and either now or future AIP deployment) and for the new backup solution.  The root CA could be on-premise or in Azure (Commercial or GCC).  If on-premise, it could also be "tied" to an already pubic ally trusted certificate authority (e.g., Entrust).  And, if InTune/MS Teams in GCC cannot make use of our Commercial Azure AD, that root CA would dictate the use of Azure commercial for both MS Teams and the new backup solution.
  4. We've confirmed that control of our encryption key within the organization is sufficient for CJIS on the backup solution.  #3 does not break such compliance only if we use/set up an on-premise root CA.
  5. Is establishing an organizational root CA now additionally necessary for ensuring police emails, devices managed by InTune, files in SharePoint and OneDrive, and files moved by MS Teams (all in our existing Azure Commercial cloud) are protected up to CJIS standards, or do the police need to move to the GCC of the Azure government series? And, if the latter, what all needs to be in there?
  6. What else is needed to of the current Office 365 (in commercial) in order to meet CJIS requirements? (this may be a question for our State)

Please feel free to reply and post here as well as directly to me.  Thank you.


Klaw; good question and not the first time I have heard it. I think though its easy to conflate some issues. Export data is typically associated or aligned with NOFORN requirements although NOFORN can be applied to far more than export data. O365 provides GCCH with explicit intent to support export data. When I use the term export data I am referring to DDTC standards and ITAR. NOFORN is orthogonal. And anecdotally; since we do not yet offer any features to perform a direct backup the data resident in the human mind I think your colleague is safe with their ITAR knowledge ;) I have spoken before to the fact that the _maturity_ of the services is not what is fundamentally different when you contrast MT, GCC, GCCH & DoD. What does change is (a) the scope of controls being added for each 'higher' level as well as (b) the increased 'rigor' of the control values. This is where a customer should focus on making a decision on what service is most appropriate for them since risk acceptance is ultimately their decision i.e. do they require the added controls, or the added rigor at available in GCCH? They may require such for different reasons. Some customers see explicit interpretations of requirements satisfied in GCCH compared to GCC. Others see benefits of competitive differentiation. Etc. Those that have heard me speak on this know I have no desire to police our customers. My intent is always to ensure they can make the most informed decision. Because migration is not fun. And the unfortunate reality is that I have experienced far more customers that decide to migrate part or all of their business to GCCH than I have seen decide to 'down level'. In summary: 


a) it is ultimately the customers decision & responsibility to determine where their requirements are best met; and a critical lesson learned we have observed is ensuring that your stakeholders are in alignment (if not agreement) on risk decisions
b) NOFORN & export are not 100% mutually inclusive. See section 126 of the DDTC regarding export license etc. But if you want explicit contractual support for export data then you will only get that from M365 in GCCH. 
c) Similarly, "maturity" and "control scope" are at best orthogonal. Process maturity can be represented at parity between our services where control scope cannot as it differs by design. If you as a customer accept FedRAMP Moderate as sufficient for your CSP to enable you to meet the CMMC levels you need that is your decision. Customers have widely variant risk appetites; some feel GCCH is necessary; others feel Commercial is sufficient.
We recommend the alignment we do based on our experiences with regulators, auditors, and customers of all sizes in addition to designing different services for different purposes; all in order to ensure that regardless of the decisions made that customers feel they are well informed.  
Senior Member

Hello @RichardWakeman and @Shawn_Veney.  At an event last year I asked @RichardWakeman if there was any difference when declaring an incident in GCC and GCC High.   He stated that the reporting was the same.  I assume that means attestations letters for GCC and GCC High are also the same?  Would you mind providing some background into how Microsoft responds to the (e) of the DFARS 252.204-7012 "preserve and protect images of all known affected information systems?  I am not aware of any large SaaS provider who is able to provide images but wanted to bring it to the forefront for discussion. 


Thank you for both again for creating this blog.  I reference it often.



(e)  Media preservation and protection. When a Contractor discovers a cyber incident has occurred, the Contractor shall preserve and protect images of all known affected information systems identified in paragraph (c)(1)(i) of this clause and all relevant monitoring/packet capture data for at least 90 days from the submission of the cyber incident report to allow DoD to request the media or decline interest.


Minor note: the map doesn't highlight Alabama in green, though it's listed below the map as a state for CJIS.



@SvenAelterman Thank you for pointing this out.  I updated the map and even added another state to the list.

New Contributor

@RichardWakeman The "Microsoft 365 Government (GCC High)" table shows that M365 GCC High has FedRAMP High accreditation. Is the FedRAMP High accreditation for M365 GCC High only for GCC High M365 license or does the FedRAMP High accreditation also apply to other GCC High licenses such as the GCC High Office 365 E3/EMS license?


@Terry Hebert - apologies for length of time to answer your 6/20 question and thanks for the reminders ;)


Rephrased: "How do we address the DFARs 7012(e) requirement regarding image retention and packet capture?"


This was initially an area of concern for exactly the point you brought up. Cloud data architecture for hyperscale providers typically cannot fulfill this requirement _as written_ in any commercially feasible manner. That said; the objective of the requirement can be met. This has often been a 'fundamentals' topic of discussion as it supports many other discussions than just this DFARs rule. So let's walk through the details for a deeper understanding to enable y'all to have this discussion and understand both why & how this is achieved differently than written. 


Data Architecture Challenge: Cloud data architecture often involved various forms of 'chunking' data into small portions and distributing it across a wide array of infrastructure. This actually results in improved performance and resiliency. It has an added benefit of providing another layer of abstraction against attackers due to the data 'chunks' often being encrypted and therefore requiring decryption and indexing for any meaningful reconstruction. An unintended benefit is that now a single blob object such as a file of interest from a CUI/DFARs/CDI perspective may be stored across dozens or hundreds of physical devices depending on the size of the document. Multiply this by the number of documents possibly impacted in the investigation of an incident and it can result in thousands of physical &/or virtual devices being 'in scope' in the literal translation of this requirement. So let's keep that in mind as we discuss the next point. 


Forensic/Investigation scope of analysis Challenge: Another 'fundamentals' issue is clear understanding of the difference between the scope of responsibility in the investigation of an incident from the tenant vs service provider perspective. Pulling back a bit the first important concept to embrace when assessing scope of responsibility is to understand scope of management responsibility (think section 9 of a SSP where the accreditation boundary is defined by the entity). This understanding allows a bright line to be accepted between the scope of tenant management of the service versus service provider management of underlying systems and infrastructure. Applied to investigation this naturally progresses to where the tenant is responsible to analyze all application level log data regarding configuration and use and the service provider would analyze all system level data regarding management of the underlying infrastructure. Each party defines the context surrounding data lending itself into comprehending what an anomaly or deviation is in the context of their management of their scope of responsibility. This is important to embrace because it means that when a tenant experiences an event or incident and conducts investigation that they understand they are equipped to perform this independent of the service provider i.e. the tenant owns the data necessary to identify anomalistic, unauthorized or otherwise concerning behavior from application telemetry they should be analyzing under their scope of control responsibility already. This is also true of the service provider. And both parties possess a unique context of comprehension that cannot be easily shared i.e. even if a service provider shared all the underlying system log data (often inappropriate for multi-tenancy systems) the tenant lacks the architectural understanding of service construction and deployment to accurately assess issues. The same is true for the service provider as they cannot identify what the tenant has (or has not) authorized for appropriate configuration, exception, deviation, muse patterns for groups or specific users, etc. The primary difference being that the likelihood of a tenant incident requiring notification of the service provider is much smaller than the converse. The intent of most service providers is to ensure as much autonomy of the tenant as possible and to commit to notification of the tenants if impacted by an incident in the scope of the service providers responsibility. 


So now taking just these two challenges into consideration lets assess the objective of sub paragraph (e). The intent is to ensure defensible data to facilitate accurate and defensible investigation implying that such defensibility can withstand scrutiny if the service provider or tenant needs to provide such data in support of more formal investigations under regulatory requirements. As we see in the first challenge regarding data architecture; there is no commercially feasible method of retaining 'images' of systems as it would require a complete replication of the underlying service to provide the indexing and decryption capabilities for all impacted systems. Furthermore it violates our principles to perform and packet capture of tenant actions. A service provider might do that for the behavior of their own staff in support of the service but it should be generally unaccepted that a service provider would perform packet capture and inspection of tenant traffic (unless of course that's part of a feature i.e. security features designed to analyze traffic &/or message content). Is an image the only defensible method to amass the data necessary to validate what occurred in an incident? No. Our position is that this is exactly why the AU control family exists and that between the scope of service provider and tenant responsibility that each party already has the _forensically relevant_ data necessary to conduct their respective investigations. This position also aligns nicely with the previous scope of responsibility point; because any packet capture or other retention of relevant data should be constrained to the appropriate scope of control of each party to ensure respect of boundaries. 


What is "forensically relevant" then? 


This term "forensically relevant" is important as it's the term I chose to adopt when constructing our attestation memorandum on DFARs (available for both GCC & GCCH as they rely on the same underlying controls from 800-53). In reading our attestation memorandum it can be noted that we've attempted to be clear that our intent is to support the requirements objective by ensuring retention of all "forensically relevant" information related to an incident. In this way my intent is to demonstrate adherence to the spirit of the requirement rather than the letter as the letter is simply not commercially feasible in most cloud solutions at scale. 


What does this mean for you the tenant? Probably three things: 


1) You will want to ensure you have a copy of the attestation memorandum for the service you reside in stored along with your other accreditation artifacts; and that you are comfortable being able to speak to (e) or your organization knows that if questions arise about the service providers stance that we remain available to help address them with auditors etc. Note: In my experience many auditors have become much more technically competent on these issues in the past 5-7 years but our industry is not renown for agility when it comes to adaptation of change regarding regulatory issues. So feel free to reach out as needed. 


2) You will want to ensure that your IR (Incident Response) processes reflect this understanding i.e. that IR processes regarding cloud service consumption are clear on the scope of data available to the tenants IR team(s) for analysis in contrast to the service providers scope of responsibility. I often recommend this should be rehearsed at minimum *prior* to cloud adoption but annual rehearsal supports control requirements and is a pragmatic (affordable) way to ensure the first time a tenant encounters a major incident that they are not confused about which party owns which data and what scope of investigation and why. Attempting to grasp the impact of these issues the first time in a real world incident tends to be less than ideal.


3) Healthy internal feedback between operations and investigations teams. This last point sounds like common sense but often overlooks implied issues that arise out of discussions like this i.e. the value of rehearsal and operational input on the log data being harvested for analysis. Tenants can often err to either side (too much or too little data retained for too long or not long enough etc.). Healthy internal checkpoints help ensure that the data being harvested from logs remains relevant to ongoing investigations; is retained as needed; &/or is formally modified over time as needed (even if from a lightweight governance process that generates defensible evidence of ongoing management of the data necessary to support investigations). 


I know this response was lengthy; but I hope it helped provide deeper context (for those of you that have read the attestation memos) on why the language of subparagraph (e) (or elsewhere) might deviate from the boilerplate type of language many of us grew up with managing our on-prem systems. Thanks again for your patience and polite reminders of your open question Terry. Always appreciate the keen inquiries as they help many others gain insight into the thinking behind 'why things are different'. 




@John_Igbokwe The accreditation boundary for the US Sovereign Cloud surrounds all of Azure Government and Microsoft 365 Government (GCC High).  Think of Microsoft 365 as being the superset of SaaS solutions, packaging Office 365, EMS and Windows 10 Enterprise.  As such, any of the components (e.g. Office 365) may be transacted separately, but are still within the same accreditation boundary for GCC High.

New Contributor

@RichardWakeman Thank you!

New Contributor

Hi @RichardWakeman! Can you please verify that the MS Authenticator Android/iOS app uses FIPS validated crypto modules to generate the TOTP codes? NSA's very recently updated MFA solutions documents (page 6) indicates that it does NOT. I haven't been able to locate any Microsoft documentation on this. Thank you in advance!


Hi @RogueAgent, while it is true the Microsoft Authenticator app does not currently use FIPS validated crypto modules, it is rather a moot point for many of our customers that require it.  At the end of the day, standards and regulations such as NIST 800-53/171 will require you to enforce an MDM solution on your mobile devices.  Should you choose a device with encryption that is either FIPS validated or even certified (e.g. iOS & Knox), then you pick up the required encryption from MDM enforcement.  That said, we do have a roadmap for native encryption to use validated crypto.  There is also discussion on Intune enforcing the encryption for MDM and MAM configurations.

Senior Member

Hi! Thank you so much for this great reference; it has been very helpful in my understanding. Will this be updated from what was brought up here: https://techcommunity.microsoft.com/t5/public-sector-blog/office-365-government-gcc-is-now-fedramp-h...?


Hi @VARenee, yes I will be updating this article in the next couple of weeks.  Typically, we do not update blogs, but re-post.  It may show up with the same title and "November 2020 Update", or something like that.  TBD.

Occasional Visitor

@RichardWakeman what is the requirement from a Managed Service Provider support personnel to administer and support GCC High?  What does the term "screened US Persons" mean?  Does that imply personnel has to be a US citizen?


Sean, I'd highly recommend an MSP request a copy of the System Security Plan to understand the scope of responsibility they incur in their role based on the scope of service(s) provided. This is where you would find the details to ensure parity between what the underlying service is providing in their control scope and what the MSP would need to implement. But specific to this one control it most definitely implies citizenship.

Occasional Visitor

Great series of articles!  Have to read them a few times over to make certain I understand them entirely.  

What led me here (to this series of articles) is trying to determine why certain M365 applications operating under a GCC / G3 license are attempting to communicate overseas.  We documented MS Word attempting to communicate with Dublin, Ireland.  We have also seen the translate feature in MS Word attempting to communicate with Singapore and a number of other PacRim countries (most of which we are geofenced by our firewall).  Oddly enough, the translate feature in Outlook doesn't do that.  I have reached out to Microsoft but they have not been able to answer the question.  The communications are TLS so I do not yet know precisely WHAT they are attempting to send, but it should be relatively easy to answer the question WHY they are attempting to talk at all. 


Dave; fair question and I get a lot of variations on this i.e. why do I see OCONUS IP data in my logs etc. There are numerous reasons for this that differ based on the product or service in question. At a high level there are 3 categories of issues. First is telemetry. We manage a global service fabric and there is telemetry infrastructure worldwide to support that. Often there are system level issues being logged into the most responsive infrastructure; other times one region is checking the health, performance or for other updates to validate across the global fabric. In each of these scenarios it is important to note that in our commitments to government services we commit we will not send or store your content outside the accreditation boundary. These interactions are limited to what we classify as system data. We've invested in, and implemented, significant automation to ensure data is appropriately 'scrubbed' before it's sent to or logged into any of our underlying service repositories. Second; there are a category of issues that fit into more complex 'by design' scenarios where analysis shows that users were engaging with services, content, etc. across regions which incurred logging of OCONUS addresses etc. Lastly there have been defects at times that erroneously log data that creates false positives. In all examples our commitment is to ensure we maintain the customer data within the accreditation boundary. We cannot prevent customers from cross regional interaction; and many government customers have justifiable OCONUS missions requiring such. Ultimately this becomes a balancing act where a black/whitelist; geofencing, etc. can have unintended performance requirements. Over time I have found data layer protections much more effective than network layer due to the increasingly complex dependencies on global infrastructure as well as increasing global composition of workforces and missions. By implementing a fuller range of ZT (zero trust) capabilities we've seen much more effective protections evolving at pace with more dynamic traffic needs. I do sympathize with the challenges having been there myself in previous roles. You should be able to engage your support team to help you find answers specific to the scenarios you encounter; any recommendations we may have; where geofencing or other constraints are known to create possible performance problems etc. 

Occasional Visitor

Thank you for the quick response.  Your answers point out why this thread is so incredibly important.  There is a LOT we (government IT and the end users) don't and seemingly can't know about the interaction of the systems we use.  Unfortunately we are the ones ultimately responsible for compliance even when we don't have all the answers and the visibility we need.

The problem with Word translate is a relatively easy one to solve.  Don't use it.  Sorry.  It is attempting to communicate with a blocked country.  I don't know WHY.  It didn't used to.  But it is now.  Use the translate service in Outlook instead.  It still works for now.

In the case of the Word document communicating with Dublin, that was picked up by our EDR before the firewall noticed it.  I guess it is possible that the process associated with the document was actually the application trying to send telemetry data.  Unfortunately we can't know that for certain.

I do appreciate your very thorough explanation.  Microsoft is certainly not the only company where we experience these types of concerns.  As long as the AHJ (Authority Having Jurisdiction) continues to hold us accountable, we are going to remain suspicious.

Version history
Last update:
‎Feb 23 2021 07:53 AM
Updated by: