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. To keep this article concise, I will refrain from repeating content from the first. I recommend that you review the first article if you are unfamiliar with the architectural relationships between Azure, Microsoft 365 and Dynamics 365.

In this article, we will focus on each of the US-based cloud offerings from Microsoft and compare the differences in compliance, including the compendium of common factors customers may use to decide which of our offerings align with current and future requirements in demonstrating compliance with US Government regulations and underlying cybersecurity frameworks.

Microsoft 365 Commercial + Azure Commercial

Compliance Chart - Commercial - Mar 2022.png

FedRAMP in Azure

The US Federal Risk and Authorization Management Program (FedRAMP) was established to provide a standardized approach for assessing, monitoring, and authorizing cloud computing products and services under the Federal Information Security Management Act (FISMA), and to accelerate the adoption of secure cloud solutions by federal agencies.

You can demonstrate compliance with the FedRAMP High Impact Level in Azure to include both Azure Commercial and Azure Government. Azure has a Provisional Authorization to Operate (P-ATO) from the FedRAMP Joint Authorization Board (JAB). The JAB is the primary governance and decision-making body for FedRAMP. Representatives from the Department of Defense, the Department of Homeland Security, and the General Services Administration serve on the board. The board grants a P-ATO to Cloud Service Providers (CSP) that have demonstrated FedRAMP compliance.

You can find a full list of Azure services that meet the requirements of FedRAMP High in the Azure audit scope documentation.

For more information, please reference:

FedRAMP in Microsoft 365 Commercial

You can demonstrate compliance with the FedRAMP High Impact Level in Microsoft 365 Commercial. In fact, you can demonstrate FedRAMP High compliance in all Microsoft cloud offerings (in scope of this article). At the time of this writing, we have successfully completed a FedRAMP High Impact Level audit, including a SAR (Security Assessment Report). This is sufficient for purposes of us advertising FedRAMP High, as it completes Microsoft’s scope of responsibility towards FedRAMP accreditation for a Federal agency ATO. In other words, we support accreditation with Federal agencies at the FedRAMP High Impact Level.

The FedRAMP Marketplace for “Microsoft - Office 365 Multi-Tenant & Supporting Services” will be updated as Federal agencies are issued an agency ATO and work with the JAB to publish it. In addition, we have accreditation from the Department of Health and Human Services (DHHS) for the FedRAMP Moderate Impact Level as formally acknowledged in the FedRAMP Marketplace. DHHS and other Federal agencies are hosted in GCC tenancies, but GCC is a data enclave of Commercial, effectively extending the accreditation to the whole of the Commercial and Government clouds.

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 ‘equivalency’ in Microsoft 365 Commercial. Microsoft validates the controls for Microsoft 365 into FedRAMP holistically because we operate all instances of Microsoft 365 employing a consistent control framework and uniform implementations of controls based on the U.S. National Institute for Standards and Technology (NIST) Special Publication (SP) 800-53 (NIST SP 800-53 - a requirement of FedRAMP).

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

A common misconception by many is regarding FedRAMP as ‘the’ requirement to protect Controlled Unclassified Information (CUI) in a cloud service offering. It is important to note that FedRAMP is just one component of overall compliance relative to CUI in a shared responsibility model. For example, International Traffic in Arms Regulation (ITAR) imposes an additional set of standards from the US Department of State that requires data sovereignty (e.g. US Persons). Export-controlled data such as ITAR technical data is one of the categories of CUI, hence ITAR is one of the components of overall compliance to holistically safeguard CUI.

I often get pulled into customer conversations on suitability for CUI in the Commercial cloud. Yes, you can demonstrate compliance with FedRAMP. However, not all FedRAMP / NIST SP 800-53 implementations are the same. Each CSP has their own individual approach to FedRAMP control implementations. In addition, a CSP may even have multiple FedRAMP control implementations depending on their cloud service offerings. For example, Microsoft has the same control ‘scope’ employing a consistent control framework across our cloud service offerings. However, there are different control ‘values’, or what’s called “Organizational Defined Values” (ODV’s) that differentiate our Government clouds from our Commercial clouds.

