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.
September 2024 Update - Access this article with the short URL https://aka.ms/MSGovCompliance
Microsoft 365 Commercial + Azure Commercial
FedRAMP in Azure
The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP enables government agencies to accelerate the adoption of cloud services with confidence, knowing they meet high security standards and comply with federal regulations. FedRAMP authorization is a rigorous and comprehensive process that involves extensive documentation, testing, and auditing by independent third-party assessors (3PAO). FedRAMP authorization demonstrates Microsoft’s commitment to delivering cloud services that meet the most stringent security and compliance requirements of the US Government.
You can demonstrate compliance with the FedRAMP High Impact Level in both Azure Commercial and Azure Government. Azure Commercial and Azure Government each have a Provisional Authorization to Operate (P-ATO/PA) from the FedRAMP Program Management Office (PMO). The PMO 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 PMO board. The PMO grants a P-ATO to Cloud Service Providers (CSP) that have demonstrated FedRAMP compliance and may chose not to pursue an Agency ATO as they are not mutually exclusive.
You can find a full list of Azure services that meet the requirements of FedRAMP High in the Azure compliance scope documentation.
For more information, please reference:
- Microsoft FedRAMP Documentation (https://aka.ms/fedramp)
- FedRAMP Package F1209051525: Azure Commercial Cloud | FedRAMP Marketplace
- FedRAMP Package F1603087869: Azure Government (includes Dynamics 365) | FedRAMP Marketplace
FedRAMP in Microsoft 365
Cloud services bundled together in Microsoft 365 are split into two separate sets of authorizations, Office 365 and Azure.
The Office 365 productivity services include:
Activity Feed Service (AFS) |
Information Protection (IP) |
Office Service Infrastructure (OSI) |
Cloud Input Intelligence (CII) (aka Windows Ink) |
Microsoft Teams (MS Teams) |
Office for Web |
Customer Insight and Analysis (CIA) (aka Usage Reports) |
ObjectStore |
People Card |
Exchange Online (EXO) |
Office 365 Remote Access Service (ORAS) |
Query Annotation Service (QAS) |
Falcon |
Office 365 Suite User Experience (SUE) |
Search Content Service (SCS) |
Hauk |
Office Intelligent Services (IS) |
SharePoint Online (SPO) including Project Online and OneDrive for Business |
All other services fall under Azure including (but not limited to) :
Entra ID (Azure Active Directory) |
Microsoft Cloud App Security |
Azure Multi-factor Authentication (MFA) |
Azure Information Protection |
Microsoft Defender Advanced Threat Protection (MDATP) |
Microsoft Stream |
Azure Key Vault |
Microsoft 365 Defender |
Microsoft Defender Vulnerability Management |
Azure Sentinel |
Microsoft PowerApps |
Microsoft Purview |
Intune |
Microsoft Stream |
Microsoft Secure Score |
Microsoft 365 Defender |
Power BI |
Many more… Azure compliance scope |
For the cloud services listed as in scope for Azure Commercial, we have the FedRAMP P-ATO as described in the previous section.
For the productivity services listed as in scope for Office 365 Commercial, Microsoft does not support FedRAMP. For those that have read previous versions of this blog, you may find it as a surprise that Microsoft 365 in Commercial has changed from FedRAMP High ‘Equivalent’ to ‘No’. This changed as a result of the release of the U.S. Department of Defense memorandum for ‘FedRAMP Moderate Equivalency for Cloud Service Provider’s Cloud Service Offerings’ dated December 21, 2023. The memo outlines requirements to achieve ‘Equivalency’ including a Body of Evidence (BOE) that is not in scope for Office 365 Commercial data enclaves other than for Microsoft 365 Government (GCC).
For more information, please see the section below FedRAMP in GCC.
The FedRAMP Marketplace for ‘Microsoft - Office 365 Multi-Tenant & Supporting Services’ only applies to GCC and no other data enclaves of Microsoft 365 Commercial.
The accreditation package for ‘Microsoft - Office 365 Multi-Tenant & Supporting Services‘ defines the scope of accreditation as covering the cloud services management plane and a dedicated portion of the data plane. This often confuses customers as the whole of the Commercial service is not within the accreditation boundary; only the data enclave for GCC as defined to support the accreditation package. Any customer deciding to use the Microsoft 365 Commercial service to demonstrate FedRAMP compliance or equivalency will struggle to achieve this due to how the accreditation scope is defined. In other words, the accreditation package and associated Body of Evidence (BOE) only includes the scope of accreditation for GCC.
You may wonder why the scope is different? Take access controls as an example. While the same access controls may be applied to any Commercial service data enclave (the whole of the data plane); they are applied with different Organizationally Defined Values (ODV). Both Commercial and GCC data enclaves require personnel screening validations that are tied to access control requirements:
- Commercial screening does not require US Citizenship and other US Government related requirements necessary to support the management of US government regulated data (e.g. Controlled Unclassified Information).
- GCC screening does include these requirements and validates their existence prior to any access control action.
Such differences make the Commercial service untenable for Microsoft 365 to support FedRAMP holistically in the Commercial service.
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.
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, the CUI-Specified category for ‘Export Controlled’ (CUI//EXPT) such as for data regulated by the International Traffic in Arms Regulation (ITAR) imposes an additional set of ‘Specified’ standards from the US Department of State that requires data sovereignty (e.g. US persons in US locations). Export-Controlled data such as ITAR technical data 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 Microsoft 365 Commercial cloud. While a very nuanced conversation (especially working with sub-contractors and supplier hosted in Commercial), Microsoft does not recommend it. Why? We did not create Microsoft 365 Commercial to support the management of CUI. Thus, in the table above for Microsoft 365, 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 US 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 the Continental United States (CONUS). These are what will direct you to our Government cloud offerings and diminish Microsoft 365 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. The 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 be released as Generally Available (GA) in 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 and partnerships that could require a much heavier lift to achieve the same levels of compliance.
Microsoft’s Secure Future Initiative (SFI) makes security our top priority at Microsoft, above all else—over all other features. We have evolved our security approach, with our work guided by the following three security principles:
- Secure by Design: Security comes first when designing any product or service.
- Secure by Default: Security protections are enabled and enforced by default, require no extra effort, and are not optional.
- Secure Operations: Security controls and monitoring will continuously be improved to meet current and future threats.
I invite you to read Charlie Bell’s blog on Secure Future Initiative (SFI), as it has been driving security that is helpful for compliance as well.
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). It also applies to Federally Funded Research and Development Centers (FFRDCs), University Affiliated Research Centers (UARCs), energy and healthcare organizations. 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 and Covered Defense Information (CDI) with an implementation of NIST SP 800-171, and FedRAMP Moderate ‘or Equivalent’ 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 (predominately in the private sector).
Due to not supporting FedRAMP in Microsoft 365 Commercial, you will observe a ‘No’ for DFARs 7012.
DFARs 7012 in Azure Commercial
As mentioned in the previous section, Microsoft 365 Commercial has a ‘No’ for DFARs 7012. However, Azure Commercial can demonstrate support for DFARS clause 252.204-7012. We have an auditor’s attestation letter summarizing how DFARS 7012 is 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 coverage 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 in US locations, 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.
Regulation Changes Impact to Commercial versus Government
Recent updates to FedRAMP “Equivalency” requirements highlight the ongoing evolution of U.S. government standards and regulations. Industry has an obligation to mature cloud service offerings and consumption practices to match and even exceed these security and compliance requirements set forth by the US government (and preferably as proactively as possible to reduce undue churn and reactive burdens). While Microsoft strives to align all our cloud service offerings to the same set of security controls and practices as reasonably practical, Commercial services achieving government certifications like FedRAMP should not be presumed unless specifically stated. It's crucial for customers to stay informed about these changes to avoid non-compliance risks.
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 (FAR 21). You may demonstrate compliance for the FAR 21 in Commercial to protect FCI, but there is a caveat. Microsoft 365 Commercial is not intended for US Government requirements. There is a risk that changes in regulations may lead to non-compliance in the future. Ultimately, it is a risk decision your organization will need to make.
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 ODVs 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, transmission 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 depending on what level you are pursuing. CMMC by itself should not be the only 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. However, there is a caveat mentioned above that Microsoft 365 Commercial is not intended for US Government requirements. The safer long-term risk posture is to use our Government cloud service offerings.
- 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-Basic that does not require explicit commitments to protect CUI-Specified and ITAR/EAR export-controlled data. Others have added additional compensating controls, such as FIPS 140-2 validated end-to-end encryption to protect 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 migrate 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.
Microsoft 365 Government (GCC)
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 infrastructure residing in Azure regions. In the case of GCC, the data enclave is in CONUS and paired with Azure Commercial US regions. 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 in US locations 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, Entra ID (formerly Azure Active Directory) in Azure Commercial is shared with GCC. Entra ID 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 along with a caveat for CMMC Levels 2-3.
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 Product Terms outlines coverage for customer support.
Many people are confused by this. After all, I mentioned above that GCC restricts access to restricted customer content 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 content, 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: Microsoft Purview Customer Lockbox 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
As mentioned in the section for DFARS 7012 in Commercial, this applies to the DIB, FFRDCs, UARCs, etc. working with the DoD. Ultimately, NIST SP 800-171 is holistically derived from NIST SP 800-53. Think of it as a subset of the controls that apply Non-Federal Information Systems. Given Microsoft uniformly implements NIST SP 800-53, in accordance with Appendix C of 800-171, we have coverage for NIST SP 800-171 controls in GCC.
In addition to NIST SP 800-171, GCC and its pairing with Azure Commercial 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. Microsoft will support 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? This is especially true for the DoD CUI Program Registry. 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-Specified categories to include Defense, Export Controlled, 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 caveats. 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 2-3 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 in GCC
For the productivity services listed as in scope for Office 365, you can demonstrate compliance with the FedRAMP High Impact Level in the GCC data enclave. At the time of this writing, we successfully completed multiple FedRAMP High Impact Level audits, including a Security Assessment Reports (SAR). This is sufficient for us advertising FedRAMP High ‘Equivalency’, 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.
Microsoft validates the controls for Office 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 US National Institute for Standards and Technology (NIST) Special Publication (SP) 800-53, Revision 5 (NIST SP 800-53 - a requirement of FedRAMP).
The FedRAMP Marketplace for ‘Microsoft - Office 365 Multi-Tenant & Supporting Services’ lists our package with Agency ATOs from over 30 different Federal Government Agencies for FedRAMP Moderate Impact Level. In brief, this means the FedRAMP PMO has completed its review of one or more Agency ATOs. It also indicates the FedRAMP PMO is satisfied that Microsoft meets the FedRAMP requirements and had earned a listing on the Marketplace as ‘Authorized’. With the Agency ATOs in place, the FedRAMP PMO will not complete a P-ATO for Office 365 as that would be redundant to Agencies’ work and is not mutually exclusive.
Together, the P-ATOs for Azure Commercial along with the Agency ATOs for Office 365 (GCC) provide holistic coverage for FedRAMP authorizations covering the Microsoft 365 Government (GCC) suite of cloud services.
For more information, please reference:
- Microsoft FedRAMP Documentation (https://aka.ms/fedramp)
- FedRAMP Package MSO365MT: Office 365 Multi-Tenant & Supporting Services | FedRAMP Marketplace
StateRAMP in GCC
StateRAMP is a non-profit membership organization comprised of CSPs, government officials, and 3PAOs. The StateRAMP standard is based on the NIST 800-53, Revision 5 catalog of security controls along with FedRAMP, and enables state and local governments to manage third-party risk and verify cloud security. Cloud solutions that secure StateRAMP certifications are listed in its Authorized Products List. States that are required to have their own cybersecurity standards have extended reciprocity with the StateRAMP certification or adopted StateRAMP as their standard. Microsoft helped to develop the StateRAMP standard and continues to support its role in US state and local government cybersecurity.
As mentioned above in the section on FedRAMP in Azure, both Azure Commercial and Azure Government each maintain FedRAMP High P-ATOs issued by the FedRAMP PMO in addition to Moderate and High Agency ATOs issued by individual federal agencies for the in-scope services.
The following cloud service offerings have achieved the StateRAMP Authorized Security Status for the High Impact Level as shown on the Authorized Products List:
- Microsoft 365 Government (GCC)
- Azure Commercial
- Azure Government
- Dynamics 365 Commercial
- Dynamics 365 Government (GCC)
For more information, please reference StateRAMP - Azure Compliance
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 dominant 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
48 states and the District of Columbia with management agreements, highlighted on the map in green include:
Alabama, Alaska, Arizona, Arkansas, California, Colorado, Connecticut, Delaware, Florida, Georgia, Hawaii, Idaho, Illinois, Indiana, Iowa, Kansas, Kentucky, Louisiana, Maine, Maryland, Massachusetts, Michigan, Minnesota, Mississippi, Missouri, Montana, Nebraska, Nevada, New Hampshire, New Jersey, New Mexico, New York, North Carolina, North Dakota, Oklahoma, Ohio, 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 April 2024 - 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
ITAR in GCC High and Azure Government
These cloud services are purpose 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-Specified categorized as Export Controlled (CUI//EXPT), especially for ITAR and EAR. 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 Entra ID 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 (aligned with FedRAMP High). In fact, we manage the GCC High environment with the same set of control scope and ODVs 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 entities, 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 and private sector 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/FFRDC/UARC customers may demonstrate compliance with CMMC leveraging our cloud service offerings.
That said, we often get pulled into customer conversations where they have a contract with the US DoD including a CC SRG IL5 requirement. The DoD is telling their prime contractor “You must put this data in an IL5 environment” with no exceptions. However, the environment is in the contractor’s information systems. The DoD does not certify a contractor’s environment for the CC SRG, regardless of whether it’s on-premises or in the cloud. As such, the CC SRG does not apply to contractor-owned environments. It’s impossible for a contractor to certify their information systems as IL5 because it’s not a DoD-owned environment. As such, I break it down this way…
- Gov’t Owned, Gov’t Operated (GOGO) = CC SRG IL 2/4/5 (NIST SP 800-53) under DISA security cognizance.
- Gov’t Owned, Contractor-Operated (GOCO) = CC SRG IL 2/4/5 (NIST SP 800-53) under DISA security cognizance. The Contractor masquerades on-behalf of the DoD.
- Contractor-Owned, Contractor-Operated (COCO) = DFARS 7012 + CUI-Specified protections (e.g. DDTC regs for ITAR). DISA does NOT have security cognizance. CMMC will in the future.
An older slide (circa 2017) but still helpful in visualizing the below breakdown between GOGO (DoD Information Systems), GOCO (Systems Operated on Behalf of the DoD) and COCO (Contractor’s Internal System) and the appropriate alignment with NIST 800-171 vs SRG.
Reference from ‘Protecting the DoD’s Unclassified Information’
We are IL5 compliant for the DoD cloud we provide for GOGOs and GOCOs. In accordance with the requirements imposed by the DoD, Microsoft will not allow COCOs in the DoD cloud. Only the DoD can sponsor tenancy in that service, yet they have not allowed any COCOs to date. If a customer feels they require a cloud service accredited at IL5, this is an issue they need to raise with the DoD. IL5 is defined as to restrict tenancy to only entities authorized by DISA.
We offer IL4 ‘Equivalent’ cloud services in GCC High. It’s ‘Equivalent’ because the DoD has not granted IL4 to GCC High since they have no intent from their mission owners in the DoD consuming that service (instead intending them to utilize the DoD cloud services).
If a contractor has DoD compliance requirements for a COCO, we expect those to fall under security cognizance for DFARS 7012 and CMMC that GCC High can support.
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 (148 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. The Isolation guidelines for IL5 workloads documentation 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 reference:
- Department of Defense Impact Level 4 - Azure Compliance
- Department of Defense Impact Level 5 - Azure Compliance
DFARs 7012 and NIST SP 800-171 in GCC High and Azure Government
Microsoft will support 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 access our Attestation of Compliance with DFARS included with our Body of Evidence (BoE).
FedRAMP High Equivalency in GCC High
You can demonstrate compliance with the FedRAMP High Impact Level in GCC High. We successfully completed multiple FedRAMP High Impact Level audits, including Security Assessment Reports (SAR). This is sufficient for purposes of us advertising FedRAMP High ‘Equivalency’, as it completes Microsoft’s scope of responsibility towards FedRAMP authorization for a Federal Agency ATO. The FedRAMP PMO now has the task to review the Agency ATOs and Microsoft’s submitted Body of Evidence (BOE).
We have several Federal Agencies actively deployed in GCC High, demonstrating compliance with FedRAMP High. The Agency ATOs include but are not limited to the U.S. Department of Homeland Security (DHS), the U.S. Department of Justice (DoJ), the U.S. Federal Bureau of Investigation (FBI), and the U.S. Department of the Treasury.
Note: The FedRAMP High Impact Level is not a requirement for DFARs 7012 compliance. FedRAMP Moderate ‘or Equivalent’ is specifically required for DFARs 7012.
For more information, please reference:
- Microsoft FedRAMP Documentation (https://aka.ms/fedramp)
- FedRAMP Package FR1824057433: Microsoft Office 365 GCC High | FedRAMP Marketplace
- Body of Evidence (BoE) section below
As discussed in the section for FedRAMP in Microsoft 365 Commercial, holistic coverage for Microsoft 365 includes both Office 365 productivity services and Azure services bundled together. The section below on Azure Government includes all the cloud services that fall in-scope for the Azure Government P-ATO.
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 PMO.
There are over 140 Azure services (161 services as of the time of this writing) covered by the FedRAMP High P-ATO in Azure Government. You may even observe that Dynamics 365 Government (GCC High) falls under the scope of the Azure Government P-ATO in the FedRAMP Marketplace where the P-ATO is recognized as ‘Authorized’ by the FedRAMP PMO.
FedRAMP 3PAO Assessments
The Third-Party Assessment Organization (3PAO), Kratos Defense & Security Solutions, conducts the annual assessments of both Office 365 and for Azure utilizing the FedRAMP High Baseline security controls. As part of the assessment, Kratos applies the NIST SP 800-30, Revision 1 methodology to identify system risks based on likelihood, impact, and risk exposure.
The security requirements for FedRAMP High are met as follows:
- NIST SP 800-53 Revision 4 requirements validated by Kratos based on this analysis and analysis conducted during the annual assessment
- Federal Information Processing Standards (FIPS) Publication 199 requirements validated by Kratos based on this analysis and analysis conducted during the annual assessment
- FIPS Publication 200 requirements validated by Kratos based on this analysis and analysis conducted during the annual assessment
- NIST SP 800-60 requirements validated by Kratos based on this analysis and analysis conducted during the annual assessment
- NIST SP 800-61 requirements validated by Kratos based on this analysis and analysis conducted during the annual assessment
The result of the 3PAO assessment includes a Security Assessment Report (SAR), a Security Assessment Plan (SAP) and letters of attestation found in the Body of Evidence.
FedRAMP Body of Evidence
The FedRAMP Body of Evidence (BoE) is a collection of documents, artifacts, and evidence that demonstrate the security controls implemented by a CSP to demonstrate compliance with the FedRAMP security control baseline through an assessment conducted by a FedRAMP authorized 3PAO. It provides a comprehensive record of the security measures in place to protect federal data.
Office 365 and Azure’s BoEs include the following:
- SSP: The System Security Plan provides an overview of the security requirements for the Cloud Services and describes the controls in place or planned for implementation to provide a level of security appropriate for the information to be transmitted, processed or stored by the system.
- CIS & CRM: The Control Implementation Summary (CIS) report includes control implementation responsibility and implementation status of the FedRAMP security controls. Also included in the CIS is an Excel spreadsheet for the Customer Responsibility Matrix (CRM). The CRM identifies what controls are inherited from the cloud service provider, versus those controls that are the responsibility of the customer (tenant owner). Most importantly, the CRM identifies the controls that are shared responsibility of both the CSP and the customer.
- SAR: The Security Assessment Report is generated by the 3PAO during the annual assessment.
- SAP: The Security Assessment Plan (SAP) lists the scope and security controls selected for annual assessment by the 3PAO.
- Penetration Testing Report: Cloud penetration testing report produced by Azure FedRAMP High and DoD SRG compliance program.
- DFARs Compliance Attestation Letter: Attestation of Compliance with Defense Federal Acquisition Regulation Supplement (DFARs) clause 252.204-7012.
- CMMC Compliance Attestation Letter: Attestation of Compliance with Cybersecurity Maturity Model Certification (CMMC) Requirements.
For more information on the specific requirements for a BoE, please review the U.S. Department of Defense memorandum for ‘FedRAMP Moderate Equivalency for Cloud Service Provider’s Cloud Service Offerings’ dated December 21, 2023.
The BoE is considered highly sensitive and confidential information. Historically, many CSPs have not been willing to share their BoE with customers, especially for Government cloud offerings. However, Microsoft is transparent and will allow for customers of our government solutions to access the BoE under a Non-Disclosure Agreement (NDA). To request the BoE, you must be a customer and make an E-mail request to:
- Office 365 GCC High: O365FedRAMP@microsoft.com
- Azure Government: AzFedDoc@microsoft.com
Note: If you have your Microsoft NDA handy and can provide the document ID, it can save time during the request.
DoD Memo for FedRAMP Moderate ‘Equivalency’
The DoD memorandum for ‘FedRAMP Moderate Equivalency for Cloud Service Provider’s Cloud Service Offerings’ establishes the definition of ‘Equivalency’. Please note the second paragraph of the memo:
This memorandum does not apply to Cloud Service Offerings (CSOs) that are FedRAMP Moderate Authorized under the existing FedRAMP process.
With this established, any cloud service that falls under the Azure Government P-ATO is fully covered and advertised in the FedRAMP Marketplace as ‘Authorized’.
For the Office 365 GCC High cloud services, we can demonstrate compliance with FedRAMP Moderate ‘Equivalency’ with our BoE in the manner the memo describes. Fundamentally, the memo requires a CSP to do all the activities leading to a FedRAMP Agency ATO or P-ATO, minus the FedRAMP PMO’s review. Microsoft has done the FedRAMP Agency ATO process numerous times and is in the process of finishing the PMO’s review. Microsoft’s BOE will suffice to meet any FedRAMP Moderate equivalency review by assessors and members of the Defense Industrial Base (DIB).
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/FFRDC/UARC 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 subject matter experts in niche areas. These support engineers might be located anywhere in the world and could be introduced to provide 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 subject matter 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.
Note: Microsoft Purview Customer Lockbox is a popular feature to moderate access to your data. We even have Customer Lockbox for Azure releasing to more and more Azure services.
Considerations for US person-only Tenant for Government Clouds
This is an organizational decision, and not one that is required to achieve compliance.
There are no restrictions for US persons nor for citizenship checks imposed by Microsoft on tenant owners (organizations) giving access control to their tenants in US Government cloud service offerings. As with all Cloud Service Providers (CSP), it is a shared scope of responsibility for compliance. Microsoft commits to personnel that are US persons on the back end with the CSP specific scope of responsibility, but it is the organization’s (customer’s) responsibility to protect their content according to their own regulatory requirements.
Microsoft 365 Government (DoD)
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 DoD regions for Microsoft 365 and Azure Government.
That said, if you are a DoD contractor with requirements for DoD CC SRG IL5, please read the section above on ‘DoD CC SRG Equivalency in GCC High’.
Azure Government Secret + Office 365 Government Secret
DoD CC SRG in Azure Government Secret
CC SRG IL6 is reserved for the storage, processing and transmission of information classified up to the Collateral Secret level. For a hyper-scale cloud offering, information that must be processed and stored at IL6 can only be hosted in an air-gapped government community cloud. Because of the requirement that the entire cloud infrastructure be dedicated and separate (air-gapped) from other CSP infrastructures, IL6 may only be provided by CSPs under contract to the DoD or a federal agency.
Azure Government Secret maintains an IL6 P-ATO at the high confidentiality, high integrity, and customer-determined availability (H-H-x) information categorization. In addition, DISA is the primary Authorizing Official (AO) for Azure Government Secret, with all other Secret compliance frameworks recognizing a program of reciprocity with the DoD CC SRG. Over 67 Azure Government Secret services are accredited for IL6 as of the time of this writing. These services include a broad range of IaaS, PaaS and SaaS capabilities. We have many more services in the queue for authorization by DISA as we speak.
Note: Azure Government Secret is the first and only classified cloud service offering (CSO) to have received the highest possible P-ATO at the H-H-x information categorization.
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 reference:
- Department of Defense Impact Level 6 - Azure Compliance
- Azure Government for national security
- Introduction to Microsoft Azure Government Secret
- Announcing new Azure Government capabilities for classified mission-critical workloads
DoD CC SRG in Office 365 Government Secret
Since announcing the general availability of Azure Government Secret, our mission has been to support all US government agencies, departments, municipalities, public sector employees and industry with IL6 compliant productivity and collaboration tools. Office 365 Government Secret is authorized for IL6 and generally available for use by the DoD today with hundreds of thousands of seats actively deployed. In addition, this O365 environment is built to support the DoD along with US Federal Civilian, Intelligence Community (IC), and US government partners (industry) working within the Secret enclave with our SaaS capabilities.
For more information, please reference Announcing Office 365 Government Secret cloud.
National Industrial Security Program Operations Manual
The National Industrial Security Program (NISP) has oversight by the DoD’s Defense Counterintelligence and Security Agency (DCSA). Just as facilities and individuals require a clearance to gain access to classified information, cleared contractor Information Systems (IS) must be assessed and authorized prior to processing classified information.
DCSA serves as the Authorizing Official (AO) for contractor IS, such as for Contractor-Owned & Contractor-Operated (COCO) Internal Research & Development (IRAD) environments. The NISP has published guidance for industry to properly manage and protect against unauthorized disclosure of classified information, including Collateral classifications (Confidential & Secret). The NISP has recognized a program of reciprocity with the DoD CC SRG IL6 including authorizations for use of cloud by industry based on the NISP Operations Manual (NISPOM).
You can now demonstrate compliance with the NISPOM and achieve an ATO using Azure Government Secret.
Note: Azure Government Secret is the first and only classified cloud service offering (CSO) to be authorized by the NISP with industry partners connecting to our hyper-scale cloud using non-government (aka ‘private’) COCO networks.
Joint Special Access Programs Implementation Guide
A Special Access Program (SAP) is a highly classified program established to protect sensitive information and impose enhanced security measures with compartmentalized access requirements that go beyond what is typically required for information at the same (Collateral) classification levels. In addition to Collateral controls (e.g. IL6 & NISPOM), a SAP imposes more rigorous requirements, non-disclosure agreements (NDA) to get ‘read-in’ to the program, special document markings, etc. Within the DoD, a SAP is better known with Special Access Required (SAR) markings.
Note: Word to the wise, when talking about SAP with your fellow cybersecurity fellows, make sure you differentiate between SAP for classified IS, as opposed to the ERP company solutions. It’s amazing how often you can talk past each other!
A big difference between Collateral versus SAP/SAR requirements is requiring cleared personnel, facilities (SAPF) and IS to be ‘read-in’ to the program, effectively compartmentalizing access to the individual program.
The Joint Special Access Programs Implementation Guide (JSIG) provides standardized policies for cybersecurity and information assurance, procedures, and implementation guidance for use in the management of IS at all classification levels under the purview of the SAP Authorizing Official (AO). Based on NIST SP 800-53, the NIST Risk Management Framework (RMF) and JSIG Protection Levels (e.g. PL2, PL3), JSIG includes the compliance control set required to achieve an ATO for SAP IS environments.
Azure Government Secret maintains JSIG ATOs at Protection Levels up to 3 (PL3).
For more information, please reference Joint Special Access Program Implementation Guide - Azure Compliance
Intelligence Community Directive
Intelligence Community Directive (ICD) 503, also known as ‘Risk Management for Federal Information Systems’ is a standard developed by NIST in collaboration with the US Intelligence Community (IC) for risk management and certification of IS across the IC. It provides a framework for managing risk and ensuring the confidentiality, integrity, and availability of information systems within US Federal agencies. ICD 503 is closely related to the NIST RMF and enables the IC to use NIST and Committee on National Security Systems (CNSS) standards for security assessments.
Azure Government Secret maintains ICD 503 ATOs with classified facilities authorized according to ICD 705.
For more information, please reference Intelligence Community Directive (ICD) 503 - Azure Compliance
Azure Government Top Secret + Office 365 Government Top Secret
Generally speaking, we do not disclose many details on our Top Secret (TS) Cloud Service Offerings (CSO) without an exclusive sponsorship by the US Government, other than what is mentioned in the blog article ‘Azure Government Top Secret now generally available for US national security missions’. That said, TS does have support for JSIG and ICD 503/705 at TS classification levels (e.g. Collateral TS & TS/SCI), like what is described above for Secret.
Appendix
Please follow me here and on LinkedIn. Here are my additional blog articles:
Blog Title |
Aka Link |
Microsoft Collaboration Framework |
|
ND-ISAC MSCloud - Reference Identity Architectures for the US Defense Industrial Base |
|
New! Microsoft Product Placemat for CMMC |
|
Microsoft CMMC Acceleration Update |
|
History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government |
|
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 |
|
Microsoft expands qualification of contractors for government cloud offerings |
|
Microsoft Expands Support for the DIB – Announcing Support for DFARS in Azure Commercial |
|
Microsoft Expands Support for the DIB – Announcing Support for DFARS in Microsoft 365 Government (GCC) |
|
New! Support for DFARS in Microsoft 365 Government (GCC High) |
|
New! Support for FedRAMP in Microsoft 365 Government (GCC High) |
|
Microsoft Federal Successfully Completes Voluntary CMMC Assessment |