What CMMC Level 2 Means for Microsoft 365 GCC High Environments
Understand what CMMC Level 2 requires in Microsoft 365 GCC High environments, including NIST 800-171 alignment, cloud responsibilities, and assessment readiness.

Why it matters now
For IT and compliance leaders at U.S. defense contractors, the path to CMMC Level 2 is not a matter of flipping a few switches. It’s a fundamental change in how you structure and govern your Microsoft 365 environment. You cannot configure your way into compliance. No amount of conditional‑access policies, encryption, or logging will make a commercial Microsoft 365 tenant Level‑2‑compliant. Level 2 compliance is a boundary and accountability issue. When export controlled CUI, such as ITAR or EAR, is in scope, it requires U.S.‑only data centres and personnel; for other CUI types, Level 2 may be achievable on GCC if FedRAMP Moderate equivalency is met. In every case, strict tenant isolation and audit‑ready evidence remain non‑negotiable.
Level 2 introduces 110 security requirements across 14 families, not the 15 basic safeguarding requirements under FAR 52.204‑21 for Level 1 plus a few extra settings. It mandates continuous evidence of how you control access, handle data, manage changes, and detect incidents, and those controls must apply to every system and person in scope. Achieving Level 2 is not about toggling features; it’s about sustained governance and documentation that will stand up to an assessor’s scrutiny.
Agile IT insight: Configuration alone won’t close the gap
Many organizations come to us believing that deploying GCC High or enabling a few extra policies will “check the box.” In reality, the underlying environment must be scoped correctly, and evidence must be gathered for each control. We routinely see migrations stall because teams can’t prove where data lives or who had access during cutover. A configuration change can’t fix a scoping error.
Level 2 is not Level 1 plus encryption and logs
CMMC Level 1 focuses on safeguarding Federal Contract Information (FCI) with 15 basic safeguarding requirements. Level 2 extends to Controlled Unclassified Information (CUI) and aligns completely with NIST SP 800‑171 Revision 2, which defines 110 security requirements across 14 families. These requirements include:
-
Access control and separation of duties: You must restrict who can view, modify or administer CUI and enforce least privilege at every layer. It’s not enough to enable multifactor authentication (MFA); you need documented role definitions, approval workflows, and evidence of periodic access reviews.
-
Audit and accountability: Logging must be comprehensive and tamper‑resistant. Assessors will ask to see audit trails showing when privileged actions occurred, who performed them, and whether events were reviewed. You can’t provide that evidence if logs weren’t enabled or retained.
-
Configuration and change management: Level 2 requires a documented baseline and a formal process to review, approve, and record changes. Improvised changes or undocumented scripts undermine your ability to show control.
-
Incident response, media protection, and system & communications security: You must have a tested incident‑response plan, policies for removable media and encryption, and controls to protect data in transit and at rest. Assessors will expect to see records of exercises, debriefs, and updates.
Agile IT insight: Most failures are scoping errors**
Our mock assessments reveal that the majority of “failures” aren’t due to missing a specific tool; they’re due to incorrectly scoping the environment. Contractors often include systems that aren’t necessary or exclude systems that handle CUI, leading to incomplete coverage. Fixing scope late in the process is expensive and delays contracts.
Why many contractors choose GCC High
GCC High provides an environment built on Azure Government with physically isolated data centers and U.S.‑only support personnel. This segregation is necessary for organizations subject to International Traffic in Arms Regulations (ITAR), Export Administration Regulations (EAR) or DoD contracts that require CUI handling. GCC High also offers tenant isolation: customer content resides in a separate cloud region, and Microsoft staff are subject to U.S. citizenship and background screening.
However, moving to GCC High does not, by itself, satisfy Level 2. It simply provides the boundary conditions needed to implement NIST 800‑171. You still need to build identity, access control, logging, and governance on top of that platform. Not every contractor handling FCI or modest amounts of CUI needs GCC High. Level 1 organizations can remain in GCC or commercial tenants if they limit scope to FCI and implement basic safeguarding. If you handle CUI or anticipate Level 2 requirements, you should plan the migration early to avoid re‑work.
Agile IT insight: GCC High isn’t a drop‑in replacement
We often see organizations migrate to GCC High thinking it’s a “plug‑and‑play” replacement for commercial M365. They quickly discover that many workloads (Teams integrations, Power Automate flows, third‑party apps) must be rebuilt, and identities require re‑mapping. Factor this complexity into your timeline and budget.
Shared responsibility across the stack
Compliance in GCC High is a shared responsibility. Microsoft provides the infrastructure controls, data‑center security, hardware, hypervisor isolation, and some baseline services—but customers own the configuration and evidence. This means you must:
-
Define which systems and personnel are in scope for CUI. Over scoping increases cost and complexity. Under‑scoping by excluding facilities, devices, or personnel that process, store, or transmit CUI can lead to missing assets in your CMMC assessment. If new projects or contracts introduce additional CUI types or systems, you may have to expand the scope and undergo a new Level‑2 assessment to remain compliant.
-
Implement and institutionalize policies, procedures, and technical configurations for each of the 110 requirements. Policies should be documented, managed, and performed consistently with clear evidence that these practices are ingrained in day‑to‑day operations. Tools like Entra ID Conditional Access and Privileged Identity Management enable least‑privilege, but you must configure them correctly, assign roles, document approvals, and capture logs to prove enforcement.
-
Maintain documentation such as a System Security Plan (SSP) and a Plan of Action & Milestones (POA&M). Assessors will read them to understand how you meet each requirement and track remediation.
-
Produce evidence on demand. Having logs isn’t enough—you need to demonstrate that you review them, respond to events, and maintain separation of duties.
Agile IT insight: Evidence wins audits
Assessors don’t ask “Do you have MFA?”—they ask “Show me evidence that you enforce MFA and review logs of privileged sign‑ins.” Many contractors fail because they can’t produce documentation or proof of recurring reviews. Building automated evidence collection into your processes saves time and mitigates risk.
Mapping key control families to GCC High
Instead of listing product features, think in terms of control objectives, configuration responsibilities, and evidence. Below is a high‑level mapping for several core domains:
| Control family | Contractor responsibilities | Evidence expected |
|---|---|---|
| Access Control (AC) | Define roles and separation of duties; implement least-privilege assignments using Entra ID RBAC; enforce Conditional Access and MFA; control remote access and restrict use of portable storage. | Role definitions and assignment logs; Conditional Access policy documents; review records showing periodic recertification and approval; logs of session locks, terminations and unsuccessful logon attempts. |
| Audit & Accountability (AU) | Enable and centralize logs across Azure AD, Exchange, SharePoint, Endpoint Manager and security tools; maintain a reliable time source; protect and retain logs; review them regularly and respond to anomalies. | SIEM or log-aggregation reports showing collection from in-scope systems; documented procedures for log review; incident tickets showing follow-up on audit findings. |
| Configuration Management (CM) | Establish baseline configurations; document and review changes; require approval for modifications; enforce least functionality on systems; manage applications and user-installed software. | Change-control tickets; configuration baselines; records of security-impact analysis; evidence of removed non-essential services; updated SSP and POA&M entries. |
| Identification & Authentication (IA) | Ensure unique identities for users and devices; enforce multi-factor authentication; restrict password reuse; use certificates for machine-to-machine authentication. | Identity inventory; MFA configuration snapshots; access logs showing MFA events; password policy documentation. |
| Incident Response (IR) | Develop and test an incident-response plan; define roles and communication channels; perform regular tabletop exercises; document lessons learned. | Incident-response playbooks; records from exercises; improvement plans; evidence of plan reviews and updates. |
| System & Communications Protection (SC) | Encrypt data in transit and at rest; segment networks; isolate test environments; monitor external connections and wireless networks. | Encryption key management procedures; network diagrams; firewall and VPN configurations; penetration-testing reports. |
This list isn’t exhaustive, but it illustrates that compliance is about process and proof, not just technology. Each domain requires you to design controls, configure services and produce verifiable evidence.
Agile IT insight: Product features don’t equal compliance
We often hear, “We’ve purchased E5 or GCC High; doesn’t that cover Level 2?” The tools are necessary but not sufficient. Without proper scoping, configuration and documentation, they remain unused or mis‑used, and you still won’t pass an assessment.
Common gaps and pitfalls
Even with GCC High and a control framework in place, contractors often fall short in these areas:
-
Overreliance on default settings. Assuming Microsoft’s defaults meet NIST 800-171 leads to missing controls (e.g., unconfigured conditional access, unmonitored event logs or unencrypted backups).
-
Missing documentation and evidence. Teams implement policies but don’t record approvals, periodic reviews or incident responses. Lack of documentation is one of the first findings auditors flag.
-
Weak separation of duties. Assigning Global Administrator rights to multiple users without justification violates least-privilege principles. Audit trails must show that high-risk actions require multiple approvals.
-
Incomplete incident-response testing. Plans exist on paper but are not exercised. Assessors ask for evidence of drills, lessons learned, and updates.
-
Insufficient change management. Configuration changes are made without formal review or approval; cross-tenant migrations are executed without tracking who did what and why.
-
Neglecting endpoints and removable media. Level 2 extends to laptops, phones and USB devices. Failing to control or encrypt them creates scope gaps.
Agile IT insight: Don’t let “unknown unknowns” sink you
In pre‑assessment workshops, we often uncover systems, integrations or storage locations that were forgotten in scoping. A single shared mailbox or third‑party connector can pull an entire workload into scope. Inventory thoroughly and revisit scope regularly.
Preparing your environment and team
Achieving Level 2 is a program, not a project. To prepare:
-
Define scope and boundaries. Identify which systems, sites, users, devices, and data are in scope. Err on the side of including too much during discovery; refine as you validate.
-
Perform a gap assessment. Compare your current controls against the 110 requirements. Document what’s missing and create a remediation plan.
-
Build your SSP and POA&M. Document how each requirement is met, who is responsible, and what evidence you collect. Use the POA&M to track remediation tasks and deadlines.
-
Train your team. Everyone who touches CUI or operates inside your compliance boundary needs to understand what your policies require and be able to demonstrate they follow them under review. Documented practices that aren’t consistently performed don’t survive assessment scrutiny. Training closes the gap between what the SSP says and what the environment actually does.
-
Conduct tabletop and technical tests. Exercise your incident response, restore from backups, simulate account compromise, and practice change-control processes. Capture lessons learned and update documentation.
-
Engage qualified partners. AOS-G-authorized and Cyber-AB-accredited providers can guide you through GCC High licensing, migration planning, control implementation, and evidence collection. Choose partners who provide opinions and validation, not just tools.
Agile IT insight: Start sooner than you think
With CMMC 2.0 assessments on the horizon and DFARS 252.204‑7021 clauses already appearing in contracts, the runway is short. Level 2 readiness can take six to twelve months depending on your scope and maturity. Procrastination results in rushed remediation and missed deadlines.
Conclusion & next steps
CMMC Level 2 is a structural and operational challenge—not a quick configuration fix. It requires rebuilding your environment within the appropriate boundary, implementing the 110 CMMC security requirements that align with NIST SP 800‑171 Rev 2 and are tailored to protect Controlled Unclassified Information (CUI) on non‑federal systems, and producing audit‑ready evidence. GCC High provides the necessary isolation and residency, but compliance remains your responsibility. The common pitfalls are scoping errors, missing documentation, and insufficient testing.
To put this into practice, validate whether your GCC High tenant is truly Level‑2‑ready and request an assessment readiness call with Agile IT to identify gaps and confirm that your environment meets NIST SP 800‑171 and CMMC 2.0 requirements. We’ll help you scope correctly, implement controls and build the evidence needed to satisfy auditors and protect your contracts.