The most notable difference in a Government cloud ODV is the requirement for US Persons. Ultimately, FedRAMP by itself is not the high watermark 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 watermark 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 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 offerings and diminish Commercial as an option.

Note: There is an entire article for Microsoft US Sovereign Cloud Myth Busters - CUI Effectively Requires Data Sovereignty

New Feature Releases in Commercial

Here is another aspect of Commercial to keep in mind. Although the FedRAMP packages cover both Commercial and Government service implementations, release of new features and services into Commercial clouds is not predicated on FedRAMP compliance the same way it is for release into Government clouds. For example, a new feature can release to Commercial cloud tenants before it has FedRAMP compliance. However, the new feature will not release to Government cloud tenants until it complies with FedRAMP. In my opinion, this is another compelling data point for our customers trying to decide on "Commercial vs Government", as there is a risk of users organically adopting new features in your tenant before the features are authorized for FedRAMP.

Note: First-party products and features developed by Microsoft follow the NIST SP 800-53 control framework out of the starting gate, accelerating the path to FedRAMP authorization and reducing the risk of using such features before authorization. However, this may not hold true for all products we ingest through 3rd-party acquisitions that could require a much heavier lift to achieve the same levels of compliance.

DFARS 7012 and NIST SP 800-171 in Microsoft 365 Commercial

This is for the Defense Industrial Base (DIB) including Aerospace and Defense (A&D) contractors of the US Department of Defense (DoD). To substantially contract with the DoD, you will likely need to demonstrate compliance with the Defense Federal Acquisition Regulation Supplement 252.204-7012 (DFARS 7012). If you have the requirement, your contracts will have a DFARS 7012 Clause, or you will be notified of a “flow-down” in sub-contracts to you. DFARS 7012 mandates the protection of CUI with an implementation of NIST SP 800-171, and FedRAMP Moderate Impact Level for clouds used to store, process, or transmit CUI. It is a set of controls that are used to secure Non-Federal Information Systems (commercial systems). NIST SP 800-171 is derived from NIST SP 800-53. Think of it as a subset of the controls that apply to the DIB. Given Microsoft uniformly implements NIST SP 800-53 in all our clouds, undoubtedly, we have coverage for NIST SP 800-171 controls in Commercial.

You will observe a caveated ‘Yes’ for both NIST SP 800-53 and 800-171.

However, there are key differences in the System Security Plan (SSP) ODV’s for Commercial as compared to what 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 7012 sub-paragraphs (c)-(g) much less tenable in Microsoft 365 Commercial.

You will observe a ‘No’ for DFARS 7012 in Microsoft 365 Commercial.

Why? 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). This is especially true for demonstrating coverage for Forensic/Investigation scope of analysis.

You may potentially demonstrate compliance with NIST SP 800-171 in a shared scope of responsibility model in Microsoft 365 Commercial. For example, you may apply compensating controls for protection of CUI. However, Commercial was not built for the regulations and standards that govern CUI. Many in the DIB believe it is a moot point though. If you cannot demonstrate compliance holistically with DFARS 7012 in Microsoft 365 Commercial, NIST SP 800-171 compliance will not be the governing factor in demonstrating your compliance to the DoD.

DFARS 7012 in Azure Commercial

As mentioned in the previous section, Microsoft 365 Commercial has a ‘No’ for DFARS 7012. However, we have announced that Azure Commercial can now demonstrate support for DFARS clause 252.204-7012 sub-paragraphs (c)-(g). We have an auditor’s attestation letter summarizing how those sub-paragraphs are supported for Azure services. This translates to a commitment where we demonstrate DFARS 7012 compliance in Azure Commercial.

Note: For more details on how we implement DFARS 7012 in Azure, please see https://aka.ms/DFARsAzure.

