Here is one of the most pernicious misconceptions in CMMC compliance: a defense contractor purchases Microsoft 365 GCC High licenses, tells their leadership "we're on the government cloud now," and believes the hard work is done.

It is not.

As a FedRAMP High-authorized cloud platform that supports meeting NIST SP 800-171 Rev 2 requirements, Microsoft GCC High gives organizations seeking certification (OSC) a strong head start on CMMC compliance. But it does not get them to the finish line. 

Microsoft will not configure your Conditional Access policies. Microsoft will not run your security awareness training. Microsoft will not show up to your C3PAO assessment and answer for your incident response plan.

Microsoft will however provide infrastructure and security capabilities needed to protect CUI. You (the OSC) are responsible for configuring those capabilities, implementing your own policies, and demonstrating compliance to a C3PAO assessor through documentation and evidence.

That is what the CMMC shared responsibility model is about.

What is the Microsoft shared responsibility model for CMMC?

The Microsoft shared responsibility model defines which security tasks Microsoft as the cloud provider handles and which tasks you as the organization handle. Under CMMC, a document called a Shared Responsibility Matrix (SRM) formally documents who is accountable for each of the 110 NIST SP 800-171 Rev 2 requirements (and their 320 assessment objectives) in your cloud environment to properly secure CUI. This document may also be referred to as a Customer Responsibility Matrix (CRM).

In a typical Microsoft GCC High deployment, there are at least two parties involved—sometimes three if an MSP is involved. Responsibilities are split between them:

1. Microsoft: The cloud platform provider, responsible for infrastructure security, data center physical controls, and certain technical controls “inherited” from its FedRAMP authorization
2. You (Organization seeking certification): The defense contractor, ultimately accountable for proving compliance with all 110 requirements
3. Your MSP/MSSP: A managed service provider or managed security service provider who may handle some implementation tasks on your organization’s behalf

Sharing responsibility with a cloud service provider at least (if not also an MSP) offers significant advantages for solving long standing information security challenges that are particularly acute for DIB organizations that need CMMC. These include limited resources and unmet responsibilities that leave your organization vulnerable to attackers, such as insufficient backup and disaster recovery.

Image source: Microsoft documentation on shared responsibility in the cloud

How responsibility is divided in Microsoft GCC High for CMMC

For CMMC Level 2, all 110 requirements and 320 AOs, and the controls needed to fully meet them, falls into one of three categories:

1. Inherited responsibility from Microsoft: The control is implemented at the platform level. Meaning, Microsoft's FedRAMP authorization covers it so you “inherit” the control from Microsoft. You can claim the control without additional implementation (but you must document this inheritance in your System Security Plan).
2. Shared responsibility: The platform provides technical capability, but your organization must configure it, use it, and prove it is working. Both parties have a role in complying.
3. Customer responsibility: Microsoft has no role. The control is entirely yours.Think: policies, procedures, physical security, personnel management, and training.

The critical point, which C3PAO assessors will hold you to: being on GCC High does not automatically satisfy any control.

• Even inherited controls require documentation.
• Even shared controls require active configuration. 
• And customer controls require you to implement them from scratch.

In other words, CMMC compliance cannot be fully inherited. But it can be shared, and therefore simplified, with the right cloud service provider. 

For a deeper look at what GCC High is and why it matters for CMMC, see our GCC High overview.

1. What Microsoft covers (Inherited Controls)

Microsoft 365 GCC High is FedRAMP High authorized, which means Microsoft has independently validated the security of its infrastructure to one of the most rigorous government standards.

Since NIST 800-171 Rev 2 (the security standard that CMMC Level 2 uses) is a subset of NIST SP 800-53 (the standard that FedRAMP uses), the Microsoft implementation of FedRAMP requirements help ensure Microsoft in-scope cloud services meet or exceed the requirements of NIST SP 800-171.

So when you use GCC High, you inherit Microsoft's controls on:

