Notifications
Clear all
Topic starter
10/07/2026 9:16 pm
TL;DR: Microsoft 365 GCC High can inherit roughly half of the 110 NIST SP 800-171 requirements, but the remaining obligations still depend on customer configuration, evidence, and operational ownership, according to Secureframe. Shared responsibility is not a shortcut to compliance; it is a governance test for whether identity, logging, training, and incident response are actually being run.
NHIMG editorial — based on content published by Secureframe: CMMC Shared Responsibility Model: You vs. Microsoft vs. Your MSP
By the numbers:
- Microsoft can cover nearly half of NIST 800-171 requirements, with 53 of 110 controls inherited in a GCC High deployment.
- 110 NIST 800-171 requirements, 800-171 requirements, or 56, remain a shared responsibility in GCC High.
- 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.
Questions worth separating out
Q: What fails when organisations assume GCC High automatically makes them CMMC compliant?
A: The failure mode is governance drift.
Q: Why do identity controls matter so much in CMMC shared responsibility?
A: Because CMMC evidence often depends on who can access CUI, how privileged access is limited, and whether authentication and review processes are operating as intended.
Q: How do you know whether a shared responsibility matrix is actually working?
A: A working matrix maps each control to a real owner, a real process, and a real evidence source.
Practitioner guidance
- Build a control ownership map before evidence collection Assign every CMMC requirement to Microsoft, the contractor, or the MSP, then document the decision in the SSP and SRM so assessors can trace ownership without ambiguity.
- Verify identity controls beyond tenant defaults Confirm that Conditional Access, MFA, RBAC, and device restrictions are explicitly configured for CUI access, because default GCC High settings do not equal compliant identity governance.
- Turn audit logging into an operating process Define who reviews logs, how often, what events trigger escalation, and how retention aligns to the contract lifecycle, then keep evidence of those reviews.
What's in the full article
Secureframe's full blog covers the operational detail this post intentionally leaves for the source:
- A control-by-control Shared Responsibility Matrix across the 14 NIST SP 800-171 families for GCC High
- Specific examples of what Microsoft inherits versus what the contractor must configure in access, audit, and incident response
- Guidance for documenting MSP responsibilities in the SSP and CRM so assessors can trace ownership
- The article's breakdown of common shared responsibility mistakes and how they show up during a C3PAO assessment
👉 Read Secureframe's CMMC shared responsibility guide for GCC High →
CMMC shared responsibility in GCC High: what teams miss?
Explore further
10/07/2026 9:38 pm
Cloud inheritance is not compliance inheritance. The central mistake in GCC High programmes is treating provider authorization as a substitute for operational control. Microsoft may inherit infrastructure duties, but the contractor still has to configure identity, logging, evidence, and response. That distinction is foundational to CMMC and to any identity programme that depends on cloud boundaries. Practitioners should assume the assessor will test the operating model, not the license label.
A question worth separating out:
Q: Who is accountable when an MSP operates part of the CMMC environment?
A: The contractor remains accountable for demonstrating compliance, even if an MSP performs configuration or monitoring tasks. The MSP can execute work, but it cannot absorb assessment responsibility, answer for gaps it does not own, or replace the contractor’s evidence and oversight.
👉 Read our full editorial: CMMC shared responsibility is bigger than Microsoft 365 GCC High