The introduction of DFARS 7012 in Azure Commercial offers you more choice in the selection of Microsoft cloud offerings that best suit your requirements for the protection of CUI. For example, those organizations that choose Microsoft 365 Government (GCC) deployed on top of Azure Commercial cloud regions in the US may now have paired Azure services that meet DFARS 7012 requirements. While we do not offer this same commitment for Microsoft 365 Commercial, we do offer DFARS 7012 compliance in Microsoft 365 Government (GCC) that operates in conjunction with Azure Commercial. See below for more details in the GCC section.

Commercial will not always recognize US Government requirements

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

Unfortunately, there 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 should not have been routed to offshore support personnel in Asia. That is how the global Commercial service works. If you have requirements for screened US Persons, there are Microsoft purpose-built cloud offerings exclusively for supporting US Government obligations that are more suitable to sovereignty requirements. See below in the GCC High + Azure Government section on support commitments for US Persons.

FCI in Microsoft 365 Commercial

In general, all US Government contractors have a requirement in their contracts to comply with 15 safeguarding requirements and procedures for Federal Contract Information (FCI) in the Federal Acquisition Regulations (FAR) 52.204-21 Basic Safeguarding of Covered Contractor Information Systems. These safeguarding requirements and procedures are also contained within NIST SP 800-171 controls. Thus, you may demonstrate compliance with this requirement in Commercial and Government cloud offerings.

Cybersecurity Maturity Model Certification (CMMC)

One of the most common questions I get is, “What cloud offerings meet the requirements for CMMC”?

Cybersecurity frameworks are applied to all Microsoft cloud offerings consistently across the spectrum of services. Cybersecurity 'maturity' is often represented as the efficacy of process and automation of practices. There are specific control requirements and ODV’s that are unique to each cloud offering. For example, sovereign clouds such as Microsoft 365 Government (GCC High) and Azure Government have controls in place for restricting sensitive data access to only screened US persons with data processing and storage only within CONUS. Sovereign clouds are more restricted in terms of the specificity of control requirements in relation to other cloud environments. Even though control requirements may vary from one cloud environment to another, each may demonstrate a level of cybersecurity maturity in alignment with CMMC.

In other words, you may demonstrate compliance with CMMC in the Commercial cloud. However, CMMC by itself will not be the decision factor on choosing which cloud offering is most appropriate. For example, CMMC 2.0 Level 2 and higher is intended for protection of CUI. I have captured details regarding CUI throughout this article to help you make a more informed decision.

To net it out, Microsoft recommends the following:

You may demonstrate compliance with CMMC 2.0 Level 1 for the data protection of FCI in Commercial and in our Government clouds.
We recommend the US Sovereign Cloud with Azure Government and Microsoft 365 Government (GCC High) for data protection of CUI in alignment with CMMC 2.0 Levels 2-3.

We understand you may have a different risk appetite and choose a different basis for your cybersecurity program. We do have customers that chose GCC (versus GCC High), in cases where they have CUI that does not require explicit commitments to protect CUI Specified and ITAR export-controlled data. Others have added additional compensating controls, such as FIPS 140-2 validated end-to-end encryption to protect ITAR export-controlled data. However, many in the DIB (especially the larger tier 1 prime contractors) have chosen the US Sovereign cloud due to the comprehensive data protection offered holistically across all categories of CUI.

Ultimately, this is a risk decision made by the customer in meeting their current and future requirements.

It is important to note that while cost and risk are prime decision criteria for our customers, many also consider future changes to their business strategy and scope of competition. Our Government cloud offerings are segregated environments where it is neither a short nor inexpensive customer project to relocate from one to another. If opportunities arise in the future to pursue business requiring a higher watermark for compliance, or a potential increase of work in other regions or industries, you may promote such criteria to assess in a decision of which cloud to choose. There are many criteria to assess in such a decision, but we have attempted to portray the keys ones in context of this article.

For more information, please see my blog Accelerating CMMC compliance for Microsoft cloud

Microsoft 365 Government Community Cloud (GCC)

Compliance Chart - GCC - Mar 2022.png

Scope of Services in GCC