• Physical and environmental security: Data centers with controlled access, CCTV, biometric authentication, and 24/7 monitoring
• Configuration management: DoD-grade network segregation keeping your data in U.S.-based, U.S.-personnel-only facilities 
• Media protection at the hardware level: Encrypted storage, secure disposal of decommissioned hardware
• Maintenance at the hardware level: Physical maintenance of servers, storage systems, and networking infrastructure (excluding endpoints like laptops)
• Platform-level cryptography: FIPS 140-2 validated encryption modules for data at rest and in transit
• Availability and redundancy: High-availability infrastructure, disaster recovery at the platform tier
• Continuous monitoring of the platform: Microsoft monitors infrastructure-level security events

These are controls where Microsoft does the work and you “inherit” them. So your only responsibility is to document the inheritance correctly in your System Security Plan (SSP).

This is an important caveat. When Microsoft covers a control at the infrastructure level, what that means is that the platform is capable of supporting the requirement. Your C3PAO assessor will review your SSP to confirm you understand which controls are inherited and from whom. Simply saying "Microsoft handles it" with no documentation is not sufficient.

You need a Shared Responsibility Matrix that references the specific controls, Microsoft's FedRAMP authorization, and how that inheritance flows into your compliance posture.

How many controls does Microsoft provide?

While the exact control coverage depends on your licensing, enabled services, and service model, you can meet nearly half of NIST 800-171 requirements (53 of 110) with inherited controls from Microsoft if using GCC High as your cloud-native environment for CUI. 

Note the following disclaimer from Microsoft: Customers must individually determine the necessary steps required to ensure their organization fully satisfies each recommended CMMC compliance practice, in addition to or in place of what is described in program resources. This responsibility spans all Microsoft (Azure, Microsoft 365, etc.) consumption decisions, including, among other things, which Microsoft offerings to procure, as well as all configuration decisions associated with such use and consumption.

2. What you must configure as the OSC (Shared Controls)

This is where most defense contractors underestimate the work involved. Roughly half (56) of the 110 NIST 800-171 requirements are a shared responsibility in a GCC High cloud environment. 

That means GCC High provides the capability to meet the requirement, but you must configure (and document) it properly to actually comply.

Think of it this way: Microsoft gives you a toolbox. You have to use the tools.

Here are the control families where most requirements are a shared responsibility:

Access Control (AC)

GCC High includes Entra ID (previously called Azure Active Directory) now with full support for Conditional Access policies, role-based access control (RBAC), and multi-factor authentication. None of these are pre-configured for your environment. You must:

• Build and enforce Conditional Access policies that require MFA for all users accessing CUI
• Define and assign roles with least-privilege access to SharePoint, Teams, Exchange
• Configure sign-in risk policies that block or challenge suspicious logins
• Restrict access to CUI from non-compliant or unmanaged devices

In other words, leaving Entra ID in its default configuration means you’ll have significant gaps in your access controls, regardless of what license you purchased.

Check out our complete configuration guide for NIST 800-171 Access Control in GCC High.

Audit and Accountability (AU)

Microsoft Purview provides a unified audit log across Microsoft 365. By default, audit logging is enabled for most workloads in GCC High, but you still must:

• Define which logs you review, how frequently, and who is responsible
• Configure log retention periods appropriate to your contract lifecycle
• Set up alerts for high-risk events (privilege escalation, mass downloads, failed logins)
• Document your log review process in your SSP

An audit log that no one reviews is not an effective operating control. C3PAO assessors test this by asking you to show them audit log review records and demonstrate what happens when an anomaly is detected.

Check out our complete configuration guide for NIST 800-171 Audit & Accountability in GCC High.

System and Communications Protection (SC)

GCC High supports data encryption in transit and at rest. Microsoft Purview also provides:

• Data Loss Prevention (DLP) but you must write the DLP policies that define what counts as CUI and what to block
• Sensitivity Labels but you must design your label taxonomy, publish labels to users, and train users on how to apply them
• Information Barriers but you must configure them if your use case requires it
• Network boundary configurations you must define the architecture (what is in-scope vs. out-of-scope for CUI)

Check out our complete configuration guide for NIST 800-171 System & Communications Protection in GCC High.

Identification and Authentication (IA)

GCC High supports FIPS 140-2 compliant authentication. You must enforce it. That means:

• Ensuring all authenticators used in your environment are FIPS-compliant
• Configuring password complexity and rotation policies through Azure AD
• Enforcing phishing-resistant MFA for privileged accounts where CMMC requires it
• Managing service account credentials and certificate-based authentication

