Assessment failures rarely start with missing controls. They start with decisions no one wrote down.
CMMC Level 2 assessments that stall inside a Microsoft environment tend to start from the same baseline, not a shortage of controls. Conditional access is enforced, audit logging is active, and identity governance is running on schedule, yet that baseline is not the biggest consideration for whether you pass an assessment.
One of the most common failure points Agile IT sees is whether the explanation the organization gives matches what the documentation over time says, not simply whether someone in the room can articulate why the control exists.
A functioning environment and a defensible one are separate claims, and CMMC Third-Party Assessment Organizations (C3PAOs) only accept the second one to pass assessment. Deployment proves a control exists. It doesn’t prove the organization owns the decision behind it, can reconstruct why the setting was chosen, or can produce a consistent account of how it has operated over time. The current CMMC Program Rule at 32 CFR Part 170, assessed against NIST SP 800-171 Revision 2, tests requirements on exactly that basis: whether something is met, monitored, and evidenced, not whether a setting was switched on.
Four patterns account for most of what surfaces in Microsoft 365 and Azure Government environments during CMMC Level 2 assessments, and none of them are technical: (1) scope inconsistency, (2) evidence gaps, (3) undocumented configuration decisions, and (4) control ownership drift.
Scope Inconsistency
Scope inconsistency is when the asset inventory, System Security Plan (SSP), and network diagram describe the assessment boundary differently. It often surfaces informally first, when IT, compliance, and program leadership give different answers to the same scoping question. The CMMC Level 2 Scoping Guide requires the Organization Seeking Assessment (OSA) to produce three artifacts before assessment starts: an asset inventory, SSP treatment for each asset, and a network diagram of the Assessment Scope. The failure pattern shows up when those artifacts contradict each other, or when the NIST SP 800-171A requirements are examined, interviewed, and tested by C3PAOs and they don’t match the operational reality.
A network diagram marking an asset out of scope, an SSP implying otherwise, and an interview or technical check showing Controlled Unclassified Information (CUI) still flowing through it is the actual failure, not three artifacts describing a boundary differently. That informal disagreement is only the early warning sign. What holds up under review is whether the artifacts and the physical environment still agree once the boundary is on paper.
Tenant architecture decisions compound this. Whether CUI-handling workloads sit in GCC, GCC High, or some hybrid arrangement using enclaves is typically decided early, treated as settled, and never re-examined as new workloads get layered in. A team that assumed a workflow stayed inside GCC High finds during scope validation that a shared mailbox or a line-of-business app now routes CUI through commercial tenant infrastructure. The architecture wasn’t wrong when it was built. It was never validated against how the environment actually operates, and the boundary on paper stopped matching the boundary in practice well before assessment prep started asking pointed questions.
Once a mismatch like this surfaces, the instinct is often to fix it by expanding the boundary defensively rather than resolving why the artifacts disagreed in the first place. That doesn’t address what actually broke down. Over-scoping to compensate wastes capital on systems that never needed to sit inside the boundary. Under-scoping leaves the exact gap an assessor is trained to find. Neither substitutes for a scope decision that was made once, documented, and repeated the same way across every artifact an OSA is required to produce.
Evidence Gaps
Evidence gaps surface once a control is confirmed to be working exactly as intended and the assessor moves to the next question anyway:
- Why does this conditional access policy exclude a specific group?
- Why was legacy authentication retained for one application after being disabled everywhere else?
- Why does an exception exist for a break-glass account?
These are ordinary operational decisions, and most Microsoft environments carry dozens of them. The issue is never that the decision was wrong. It’s that the decision exists only as a configuration setting, with no record tying it to the requirement it satisfies or the person who approved it.
The same gap opens between the SSP narrative and what the environment currently reflects. An SSP might describe a conditional access requirement one way while the deployed policy has since been modified to accommodate a vendor exception, a merger, or a new business unit, and the narrative was never updated to match. The control still functions correctly. The evidence package no longer agrees with itself, and an assessor reading the SSP against the live tenant finds the mismatch before anyone explains the exception that caused it.
A working policy is the baseline assessors start from, not what earns a passing result. Whether the conditional access policy behaves as configured is rarely in question; what’s tested is whether the explanation for why it’s configured that way matches the documentation already on file for it, not just whether someone can articulate a reason when asked. Security tools generate data. A documented decision trail is what turns that data into evidence, and that distinction is the entire basis on which NIST SP 800-171 assessment objectives operate.
Undocumented Configuration Decisions
Conditional access, audit log retention, and identity governance carry the heaviest share of this exposure in Microsoft environments, because each one requires an ongoing decision rather than a one-time activation.
Audit log retention configured in Microsoft Purview means little to an assessor without the decision record tying the retention interval to the requirement it’s meant to satisfy. Identity governance access reviews running on schedule mean little without documented ownership of what happens when a review flags access that never gets revoked. Conditional access exceptions accumulate for legacy systems, specific roles, and vendor accounts over time, and each one needs a decision behind it that can be produced independent of who happens to be explaining it that day.
Each of these three settings carries the same structural weakness. The technical control and the governance decision behind it live in two different places: one inside the Microsoft admin center, and one that’s supposed to exist in policy, a risk acceptance memo, or an SSP appendix. When only the technical side gets maintained, the environment continues operating correctly while the governance record goes stale, and the two versions drift apart without anyone noticing until an assessor asks for both.
The configuration has to hold up as its own witness. If the explanation only exists in one person’s memory, it isn’t evidence yet. It’s an assumption that hasn’t been tested.
Control Ownership Drift
Control ownership drifts when responsibility for a control changes over time without the supporting documentation changing with it. In Microsoft environments, administration is frequently divided across infrastructure, security, compliance, and managed service providers. A conditional access policy may be created by one team, reviewed by another, and monitored by a third. The control continues operating as intended while accountability becomes increasingly difficult to demonstrate during assessment.
The gap usually appears when an assessor asks who owns the control, who reviews it, who approves exceptions, and where those decisions are documented. Different answers from different stakeholders become evidence that ownership was never maintained consistently. The control itself remains functional. The governance record describing responsibility no longer reflects the environment as it exists on the day of assessment.
The same pattern develops as organizations add business units, inherit legacy systems, or reorganize administrative responsibilities. Documentation often reflects the environment that existed when the control was implemented rather than the one operating today. Shared responsibility across Microsoft, internal teams, and external service providers adds another layer of complexity when governance records do not clearly define where one responsibility ends and another begins.
Ownership becomes part of the assessment evidence alongside the technical control itself. Microsoft 365 and Azure Government centralize identity, access, compliance, and governance functions, but responsibility for those controls is often distributed across multiple teams. The technical configuration can remain unchanged while the documented ownership behind it gradually diverges from operational reality, leaving multiple accounts of the same control for an assessor to reconcile.
Why the Gap Surfaces Now
In July 2026, the Department of War (DoW, formerly DoD) suspended CMMC Phase 2 requirements and opened a review of the program. That pause changes timing, not exposure. DFARS 252.204-7012, NIST SP 800-171 compliance, and SPRS self-assessment scores remain contract requirements while the review runs, and the gaps described above exist regardless of the enforcement schedule.
For subcontractors carrying a prime’s compliance warning, this exposure doesn’t resolve the same way it did under self-assessment. C3PAO certification versus self-assessment is set by contract terms, not by prime or sub status, and DFARS 252.204-7020 flows the applicable level down regardless of tier. Which situations call for a C3PAO assessor and which don’t still come down to what the specific contract requires. Phase 1 gave DoW Program Managers discretion to require Level 2 (C3PAO) in place of self-assessment on individual contracts, and individual contracts can still carry that requirement today. Organizations that treat the suspension as a reason to stop preparing will meet the same gaps when enforcement resumes, on someone else’s timeline.
Confused about C3PAO requirements after the DoW announcement?
Read our breakdown of the Phase 2 suspension.
Self-attestation absorbed a certain amount of internal inconsistency, because the organization was answering its own questions. Third-party assessment doesn’t work the same way. A C3PAO assessor has no context for why a scope decision was made, no history with the environment, and no reason to fill in gaps generously. The assessor works from the SSP, the assessment objectives, and whatever the organization can produce in the room. The inconsistency between all of those components becomes a line item, not a conversation.
Where This Leaves an Organization
Assessment doesn’t create these gaps. It reveals decisions that were already made or never formally made at all. It evaluates a boundary, a policy, and a review process exactly as they exist on the day the assessor arrives (not as they were intended to exist).
Organizations that walk into assessment with a defensible position aren’t the ones with more controls than everyone else. They’re the ones who settled scope, evidence, and configuration ownership before a C3PAO forced the question, which means the validation happened on their timeline instead of the assessor’s.
Frequently Asked Questions
Why do CMMC Level 2 assessments fail?
Most CMMC Level 2 assessment failures trace to governance gaps, not missing controls. The four most common patterns in Microsoft environments are scope inconsistency across required artifacts, evidence gaps behind working controls, undocumented configuration decisions, and control ownership drift. Each one leaves an assessor with accounts that do not agree, even when the environment itself is functioning correctly.
Does GCC High guarantee CMMC compliance?
No. GCC High is a tenant decision, not a certification. It provides the infrastructure to meet requirements tied to CUI and ITAR data, but assessment outcomes depend on how the environment is scoped, configured, documented, and evidenced. An organization can fail an assessment inside GCC High and, depending on contract requirements and data types, pass outside of it.
What evidence do C3PAO assessors require?
C3PAO assessors work from the NIST SP 800-171A assessment objectives, which means every requirement is examined, interviewed, and tested. Expect to produce a current System Security Plan, an asset inventory, a network diagram of the Assessment Scope, and decision records tying each configuration to the requirement it satisfies. A control that works but has no documented decision behind it is a finding waiting to happen.
Is CMMC still required after the Phase 2 suspension?
Yes. The Department of War suspended CMMC Phase 2 requirements in July 2026 pending a program review, but that pause changes timing, not obligation. DFARS 252.204-7012, NIST SP 800-171 compliance, and SPRS self-assessment scores remain contract requirements, and individual contracts can still require third-party certification. Organizations that treat the suspension as a reason to stop preparing will face the same gaps when enforcement resumes.
Looking for support? A strategy session is where we look at where you are and determine what the right next step is, whether that’s a gap analysis, a mock assessment pressure test, or building out what’s missing, before an assessor makes that determination for you. Schedule a strategy session.