The Microsoft 365 Government (GCC) cloud offering is a data enclave of Commercial. A data enclave in this context is a segregated environment, with servers residing in regional Azure data centers. In the case of GCC, the data enclave is in CONUS. There is a commitment to ensure data residency and data processing is in CONUS for the primary Office workloads. In addition, only screened US Persons are authorized for customer content access.

The service description for all Microsoft 365 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
Teams & Voice (Phone System & Audio Conferencing)
Office for the web
Microsoft Defender
Power BI Pro
Project Online
and more as documented in the Service availability for each plan

Given GCC is a data enclave of Commercial, there are several shared services. These shared services may have data processing globally 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 is supported globally and may have data processing (authentication) occur OCONUS along with service management by global support personnel. This is one of the reasons Microsoft will not commit to export controls in GCC.

As a result, you will 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, Azure DevOps and GitHub 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.

Customer Support for GCC and Azure Commercial

Microsoft 365 Government (GCC) customer support is provided under the same terms and conditions offered to Microsoft 365 Commercial, without assurances for agent physical location nor citizenship.

The latest version of the Customer Support Terms and Conditions for GCC (referencing the above statement) can be found here.

GCC operates in conjunction with Azure Commercial, which is supported with a global follow-the-sun support model as well. For products and services that fall under Azure Commercial, such as IaaS and PaaS deployments in the same tenant as GCC, the Azure Online Services Terms (OST) outlines coverage for customer support.

Many people are confused by this. After all, I mentioned above that GCC restricts access to restricted customer data to authorized screened US Persons only. This is true of datacenter personnel who request temporary permission elevation under management oversight, granting access to customer content only when necessary. While datacenter personnel are limited in their access to restricted customer data, customer support personnel have no direct standing access to the datacenter nor to customer content. They can only be exposed to sensitive information when it is provided directly by the Customer during a customer support ticket. We remind you not to share any controlled, sensitive, or confidential information with support personnel as part of your support incident, and follow your own internal data sharing controls, policies and procedures when engaging with Microsoft customer support.

Note: Customer Lockbox for Office 365 is a popular feature to moderate access to your data. We even have Customer Lockbox for Azure releasing to more and more Azure services.

DFARS 7012 in GCC

Microsoft 365 Government (GCC) and its conjunction with Azure Commercial can now 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. Microsoft will sign a Flow-Down for DFARS 7012 in GCC. This translates to a commitment where we demonstrate DFARS 7012 compliance in GCC. As a result of the Flow-Downs commitment, you will observe a ‘Yes’ in the GCC column for DFARS 7012.

Note: For more details on how we implement DFARS 7012 in GCC, please see https://aka.ms/DFARsGCC.

Controlled Unclassified Information is a Maybe in GCC

The NIST SP 800-60 Volume 2 registry is rather large. There are many CUI categories, to include multiple 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 they review the relevant regulations and Microsoft's offering prior to determining which Microsoft Government cloud service offering is the best fit to support their obligations for CUI.

As not all CUI Specified can be supported, you will observe a caveated ‘Yes’ in the GCC column for CUI.

CMMC in GCC

You may demonstrate compliance with CMMC 2.0 Level 1 in GCC for protection of FCI. You may also demonstrate compliance with CMMC 2.0 Levels 2-3 with notable exceptions. The intent of CMMC 2.0 Levels 2+ is to safeguard CUI. As mentioned in the previous section, GCC is not permissible for all categories of CUI. Most notably, GCC does not support export-controlled data, such as ITAR and EAR natively. As such, we recommend the US Sovereign Cloud with Microsoft 365 Government (GCC High) and Azure Government for CMMC Levels 3-5 to holistically safeguard all categories of CUI. Please see the CMMC section above in Commercial for more rationale.

You will observe a ‘Yes’ in the GCC column for CMMC L1. However, as not all CUI Specified can be supported, you will observe a caveated ‘Yes’ in the GCC column for CMMC L2-3.

FedRAMP High in GCC