Check out our complete configuration guide for NIST 800-171 Identification & Authentication Controls in GCC High.

System and Information Integrity (SI)

GCC High provides malware protection and security alerting capabilities, but you are responsible for configuring alerts, reviewing security event data, and acting on anomalies.

The bottom line on shared controls: every control in this category represents a decision your organization must make, a policy your organization must write, and a configuration your organization must implement and maintain. Purchasing the license is Step 0. The actual work starts after that.

Check out our complete configuration guide for NIST 800-171 System & Information Integrity in GCC High.

The bottom line on shared controls: Every control in this category represents a decision your organization must make, a policy your organization must write, and a configuration your organization must implement and maintain. Purchasing the license is only one step. The actual work to fully implement these NIST 800-171 requirements starts after that.

3. What is entirely on you (Customer Controls)

Depending on the license, a GCC High deployment may only have 1 of the 110 NIST 800-171 high-level requirements fall entirely to the customer.

This is CM.L2-3.4.8, which covers the restriction of the use of organization-defined software to execute on customer-deployed resources in accordance with established blacklisting and whitelisting policies.

Image source: Microsoft Product Placemat for CMMC 2.0 (Preview)

However, when looking at all 110 requirements and 320 assessment objectives of NIST 800-171 Rev 2, then the number of controls that the customer is entirely responsible for is substantially larger.

These controls are related to your organizational policies, physical premises, people management, and operational procedures. No GCC High license, regardless of tier, provides this coverage.

These assessment objectives that can only be met with customer controls primarily fall into the following CMMC domains:

• Awareness and Training (AT): While GCC High provides a platform that can support training delivery, your organization is responsible for actually executing the program. Read the complete configuration guide for AT. 
• Incident Response (IR): GCC High can detect events and generate alerts, but responding to those events is your responsibility. Read the complete configuration guide for IR. 
• Personnel Security (PS): Your employment practices (such as defining and following a screening process to authorize employee access to CUI) are your responsibility. Read the complete configuration guide for PS. 
• Risk Assessment (RA): You must conduct and document periodic risk assessments of your own environment. Read the complete configuration guide for RA. 
• Security Assessment (CA): You must periodically assess the security controls in your own environment and document and track any remediation in a Plan of Action and Milestones (POA&M). Read the complete configuration guide for CA. 

These operational responsibilities cannot be inherited from or shared with your cloud provider. But they can be shared with a managed service provider, or simplified with a compliance automation vendor like Secureframe. We’ll deep dive into what can be outsourced after the high-level SRM represented in the table below. 

Shared Responsibility Matrix: All 14 NIST 800-171 Families

The table below shows the general responsibility distribution of all 110 high-level requirements across the 14 NIST SP 800-171 control families in a GCC High deployment.

We confirmed these numbers by double-clicking on all 110 requirements to view the GCC HIGH coverage listed in the CMMC Practice details table in the Microsoft Product Placemat for CMMC 2.0 (Preview). Note that this only reflects the high-level requirement categorization.

To see which assessment objectives within each family that are inherited vs. shared vs. customer-only, you need to access Microsoft's Customer Responsibility Matrix (CRM) through the Microsoft Service Trust Portal or request it by email. Your SSP should reference this document and map it to your specific system boundary.

We confirmed these numbers by double-clicking on all 110 requirements to view the GCC HIGH coverage listed in the CMMC Practice details table in the Microsoft Product Placemat for CMMC 2.0 (Preview). Note that this only reflects the high-level requirement categorization.

To see which assessment objectives within each family that are inherited vs. shared vs. customer-only, you need to access Microsoft's Customer Responsibility Matrix (CRM) through the Microsoft Service Trust Portal or request it by email. Your SSP should reference this document and map it to your specific system boundary.

We confirmed these numbers by double-clicking on all 110 requirements to view the GCC HIGH coverage listed in the CMMC Practice details table in the Microsoft Product Placemat for CMMC 2.0 (Preview). Note that this only reflects the high-level requirement categorization.

To see which assessment objectives within each family that are inherited vs. shared vs. customer-only, you need to access Microsoft's Customer Responsibility Matrix (CRM) through the Microsoft Service Trust Portal or request it by email. Your SSP should reference this document and map it to your specific system boundary.