You can demonstrate compliance with the FedRAMP High Impact Level in Microsoft 365 Government (GCC). Please see the section above on ‘FedRAMP in Microsoft 365 Commercial’ for more information.

DoD CC SRG in GCC and Azure Commercial

The Defense Information Systems Agency (DISA) is an agency of the DoD that is responsible for developing and maintaining the DoD Cloud Computing (CC) Security Requirements Guide (SRG). The SRG defines the baseline security requirements used by the DoD to assess the security posture of a CSP and establishes a baseline requiring a FedRAMP Moderate authorization for all information Impact Levels (IL).

SRG Section 5.1.1 (DoD use of FedRAMP Security Controls) states that IL2 information may be hosted in a CSP that minimally holds a FedRAMP Moderate authorization. Given that Microsoft 365 Government (GCC) and Azure Commercial are both FedRAMP Moderate authorized (and higher), you may demonstrate compliance for IL2. As such, there is effectively ‘equivalency’ between DoD CC SRG IL2 and FedRAMP Moderate.

For more information, please see Microsoft SRG Documentation.

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 SP 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 Azure Government, Microsoft 365 Government (GCC), and Dynamics 365 Government (GCC), and will attest to their ability in the applicable services agreements to meet FBI requirements for the use of in-scope services.

CJIS status in the United States

Microsoft CJIS States - Mar 2022.png

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

Alabama, Alaska, Arizona, Arkansas, California, Colorado, Connecticut, Florida, Georgia, Hawaii, Idaho, Illinois, Indiana, Iowa, Kansas, Kentucky, Maine, Massachusetts, Michigan, Minnesota, Mississippi, Missouri, Montana, Nebraska, Nevada, New Hampshire, New Jersey, New Mexico, New York, North Carolina, North Dakota, Oklahoma, Oregon, Pennsylvania, Rhode Island, South Carolina, Tennessee, Texas, Utah, Vermont, Virginia, Washington, West Virginia, Wisconsin, and the District of Columbia.

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.8.

Current as of March 2022 - Criminal Justice Information Services (CJIS) Security Policy - Microsoft Compliance

Note: This section also applies to CJIS in Azure Government as well.

For information from the FBI: Security Control Mapping of CJIS Security Policy

Microsoft 365 Government (GCC High) + Azure Government

Compliance Chart - GCC High - Mar 2022.png

ITAR in GCC High and Azure Government

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 and Azure Government were created to give you a commitment for export controls in the US. This includes a US Sovereign Cloud accreditation boundary encompassing all services attached to Azure Government, Microsoft 365 Government (GCC High) and Dynamics 365 Government (GCC High). For example, the network is sovereign and constrained to CONUS. The GCC High directory services with Azure AD are provided by Azure Government and are sovereign to the US.

DoD CC SRG 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. In fact, we manage the GCC High environment with the same set of control scope and ODV’s as the DoD environment. This translates to SRG ‘equivalency’ of both IL4 and IL5 in GCC High.

However, for most Federal contractors and the DIB, SRG impact level is a moot point. Technically speaking, the SRG only applies to Federal information systems. IL4 is not an authorization the DoD will provide to a non-Federal nor private-sector entity, nor is it for a CSP cloud environment not in use directly by the DoD. For the DIB, DFARS 7012 and CMMC is what applies to non-Federal information systems. As such, Microsoft has pivoted away from advertising the SRG impact levels in alignment with Microsoft 365 Government (GCC High). We now focus on how our DIB customers may demonstrate compliance with CMMC leveraging our cloud service offerings.

DoD CC SRG in Azure Government

Cloud services in Azure Government are authorized for DoD CC SRG IL2 and IL4. In addition, Azure Government has over 120 services accredited at IL5 (as of the time of this writing). These services include a broad range of IaaS, PaaS and SaaS capabilities. When supporting IL5 workloads on Azure Government, the isolation requirements can be met in different ways. Isolation guidelines for IL5 workloads documentation page addresses configurations and settings for the isolation required to support IL5 data with specific service instructions.

You can find a full list of Azure Government services that meet the requirements of the DoD in the Azure Government audit scope documentation.