How an MSP fits into the Shared Responsibility Matrix (+ the Risks of Over-Delegating)

Many defense contractors rely on a managed service provider (MSP) to handle their IT environment. MSPs can play a legitimate and valuable role in CMMC compliance, but only if the relationship is structured correctly and documented thoroughly.

Here is what MSPs can legitimately take on:

• Managing the GCC High tenant configuration (Conditional Access, Intune baselines, sensitivity labels)
• Running your SIEM and monitoring security logs on your behalf
• Managing endpoint detection and response (EDR) tools
• Providing incident triage and first-response support
• Maintaining patching and configuration management for endpoints

Here is what MSPs cannot do:

• Be CMMC certified on your behalf. You, the OSC, must achieve CMMC certification yourself. It cannot be delegated to or “inherited” from an MSP.
• Take accountability for controls your MSP does not have visibility into. If you have physical security gaps, personnel screening gaps, or training gaps, those are yours regardless of what your MSP contract says.
• Testify to a C3PAO assessor. When the assessor asks "who reviews your audit logs and how often?", your staff must be able to answer that question with evidence to show that they understand and participate in the process, not your MSP.

The documentation requirement is using an MSP

Under CMMC, if an External Service Provider (ESP) handles any part of your CMMC control implementation, that relationship must be documented in detail in your System Security Plan. The CMMC final rule allows ESPs to be assessed alongside an OSC, but only if the SSP clearly delineates what the ESP is responsible for vs. what the OSC retains.

Vague language like "our MSP handles security" will not satisfy an assessor. Your SSP must specify, for each assessment objective where the MSP is involved:

• Which specific task the MSP performs
• How you verify the MSP is performing it
• What evidence exists that it has been performed

The over-delegation risk of using an MSP

One of the most dangerous compliance mistakes is an organization that has genuinely delegated a CMMC control to an MSP, but has no way to verify or provide evidence that the MSP is actually doing the work. For example, say your SIEM alerts fire and your MSP is responsible for reviewing them, but you have no ticketing records, SLA reports, or documented reviews. Then you have a gap in your documentation, and the C3PAO assessor will find it.

If your MSP says "we handle CMMC" as a blanket offering, ask them to show you the Shared Responsibility Matrix. Ask which of the 110 requirements and 320 assessment objectives they implement, which they share with you, and which are entirely yours. If they cannot answer at that level of specificity, you are at risk.

How a C3PAO will assess “shared” compliance

When a Certified Third-Party Assessor Organization (C3PAO) conducts your CMMC Level 2 assessment, they are not assessing Microsoft. They are assessing you.

The SSP is your primary document of compliance. A well-documented, properly structured SSP that accurately reflects your actual environment (including which controls are inherited from Microsoft and/or what your MSP handles) and is supported by evidence is the foundation of a successful assessment.

An assessment involves three assessment methods: examine, interview, and test. All three are aimed at your organization, not at your cloud service provider or MSP (if you use one).

1. Examine: The assessor reviews your SSP, policies, procedures, configuration screenshots, logs, training records, and the Shared Responsibility Matrix. They will check that the SRM exists, that it accounts for all 110 requirements and 320 assessment objectives, and that it matches what you have actually implemented.
2. Interview: The assessor talks to your staff, including IT administrators, system owners, security leads, and end users. They ask questions like: "Walk me through what happens when an employee is terminated" or "Show me how you know when an unauthorized login attempt occurs." Microsoft or your MSP cannot answer these questions on your behalf.
3. Test: The assessor attempts to verify that controls work as described. This includes inherited and shared controls as well as the controls you are fully responsible for. They may attempt to access a system without MFA to see if it blocks them. They may request evidence that DLP policies are active. They may ask to see a recent incident log review.

That means:

• If your Conditional Access policies are not configured, regardless of your license tier, you will not fully meet the Access Control requirements.
• If your training records do not show documented completion, you will not fully meet the Awareness and Training requirements.
• If your incident response plan has never been tested, you will not fully meet the Incident Response requirements.

For help identifying your gaps before an assessment, see our CMMC gap analysis guide. 

"We thought we were CMMC compliant": 5 Common Shared Responsibility Mistakes

These are the patterns that appear consistently when organizations fail CMMC assessments or conduct their first gap analysis and find significant gaps they did not expect:

"We bought GCC High so we're covered"

GCC High provides the environment with some controls already in place that fulfill some CMMC requirements for you. But ultimately, you provide the compliance.

Without configuring Conditional Access, enabling MFA enforcement, deploying Intune baselines, writing DLP policies, classifying data with sensitivity labels, and implementing dozens of other configurations, GCC High is a compliant-capable platform that is not operating in a compliant way.

"Our MSP handles CMMC"

An MSP can implement some technical controls on your behalf. But they cannot be responsible for your policies, cannot answer assessment questions about your internal procedures, cannot own the physical and personnel security controls that are entirely your responsibility, and cannot perform the assessment or certify you.

If your SSP is not specific about what your MSP does and does not do, you have documentation gaps that will surface during assessment.

"We have MFA so access control is done"

MFA is one requirement within Access Control. The AC family has 22 requirements covering account management, least privilege, session controls, remote access, privileged user controls, and more. Passing MFA enrollment does not satisfy the family.

"We enabled audit logging"

Enabling logging is a prerequisite. The actual requirements are to review logs, investigate anomalies, protect log integrity, and retain logs for an appropriate period. A log that sits in storage unreviewed is not a functioning control.

"Our MSP wrote our SSP"

An SSP written by an MSP or consultant is not a guarantee of compliance. If they do not deeply understand your business, your data flows, your physical environment, and your personnel practices, then it will contain inaccuracies that will become findings during an assessment. Even if they do have this deep understanding, then the SSP may still not accurately reflect your environment by the time of your assessment if they use spreadsheets and manual processes to build it. Or your team won’t be able to answer the assessor’s questions about the SSP if the process was completely outsourced. 

Your SSP must accurately describe your current environment, including all the controls your vendors do NOT handle, and be clearly understood and explained by your team to successfully pass a C3PAO assessment. 

Building your CMMC Shared Responsibility Matrix

Creating a Shared Responsibility Matrix is not optional for organizations using cloud services in their CMMC boundary. The CMMC assessment guidance requires that for each assessment objective, it is clear who is responsible (you, your cloud provider, or your MSP).

Here is the process for building one:

Step 1: Download or request Microsoft's CRM

To access the Customer Responsibility Matrix for Microsoft GCC High, you can access it through the Service Trust Portal if you have an active deployment or request it by email. This document maps each NIST SP 800-171 requirement and assessment objective to one of three responsibility categories: Microsoft, Customer, or Shared. Start here.

Step 2: Map your MSP's scope

Review your MSP contract and service catalog. For each control where your MSP performs implementation work, document: which specific task the MSP performs, how you monitor their performance, and what evidence they provide. Your MSP should supply a description of their implementation for each control they own — this feeds directly into your SSP.

Step 3: Identify the gaps

The controls that are neither inherited from Microsoft nor covered by your MSP are entirely yours to implement. These are your remediation priorities. Many organizations discover at this stage that training, incident response, risk assessment, and security assessment programs do not exist in any formal way.

Step 4: Document in your SSP

For each of the 110 requirements and 320 AOs, your SSP should identify the responsible party, describe the implementation, and reference the evidence. For inherited controls, reference the Microsoft CRM and FedRAMP authorization. For MSP-managed controls, reference your MSP's SSP contribution and your verification process. For customer-only controls, describe your internal program in sufficient detail for an assessor to understand and verify it.

Step 5: Keep it current

The SRM is a living document. When your CSP or MSP changes their service offerings, when you move workloads in or out of scope, or when you add new systems to your CMMC boundary, the SRM must be updated. An assessor reviewing a SRM will verify it reflects current reality and know if it’s stale.

Simplify CMMC shared responsibility with Secureframe Defense

CMMC compliance doesn't happen by simply buying the right cloud license or security tool. It's built control by control by your organization and your cloud service provider (and managed service provider, if you work with one). 

Secureframe Defense maps your GCC High environment directly to all 110 NIST 800-171 requirements, automatically pulls evidence from your Microsoft 365 tenant, and shows you exactly which controls are met, which need configuration, and which require operational work (like policies). 

Your shared responsibility matrix is built into the platform so you always know who owns what. Learn more about Secureframe Defense for CMMC by visiting our website or talking to an expert.