For more information, please see Microsoft SRG Documentation.

DFARS 7012 and NIST SP 800-171 in GCC High and Azure Government

Microsoft will sign a Flow-Down for DFARS 7012 in GCC High and in Azure Government. This translates to a commitment where we demonstrate DFARS 7012 compliance in the US Sovereign Cloud. This includes DFARS 7012 alignment with NIST SP 800-171 in a shared responsibility model with the Customer.

Note: You may request our Attestation of Compliance with DFARS by submitting a support ticket and asking for a copy.

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 multiple FedRAMP High Impact Level audits including a SAR (Security Assessment Report). We have several Federal Agencies actively deployed in GCC High, demonstrating compliance with FedRAMP High. The FedRAMP High Agency ATO for the US Department of Justice 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 7012 compliance. FedRAMP Moderate is specifically required for DFARS 7012. And for that, we do have a Federal agency ATO currently in place covering GCC High.

FedRAMP High in Azure Government and Dynamics 365 GCC High

As described above for Azure Commercial, Azure Government has a P-ATO for FedRAMP High from the FedRAMP JAB.

As of the time of this writing, there are over 140 Azure services covered by the FedRAMP High P-ATO in Azure Government. You can find a full list of Azure Government services that meet the requirements of FedRAMP High in the Azure audit scope documentation. You may even observe that Dynamics 365 Government (GCC High) falls under the scope of the Azure Government P-ATO in the FedRAMP Marketplace.

CMMC in the US Sovereign Cloud

You may demonstrate compliance with all maturity levels of CMMC in the US Sovereign Cloud. We exclusively recommend our US Sovereign Cloud with Microsoft 365 Government (GCC High) and Azure Government for data protection of CUI in alignment with CMMC 2.0 Levels 2-3.

CJIS in Azure Government

CJIS in Azure Government is aligned with the same description as provided above in the section “Criminal Justice Information Services in GCC”.

CJIS in GCC High

Criminal Justice Information Services in Microsoft 365 Government (GCC High) is described as for “Federal” only. CJIS Information Agreements are signed primarily at the US State level. Most US States have Information Agreements established for both Microsoft 365 Government (GCC) and for Azure Government. However, those agreements are not in scope for Microsoft 365 Government (GCC High). This is because no State nor local government entities deploy into GCC High. To date, only Federal agencies and the DIB deploy into GCC High. Thus, a US State has not had the need to sign a CJIS Information Agreement for GCC High. It doesn’t mean that GCC High is non-compliant with CJIS. That is evident as the US Federal Bureau of Investigation (FBI) is deployed in GCC High. Hence, the FBI has authorized the use of GCC High for CJIS at the “Federal” level.

NERC and FERC in the US Sovereign Cloud

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 the US Sovereign Cloud with Microsoft 365 Government (GCC High) 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.

Customer Support for the US Sovereign Cloud

The US Sovereign Cloud with Azure Government, Microsoft 365 Government (GCC High) and Dynamics 365 Government (GCC High) offer differentiated support staffing, with technical support provided 24x7 by screened US Persons in a US Location. However, these terms do not preclude the use of global support staff in customer support escalations. It is not uncommon for Microsoft customer support to rely on support engineers that specialize in specific services or technologies and are experts in niche areas. These support engineers might be located anywhere in the world and could be introduced to provide subject matter expertise and guidance on a specific customer support ticket. Since customer support personnel have no direct standing access to the datacenter nor to customer content, they can only be exposed to sensitive information when it is provided directly by the Customer during a customer support ticket. We remind you not to share any controlled, sensitive, or confidential information with support personnel as part of your support incident, and follow your own internal data sharing controls, policies and procedures when engaging with Microsoft customer support.

Important: Within the US Sovereign Cloud, you may request your ticket to remain limited and restricted to “screened US Persons in a US Location” only. However, availability of the engineer may be limited to US time zones as opposed to 24x7 support. This may negatively impact the response and mitigation of the Customer support ticket.